Министерство образования и науки РФ
Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования
Уфимский государственный авиационный технический университет
Методическое пособие
по дисциплине
"Объектно-ориентированный анализ "
по направлению подготовки бакалавров
080800 «Прикладная информатика »
(очной формы обучения)
Кафедра: автоматизированных систем управления
Составитель: ______________ Р.Р. Еникеев
2009
СОДЕРЖАЕНИЕ
Введение..................................................................................................................3
1. Краткий обзор объектно-ориентированного анализа........................................5
2. Концепции информационного моделирования..............................................11
3. Жизненные циклы объектов............................................................................23
4. Динамика связей...............................................................................................43
Введение
При традиционном подходе, характеризуемом лавинообразным нарастанием сложности, в цикле создания программного продукта условно выделяется пять этапов, анализ, проектирование, программирование, тестирование и сборка.
Недостатки этой до недавнего времени общепринятой схемы: непригодность для разработки сложных программных систем и организации процесса внесения в систему последующих изменений, обязательное последовательное выполнение всех этапов разработки, несовместимость с эволюционным подходом и перспективными методами разработки
Предлагаемая Вашему вниманию книга известных американских специалистов Шлеер и Меллора "Объектно-ориентированный анализ, моделирование мира в состояниях" (Sally Shiaer and Stephen J Mellor "Object Lifecycles- Modeling the World in States", Prentice-Hall, 1992) посвящена изложению самых первых этапов разработки сложных программных систем. В ней детально описан один из наиболее нетривиальных элементов объектного подхода - объектно-ориентированный
Книга Шлеер и Меллора "Объектно-ориентированный анализ моделирование мира в состояниях" является наиболее удачным и компактным изложением метода ООА и с выдающейся книгой Гради Буча "Объектно-ориентированное проектирование с примерами применения" (совместное издание фирмы "Диалектика" и АО "И В К", 1992 г ) дает полное представление об объектно-ориентированной методологии как инструменте преодоления сложности разрабатываемых систем
С выходом в свет этой книги наша скудная литература по ООМ получает не просто описание одной из самых современных и наиболее популярных версий ООА - ООА Project Technology, - но и тщательно продуманное руководство по использованию этого метода, содержащее множество важных вспомогательных соображений
Поскольку книга предназначена в первую очередь для программистов-профессионалов и всех, кто занимается программированием, то во многих случаях сохранена профессиональная терминология, принятая во многих коллективах, где из-за информационного голода и дефицита отечественной литературы по данной тематике в основном приходится работать с оригинальной документацией на иностранном языке.
Предмет объектно-ориентированный анализ (ООА) - метод для отождествления важных сущностей в задачах реального мира, для понимания и объяснения того, как они взаимодействуют между собой. Этот метод, используемый главным образом в контексте программной пли системной инженерии, лучше всего описывается в три этапа
Информационные модели. На этом этапе центральным является абстрагирование концептуальных сущностей в задаче в терминах объектов и атрибутов. Отношения между сущностями формализуются в связях, которые основываются на линиях поведения, правилах и физических законах, превалирующих в реальном мире. Этот этап обсуждается в "Object Oriented Systems Analysis. Modeling the Word in Data"(Prentice Hall, 1988), и в этой, родственной книге при водится лишь его краткий обзор.
Модели состояний. Второй этап метода связан с поведением объектов и связей во времени. В ООА каждый объект и связь имеет жизненный цикл - регулярную составную часть динамического поведения. Мы используем модели состояний для формализации жизненных циклов, как объектов, так и связей Модели состояний, которые выражаются в переходных диаграммах и таблицах, взаимодействуют между собой посредством событий, их организовывают в уровни, чтобы сделать систему взаимодействия упорядоченной и понятной.
Модели процессов. Все процессы, связанные с задачей, заключены в действиях моделей состояний. Здесь, на третьем этапе метода, действия расчленяются на фундаментальные процессы и многократно используемые и изображаются усиленной формой традиционных диаграмм потоков данных (ДПД) - ДПД действий. Получаемые таким образом процессы в дальнейшем могут быть преобразованы непосредственно в операторы (методы) объектно-ориентированного проектирования.
Хотя изначально ООА определялся как метод для анализа задач реального времени (и поэтому упор делался на согласование синхронных взаимодействий с асинхронными и одно временностью), сегодня мы находим его пригодным как для MIS-приложений, так и для задач реального времени. Мы знаем, что метод успешно и широко применялся в различных областях, включающих банковские операции, производство самолетных двигателей, печатных плат, полупроводников и других подобных изделий, моделирование сценариев сражений, дистанционно управляемые летательные аппараты, телекоммуникационные системы, оформление кредитных карточек, развитые компьютерные периферии, создание качественных баз данных, лаборатории искусственного интеллекта и медицинские инструменты
Несмотря на то, что ООА может быть представлен достаточно формализовано всецело из определений, теорем и лемм, мы целенаправленно адресовали его программистам профессионалам и всем, кто занимается программированием, и поэтому излагаем это представление в виде примеров, руководящих принципов, которые могут быть усвоены довольно быстро. Для того чтобы этот метод повседневно использовался на практике, мы описали рабочие продукты ООА более детально. Опыт показывает, что внедрение метода в эффективную практику происходит намного легче, если для создания программного продукта программисты имеют четкое понимание то. О, что они делают. И, наконец, мы привели простой организационный фрейм для проектного планирования, составления графиков, текущей оценки развития и других ежедневных технических задач управления подобного рода
История создания ООА
Создание ООА началось с анализа части большого проекта реального времени в 1979 г. в Лаборатории Беркли. В этом проекте мы широко применяли информационные модели, как для статических, так и для динамических данных Мы использовали статические модели для исследования отдельных задач, но эти модели не выглядели как стандартная часть проектной методологии. Также использовались диаграммы потоков данных в стиле де Марко, и все данные, которые приводились на них, находились в определенном соотношении с информационной моделью.
С 1980 до 1984 г. мы применяли информационное моделирование в нескольких широкомасштабных проектах реального времени. В начале 1985 г мы уже пользовались моделями состояний для моделирования жизненных циклов информационных моделей объектов. Диаграммы потоков данных, став более близко связанными с моделями состояний, объединили архивы данных, которые именно так отображали информационные модели объектов. В 1986-1987 гг. мы разделили диаграммы потоков данных на соответствующие состояния жизненных циклов и добавили модель отношений объектов. Да лее метод был систематизирован в учебный курс ООА Project Technology и получил одноименное название как аналог анализа проектной и программной технологии, которая потом развилась в объектно-ориентированную общность.
Что нового?
С 1987 г данный метод анализа развивался преимущественно в двух направлениях, во-первых, совершенствовались руководящие принципы для разделяющих действий, для того чтобы гарантировать, что получаемые таким образом процессы имеют определенные желаемые свойства, и, во-вторых, разрабатывались специальные высокоуровневые диаграммы, которыми можно было бы пользоваться при работе с моделями на больших проектах. Кроме того, были произведены определенные улучшения, направленные на внесение ясности в представление некоторых понятии и на увеличение возможностей нахождения элементов графических моделей. Для тех пользователей, которые открывают для себя метод ООА посредством нашей консультативной практики, учебных курсов или публикаций, мы делаем обобщение того нового, что есть в "ООА91"
Информационные модели. Объекты сейчас кроме номеров определяются ключевыми буквами, что делает их понятнее при корреляции различных элементов моделей. Соглашение о нумеровании связей добавлено для поддержки корреляции элементов модели и для того, чтобы способствовать пониманию графической репрезентации информационной модели. Мы также отказались от таблицы корреляций как сущности формализации. Она изначально виделась как педагогический прием, нацеленный на облегчение понимания ассоциативного объекта, но благодаря студентам наших учебных курсов выяснилось, что такое улучшение положения является не только ненужным, но и сбивающим с толку. Поэтому мы соединили два понятия в более общем ассоциативном объекте.
Модели состояний. Монитор моделей состояний, предварительно используемый для формализации динамики конкурирующих связей был обобщен и появился в ООА91 как особый случай более общей модели состояния Определителя Внесена ясность в содержание жизненных циклов для объектов подтипов и супертипов. По требованию наших нынешних клиентов объект Таймер развивался, чтобы стать элементом формализации, он больше не рассматривается как объект, который поставляется пользователем. И, наконец, для обозначения событий развивалось альтернативное соглашение. Несмотря на то, что это не так существенно, мы считаем, что новое, основанное на их предназначении обозначение событий намного облегчает хранение следа событий
Модели процессов. Наиболее значительные изменения произошли на этапе моделирования процессов. Руководящие принципы были сформулированы для внесения действий в отдельные процессы, для наименования процессов и для их описания. Порядок выполнения процессов сейчас сохраняется на диаграммах потоков данных действий, и на них в нарядной форме представлены условные выводы. И наконец, решена давно существующая (и семантически значимая) проблема с диаграммами потоков данных каким образом обозначать поток данных между двумя процессами, имеющими совершенно различные взгляды на смысл данных
Что дальше?
Последние несколько лет работали над методами преобразования моделей ООА в проекты различных типов. Эта работа, известная как рекурсивное проектирование RD. Обратите внимание на то, что это проектирование не единственно возможное решение. Одно из преимуществ RD заключается в том, что оно предоставляет инженеру широкий выбор и контроль над типом проектирования