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


The Presentation inside:

Slide 0

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


Slide 1

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


Slide 2

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


Slide 3

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


Slide 4

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


Slide 5

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


Slide 6

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


Slide 7

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


Slide 8

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


Slide 9

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


Slide 10

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


Slide 11

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


Slide 12

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


Slide 13

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


Slide 14

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


Slide 15

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


Slide 16

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


Slide 17

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


Slide 18

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


Slide 19

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


Slide 20

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


Slide 21

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


Slide 22

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


Slide 23

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


Slide 24

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


Slide 25

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


Slide 26

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


Slide 27

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


Slide 28

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


Slide 29

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


Slide 30

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


Slide 31

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


Slide 32

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


Slide 33

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


Slide 34


Slide 35

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


Slide 36

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


Slide 37

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


Slide 38

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


Slide 39

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


Slide 40

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


Slide 41

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


Slide 42

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


Slide 43

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


Slide 44

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


Slide 45

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


Slide 46

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


Slide 47

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


Slide 48

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


Slide 49

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


Slide 50

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


Slide 51

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


Slide 52

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


Slide 53

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


Slide 54

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


Slide 55

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


Slide 56

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


Slide 57

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


Slide 58

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


Slide 59

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


Slide 60

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


Slide 61

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


Slide 62

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


Slide 63

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


Slide 64

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


Slide 65

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


Slide 66

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


Slide 67

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


Slide 68

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


Slide 69

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


Slide 70

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


Slide 71

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


Slide 72

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


Slide 73


Slide 74

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


Slide 75

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


Slide 76

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


Slide 77

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


Slide 78

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


Slide 79

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


Slide 80

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


Slide 81

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


Slide 82

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


Slide 83

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


Slide 84

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


Slide 85

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


Slide 86


Slide 87

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


Slide 88

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


Slide 89

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


Slide 90

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


Slide 91

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


Slide 92

Заказ создан Диаграмма состояний для объекта «строка заказа» Заказ оформлен Заказ выполнен Заказ отложен


Slide 93

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


Slide 94

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


Slide 95

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


Slide 96

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


Slide 97

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


Slide 98

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


Slide 99

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


Slide 100

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


Slide 101

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


Slide 102

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


Slide 103

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


Slide 104

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


Slide 105

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


Slide 106

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


Slide 107

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


Slide 108

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


Slide 109


Slide 110

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


Slide 111

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


Slide 112

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


Slide 113

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


Slide 114

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


Slide 115

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


Slide 116

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


Slide 117

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


Slide 118

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


Slide 119

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


Slide 120


Slide 121

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


Slide 122

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


Slide 123

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


Slide 124

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


Slide 125

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


Slide 126

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


Slide 127

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


Slide 128

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


Slide 129

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


Slide 130

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


Slide 131

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


Slide 132

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


Slide 133

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


Slide 134

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


Slide 135

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


Slide 136

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


Slide 137

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


Slide 138

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


Slide 139

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


Slide 140

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


Slide 141

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


Slide 142

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


Slide 143

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


Slide 144

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


Slide 145

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


Slide 146

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


Slide 147

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


Slide 148

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


Slide 149

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


Slide 150

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


Slide 151

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


Slide 152

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


Slide 153

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


Slide 154

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


×

HTML:





Ссылка: