Анализ и проектирование на UML - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Анализ и проектирование на UML, слайд №1

Анализ и проектирование на UML, слайд №2

Анализ и проектирование на UML, слайд №3

Анализ и проектирование на UML, слайд №4

Анализ и проектирование на UML, слайд №5

Анализ и проектирование на UML, слайд №6

Анализ и проектирование на UML, слайд №7

Анализ и проектирование на UML, слайд №8

Анализ и проектирование на UML, слайд №9

Анализ и проектирование на UML, слайд №10

Анализ и проектирование на UML, слайд №11

Анализ и проектирование на UML, слайд №12

Анализ и проектирование на UML, слайд №13

Анализ и проектирование на UML, слайд №14

Анализ и проектирование на UML, слайд №15

Анализ и проектирование на UML, слайд №16

Анализ и проектирование на UML, слайд №17

Анализ и проектирование на UML, слайд №18

Анализ и проектирование на UML, слайд №19

Анализ и проектирование на UML, слайд №20

Анализ и проектирование на UML, слайд №21

Анализ и проектирование на UML, слайд №22

Анализ и проектирование на UML, слайд №23

Анализ и проектирование на UML, слайд №24

Анализ и проектирование на UML, слайд №25

Анализ и проектирование на UML, слайд №26

Анализ и проектирование на UML, слайд №27

Анализ и проектирование на UML, слайд №28

Анализ и проектирование на UML, слайд №29

Анализ и проектирование на UML, слайд №30

Анализ и проектирование на UML, слайд №31

Анализ и проектирование на UML, слайд №32

Анализ и проектирование на UML, слайд №33

Анализ и проектирование на UML, слайд №34

Анализ и проектирование на UML, слайд №35

Анализ и проектирование на UML, слайд №36

Анализ и проектирование на UML, слайд №37

Анализ и проектирование на UML, слайд №38

Анализ и проектирование на UML, слайд №39

Анализ и проектирование на UML, слайд №40

Анализ и проектирование на UML, слайд №41

Анализ и проектирование на UML, слайд №42

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Анализ и проектирование на UML. Доклад-сообщение содержит 42 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Слайд 2

Описание слайда:

Модель поведения — это описание алгоритма работы системы. В 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 сводится к описанию параллельных потоков управления и способов взаимодействия между ними.

Слайд 24

Описание слайда:

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

Слайд 25

Описание слайда:

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

Слайд 26

Описание слайда:

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

Слайд 27

Описание слайда:

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

Слайд 28

Описание слайда:

Моделирование параллелизма Пусть у нас определены два класса: 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 можно описать с помощью диаграммы объектов, на которой показано, как должны измениться связи между объектами в результате выполнения операции. В данном описании контекста рассматривается типичный сценарий, в котором до выполнения операции сотрудник занимает некоторую должность, а целевая должность вакантна.

Слайд 33

Описание слайда:

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

Слайд 34

Описание слайда:

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

Слайд 35

Описание слайда:

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

Слайд 36

Описание слайда:

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

Слайд 37

Описание слайда:

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

Слайд 38

Описание слайда:

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

Слайд 39

Описание слайда:

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

Слайд 40

Описание слайда:

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

Слайд 41

Описание слайда:

Слайд 42

Описание слайда:

Выводы Диаграммы для моделирования поведения позволяют связать диаграммы структуры и диаграммы использования. По сути в процессе моделирования поведения создаётся модель системы.

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

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