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


Презентация изнутри:

Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

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


Слайд 33

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


Слайд 34


Слайд 35

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


Слайд 36

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


Слайд 37

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


Слайд 38

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


Слайд 39

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


Слайд 40

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


Слайд 41

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


Слайд 42

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


Слайд 43

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


Слайд 44

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


Слайд 45

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


Слайд 46

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


Слайд 47

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


Слайд 48

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


Слайд 49

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


Слайд 50

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


Слайд 51

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


Слайд 52

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


Слайд 53

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


Слайд 54

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


Слайд 55

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


Слайд 56

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


Слайд 57

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


Слайд 58

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


Слайд 59

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


Слайд 60

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


Слайд 61

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


Слайд 62

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


Слайд 63

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


Слайд 64

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


Слайд 65

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


Слайд 66

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


Слайд 67

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


Слайд 68

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


Слайд 69

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


Слайд 70

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


Слайд 71

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


Слайд 72

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


Слайд 73


Слайд 74

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


Слайд 75

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


Слайд 76

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


Слайд 77

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


Слайд 78

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


Слайд 79

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


Слайд 80

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


Слайд 81

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


Слайд 82

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


Слайд 83

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


Слайд 84

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


Слайд 85

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


Слайд 86


Слайд 87

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


Слайд 88

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


Слайд 89

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


Слайд 90

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


Слайд 91

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


Слайд 92

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


Слайд 93

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


Слайд 94

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


Слайд 95

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


Слайд 96

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


Слайд 97

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


Слайд 98

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


Слайд 99

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


Слайд 100

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


Слайд 101

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


Слайд 102

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


Слайд 103

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


Слайд 104

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


Слайд 105

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


Слайд 106

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


Слайд 107

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


Слайд 108

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


Слайд 109


Слайд 110

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


Слайд 111

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


Слайд 112

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


Слайд 113

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


Слайд 114

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


Слайд 115

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


Слайд 116

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


Слайд 117

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


Слайд 118

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


Слайд 119

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


Слайд 120


Слайд 121

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


Слайд 122

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


Слайд 123

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


Слайд 124

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


Слайд 125

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


Слайд 126

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


Слайд 127

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


Слайд 128

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


Слайд 129

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


Слайд 130

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


Слайд 131

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


Слайд 132

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


Слайд 133

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


Слайд 134

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


Слайд 135

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


Слайд 136

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


Слайд 137

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


Слайд 138

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


Слайд 139

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


Слайд 140

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


Слайд 141

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


Слайд 142

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


Слайд 143

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


Слайд 144

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


Слайд 145

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


Слайд 146

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


Слайд 147

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


Слайд 148

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


Слайд 149

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


Слайд 150

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


Слайд 151

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


Слайд 152

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


Слайд 153

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


Слайд 154

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


×

HTML:





Ссылка: