Объектно-ориентированное проектирование ИС

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

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

В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language),

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 1. Диаграмма прецедентов использования (Use – case diagram), которая отражает функциональность ИС в виде совокупности выполняющихся последовательностей транзакций; 2. Диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов (аналогична диаграмме «сущность – связь» )

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий; 4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 5. Диаграммы деятельности (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы); 6. Диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим системам (могут декомпозироваться на более детальные диаграммы);

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода; 8. Диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.

Интегрированная модель сложной системы в нотации UML

Функциональный анализ может представлять собой основу для объектно-ориентированного проектирования. Элементы структур данных из диаграммы потоков данных могут являться кандидатами в классы в диаграммах классов. ПРИМЕР

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

Диаграмма прецедентов использования Прецеденты использования (бизнес-процессы) инициируются из внешней среды пользователями – актерами ИС. Примеры актеров: клиенты, поставщики, инвесторы, государственные органы. На этом уровне моделирования не раскрывается механизм реализации процессов

Вводятся следующие графические обозначения: Актер – внешний пользователь процесса. Прецедент использования (бизнес-процесс) Актер инициирует выполнение прецедента использования (бизнес-процесса) и получает от него результаты.

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

При наименовании прецедентов используют либо глагол, либо существительное, обозначающее действие. Эквивалентные прецеденты использования

Выделяют три группы актеров: пользователи системы; другие системы, взаимодействующие с данной системой; время. Время становится актером, если от него зависит запуск каких-либо событий в системе. «actor» как «действующее лицо» или «актор»

Абстрактные актеры и прецеденты Цель – подчеркнуть функциональность системы, используемую другими прецедентами. Абстрактные прецеденты связываются с обычными прецедентами отношением обобщения. При этом абстрактный прецедент является предком.

Абстрактные актеры не связываются с прецедентами.

Отношения в диаграммах прецедентов использования отношение ассоциации (association relationship); отношения расширения (extend relationship); отношение включения (include relationship); отношение обобщения (generalization relationship).

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

Направленные и ненаправленные ассоциации

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

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

Отношение расширения Если имеет место отношение расширения, направленное от прецедента А к прецеденту В, это означает, что свойства экземпляра прецедента В могут быть дополнены, благодаря наличию свойств у расширяющего прецедента А.

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

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

Отношение включения Отношение включения, направленное от прецедента А к прецеденту В, указывает, что каждый экземпляр прецедента А включает в себя функциональные свойства прецедента В. Изображается пунктирной стрелкой и направлено к прецеденту, включаемому в более общий прецедент использования.

Отношение включения

Отношение обобщения Отношение обобщения служит для указания того факта, что некоторый прецедент A может быть обобщен до прецедента B. Прецедент A - потомок прецедента B, а B будет считаться предком или родителем прецедента A. Изображается сплошной стрелкой, на конце которой располагается не закрашенный треугольник. Отношение обобщения всегда является направленным, указывая на родительский Элемент.

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

Пример использования отношения обобщения между актерами

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

Предусловия прецедента представляют собой условия, которые должны быть выполнены, прежде чем прецедент начнет выполняться. Постусловиями называются условия, которые должны быть выполнены после завершения прецедента

В реализации прецедента использования возможно выделение нескольких потоков событий: основной поток событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек; альтернативные потоки событий, например временное откладывание или полный отказ от выполнения заказа.

Диаграммы классов объектов (Class diagram) Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов. На диаграмме классов не указывается информация о временных аспектах функционирования системы.

Диаграммы классов объектов (Class diagram) Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов. Классы объектов могут иметь различные стереотипы поведения: объекты – сущности; Пассивный объект, над которым выполняются операции обработки процесса.

Понятие класса Класс в языке UML служит для обозначения множества объектов, которые обладают идентичной структурой, поведением и отношениями с объектами из других классов.

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

Имя класса указывается в верхней части прямоугольника, записывается по центру полужирным шрифтом и должно начинаться с заглавной буквы «Студент», «Компания», «Руководитель», «Клиент», «Продавец», «Менеджер», «Офис» ПРИМЕР:

Атрибуты Атрибуты – это значения, характеризующее объект в его классе, перечисляются в средней части прямоугольника, изображающего класс Атрибуты объектов класса «Счет» баланс кредит Атрибутов объектов класса ««Человек» имя возраст вес

Атрибуты постоянные переменные номер счета, категория, имя человека баланс счета, возраст человека

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

Примерами операций для класса «Файл» – создать, открыть_для_чтения, читать, переименовать, сохранить, закрыть

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

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

Двунаправленные ассоциации рисуют в виде простой линии без стрелок. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление.

Отношение между двумя классами – классом «Компания» и классом «Сотрудник»

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

Пример однонаправленной ассоциации Однонаправленные отношения позволяют выявить классы, являющиеся кандидатами на повторное использование.

Отношение зависимости всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Зависимости изображают в виде стрелки, проведенной пунктирной линией.

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

Отношение агрегации Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой ромб. Этот ромб указывает на тот из классов, который представляет собой «целое».

Отношения агрегации между ПК и его элементами

Отношение композиции Частный случай отношения агрегации. Части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части.

Отношение композиции Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс- композицию или «целое».

Пример использования отношения композиции с указанием кратности

Отношение обобщения описывает иерархическое строение классов и наследование их свойств и поведения При этом предполагается, что класс- потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка.

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

Пример использования отношения обобщения на диаграмме классов

Диаграммы классов объектов (Class diagram) управляющие объекты; Активный объект, координирующий Выполнение функций. интерфейсные объекты. Активный объект, форма взаимодействия ИС с пользователем (меню, кнопка, командная строка).

Фрагмент диаграммы классов объектов Продукт -Код продукта: численный -Название: строковый -Цена: денежный Запас -Код продукта: численный -Текущий запас: численный -Минимум: численный + Уменьшение запаса + Увеличение запаса + Анализ запаса В прямоугольниках в верхней части даны имена классов объектов, в средней части – имена атрибутов, в нижней части – имена операций (методов). 1 1

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

Пакетная технология группировки классов объектов позволяет упростить: разработку и эксплуатацию ИС; гибкую адаптацию типовых компонентов с позиции их повторного использования.

Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в один общий пакет «Проблемная область». Каждый пакет может быть разбит на подпакеты в соответствии с семантической близостью и теснотой взаимодействия классов объектов. Функциональные Обеспечивающие ИС

Обычно пакеты проблемной области содержат обобщения и агрегации. Классы объектов, требуемые в нескольких подсистемах, выделяются в самостоятельные пакеты. В одном пакете, как правило, определяется не более 20 компонентов (обычно 5 – 15).

Выделяют 5 основных пакетов: «Интерфейс», объекты которого реализуют функции взаимодействия пользователей с ИС по вводу-выводу информации и обмен сообщениями между подсистемами; «База данных», объекты которого выполняют доступ к данным во внешней памяти; «Управление задачами», объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов (например, в системе управления рабочими потоками);

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

Графическое представление пакета

Графическое представление отношения вложенности пакетов друг в друга на диаграмме пакетов

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

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

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

Каждое из действий записывается в виде отдельной строки в следующем виде: /

В UML для метки действия определены следующие значения: entry – указывает на действие, которое выполняется в момент входа в данное состояние (входное действие); do – указывает на деятельность, которая выполняется в течение всего времени, пока объект находится в данном состоянии; exit – указывает на действие, которое выполняется в момент выхода из данного состояния (выходное действие).

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

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

С каждым состоянием связано одно или большее количество событий, которые могут его изменить. Таким образом, события инициируют переходы из одних состояний в другие. В качестве событий можно рассматривать: сигналы; вызовы; окончание фиксированных промежутков времени; моменты окончания выполнения определенных действий.

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

Переход состояний графически изображается сплошной линией со стрелкой - Переход состояний

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

Переход состояний описывается следующим набором спецификаций: событие; аргументы; сторожевые условия; действия; посылаемой информацией о событии.

Событие (Event) – это то, что вызывает переход объекта из одного состояния в другое. События размещают на диаграмме вдоль линии перехода. У событий могут быть аргументы Пример: Событие «Выбор суммы», вызывающее переход из состояния «Ожидание выбора клиента» в состояние «Обработка запроса на снятие наличных» может иметь аргумент «Количество», описывающий сумму денежной наличности.

Вызываемые события могут быть: внешними, осуществляемыми актерами; внутренними, связанными с поведением других объектов; временными, связанными с истечением заданного интервала времени.

Сторожевые условия (Guard Condition) определяют, когда переход может быть выполнен, а когда нет. На диаграмме состояний сторожевые условия располагаются вдоль линии перехода и заключаются в квадратные скобки.

Действие – атрибут, информационно описывающий сущность действия, которое должно выполняться при переходе состояний. Действие, выполняемой при переходе размещается вдоль линии перехода после имени события, и ему предшествует косая черта (/). три неудачи / конфискация карточки

Составное состояние Составное состояние – сложное состояние, состоящее из других вложенных в него состояний, называемых подсостояниями.

При этом любое из подсостояний, в свою очередь, может являться составным состоянием и содержать внутри себя другие вложенные подсостояния. Выделяют последовательные и параллельные подсостояния

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

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

Заказ создан Диаграмма состояний для объекта «строка заказа» Заказ оформлен Заказ выполнен Заказ отложен Создание Строки-заказа Создать объект «строка-заказ» Оформление Ввести данные в строку-заказ Откладывание Информировать менеджера Выполнение Уменьшить заказ Уничтожение Удалить строку-заказ

Диаграмма взаимодействия объектов (Interaction diagram) Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм: в форме диаграммы последовательностей (sequence diagram), показывающей последователь- ность взаимодействий на графе; в форме кооперативной диаграммы (collaboration diagram), показывающей взаимодействие объектов в табличной форме.

В диаграмме последовательностей взаимодействие объектов отображается в виде стрелки между объектами, которая соответствует событию или сообщению от одного объекта к другому, вызывающему выполнение метода, реагирующего на событие (сообщение) объекта. Номер стрелки соответствует номеру события в последовательности. Диаграмма последовательности

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

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

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

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

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

Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены. Для таких объектов линия жизни обрывается в момент их уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы «X». Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

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

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

Правила построения диаграммы кооперативного поведения (табличный вид) III. На пересечении строк и столбца вертикально отображается условный отрезок времени, в течении которого выполняется то или иное действие над объектом.

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

объект с именем «клиент», играющий роль «инициатор запроса» анонимный объект, который играет роль инициатора запроса присутствует обозначение класса, при этом объект также является анонимным

Составные объекты На кооперативных диаграммах составной объект изображается как обычный объект, состоящий из двух секций: верхней и нижней. В верхней секции записывается имя составного объекта, а в нижней – его составные части.

Связи Связь как элемент языка UML может иметь место между двумя и более объектами. Связь может иметь некоторые стереотипы, которые записываются рядом с одним из ее концов и указывают на особенность реализации данной связи.

Стереотипы связи «association» – ассоциация (предполагается по умолчанию, поэтому этот стереотип можно не указывать); «parameter» – параметр метода. Соответствующий объект может быть только параметром некоторого метода; «local» – локальная переменная метода. Ее область видимости ограничена соседним объектом; «global» – глобальная переменная. Ее область видимости распространяется на всю диаграмму кооперации; «self» – рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе, изображается петлей в верхней части прямоугольника объекта.

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

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

Графическое представление Графически диаграмма деятельности представляется в форме графа, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому.

Графически состояние действия изображается прямоугольником, боковые стороны которого заменены выпуклыми дугами. Внутри этой фигуры записывается выражение действия, которое должно быть уникальным в пределах одной диаграммы деятельности. Выражение действия Глагол

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний. Действия следуют сверху вниз или слева направо. На диаграмме такой переход из одного состояния действия в другое изображается сплошной линией со стрелкой.

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

Диаграмма деятельности для алгоритма нахождения корней квадратного уравнения

Разделение и слияние В языке UML для разделения и слияния параллельных вычислений используется специальный символ – прямая черта, толщина которой несколько шире основных линий диаграммы деятельности.

Определим используемые в диаграмме деятельности понятия и их графическое обозначение: - Деятельность - Разделение потока на деятельности, выполняемые параллельно или произвольно - Решение - Поток от деятельности к деятельности - Начало

Определим используемые в диаграмме деятельности понятия и их графическое обозначение: - Интеграция - Выход Exit - Синхронизация

Начало [ Не принято ] Конец Разделение на параллельные ветви Слияние параллельных ветвей Выбрать площадку Нанять архитектора Разработать проект Составить смету Выполнить работы по возведению здания Выполнить отделочные и инженерные работы Закончить строительство Состояние действия [ Иначе ]

МОДЕЛИ РЕАЛИЗАЦИИ ОБЪЕКТНО- ОРИЕНТИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

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

Цели разработки диаграммы компонентов визуализации общей структуры исходного кода программной системы; обеспечения многократного использования отдельных фрагментов программного кода; представления концептуальной и физической схем баз данных.

Компонент Для представления физических сущностей в языке UML применяется специальный термин – компонент. Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели.

Для графического представления компонента используется прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Имя компонента

Общепринятые обозначения для компонентов Не специфицированы в языке UML.

Интерфейсы Графически изображается окружностью, которая соединяется с компонентом отрезком линии. При этом имя интерфейса, которое обязательно должно начинаться с заглавной буквы «I», записывается рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.

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

Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу).

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

По способу связи компонента с интерфейсом различают: экспортируемый интерфейс – интерфейс, который реализует компонент и предлагает как услугу клиентам; импортируемый интерфейс – интерфейс, который компонент использует как услугу другого компонента.

Для указания связи компонента и интерфейса рисуют стрелку от компонента-клиента к импортируемому интерфейсу. Компонент не реализует соответствую- щий интерфейс, а использует его в процессе своего выполнения. может присутствовать и другой компонент, который реализует этот интерфейс

Графическое изображение отношения зависимости между компонентами Внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента.

Графическое изображение зависимости между компонентом и классами Изменения в структуре описаний классов могут привести к изменению компонента Согласование логического и физического представлений модели системы.

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

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

Диаграммы размещения Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов.

Диаграммы размещения представляются только компоненты- экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Компоненты, которые не используются на этапе исполнения, на диаграмме размещения не показываются.

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

При разработке диаграммы размещения ставятся следующие цели: определить распределение компонентов системы по ее физическим узлам; показать физические связи между всеми узлами реализации системы на этапе ее исполнения;

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

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

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

Кроме соединений, на диаграмме размещения могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами.

Технологическая сеть проектирования ИС на основе объектно-ориентированной Case-технологии

Анализ системных требований Логическое проектирование Физическое проектирование Реализация Описание орг.структуры Диаг-мы прецедентов использования Диаграммы пакетов Диаг-мы классов объектов Диагр-мы состояний объектов Диагр-мы деятельностей Диагр-мы взаимодействия Диагр-мы состояний Диагр-мы классов объектов Диагр-мы пакетов Диагр-ма размещения компонетов Диагр-ма компонентов Диагр-ма классов объектов Диагр-мы деятельности Классы объектов Процедуры методов

Технологическая сеть анализа системных требований

Разработка диаг-мы классов объектов Разработка диаг-мы пакетов Разработка диаг-мы состояний Разработка диаг-мы прецедентов использования Описание орг.структуры Диаг-ма классов объектов Диаг-ма прецедентов использования Диагр-мы состояний Диагр-ма пакетов

Технологическая сеть логического проектирования

Детализация диаграммы прецедентов использования Разработка диаграммы взаимодействий объектов Уточнение диаграммы состояний Разработка диаграммы деятельностей Детализация диаграммы классов объектов Детализация диаграммы компонентов Диаграмма прецедентов использования Диаграмма состояний Диаграмма классов объектов Диаграмма классов объектов Диаграмма состояний Диаграммы взаимодействий Диаграмма деятельностей Диаграмма пакетов

Технологическая сеть физического проектирования

Спецификация физической реализации диаграммы классов объектов Детализация диаграммы пакетов Разработка диаграммы компонентов Разработка диаграммы размещения Диаграмма классов объектов Диаграмма пакетов Диаграмма пакетов Диаграмма компонентов Диаграмма размещения компонентов

Технологическая сеть реализации ИС

Генерация классов объектов Генерация процедур методов Программирование процедур методов Диаграмма классов объектов Классы объектов Диаграмма взаимодействий Шаблоны процедур методов Диаграмма деятельности Процедуры методов