Объектно-ориентированный анализ и проектирование

Привет, Вы узнаете о том , что такое оо анализ, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое оо анализ, ооа, объектно ориентированный анализ, объектно ориентированный проектирование, канал управления, модель взаимодействия объектов, мво , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.

Содержание

• объектно ориентированный анализ

• Динамика систем, схемы взаимодействия, каналы управления, имитирование

• Диаграмма потоков данных действия. Понятие процесс и потоков управления. Модель доступа к объектам

• Динамическое поведение объектов, понятия состояний, событий, действий состояний, жизненный цикл.

• Концепция информационного моделирования. Понятие классов, атрибутов и связей. Формализация связей.

• Модели доменного уровня, понятие мостов, клиентов, серверов.

Объектно ориентированный анализ

Циклы разработки ПО с использованием ОО проектирования:
Основной этап: оо анализ , больше всего времени. Задача ооа – построение модели системы. На основе построенной модели выполняется проектирование.


Проектирование – перевод модели в проектные документы с помощью CASE-средств.


Эволюция. Написание кода, тестирование, итерирование - ОО подход за счет рекурсивного дизайна, система разворачивается и усложняется. 
Модификация – эволюционирование на готовом продукте, сданном заказчику.

Преимущества рекурсивного дизайна при эволюционировании:

• система постоянно развивается, но всегда готова – обеспечивается обратная связь с заказчиком

• предоставляются разные версии системы – можно откатываться на шаг назад; можно пускать разные версионные ветки
• заказчик постоянно видит результат

• серьезных ошибок не возникает за счет постоянного взаимодействия с заказчиком

• хорошо распределяется время при проектировании

• размеры системы (кода) в принципе не ограничиваются; при структурном же подходе чрезвычайно большая программа при большом количестве разработчиков вызывает проблемы с взаимодействием оных

Изменения в системе в порядке ухудшения сценария:

• проектировать надо так, чтобы добавление классов было безболезненно
• 
изменение реализации класса

• изменение представления класса

• реорганизация структуры классов

• изменение интерфейса класса – самое страшное, тянет за собой кучу изменений в основном коде

Задача анализа – довести модель до такого состояния, чтобы дальше не понадобилось изменять интерфейс.

ОО анализ
В структурном программировании используется принцип черного ящика – мы не думаем о конкретных действиях и данных, а о том что нужно сделать. В ООП – белый ящик, первее всего – данные. Мы выделяем характеристики объектов, и потом уже приходим к тому, как их обрабатывать.

Система разбивается на домены – интерфейс, реализация, сама задача, сервисные функции (например коммуникация) и так далее. Рисуется схема доменов для доменного уровня всей задачи. Для выполнения же этапов анализа рисуется проектная матрица – мы контролируем, какие этапы анализа нами пройдены. 
С доменом, в котором более 150 классов работать тяжело, а на деле – уже даже с более 50. В домене четко выделяются группы классов, между которыми много связей, в то время как между группами связей мало – домен делится на подсистемы, и проектируем вначале подсистемы, а потом реализуем связи.

Для домена строится модель связи подсистем. Выделяются синхронная и асинхронная схемы взаимодействия, соответственно модель доступа к подсистемам (синхронная) и модель взаимодействия подсистем (асинхронная).

Динамика систем, схемы взаимодействия, каналы управления, имитирование

модель взаимодействия объектов ( мво ) – графическое представление взаимодействия между моделями состояний и внешними сущностями. (Строится для каждой подсистемы или домена).

МВО рисуется в овале, внешняя сущность – прямоугольник (именуемый терминатором). События, которые порождаются одной моделью для другой, рисуются стрелкой – так же могут приходить события от внешних сущностей. События могут быть направлены к терминаторам. МВО формируется иерархически – объекты, наиболее осведомленные о всей системе (активные) располагаются вверху диаграммы. Если событие приходит извне к МВО, находящимся вверху, терминаторы рисуются вверху – терминаторы верхнего уровня. Если события уходят или приходят к МВО нижнего уровня, терминаторы рисуются снизу. Может быть схема верхнего и нижнего управления – система ограничена терминаторами сверху или снизу. Надо стремиться к тому, чтобы на верхнем уровне взаимодействие терминатора сводилось к одной модели. С нижним этого ограничения нет – может быть сколько угодно МВО, взаимодействующих с терминаторами нижнего уровня. Как правило на нижнем уровне терминатор (внешняя сущность) может быть физическим объектом, с которым мы работаем. С точки зрения организации МВО, есть более и менее осведомленные объекты; терминаторы в этой иерархии взаимодействуют четко: верхние терминаторы взаимодействуют с осведомленными объектами, нижние с неосведомленными. Противных схем лучше избегать – нужно продолжать формализацию, искусственно выделяя объекты меньшей осведомленности.

Типы событий:

• Внешние события (приходят и уходят от терминатора)
  • Незапрашиваемые события (не являются результатом действий подсистемы)
  • Запрашиваемые (порождаются какой-либо моделью состояний подсистемы)(соединяют одну модель состояний с другой)
• внутренние (соединяют одну модель состояний с другой).

канал управления – последовательность событий и действий, происходящих в ответ на поступление некоторого незапрашиваемого события. Если возникло событие к терминатору, влекущее за собой новые события от терминатора, то они тоже включаются в канал управления.

Процесс имитирования(тесты): понять, насколько правильно была выбрана модель, нет ли ошибок. Необходимо рассмотреть всевозможные начальные состояния объектов подсистемы. Далее, в любом состоянии надо проверить, как подсистема будет реагировать на все незапрашиваемые события, и построить соответствующие каналы управления.

Время имитирования:

• Время выполнения действия;
• Время задержки – время, в течении которого объект должен находится в определенном состоянии (резкий переход из состояния в состояние невозможен).

Этапы имитирования:

• Установка начального состояния
• Прием незапрашиваемого события и выполнение канала управления
• Оценка конечного результата

Диаграмма потоков данных действия. Понятие процесс и потоков управления. Модель доступа к объектам

ДПДД (Диаграмма потоков данных действий) – обеспечивает графическое представление модулей процесса в пределах действия и взаимодействия между ними. Строится для каждого состояния каждого объекта класса.

На диаграмме каждый процесс рисуется овалом. При написании псевдокода выделяется последовательность действий – здесь мы отходим от этого принципа; процесс может выполняться, когда будут доступны все данные, необходимые для его выполнения.

Процессы могут получать данные от других процессов и от каких-либо внешних сущностей.

В случае 1) ,если верхний процесс не выполнился, второй не может выполниться.

В 2), процесс может выполниться, поскольку данные внешних сущностей всегда доступно. То же самое касается атрибутов самого себя

в 3)Результатом процесса могут быть данные, возвращающиеся обратно

Возможно условное выполнение – процесс выполняется в зависимости от условий. Об этом говорит сайт https://intellect.icu . При этом нет передачи данных, а есть условность выполнения – от «условного» процесса рисуется пунктирная стрелочка с указанием условия выполнения, для каждого перехода.

Правила выполнения для ДПДД:

1. процес может выполняться, когда всех входы доступны.
2. выводы процесса доступны, когда он завершает свое выполнение.
3. данные событий (^ просто стрелка сверху) всегда доступны; данные из архивов данных и терминаторов также всегда доступны

Все процессы можно разбить на четыре типа.

• Аксесоры – процессы, которые читают какой-либо атрибут, записывают, создают или уничтожают объекты.
• Генераторы событий – стрелочка наружу процесса.
• Процессы преобразования – выполняют каки-лбо вычисления.
• Процессы проверки – условные переходы.

Каждый процесс нужно четко именовать и описывать. Аксессоры – какие атрибуты считывают или записывют, какие объекты создают или уничтожают. Генераторы событий – результат-событие, метка события. Преобразования – что делают. Проверки – «проверить, что...»

Все процессы в подсистеме объединяются в единую таблицу. В разных действиях могут происходить одни и те же процессы - они будут общими. Общие процессы могут выполнять одну и ту же функцию, читать и записывать и создавать и уничтожать одни и те же объекты, и т.д..

На основе выдленных аксессорных процессов строится модель доступа к объектам. На модели доступа, модели состояний (объектов) рисуются вытянутыми овалами.
Если А использует аксессор модели состояний В,
то рисуется стрелка, А будет аксессором.

Аксессоры реализуются добавлением в объект
действий по записи и чтению атрибутов.

Динамическое поведение объектов, понятия состояний, событий, действий состояний, жизненный цикл.

Можно четко выделить сущности, которые появляются, проходят через отчетливые стадии и прекращают существование. Соответственно, можно представить мир через изменение состояния объектов.

• Многие предметы на протяжение своего существования проходят через отчетливые стадии.

• Порядок перехода из одной стадии в другую (эволюционирование) формирует характерную черту поведения объекта

• Реальный объект находится в единственной стади модели поведния в любой момент времени

• Предметы эволюционируют от одной стадии к другой скачкообразно

• В схеме поведения разрешены не все эволюции между стадиями (самолет стоящий должен вначале взлететь а потом убрать шасси)

• В реальном мире существуют инцинденты, которые заставляют объекты переходить из одной стадии в другую – эволюционировать

Для описания динамического поведения используется модель состояний Мура. Она состоит из множества состояний, множества событий (инциндентов), правил перехода и из действий состояний. Для правил перехода используется либо ДиаграммаПереходовСостояний, либо ТаблицаПереходовСостояний. В реальном мире, состояния разных сущностей (относящихся к разным классам) скоординированы друг с другом. Изменение одного состояния одного объекта приводит к изменению состояний других объектов. Как правило, мы рассматриваем объекты во взаимосвязи друг с другом.

Cостояние – положение объекта, в котором применяется определенный набор правил, линий поведения, физических законов и т.д..

Можно выделить три вида состояний:

• создание - объект появляется в первый раз (может быть несколько). Возникает событие, но не происходит перехода.
• заключительное – 1) объект переходит через стадии и приходит в состояние, из которого других переходов нет; 2) объект уничтожается при переходе в это состояние (рисуется пунктирной линией).
• текущее

Событие – абстракция инцидента или сигнала в реальном мире, которая сообщает о том, что что-либо переходит в новое состояние.

Выделяют четыре аспекта событий:

• значение – короткая фраза, которая сообщает что происходит с объектом.
• предназначение – модель состояний, которую принимает событие. Приемник должен быть один.
• уникальная метка – как правило буква (ключевой литерал сущности/МС) и номер. Если событие внешнее, то помечается буквой Е
• данные события – данные, сопровождающие событие. Каждому состоянию ставится в соответствие действие, которое должно произойти по событию. Событие должно перевести данные для выполнения этого действия.
  • идентифицирующие данные
  • дополнительные данные

Существует ряд правил, связывающих события и данные.

1. Правило тех же данных – все события, которые вызывают переход в определенное состояние, должны нести одни и те же данные.
2. Правило состояний несоздания – если событие переводит объект из состояния в состояние, то оно должно переносить идентификатор объекта.
3. Правило состояния создания – событие, переводящее объект в состояние создания, не несет его идентификатора. Модель скачкообразная. Плавный переход из состояния в состояние можно формализовать несколькими промежуточными состояниями в модели.

Действие – операция, которая должна быть выполнена объектом когда он достигает некоего состояния.

С каждым состоянием связано только одно действие. При формировании ДПС мы стараемся описать действия. Для этого как правило используется псевдокод. Если действие небольшое, то его можно располагать непосредственно под состоянием на диаграмме, если большое – то выносим. Что может выполнять действие: любые вычисления; порождать событие для любого объекта любого класса; порождать событие для чего-либо вне области анализа; выполнять все работы с таймером – создавать\удалять\устанавливать\считывать. Действие может иметь доступ к любым атрибутам любого объекта, как своего так и всех других – читать, записывать.

Однако на выполнение действия накладываются ограничения:

• действие не должно оставить данные противоречивыми.
• действие не должно оставлять противоречивыми связи (если был удален объект, то нужно позаботиться и об удалении\изменении объектов с ним связанных).
• только одно действие может выполняться в данный момент для конкретного объекта; но для разных – действия могут выполняться одновременно.

События могут откладываться до тех пор, пока не будет выполнено действие. Каждое событие прекращается, когда оно «перестает быть» событием.

К выделению МоделиСостояний мы подходим как к формализации асинхронного взаимодействия – происходит инцидент, в результате него объекты меняют состояния. Смена состояния может происходить не мгновенно, а через какое-то время после.

В каких случаях надо выделять жизненные циклы (совокупности состояний)?

• создание и уничтожение объекта во время выполнения
• миграция между подклассами
• накопление атрибутов. С изменением значения атрибута меняется поведение объекта (человек в зависимости от возраста изменяет поведение)
• операционный цикл оборудования (лифт, станок)
• объект производится поэтапно (сборка машины на конвеере)
• если возникают объекты с жизненным циклом, и мы хотим реализовать асинхронную схему взаимодействия, то задача или запрос – тоже имеют жизненный цикл.
• динамические связи. Формализуется ассоциативным объектом, и для него выделяется свой жизненный цикл. Объект, являющийся таким «результатом» связи, стоит на более высоком уровне, лучше осведомлен о состоянии системы.
• если для какого-то объекта мы выделили цикл, но он имеет безусловную связь с другим объектом (пассивным), то жизненный цикл нужно выделить и для этого пассивного объекта.

Концепция информационного моделирования. Понятие классов, атрибутов и связей. Формализация связей.

Концепция

• Выделение сущностей, с которыми мы работаем
• Описание или понятие этой сущности.
  • Выделение атрибутов, каждая характеристика которая является общей для всех возможных экземпляров классов выделяется как отдельный атрибут.
  • Идентификатор – это множество из одного или множества атрибутов, которое определяет класс.
  • Выделение привилегированных атрибутов.
• Выявление связей между сущностями
• Реализация

Для каждой подсистемы:

• Строится описание классов, атрибутов, связей между классами.
• Также строится модель взаимодействия объектов (событийная).
• Модель доступа к объектам.
• Таблица процессов состояний.

Для каждого класса:

• Выделяем модель состояний (модель переходов состояний).

Для каждого состояния каждой модели состояний:

• Строится диаграмма потоков данных действий (ДПДД).

Для каждого действия (процесса):

• Делается описание процесса.

Выделили домен. На подсистемы делить бессмысленно – нужно вначале наполнить его сущностями-классами. Идея информационного моделирования: мы начинаем работать с физическими объектами, которые есть в реальном физическом мире; все остальное появится в результате их анализа. Выделяются физические объекты. Мы пытаемся посмотреть, какими объектами населен домен, и разбить их на группы. Пытаемся выделить характеристики сущностей. Если все объекты имеют одинаковые характеристики, то их можно отнести к одному классу – формируется класс.

Атрибут – каждая отдельная характеристика, являющаяся общей для всех возможных экземпляров классов. Каждый атрибут задается множеством значений, которое важно определить при анализе для определения в дальнейшем типе атрибута.

Идентификатор – то, что четко определяет конкретный объект. Может состоять из одного или нескольких атрибутов. Изменение атрибута не приводит к изменению самого объекта – объект просто меняет «имя», но остается тем же самым.

Выделяют три типа атрибутов:

• Описательные – характеристика, присущая каждому экземпляру класса (вес студента).
• Указывающие – идентификатор или его часть (имя студента).
• Вспомогательные – используются для формализации связей; атрибуты состояния объектов.(если динамическое поведение)

Выделяют четыре правила атрибутов:

• Один экземпляр имеет единственное значения для любого атрибута в любое данное время – не может быть чтобы значений было два, или не было. Если появляется объект с неопределенным значением атрибута, то относить его к этому классу мы не можем – это уже объект другого класса.
• Атрибут не должен содержать никакой внутренней структуры.
• Когда объект имеет составной идентификатор, каждый атрибут-часть идентификатора представляет характеристику всего объекта, а не его части (и тем более не характеристику чего-либо другого).
• Атрибут, не являющийся частью идентификатора, представляет характеристику экземпляра указанного идентификатором, а не характеристику некоторого другого атрибута-неидентификатора. Не должно быть атрибутов, описывающих только часть объекта (атрибут описывающий другой атрибут).

<№><имя>(<к.л>)
* часть_идентификатора
V Атрибут
V Атрибут

Объекты вступают во взаимодействия друг с другом, что нужно формализовать.

Связь – абстракция набора отношений, которая систематически возникает между различными предметами в реальном мире – внутренняя (R) и внешняя (E).

Дальше необходимо выявить множественность связей. С каждой стороны может участвовать один объект, или один с многими, или многие со многими: один к одному, один к многим, многие к многим – виды связей. Учебный курс – студент, МкМ; Преподаватель – Студент, ОкМ.

Иногда с какой-то стороны объект МОЖЕТ не участвовать в связи, тогда связь – условная (преподаватель не руководит студентами – условная связь со стороны преподавателя, т.к. у студента должен быть руководитель, а преподаватель не обязан руководить). Если с обоих сторон объекты МОГУТ не участвовать в связи, то связь – биусловная (УчебныйКурс – Студент; курс не читается в этом семестре, или студент не выбрал этот курс).
Итого – 3 безусловных (ОКО, ОКМ, МКМ), 4 условных ОуКМ, ОКМу, МуКМ, МкМу), 3 биусловных(ОукОу, ОуКМу, МуКМу).

При формализации связи, вспомогательный атрибут добавляется к одному из объектов в связи. При связи ОКМ добавляется атрибут со стороны многих – поскольку атрибут не может содержать внутреннюю структуру. Однако при связи МКМ добавляется так называемый ассоциативный класс, который формализует связь. Собственник может владеть многими квартирами, у квартиры может быть много собственников.

Владение формализует связь. Его адрес и фио четко идентифицируют два объекта, находящихся в связи R1.

Если связь ОКО и один объект удаляется, то второй объект, участвующий в связи, тоже должен быть удален, либо изменен – если жены не будет, то муж станец вдовцом или холостяком. Это будет другой объект другого класса. Если есть условность связи (связь имеет динамичекое поведение), то такая связь должна формализовываться ассоциативным объектом. При этом условность необязательна, достаточно динамики – была одна связь, потом поменялась. Могут возникать ситуации, когда некоторые связи могут являться результатом других связей. Студент – куратор – кафедра. Куратор выбирается с той же кафедры, что и студент.

Жена – муж, ассоциативный объект – свидетельство о браке, может иметь связь с ЗАГСом в котором выдано.

Модели доменного уровня, понятие мостов, клиентов, серверов.

Когда имеется большая система, мы разбиваем задачу на домены.


Прикладные - основные домены, которые решают непосредствено задачу. 


Сервисные домены – обеспечивают функции, необходимые для поддержания прикладного домена, всевозможные сервисные функции.


Архитектурный – домен, отвечающий за архитектуру построения системы (один домен на систему); обеспечивает общие механизмы для управления системы.


Домены реализации – стандартные, библиотечные функции и так далее. Дают возможность легкой замены одной реализации на другую.

Один домен использует возможности и механизмы другого – между этими доменами есть мост. Тот, который предоставляет возможности, называют сервером; использующий – клиентом. Клиент рассматривает мост как набор каких-то предложений, которые кто-то ему представляет. Сервер – набор требований. Диаграмма доменного уровня как правило содержит в верхней части – домены, наиболее осведомленнее о системе (прикладные), внизу – сервисные и реализации.

При разбиении задачи для проектирования каждого домена можно использовать разные технологии. Например в задаче отрисовки, непосредственно рисование – структурный подход, а различные взаимодействия на сцене – объектный. Доменный подход позволяет в дальнейшем легко заменить один домен на другой; сервер рассматривается как набор предложений.

Прикладной домен разбивается на подсистемы, в то время как сервисный – просто набор функций. Для домена, так же как и для подсистемы, рисуется три диаграммы.

• модель связей подсистем (по информационной модели)
• модель взаимодействия подсистем (по МВО)
• модель доступа подсистем (по МДО)
  • Модель доступа к объекта. Стрелочкой помечается идентификатор процесса. Модель взаимодействия – асинхронная, событийная модель. Модель доступа – синхронное взаимодействие (один объект может получить данные другого объекта) В итоге получаем модель доступа к объектам, таблица процессов состояний, диаграмма потомков данных действий.

Циклы разработки ПО с использованием ОО проектирования:
Основной этап: ОО анализ, больше всего времени. Задача ООА – построение модели системы. На основе построенной модели выполняется проектирование.


Проектирование – перевод модели в проектные документы с помощью CASE-средств.


Эволюция. Написание кода, тестирование, итерирование - ОО подход за счет рекурсивного дизайна, система разворачивается и усложняется. 
Модификация – эволюционирование на готовом продукте, сданном заказчику.

Преимущества рекурсивного дизайна при эволюционировании:

• система постоянно развивается, но всегда готова – обеспечивается обратная связь с заказчиком

• предоставляются разные версии системы – можно откатываться на шаг назад; можно пускать разные версионные ветки
• заказчик постоянно видит результат

• серьезных ошибок не возникает за счет постоянного взаимодействия с заказчиком

• хорошо распределяется время при проектировании

• размеры системы (кода) в принципе не ограничиваются; при структурном же подходе чрезвычайно большая программа при большом количестве разработчиков вызывает проблемы с взаимодействием оных

Изменения в системе в порядке ухудшения сценария:

• проектировать надо так, чтобы добавление классов было безболезненно
• 
изменение реализации класса

• изменение представления класса

• реорганизация структуры классов

• изменение интерфейса класса – самое страшное, тянет за собой кучу изменений в основном коде

Задача анализа – довести модель до такого состояния, чтобы дальше не понадобилось изменять интерфейс.

ОО анализ
В структурном программировании используется принцип черного ящика – мы не думаем о конкретных действиях и данных, а о том что нужно сделать. В ООП – белый ящик, первее всего – данные. Мы выделяем характеристики объектов, и потом уже приходим к тому, как их обрабатывать.

Система разбивается на домены – интерфейс, реализация, сама задача, сервисные функции (например коммуникация) и так далее. Рисуется схема доменов для доменного уровня всей задачи. Для выполнения же этапов анализа рисуется проектная матрица – мы контролируем, какие этапы анализа нами пройдены. 
С доменом, в котором более 150 классов работать тяжело, а на деле – уже даже с более 50. В домене четко выделяются группы классов, между которыми много связей, в то время как между группами связей мало – домен делится на подсистемы, и проектируем вначале подсистемы, а потом реализуем связи.

Для домена строится модель связи подсистем. Выделяются синхронная и асинхронная схемы взаимодействия, соответственно модель доступа к подсистемам (синхронная) и модель взаимодействия подсистем (асинхронная).

Вау!! 😲 Ты еще не читал? Это зря!

• DDD
• ООП
• ООД
• ООА
• SOLID

Исследование, описанное в статье про оо анализ, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое оо анализ, ооа, объектно ориентированный анализ, объектно ориентированный проектирование, канал управления, модель взаимодействия объектов, мво и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Объектно-ориентированное программирование ООП