Анализ и проектирование на UML

Содержание

Слайд 2

Модель поведения — это описание алгоритма работы системы. В UML предусмотрено

Модель поведения — это описание алгоритма работы системы.
В UML предусмотрено несколько

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

Диаграммы взаимодействия Диаграммы взаимодействия предназначены для моделирования поведения путем описания взаимодействия

Диаграммы взаимодействия

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

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

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

Диаграммы взаимодействия

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

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

Диаграммы взаимодействия Оба типа диаграмм моделируют поведение "по индукции", от частного

Диаграммы взаимодействия

Оба типа диаграмм моделируют поведение "по индукции", от частного к

общему, путем описания конкретного протокола передачи сообщений (т. е. сценария).
Сильная сторона состоит в том, что в объектно-ориентированной парадигме обмен сообщениями — это и есть само выполнение программы, поэтому протокол передачи сообщений является наиболее точной моделью поведения. Диаграммы взаимодействия находятся "ближе" к реальному выполнению программы, чем другие средства описания поведения.
Слабость диаграмм взаимодействия состоит в том, что это диаграммы описывают поведение на уровне объектов, а не классов, на уровне протоколов выполнения алгоритма, а не самого алгоритма. Диаграммы взаимодействия менее "алгоритмичны", чем машины состояний и диаграммы деятельности.
Слайд 6

Диаграммы взаимодействия На диаграммах обоих типов основными сущностями являются объекты: экземпляры

Диаграммы взаимодействия

На диаграммах обоих типов основными сущностями являются объекты: экземпляры классификаторов

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

Диаграммы взаимодействия Диаграммы кооперации и диаграммы последовательности семантически эквиваленты, хотя графически

Диаграммы взаимодействия

Диаграммы кооперации и диаграммы последовательности семантически эквиваленты, хотя графически выглядят

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

Диаграмма последовательности

Диаграмма последовательности

Слайд 9

Диаграмма кооперации

Диаграмма кооперации

Слайд 10

Зависимость на диаграмме кооперации

Зависимость на диаграмме кооперации

Слайд 11

Поведение приложения Для пользователя поведение приложения проявляется прежде всего в интерфейсе.

Поведение приложения

Для пользователя поведение приложения проявляется прежде всего в интерфейсе.
В принципе

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

Поведение приложения В настоящее время более распространенным, особенно в наиболее массовых

Поведение приложения

В настоящее время более распространенным, особенно в наиболее массовых приложениях

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

Поведение приложения При всех своих достоинствах пассивный интерфейс обладает и определенными

Поведение приложения

При всех своих достоинствах пассивный интерфейс обладает и определенными недостатками,

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

Поведение приложения Событийное управление — это способ структуризации программного кода, основанный

Поведение приложения

Событийное управление — это способ структуризации программного кода, основанный на

следующей идее. Имеется некоторое предопределенное множество поименованных событий.
Слайд 15

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

Поведение приложения

События могут быть явным образом связаны с объектами, а могут

быть связаны неявным образом или быть связаны с неявными объектами, в таком случае события обычно называют системными.
Слайд 16

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

Поведение приложения

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

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

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

Поведение приложения

В программе, целиком управляемой событиями, нет основного потока управления, он

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

Поведение приложения Однако приложения для бизнеса с пассивным пользовательским интерфейсом являются

Поведение приложения

Однако приложения для бизнеса с пассивным пользовательским интерфейсом являются хотя

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

Поведение приложения Поток управления — это последовательность выполнения операторов (команд) в

Поведение приложения

Поток управления — это последовательность выполнения операторов (команд) в программе.


Если программа представляет собой просто последовательность операторов, то операторы в программе выполняются по очереди в естественном порядке (от начала к концу). В этом случае поток управления просто совпадает с последовательностью операторов в программе.
Однако обычно это не так.
Слайд 20

Поведение приложения Во-первых, на поток управления оказывают влияние различные управляющие конструкции:

Поведение приложения

Во-первых, на поток управления оказывают влияние различные управляющие конструкции: операторы

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

Поведение приложения Различаются однопоточные (т. е. с одним потоком управления) и

Поведение приложения

Различаются однопоточные (т. е. с одним потоком управления) и многопоточные

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

Моделирование параллелизма Термин параллельность в программировании, вообще говоря, означает "одновременное" выполнение

Моделирование параллелизма

Термин параллельность в программировании, вообще говоря, означает "одновременное" выполнение нескольких

активностей. Слово "одновременное" в данном контексте означает, что невозможно (или не нужно) указать, какая из активностей происходит раньше другой во времени. Другими словами, параллельные процессы не упорядочены во времени. Тем самым термин "параллельный" противопоставляется термину "последовательный«: последовательные активности упорядочены во времени, причем строго.
Слайд 23

Моделирование параллелизма В UML с каждой параллельно выполняемой активностью связывается поток

Моделирование параллелизма

В UML с каждой параллельно выполняемой активностью связывается поток управления.

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

Моделирование параллелизма Средства описания параллелизма в UML не противопоставлены средствам описания

Моделирование параллелизма

Средства описания параллелизма в UML не противопоставлены средствам описания последовательного

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

Моделирование параллелизма Допустим, что имеются несколько параллельно выполняющих процессов, каждый из

Моделирование параллелизма

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

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

Моделирование параллелизма Если процессы не взаимодействуют, то они независимы и с

Моделирование параллелизма

Если процессы не взаимодействуют, то они независимы и с точки

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

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

Моделирование параллелизма

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

функциональность, т. е. изменения состояния системы.
Слайд 28

Моделирование параллелизма Пусть у нас определены два класса: Position (должность) и Person (сотрудник)

Моделирование параллелизма

Пусть у нас определены два класса: Position (должность) и Person

(сотрудник)
Слайд 29

Моделирование параллелизма У объектов этих классов имеются по два состояния: должность

Моделирование параллелизма

У объектов этих классов имеются по два состояния:
должность может

быть вакантна (Vacant) или занята определенным сотрудником (Occupied) и сотрудник может быть не занят (Free) или назначен на определенную должность (Assigned).
Соответственно, у каждого из классов есть конструктор (new) и деструктор (destroy) и по паре операций, которые ответственны за изменение состояния объекта: у класса Position операции называются occupy (занять должность) и free (освободить должность), а у класса Person — assign (назначить на должность) demote (освободить от должности).
У каждого класса есть скрытый атрибут, предназначенный для хранения ссылки на объект другого класса (т. е. между этими классами существует ассоциация) и предусмотрена операция без побочного эффекта, возвращающая значение данного (getPerson и getPosition, соответственно).
Слайд 30

Моделирование параллелизма Рассмотрим теперь, как должна выполнятся операция назначения сотрудника на

Моделирование параллелизма

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


Мы оставим в стороне вопрос о том, в каком классе разумно определить данную операцию (на самом деле это совершенно не важно).
Положим, что операция назначения сотрудника на должность имеет два параметра — сотрудника и должность:
assignP2P(person:Person,position:Position)
Слайд 31

Моделирование параллелизма Допустим, что требуется обеспечить элементарный порядок в учете кадров

Моделирование параллелизма

Допустим, что требуется обеспечить элементарный порядок в учете кадров (целостность

данных): если сотрудник А назначен на должность Б, то и в должности Б должно быть записано, что ее занимает сотрудник А и наоборот.
Другими словами, занятые должности и сотрудники должны взаимно однозначно соответствовать друг другу, а свободные должности и сотрудники должны быть действительно свободны и не должны содержать неадекватных ссылок друг на друга.
Слайд 32

Моделирование параллелизма Требуемое поведение операции assignP2P можно описать с помощью диаграммы

Моделирование параллелизма

Требуемое поведение операции assignP2P можно описать с помощью диаграммы объектов,

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

Моделирование параллелизма

Моделирование параллелизма

Слайд 34

Моделирование параллелизма Мы видим, что при назначении сотрудника на должность задействованы

Моделирование параллелизма

Мы видим, что при назначении сотрудника на должность задействованы три

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

Моделирование параллелизма Рассмотрим диаграммы машин состояний для Position и Person, соответственно.

Моделирование параллелизма

Рассмотрим диаграммы машин состояний для Position и Person, соответственно. Классы

Position и Person в нашей модели совершенно равноправны и их поведение по отношению друг к другу совершенно симметрично.
Слайд 36

Моделирование параллелизма

Моделирование параллелизма

Слайд 37

Моделирование параллелизма

Моделирование параллелизма

Слайд 38

Моделирование параллелизма В таком случае, требуемая операция назначения сотрудника на должность

Моделирование параллелизма

В таком случае, требуемая операция назначения сотрудника на должность может

быть реализована двумя вызовами операций объектов, являющихся аргументами операции:
position.occupy(person)
person.assign(position)
Слайд 39

Моделирование параллелизма Указанные две операции можно вызвать в любом порядке или

Моделирование параллелизма

Указанные две операции можно вызвать в любом порядке или параллельно,

более того, их можно вызывать с ожиданием возврата управления или без ожидания — в любом случае взаимодействие автоматов обеспечит требуемое поведение (если только в процесс обмена сообщениями не вмешается "посторонний" вызов операции одного из этих объектов).
Слайд 40

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

Моделирование параллелизма

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

Слайд 41

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

Моделирование параллелизма

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

- Предыдущая
общий курс транспорта
Следующая -
Концепции космологии

Похожие презентации

Компьютерное моделирование процессов нанотехнологий 1
Правотворческая инициатива обладающего
Проект «Гольф в школу»
Маккартизм
Презентация "Легенды и сказания Коми народа в иллюстрациях Игнатова В.Г" - скачать презентации по МХК
Презентация по теме: «Плавание» Ученицы 8 Б класса Ярвеской Русской Гимназии Тийны Коппельман 2009 года
Машинаның теңестірілуі
Киіз үй тренингі
Презентация Социологическая концепция П.Сорокина: истоки, формирование, применение.
Методы повышения пропускной способности базовых станций сети lte путем рационального использования ресурсов
Летние Олимпийские игры
Интегративная функция правовой информатики А.Ю. Пустовая (группа Ю-103)
FC Shakhtar. Александр Кравчук
Путешествие в зеленую аптеку
«Сделки. Виды сделок» _
Боже, славимо Тебе. Ф. Гейден (з німецької, XVIII ст.). Відень, 1774
Prezentacja z technologii informacyjnej na temat ćwiczeń w programie Microsoft Excel
Русская изба
Ремонт блока цилиндров
Простой тест
Казанский Базовый Медицинский Колледж ПРЕЗЕНТАЦИЯ Общение с больными на различных этапах медицинской службы. Выполнила
Формирование карманов КМОП (комплементарная структура металл-оксид-полупроводник) интегральных схем. (Лекция 5)
ТОЛЕРАНТНОСТЬ ИНТОЛЕРАНТНОСТЬ социальный педагог ОПСОП по Куйбышевскому району ЦРО г.о. Самара Мищенкова Лариса Петровна
Проблемы физического воспитания студенческой молодежи
МБОУ Щелкансая СОШ Руднянский район Волгоградская область Урок – тренинг во 2 классе по теме: «Орфограммы корня» Автор п
Птицы в СПБ
Meine Heimastadt heist Belgorod
стабилизация, хранение и транспортировка проб. Л.4
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть