Стадии и этапы создания АИС. Типовое проектирование АИС

Методы и средства проектирования информационных систем и технологий Лекция 2 Этапы проектирования ИС Стадии и этапы создания АИС Стадия 1. Формирование требований к АИС:  обследование объекта и обоснование необходимости создания АИС;  формирование требований пользователей к АИС;  оформление отчета о выполненной работе и тактико-технического задания на разработку. Стадия 2. Разработка концепции АИС:  изучение объекта автоматизации;  проведение необходимых научно-исследовательских работ;  разработка вариантов концепции АИС, удовлетворяющих требованиям пользователей;  оформление отчета и утверждение концепции. Стадия 3. Техническое задание:  разработка и утверждение технического задания на создание АИС. 2 Стадии и этапы создания АИС Стадия 4. Эскизный проект:  разработка предварительных проектных решений по системе и ее частям;  разработка эскизной документации на АИС и ее части. Стадия 5. Технический проект:  разработка проектных решений по системе и ее частям;  разработка документации на АИС и ее части;  разработка и оформление документации на поставку комплектующих изделий;  разработка заданий на проектирование в смежных частях проекта. Стадия 6. Рабочая документация:  разработка рабочей документации на АИС и ее части;  разработка и адаптация программ. 3 Стадии и этапы создания АИС Стадия 7. Ввод в действие:  подготовка объекта автоматизации;  подготовка персонала;  комплектация АИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);  строительно-монтажные работы;  пусконаладочные работы;  проведение предварительных испытаний;  проведение опытной эксплуатации;  проведение приемочных испытаний. Стадия 8. Сопровождение АИС:  выполнение работ в соответствии с гарантийными обязательствами;  послегарантийное обслуживание. 4 Типовое проектирование АИС Типовое проектное решение (ТПР) — это тиражируемое (пригодное к многократному использованию) проектное решение. ТПР классифицируются по уровням декомпозиции системы. Приняты следующие классы:  элементные ТПР. Типовое решение задачи или отдельного вида обеспечения задачи (информационного, программного, технического, технологического, математического, организационного);  подсистемные ТПР. Решение является отдельной функционально полной подсистемой;  объектные ТПР. Типовой проект, включающий полный набор функциональных и обеспечивающих подсистем АИС (для вида деятельности, отрасли и т. п.). ТПР должно содержать не только функциональные элементы, но и документацию с детальным описанием состава компонентов и процедуры настройки в соответствии с задачами проекта. 5 Модельно--ориентированное проектирование Модельно Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой АИС в соответствии с моделью объекта автоматизации. Технология проектирования в этом случае должна обеспечивать единые средства для работы с моделями типовой АИС и автоматизируемого объекта (предприятия). 6 Unified Modeling Language UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля. UML это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UMLмоделей возможна генерация кода. 7 История UML UML собрал в себе черты нотаций Грейди Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh), Айвара Якобсона (Ivar Jacobson) и многих других. 8 Структура UML 9 10 Диаграммы UML Диаграммы делятся на следующие категории: - структурные; - поведенческие. Структурные диаграммы используют для отражения физической организации сущностей в системе, то есть отношений между объектами. Поведенческие диаграммы сконцентрированы на поведении элементов системы. 11 Диаграммы вариантов использования (модели прецедентов) Поведение разрабатываемой системы описывается с помощью функциональной модели, которая отображает: - Системные прецеденты; - Системное окружение (действующих лиц или актеров); - Связи между прецедентами и актерами. Основная задача диаграммы: представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Актеры (кто-то и что-то, что должно взаимодействовать с системой) могут: - Только снабжать информацией систему; - Только получать информацию из системы; - Снабжать информацией и получать информацию из системы. 12 Нотации UML Актер – это кто-то (или что-то) внешний по отношению к компьютерной системе, кто взаимодействует с ней. Графически актер изображается в виде пиктограммы, представляющей человека Актеры делятся на 3 основных типа: - пользователи системы - другие системы, взаимодействующие с данной - время Примерами актеров могут быть сущности, имеющие отношение к концептуальной модели соответствующей предметной области. С помощью прецедентов моделируется диалог между актером и системой. Между актером и прецедентом может существовать ассоциативное отношение. Ассоциативная связь может быть либо двусторонней (от актера к прецеденту и от прецеденту к актеру) либо односторонней. Направление связи показывает кто является ее инициатором (обозначается стрелками на линии связи). 13 Варианты представления актеров 14 Нотации UML Отдельный вариант использования, прецедент это описание множества последовательных событий, выполняемых компьютерной системой, которые приводят к наблюдаемому актером результату. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только имя прецедента. 15 Нотации UML Цель варианта использования заключается в том, чтобы определить законченный аспект или фрагмент поведения некоторой сущности без раскрытия её внутренней структуры. Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая сущность по запросу актера, то есть определяет способ применения этой сущности. Сервис, который инициализируется по запросу актера, представляет собой законченную неделимую последовательность действий. Это означает, что после того как система закончит обработку запроса, она должна возвратиться в исходное состояние, чтобы быть готовой к выполнению следующих запросов. 16 Нотации UML Варианты использования могут применяться как для спецификации внешних требований к проектируемой системе, так и для спецификации функционального поведения уже существующей системы. Множество вариантов использования в целом должно определять все возможные стороны ожидаемого поведения системы. Кроме этого, варианты использования неявно устанавливают требования, определяющие, как актеры должны взаимодействовать с системой, чтобы иметь возможность корректно работать с предоставляемыми сервисами. Для удобства множество вариантов использования может рассматриваться как отдельный пакет. Примерами вариантов использования могут являться следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия. 17 Построение диаграммы Диаграммы вариантов использования описывают функциональное назначение системы или то, что система должна делать. Разработка диаграммы преследует следующие цели:     определить общие границы и контекст моделируемой предметной области; сформулировать общие требования к функциональному поведению проектируемой системы; разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей; подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. 18 Построение диаграммы Актеры взаимодействуют с системой посредством сообщениями с вариантами использования. обмена Сообщение представляет собой запрос актером определенного сервиса системы и получение этого сервиса. Это взаимодействие может быть выражено посредством ассоциаций между отдельными актерами и вариантами использования или классами. С актерами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими актерами. Два и более актера могут иметь общие свойства (взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом). Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей. 19 Нотации UML Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне, без указания их внутренней структуры. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов для актеров. Графический символ отдельного интерфейса соединяется на диаграмме сплошной линией или пунктирной линией со стрелкой с тем вариантом использования, который его поддерживает. Сплошная линия указывает, что связанный с интерфейсом вариант использования должен реализовывать все необходимые для него сервисы. Пунктирная линия со стрелкой означает, что вариант использования предназначен для спецификации только того сервиса, который необходим для реализации данного интерфейса. 20 Нотации UML Примечания (notes) предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. В качестве такой информации могут быть комментарии разработчика, ограничения и помеченные значения. Если в примечании указывается ключевое слово «constraint», то оно является ограничением, налагаемым на соответствующий элемент модели. 21 Нотации UML Между элементами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров актеров и вариантов использования. В языке UML существует несколько стандартных видов отношений между актерами и вариантами использования:  ассоциации (association relationship);  расширения (extend relationship);  обобщения (generalization relationship);  включения (include relationship). 22 Отношение ассоциации Применительно к диаграммам вариантов использования ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. На диаграмме вариантов использования отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь условные обозначения, такие как имя и кратность. Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации:  целое неотрицательное число (включая 0);  два целых неотрицательных числа, разделенные двумя точками;  два символа, разделенные двумя точками (0..*  единственный символ «*»;  если кратность отношения ассоциации не указана, то, по умолчанию, принимается значение равное 1. 5..*); 23 Отношение расширения Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров.  Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом «extend» (расширяет).  Один вариант использования может быть расширением для нескольких базовых вариантов, а также иметь в качестве собственных расширений несколько других вариантов. Базовый вариант использования может дополнительно никак не зависеть от своих расширений. «extend» 24 Отношение обобщения Отношение обобщения служит для указания того факта, что некоторый вариант использования А (потомок) может быть обобщен до варианта использования В (родитель). В этом случае вариант А будет являться специализацией варианта В. Потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой, которая указывает на родительский вариант использования. Отношение обобщения между вариантами использования применяется в том случае, когда необходимо отметить, что дочерние варианты использования обладают всеми атрибутами и особенностями поведения родительских вариантов. Между отдельными актерами также может существовать отношение обобщения. Данное отношение является направленным и указывает на факт специализации одних актеров относительно других. 25 26 Отношение включение Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Один вариант использования может быть включен в несколько других вариантов, а также включать в себя другие варианты. Включаемый вариант использования может быть независимым от базового варианта (он предоставляет ему некоторое инкапсулированное поведение, детали реализации которого скрыты и могут быть перераспределены между несколькими включаемыми вариантами использования). Базовый вариант может зависеть только от результатов выполнения включаемого в него поведения, но не от структуры включаемых в него вариантов. «include» 27 Пример диаграммы вариантов использования для банковского автомата 28 Пример диаграммы вариантов использования 29 Пример диаграммы вариантов использования 30 Диаграммы использования Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования. Цель - представить совокупность проектируемой системы. требований к поведению Спецификация требований к проектируемой системе в диаграммы вариантов использования представляет самостоятельную модель. форме собой Большая часть вариантов использования формируется на этапе исследования проекта, однако в ходе дальнейшей работы можно обнаружить дополнительные особенности. Каждый вариант использования является потенциальным требованием к системе, и пока оно не выявлено, не возможно перейти к планированию его реализации. 31 Диаграммы использования Некоторые разработчики вначале: - составляют перечень вариантов использования и обсуждают их, - приступают к моделированию. Концептуальное моделирование с участием пользователей помогает выявить варианты использования.  Важно помнить, что варианты использования служат внешним представлением системы. 32 Диаграммы использования Сколько вариантов использования следует сформировать?  Некоторые эксперты по вариантам использования утверждали, что для проекта с трудоемкостью 10 человеко-лет необходимо около дюжины вариантов использования. Но это только базовые варианты использования; каждый из таких вариантов использования может заключать в себе несколько сценариев и альтернативных вариантов использования.  Также встречаются проекты аналогичной трудоемкости с более чем сотней отдельных вариантов использования. (Если подсчитать количество альтернативных вариантов использования для дюжины базовых вариантов использования, то их общее количество как раз и будет около 100.).  Рекомендуемое общее количество актеров в модели - не более 20, а вариантов использования - не более 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм 33 34 Диаграммы использования В случае, когда для представления иерархической структуры проектируемой системы используются подсистемы, система может быть определена в виде вариантов использования на всех уровнях. Отдельные подсистемы или классы могут выступать в роли таких вариантов использования. При этом вариант, соответствующий некоторому из этих элементов, в последующем может уточняться множеством более мелких вариантов использования, каждый из которых будет определять сервис элемента модели, содержащийся в сервисе исходной системы. 35 36 Диаграмма последовательности Диаграмма взаимодействия предназначена для моделирования отношений между объектами (ролями, классами, компонентами) системы в рамках одного прецедента.    Данный вид диаграмм отражает следующие аспекты проектируемой системы: обмен сообщениями между объектами (в том числе в рамках обмена сообщениями со сторонними системами) ограничения, накладываемые на взаимодействие объектов события, инициирующие взаимодействия объектов. Диаграмма последовательности является одной из разновидности диаграмм взаимодействия и предназначена для моделирования взаимодействия объектов системы во времени, а также обмена сообщениями между ними. 37 Диаграмма последовательности Диаграмма последовательности — показывает взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. Основными элементами диаграммы последовательности являются обозначения объектов, вертикальные «линии жизни», отображающие течение времени, элементы, отражающие деятельность объекта или исполнение им определенной функции, и стрелки, показывающие обмен сигналами или сообщениями между объектами. Объекты располагаются с лева на права таким образом, чтобы крайним с лева был тот объект, который инициирует взаимодействие. 38 Диаграмма последовательности Линия жизни показывает время, в течение которого объект существует в Системе. Периоды активности объекта в момент взаимодействия показываются с помощью фокуса управления. Временная шкала на диаграмме направлена сверху вниз. 39 Нотации UML Actor – экземпляр участника процесса Boundary – Класс-Разграничитель - используется для классов, отделяющих внутреннюю структуру системы от внешней среды (экранная форма, пользовательский интерфейс, устройство ввода-вывода) Controll – Класс-контроллер - активный элемент, который используется для выполнения некоторых операций над объектами (программный компонент, модуль, обработчик) Entity – Класс-сущность - обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах (соответствует таблице или элементу БД) 40 Сообщения на диаграмме последовательности На диаграмме деятельности выделяются сообщения, инициирующие ту или иную деятельность или являющиеся ее следствием. На диаграмме состояний частично показан обмен сообщениями в рамках сообщений инициирующих изменение состояния объекта. На диаграмме последовательности мы можем увидеть следующие аспекты:  Сообщения, побуждающие объект к действию;  Действия, которые вызываются сообщениями (методы) – передача сообщения следующему объекты или возвращение определенных данных объекта;  Последовательность обмена сообщениями между объектами. Прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. 41 Виды сообщений Синхронное сообщение (synchCall) - соответствует синхронному вызову операции и подразумевает ожидание ответа от объекта получателя. Пока ответ не поступит, никаких действий в Системе не производится. Асинхронное сообщение (asynchCall) - которое соответствует асинхронному вызову операции и подразумевает, что объект может продолжать работу, не ожидая ответа. Ответное сообщение (reply) – ответное сообщение от вызванного метода. Данный вид сообщения показывается на диаграмме по мере необходимости или, когда возвращаемые им данные несут смысловую нагрузку. Потерянное сообщение (lost) – сообщение, не имеющее адресата сообщения, т.е. для него существует событие передачи и отсутствует событие приема. Найденное сообщение (found) – сообщение, не имеющее инициатора сообщения, т.е. для него существует событие приема и отсутствует событие передачи 42 Для сообщений также доступен ряд предопределенных стереотипов.  Сообщение со стереотипом create, вызывает в классе метод, которые создает экземпляр класса.  Для уничтожения экземпляра класса используется сообщение со стереотипом destroy, при этом в конце линии жизни объекта отображаются две перекрещенные линии. 43 При отображении работы с сообщениями можно указать следующие временные параметры:  ограничение продолжительности (Duration Constraint) – минимальное и максимальное значение продолжительности передачи сообщения  ограничение продолжительности ожидания между передачей и получением сообщения (Duration Constraint Between Messages)  перехват продолжительности сообщения (Duration Observation)  временное ограничение (Timing Constraint) – временной интервал, в течение которого сообщение должно прийти к цели (устанавливается на стороне получателя)  перехват времени, когда сообщение было отправлено (Timing Observation) 44 Отдельные фрагменты диаграммы взаимодействия можно выделить с помощью фрейма. Фрейм должен содержать метку оператора взаимодействия. UML содержит следующие операнды:  Alt - Несколько альтернативных фрагментов (alternative); выполняется только тот фрагмент, условие которого истинно  Opt - Необязательный (optional) фрагмент; выполняется, только если условие истинно. Эквивалентно alt с одной веткой  Par - Параллельный параллельно  loop - Цикл (loop); фрагмент может выполняться несколько раз  region - Критическая область (critical region); фрагмент может иметь только один поток, выполняющийся за один прием  Neg - Отрицательный (negative) фрагмент; обозначает неверное взаимодействие  ref - Ссылка (reference); ссылается на взаимодействие, определенное на другой диаграмме.  Sd - Диаграмма последовательности (sequence diagram); используется для очерчивания всей диаграммы последовательности, если это необходимо. (parallel); все фрагменты выполняются 45 При использовании условного или параллельного операнда фрейм делится на регионы взаимодействия с помощью разделителя операторов взаимодействия. Операнд alt используется при моделировании расширения сценария, т.е. при наличии альтернативного потока взаимодействия. Оператор opt используется, если сообщение должно быть передано, только при истинности какого-то условия. Данный фрейм используется без разделения на регионы. 46 Цикличность потока взаимодействия может быть представлена на диаграмме последовательности с помощью операнда loop. При использовании оператора цикла можно указать минимальное и максимальное число итераций. Также фрейм должен содержать условие, при наступлении которого взаимодействие повторяется. 47  У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным сообщением 48 49 50 51 52 Диаграммы последовательности Диаграммы последовательности предназначены для моделирования взаимодействия между несколькими объектами. Д Диаграммы последовательности создаются для взаимодействия в рамках одного прецедента. моделирования Также диаграммы последовательности подойдут для моделирования взаимодействия пользователя и Системы в целом. На уровне детальной спецификации требований диаграммы последовательности используются для моделирования взаимодействия компонентов Системы и пользовательских классов в рамках выбранного прецедента. На уровне реализации с помощью диаграммы последовательности моделируется взаимодействие между отдельными компонентами Системы. На данном уровне детализации лучше подойдет диаграмма коммуникации. 53 Поведенческие диаграммы  Диаграммы коммуникаций (кооперации)– это особый вид диаграмм взаимодействия, акцентированных на обмене данными между различными участниками взаимодействия.  Коммуникационные диаграммы допускают произвольное размещение участников, позволяя рисовать связи, показывающие отношения участников, и использовать нумерацию для представления последовательности сообщений. 54 На диаграмме коммуникации отображаются связи:  связей, которые представляют собой экземпляры ассоциаций можно также показать временные связи, возникающие только в контексте взаимодействия:    связь «local» (локальная) от объекта Order (Заказ) к объекту Product (Продукт) – это локальная переменная, «parameter» (параметр) «global» (глобальная) Стиль простой нумерации в языке UML не разрешен. В соответствии с правилами UML необходимо придерживаться вложенной десятичной нумерации. 55 56 Вложенная десятичная нумерация нужна, потому что требуется исключить неопределенность при самовызовах. Метод getDiscountInfo вызывается из метода calculateDiscount. 57 Диаграммы взаимодействия    Диаграммами взаимодействия следует пользоваться в том случае, когда необходимо описать поведение нескольких объектов в рамках одного варианта использования. Диаграммы взаимодействия удобны для изображения кооперации объектов и вовсе не так хороши для точного представления их поведения. Если необходимо описать поведение единственного объекта во многих вариантах использования, то следует применять диаграмму состояний. Если же возникает необходимость описать поведение, охватывающее несколько вариантов использования или несколько нитей процесса, следует рассматривать диаграмму деятельности. 58 59 Диаграмма деятельности Создание Информационной Системы – сложный процесс, который можно представить как поэтапный спуск от общей концепции будущей ИС, через понимание ее логической структуры к наиболее детальным моделям, описывающим физическую реализацию. Диаграмма вариантов использования (use case) отвечает на вопрос ЧТО должна делать Система. Диаграмма деятельности отвечает на вопрос КАК в системе выполняются требуемые функции. Деятельность может содержать входящие и/или исходящие дуги деятельности, показывающие потоки управления и потоки данных. Если поток соединяет две деятельности, он является потоком управления. Если поток заканчивается объектом, он является потоком данных. 60 Диаграмма деятельности Деятельность выполняется, только тогда, когда готовы все его «входы», после выполнения, деятельность передает управление и(или) данные на свои «выходы». Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали слева направо или сверху вниз. Чтобы указать, где именно находится процесс, используется абстрактная точка «маркер» (или «токен»). Визуально на диаграмме маркер не показывается, данное понятие вводится только для удобства описания динамического процесса. Переход маркера осуществляется между узлами. Маркер: может не содержать никакой дополнительной информации (пустой маркер) и тогда он называется маркером управления (control flow token) может содержать ссылку на объект или структуру данных, и тогда маркер называется маркером данных (data flow token). 61 Диаграмма деятельности Для создания диаграммы деятельности используются следующие узлы: Узел управления (control node) – это абстрактный узел действия, которое координирует потоки действий Начальный узел деятельности (или начальное состояние деятельности) (activity initial node) является узлом управления, в котором начинается поток (или потоки) при вызове данной деятельности извне Конечный узел деятельности (или конечное состояние деятельности) (activity final node) является узлом управления, который останавливает все потоки данной диаграммы деятельности. На диаграмме может быть более одного конечного узла Конечный узел потока (или конечное состояние потока) (flow final node) является узлом управления, который завершает данный поток. На другие потоки и деятельность данной диаграммы это не влияет Объект, над которым выполняются действия. Это не обязательный элемент диаграммы, но в некоторых случаях необходимо показать объект инициирующий выполнение действий, или являющийся результатом его 62 Для отображения расширений сценария на диаграмме деятельности используются, так называемые узлы решения . Узел решения предназначен для определения правила ветвления и различных вариантов дальнейшего развития сценария. В точку ветвления входит ровно один переход, а выходит - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Элемент узел объединения. Узел объединения имеет два и более входящих узла и один исходящий. 63 Для отображения условий соответствующих логическому оператору «и» на диаграмме используются синхронизационная черта. Точка разделения обеспечивает разделение одного потока на несколько параллельных потоков:  входит ровно один поток;  выходит два и более потока, каждый из которых далее выполняется параллельно с другими. Точка слияния обеспечивает синхронизацию нескольких параллельных потоков.  входят два или более потока, причем эти потоки выполняются параллельно;  выходит ровно один поток, причем в точке слияния входящие параллельные потоки синхронизируются, то есть каждый из них ждет, пока все остальные достигнут этой точки, после чего выполнение продолжается в рамках одного потока. 64 Диаграмма деятельности может описывать поведение, на которое оказывают влияние внешние события, происходящие за пределами данной Системы. На диаграмме это может быть показано при помощи изображения передачи сигнала. Передача сигнала может изображаться путем помещения между двумя действиями соответствующего элемента. 65  Для отображения объекта, осуществляющего управление потоками из нескольких источников используется два специальных узла: центральный буфер и хранилище данных. Центральный буфер - объект, который управляет потоками между множественными источниками и приемниками. На диаграмме центральный буфер представляется в виде объекта. Данный объект может применяться на уровне описания реализации функций Системы для визуализации временных таблиц. 66 Диаграммы последовательности Принципиальным отличием Хранилища данных является то, что оно содержит все поступившие данные и на выходе отдает лишь копии. Результатом действия «Сформировать заказ» является непосредственно заказ, который помещается в базу заказов. 67 Разделы группируют действия относительно какой-либо общей характеристики, при этом на течение потоков эта группировка никак не влияет. Разделение при данной структуре диаграммы деятельности, зачастую символизируют роль пользователя или организационное подразделение, осуществляющее определенные действия в рамках данной деятельности. 68 Спецификация UML предлагает несколько способов представления декомпозиции деятельности на диаграмме. Мы можем использовать обозначение под-деятельности (subactivity state), где указываем:  наименование деятельности;  предусловие и постусловие  пиктограмму, информирующую о наличие развернутой диаграммы для данной деятельности . При необходимости описание последовательности действий для под-деятельности может быть размещено непосредственно на основной диаграмме. Для этого описание под-деятельности размещается в отдельный фрейм. При таком способе декомпозиции мы можем указать:  предусловия и постусловия;  входные и выходные параметры (объекты);  внутреннее устройство деятельности. 69 Для описания концепции процесса совершения покупки через интернетмагазин можно использовать диаграмму действия в стиле IDEF0, где указываются следующие параметры: • входные и выходные данные; • объекты, управляющие процессом (в нашем случае это каталог товаров и прайс-лист); • используемые ресурсы (в нашем примере это Покупатель и Менеджер). 70 Для создания концептуальной модели необходимо выделять только основные процессы, так как вспомогательные процессы и сущности могут перегружать диаграмму. Также концептуальная модель должна включать только процессы верхнего уровня. 71 Диаграмма состояния Система может становится событийно управляемой, поэтому разработчикам важно знать, как должен реагировать тот или иной объект на определенные события. Инициаторами событий могут быть как объекты самой Системы, так и её внешнее окружение.  Также диаграмма состояний используется аналитиками для описания последовательности переходов объекта из одного состояния в другое.  Диаграмма состояний показывает нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния. 72 Основными элементами «Состояние» и «Переход». диаграммы состояний являются Диаграмма состояний имеет схожую семантику с диаграммой деятельности. Таким образом, если для диаграммы деятельности отличие между понятиями «Деятельность» и «Действие» заключается в возможности дальнейшей декомпозиции, то на диаграмме состояний деятельность символизирует состояние, в котором объект находится продолжительное количество времени, в то время как действие моментально. 73 Переход может быть инициирован событием, которое также отражается на диаграмме состояний. Состояние может содержать только имя или имя и дополнительно список внутренних действий. Список внутренних действий содержит перечень действий или деятельностей, которые выполняются во время нахождения объекта в данном состоянии. Данный список фиксированный. Список основных действий включает следующие значения: entry - действие, которое выполняется в момент входа в данное состояние (входное действие); exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие); do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии; defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены. 74 75 Различаются следующие виды событий: Событие вызова (call event) - событие, возникающее при вызове метода класса. При срабатывании данного вида события объектом ассинхронно создается Сигнал, который принимается другим объектом. Для указания на то, что некоторая операция посылает сигнал, можно воспользоваться зависимостью со стереотипом send. Событие сигнала (signal event) - событие, возникающее при посылке сигнала. Если событие сигнала представляет возбуждение сигнала, то событие вызова предназначено для описания выполнения операции. Т.е. переход осуществляется при получении сигнала от другого объекта. В то время как сигнал является событием асинхронным, событие вызова обычно синхронно. Сигнал также может быть представлен на диаграмме в виде объекта со стереотипом «signal». Событие таймера (time event) - возникает, когда истек заданный интервал времени с момента попадания автомата в данное состояние. В UML событие времени моделируется с помощью ключевого слова after(после), за которым следует выражение, вычисляющее некоторый промежуток времени. Событие изменения (change event) - событие, которое возникает, когда некоторое логическое условие становится истинным, будучи до этого ложным. Данное событие моделируется с помощью ключевого слова when 76 Помимо основных узлов, на диаграмме состояний могут использоваться, так называемые, псевдосостояния – вершины которые не обладают поведением, и объект не находится в ней, а «мгновенно» ее проходит. Под псевдосостояниями на диаграмме состояний понимаются, знакомые уже нам начальное и конечное состояние. Начальное состояние обычно не содержит никаких внутренних действий и определяет точку, в которой находится объект по умолчанию в начальный момент времени. Конечное состояние также не содержит никаких внутренних действий и служит для указания на диаграмме области, в которой завершается процесс изменения состояний в контексте конечного автомата. Если необходимо отразить уничтожение объекта используется узел завершения (terminate node), псевдосостояние, вход в который означает завершение выполнения поведения конечного автомата в контексте его объекта. 77 Составное состояние может содержать два или более параллельных подавтомата или несколько последовательных подсостояний. 78 Иногда возникает ситуация, когда необходимо показать переход из одного состояния в подсостояние композитного состояния, декомпозиция которого производится на отдельной диаграмме. 79 80 Диаграммы деятельности Подобно большинству других методов моделирования диаграммы деятельности обладают определенными достоинствами и недостатками, поэтому их лучше всего использовать в сочетании с другими методами.  Самым большим достоинством диаграмм деятельности является возможность представления и описания параллельного поведения.  Большой недостаток этих диаграмм заключается в том, что они не позволяют представить связи между действиями и объектами достаточно наглядно. Желательно использовать диаграммы в следующих случаях:  Анализ варианта использования. На этом этапе не интересует связь между действиями и объектами; нужно понять, какие действия должны иметь место и каковы зависимости в поведении системы.  81 Диаграммы деятельности    Понимание потока работ. Прежде чем приступить к рассмотрению содержания вариантов использования, целесообразно привлечь диаграммы деятельности для лучшего понимания соответствующего бизнес-процесса. Эти диаграммы лучше разрабатывать совместно с бизнес-аналитиками, поскольку при этом можно понять особенности бизнес-процесса и возможности его изменения. Описание сложного последовательного алгоритма. В этом случае диаграмма деятельности не позволяет представить ничего сверх того, что может быть изображено на согласованной с обозначениями языка UML схеме алгоритма. При этом можно использовать принятые на схемах алгоритмов специальные обозначения. Работа с многопоточными приложениями. 82 Диаграммы деятельности Диаграммы деятельности не следует использовать в следующих ситуациях:  Пытаться представить кооперацию объектов. Диаграммы взаимодействия являются более простыми и обеспечивают более наглядное представление кооперации.  Пытаться представить поведение объектов в течение их жизненного цикла. Для этой цели лучше использовать диаграмму состояний.  Представление сложных логических условий. Для этой цели лучше использовать таблицу истинности. 83 84 Структурные диаграммы UML  Диаграммы классов используют классы и интерфейсы для отражения подробной информации о сущностях, образующих систему, и статических отношений между ними. 85 Диаграммы классов Атрибуты класса определяют состав и структуру данных, хранимых в объектах этого класса. Каждый атрибут имеет имя и тип, определяющий, какие данные он представляет. При реализации объекта в программном коде для атрибутов будет выделена память, необходимая для хранения всех атрибутов, и каждый атрибут будет иметь конкретное значение в любой момент времени работы программы. Для каждого атрибута класса можно задать видимость (visibility). В UML определены следующие уровни видимости атрибутов:  Открытый (public) – атрибут виден для любого другого класса (объекта);  Защищенный (protected) – атрибут виден для потомков данного класса;  Закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим. 86 87 Диаграммы классов На диаграммах классов обычно показываются ассоциации и обобщения Каждая ассоциация несет информацию о связях между объектами. Наиболее часто используются бинарные ассоциации, связывающие два класса. Ассоциация может иметь название, которое должно выражать суть отображаемой связи. Ассоциация может иметь такую характеристику, как множественность. Она показывает, сколько объектов каждого класса может участвовать в ассоциации. 88 Диаграммы классов Обобщение на диаграммах классов используется, чтобы показать связь между классом-родителем и классом-потомком. Оно вводится на диаграмму, когда возникает разновидность какого-либо класса, а также в тех случаях, когда в системе обнаруживаются несколько классов, обладающих сходным поведением. 89 Диаграммы классов При создании диаграмм классов часто пользуются понятием «стереотип». Стереотип класса – это элемент, который обозначает отличительные особенности в использовании класса. Стереотип имеет название, которое задается в виде текстовой строки. При изображении класса на диаграмме стереотип показывается в верхней части класса в двойных угловых скобках. Есть четыре стандартных стереотипа классов, для которых предусмотрены специальные графические изображения.  Стереотип используется для обозначения классов-сущностей  Применение стереотипов позволяет, в частности, изменить вид диаграмм классов. 90 Диаграммы классов Диаграммы классов создаются при логическом моделировании и служат для следующих целей:  Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.  Для представления архитектуры. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру.  Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.  Для моделирования логики программных компонентов.  Для моделирования логики обработки данных. 91 Диаграммы классов Диаграммы классов могут применяться  при прямом проектировании, то есть в процессе разработки новой системы,  при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения . 92 Диаграммы классов       Диаграммы классов являются фундаментом почти всех объектноориентированных методов, поэтому работать с ними приходится практически постоянно. Трудность, связанная с использованием диаграмм классов, заключается в том, что их нотация слишком богата и в ней можно заблудиться. Не нужно использовать сразу все доступные понятия. Необходимо начать с классов, ассоциаций, атрибутов, обобщений и ограничений. Выбор точки зрения для построения модели должен соответствовать конкретному этапу работы над проектом: Если вы работаете с программным обеспечением, сосредоточьте свое внимание на моделях спецификации. Необходимо применять модели реализации только в тех случаях, когда иллюстрируете конкретный способ реализации. 93 Диаграммы классов   Не надо строить модели для всего на свете; вместо этого следует сконцентрироваться на главных аспектах. Лучше иметь мало диаграмм, которые постоянно используются в работе и отражают все внесенные изменения, чем большое количество забытых и устаревших моделей. Самая большая опасность, связанная с диаграммами классов, заключается в том, что можно слишком рано увязнуть в деталях реализации. Чтобы этому противостоять, необходимо концентрировать внимание на концептуальной точке зрения и точке зрения спецификации. 94 Диаграммы классов Объект – некая сущность реального мира или концептуальная сущность. Состояние объекта – одно из условий, в которых он может находится. Поведение – определяет как объект реагирует на запросы других объектов и что может делать сам объект. Уникальность - означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта. Класс – описание группы объектов с общими свойствами, поведением, отношениями с другими объектами и семантикой. Класс-сущность используется для моделирования данных и поведения с длинным жизненным циклом. Граничные классы – обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Управляющие классы – служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, ревизиющих заложенное в них поведение. 95 Диаграммы объектов Диаграмма экземпляров Объект  конкретная материализация абстракции;  сущность с хорошо определенными границами, в которой инкапсулированы состояние и поведение;  экземпляр класса . Объект уникально идентифицируется значениями атрибутов, определяющими его состояние в данный момент времени.  диаграмма объектов - это своего рода снимок состояния системы в определенный момент времени, показывающий множество объектов, их состояния и отношения между ними в данный момент. 96 Диаграммы объектов Таким образом, диаграммы объектов представляют статический вид системы с точки зрения проектирования и процессов, являясь основой  для сценариев,  описываемых диаграммами взаимодействия. Диаграмма объектов используется для пояснения и детализации диаграмм взаимодействия, например, диаграмм последовательностей. Хорошо структурированная диаграмма объектов характеризуется следующими свойствами:  акцентирует внимание на одном аспекте статического вида системы с точки зрения проектирования или процессов;  представляет лишь один из кадров динамического сценария, показанного на диаграмме взаимодействия;  содержит только существенные для понимания данного аспекта элементы;  уровень ее детализации соответствует; уровню абстракции системы.  не настолько лаконична, чтобы ввести читателя в заблуждение относительно важной семантики. 97 Диаграммы объектов Моделирование объектной структуры: 1. Необходимо идентифицировать механизм, который собираетесь моделировать. Механизм представляет собой некоторую функцию или поведение части моделируемой системы, являющееся результатом взаимодействия сообщества классов, интерфейсов и других сущностей. 2. Для каждого обнаруженного механизма идентифицируйте классы, интерфейсы и другие элементы, участвующие в кооперации, а также отношения между ними. 3. Рассмотрите один из сценариев использования работы механизма. Заморозьте этот сценарий в некоторый момент времени и изобразите все объекты, участвующие в механизме. 4. Покажите состояние и значения атрибутов каждого такого объекта, если это необходимо для понимания сценария. 5. Покажите также связи между этими объектами, которые представляют экземпляры существующих ассоциаций. 98 Диаграммы объектов Подчеркнутые имена показывают, что элементы, являются экземплярами класса. Каждое имя представляется в виде: имя экземпляра : имя класса. Если указано только имя класса, то необходимо поставить двоеточие. Можно также задать значения и атрибуты. 99 Диаграммы объектов 100 Диаграммы объектов С помощью диаграмм объектов, как и с помощью диаграмм классов, моделируют статический вид системы с точки зрения проектирования или процессов, но принимая во внимание реальные экземпляры или прототипы.  Этот вид описывает главным образом функциональные требования к системе, то есть услуги, которые она должна предоставлять конечным пользователям. Диаграммы объектов позволяют моделировать статические структуры данных. При моделировании статического вида системы с точки зрения проектирования или процессов объектные диаграммы применяют для того, чтобы моделировать структуру объектов.  Моделирование структуры объектов предполагает получение "снимка" объектов системы в некоторый момент времени. Диаграммы объектов предоставляют статическую основу динамического сценария, описываемого диаграммой взаимодействия. Они применяются для визуализации, специфицирования, конструирования и документирования определенных экземпляров в системе, а также отношений между этими экземплярами. 101 Диаграммы объектов Изображая диаграмму объектов, следует придерживаться следующих правил:  давайте ей имя, соответствующее назначению;  располагайте элементы так, чтобы число пересечений было минимальным;  располагайте элементы так, чтобы семантически близкие сущности оказывались рядом;  используйте примечания и цвет для привлечения внимания к важным особенностям диаграммы;  включайте в описания каждого объекта значения, состояния и роли, если это необходимо для понимания ваших намерений. 102 Нотации UML Пиктограмма "пакет" изображает единственную первичную группирующую сущность. в языке UML В пакет можно поместить: - структурные сущности; - поведенческие сущности; - и даже другие пакеты. Изображается пакет в виде папки с закладкой. Существуют также вариации пакетов, например, каркасы, модели и подсистемы. Пакет - это способ организации элементов модели в более крупные блоки, которыми впоследствии позволяется манипулировать как единым целым. Можно управлять видимостью входящих в пакет сущностей, так что некоторые будут видимы извне, а другие - нет. Кроме того, с помощью пакетов можно представлять различные виды архитектуры системы. 103 У каждого пакета должно быть имя, отличающее его от других пакетов. Имя -это текстовая строка. К составному имени спереди добавлено имя объемлющего его пакета, если таковой существует. Имя пакета должно быть уникальным в объемлющем пакете. 104 Диаграммы пакетов Пакет может владеть другими элементами, в том числе классами, интерфейсами, компонентами, узлами, кооперациями, диаграммами и прочими пакетами. Владение - это композитное отношение , означающее, что элемент объявлен внутри пакета. Если пакет удаляется, то уничтожается и принадлежащий ему элемент. Элемент может принадлежать только одному пакету Между пакетами определены отношения: импорта, доступа и обобщения, используемые для специфицирования семейств пакетов. Отношения обобщения между пакетами очень похожи на отношения обобщения между классами. 105 Диаграммы пакетов Принадлежащих пакету элементов можно контролировать точно так же, как видимость атрибутов и операций класса. По умолчанию такие элементы являются открытыми, то есть видимы для всех элементов, содержащихся в любом пакете, импортирующем данный. Защищенные элементы видимы только для потомков, а закрытые вообще невидимы вне своего пакета. 106 Диаграммы пакетов В языке UML определены пять стандартных стереотипов, применимых к пакетам:  facade - определяет пакет, являющийся всего лишь представлением какого-то другого пакета;  Framework - определяет пакет, состоящий в основном из образцов;  Stub - определяет пакет, служащий заместителем открытого содержимого другого пакета;  Subsystem - определяет пакет, представляющий независимую часть моделируемой системы;  system - определяет пакет, представляющий всю моделируемую систему. Стереотип facade используется для показа свернутого представления сложного пакета. Стереотип stub используют, если в вашем распоряжении имеются инструменты, расщепляющие систему на пакеты для последующей работы с ними в разное время и в разных местах. 107 Диаграммы пакетов  Просмотреть моделирующие элементы в некотором представлении архитектуры системы с целью поиска групп семантически или концептуально близких элементов.  Поместить каждую такую группу в пакет.  Для каждого пакета определить, какие элементы должны быть доступны извне. Отметить их как открытые, а остальные - как защищенные или за крытые.  Явно соединить пакеты отношениями импорта с теми пакетами, от которых они зависят.  Если имеются в наличии семейства пакетов, соедините специализированные пакеты с общими отношениями обобщения. 108 Диаграммы пакетов Пакеты нужны только для организации элементов вашей модели. Хорошо структурированный пакет характеризуется следующими свойствами:  он внутренне согласован и очерчивает четкую границу вокруг группы родственных элементов;  он слабо связан и экспортирует в другие пакеты только те элементы, которые они действительно должны "видеть", а импортирует лишь элементы, которые необходимы и достаточны для того, чтобы его собственные элементы могли работать;  глубина вложенности пакета невелика;  владеть сбалансированным набором элементов, пакет по отношению к другим пакетам в системе не должен быть ни слишком большим, ни слишком маленьким. 109 Диаграмма развертывания Диаграмма применения  Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Диаграммы развертывания, или применения, - это один из двух видов диаграмм, используемых при моделировании физических аспектов объектно-ориентированной системы Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения. Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними.  110 Диаграмма развертывания Разработка диаграммы развертывания, как правило, является последним этапом спецификации модели программной системы. При разработке диаграммы развертывания преследуют следующие цели:  определить распределение компонентов системы по ее физическим узлам;  показать физические связи между всеми узлами реализации системы на этапе ее исполнения;  выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.  Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками. 111 Диаграмма развертывания UML диаграммы развертывания используются для визуализации статических аспектов физических узлов и их взаимосвязей, а также для описания их деталей, которые имеют отношение к конструированию системы 112 Диаграмма развертывания  Диаграмма развертывания обладает общими свойствами, присущими всем диаграммам, - именем и графическим содержанием, которое отражает одну из проекций модели. Диаграммы развертывания обычно включают в себя:  Узлы ;  отношения зависимости и ассоциации. 113 Диаграмма развертывания При моделировании статического вида системы с точки зрения развертывания диаграммы используются, как правило, в трех случаях:  моделирование встроенных систем. Встроенной системой называется аппаратный комплекс, взаимодействующий с физическим миром, в котором велика роль программного обеспечения. Диаграмму развертывания можно использовать для моделирования устройств и процессоров, из которых состоит встроенная система; клиент-серверных систем. Клиент-серверная  моделирование система - это типичный пример архитектуры, где основное внимание уделяется четкому разделению обязанностей между интерфейсом пользователя, существующим на клиенте, и хранимыми данными системы, существующими на сервере;  моделирование полностью распределенных систем. Ha другом конце спектра распределенных систем находятся такие системы, которые распределены широко или даже глобально и охватывают серверы различных уровней. 114 Диаграмма развертывания Моделирование встроенной системы включает в себя следующие этапы: 1. Необходимо идентифицировать устройства и узлы, уникальные для системы. 2. Определить визуальные обозначениях для нестандартных устройств, воспользовавшись механизмами расширения UML для определения специфических стереотипов в виде подходящих пиктограмм. 3. Смоделировать отношения между процессорами и устройствами на диаграмме развертывания. Кроме того, специфицировать отношения между компонентами вида системы с точки зрения реализации и узлами вида с точки зрения развертывания. 4. При необходимости раскрыть описание наиболее "интеллектуальных" устройств, промоделировав их структуру на более детальной диаграмме развертывания. 115 Диаграмма развертывания Моделирование клиент-серверной системы осуществляется : 1. Необходимо определить узлы, представляющие процессоры клиента и сервера. 2. Выделить те устройства, которые так или иначе влияют на поведение системы. С помощью стереотипов разработать визуальные обозначения для 3. процессоров и устройств. 4. Смоделировать топологию узлов на диаграмме развертывания. Специфицировать также отношения между компонентами вида системы с точки зрения реализации и узлами вида с точки зрения развертывания. 116 Диаграмма развертывания Документируя полностью распределенную систему, можно полностью раскрыть детали сетевых устройств, представляя их в виде стереотипных узлов. Моделирование полностью распределенной системы осуществляется следующим образом: Определить устройства и процессоры, как и в отношении более 1. простой клиент-серверной системы. 2. Если необходимо строить выводы о производительности сетевой инфраструктуры или о влиянии на сеть изменений, промоделировать коммуникационные устройства со степенью детализации, достаточной для такого рода оценок. 3. Обратить особое внимание на логическое группирование узлов; для этого можно воспользоваться пакетами. 4. Смоделировать устройства и процессоры с помощью диаграмм развертывания. 5. Если необходимо сфокусировать внимание на динамике системы, подключая диаграммы прецедентов для специфицирования представляющих интерес видов поведения и раскройте их с помощью диаграмм взаимодействия. 117 Диаграмма развертывания 118 Диаграмма развертывания Прямому проектированию (созданию кода по модели) диаграммы развертывания поддаются лишь в очень небольшой степени. Обратное проектирование (создание модели по коду) из реального мира в диаграммы развертывания может иметь огромную ценность, особенно для полностью распределенных систем, которые постоянно изменяются. Преимущество использования UML состоит в том, что это стандартный язык, на котором можно выразить интересы не только администратора, но и разработчиков программного обеспечения. 119 Диаграмма развертывания Обратное проектирование диаграммы развертывания: 1. Определить что именно необходимо подвергнуть обратному проектированию. 2. Выбрать степень детализации обратного проектирования. Используя инструментальные средства, совершить обход системы 3. и показать ее топологию. 4. Определить какие компоненты размещены в каждом узле, и занесите их в модель развертывания. 5. Используя инструменты моделирования, создайте диаграмму развертывания путем опроса модели. Например, можно начать с визуализации базовой клиент-серверной топологии, а затем расширять диаграмму, добавляя в описания тех или иных узлов размещенные в них компоненты. Раскройте детали содержания диаграммы развертывания в той степени, в какой это требуется. 120 Диаграмма развертывания Хорошо структурированная диаграмма развертывания обладает следующими свойствами:  сосредоточена на каком-то одном аспекте статического вида системы с точки зрения развертывания;  содержит только те элементы, которые существенны для понимания этого аспекта;  раскрывает только те детали, которые присутствуют на выбранном уровне абстракции;  не является настолько краткой, чтобы скрыть от читателя важную семантику. 121 Структурные диаграммы UML  Диаграммы компонентов отражает логическую организацию и зависимости, задействованные в реализации системы. Диаграммы компонент показывают, как выглядит модель на физическом уровне. На ней изображаются компоненты программного обеспечения вашей системы и связи между ними. При этом выделяют два типа компонент: исполняемые компоненты и библиотеки кода. 122 123 Диаграммы компонентов и развертывания  Хотя диаграммы развертывания и диаграммы компонентов можно изображать отдельно, также допускается помещать диаграмму компонентов на диаграмму развертывания. Это целесообразно делать, чтобы показать какие компоненты выполняются и на каких узлах. 124 Диаграммы компонентов и развертывания     Разработчики часто изображают на физических диаграммах специальные символы, которые по своему внешнему виду напоминают различные элементы. Например, применяются специальные пиктограммы для серверов, ПК и баз данных. Каждую из пиктограмм можно рассматривать как стереотип соответствующего элемента диаграммы. Обычно такие пиктограммы способствуют лучшему пониманию диаграммы, хотя и усложняют ее, если одновременно изображаются узлы и компоненты. Многие разработчики творчески подходят к использованию этого вида информации, однако другие строят эти диаграммы формально с целью соответствия стандартам языка UML. В большинстве случаев разрабатывается по меньшей мере одна диаграмма, на которой показаны узлы и основные компоненты, при этом допустимо использовать графические пиктограммы, если это не приводит к излишнему усложнению диаграммы. 125 126 127 Средства и их использование 128 129 Структурные диаграммы UML  Диаграммы составной структуры принадлежат к числу нововведений Uml 2.0. На концептуальном уровне диаграммы составной структуры связывают диаграммы классов с диаграммами компонентов.  Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. 130 Поведенческие диаграммы  Диаграммы синхронизации разновидность диаграмм взаимодействий, в которой центральное место занимает подробное указание хронометражной последовательности сообщений. 131 Временные диаграммы UML  Цель- Обозначить временные интервалы между изменениями состояний различных объектов.  Временные диаграммы – это еще одна форма диаграмм взаимодействия, которая акцентирована на временных ограничениях: либо для одиночного объекта, либо, что более полезно, для группы объектов. Рассмотрим простой сценарий, основанный на использовании насоса (Pump) и нагревательного элемента (Hotplate) в кофеварке (coffee pot). 132 Временные диаграммы UML Стиль представления состояний в виде линий, следует предпочесть, когда состояний немного, а стиль представления состояний в виде областей, лучше подходит, большого количества состояний. 133 134