Развитие средств проектирования автоматизированных систем

Развитие средств проектирования автоматизированных систем

Появлению CASE - технологий и CASE - средств предшествовали исследования в области методологии программирования и проектирования информационных систем.

Можно отметить два этапа программирования и разработки информационных систем до их появления:

1. Стихийное программирование (до середины 60-х годов.).

Его достижение – подпрограммы и глобальные данные.

2. Структурное (модульное) программирование (60 - 70 – е годы).

В конце 60 - х гг. ХХ в. стали появляться и применяться первые методологии, ориентированные на структурный подход.

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

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

Основа структурного подхода – последовательная детализация.

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

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

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

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

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

Программы приобрели структуру иерархической многоуровневой модульной системы.

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

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

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

C помощью репозитория осуществляется контроль и отслеживание вносимых изменений.

В общем случае репозиторий может хранить объекты различных типов:

* диаграммы;

* определения экранов и меню;

* проекты отчетов;

* описание данных;

* логику их обработки;

* исходные коды программ и т.п.;

* прямое проектирование программного обеспечения и баз данных.

При этом порядок использования разработчиками CASE - средства следующий:

* создается логическая модель системы;

* выбирается конкретный язык программирования или СУБД для построения физической модели, после чего CASE - средство автоматически создает физическую модель системы.

В случае изменения модели системы могут быть автоматически внесены необходимые изменения в физическую реализацию или наоборот.

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

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

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

В основе CASE – процесс выявления функций систем и их элементов и информационных потоков.

С другой стороны - это средства перехода от неясных знаний к точным.

Анализ характеристик и возможностей большинства современных CASE - систем позволяет сделать следующие выводы:

1. Применение CASE - систем ведет к сокращению объема ручной работы программистов, особенно при проектировании интерактивных частей программ.

2. Уменьшению затрат на разработку программного и информационного обеспечений за счет числа итераций и числа ошибок.

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

4. Позволяют ускорить и облегчить разработку.

 

Результат применения CASE - средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.

 

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

Кроме структур­ной методологии, в ряде современных CASE - средств используется объектно - ориен­тированная методология проектирования.

Таким образом, в настоящее время  имеется две основные тенденции в методологии проектирования с помощью CASE – систем:

1. Структурный (функциональный, модульный).

2. Объектно – ориентированный.

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

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

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

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

Концептуальной основой объектно - ориентированного подхода является объектная модель.

Ее основные принципы (абстрагирование, инкапсуляция, модульность,  иерархия и др.) и понятия (объект, класс, атрибут, операция, интерфейс.) были  сформулированы Гради Бучем в его работах.

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

Основными понятиями объектно - ориентированного подхода являются объект и класс.

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

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

Иерархия понятий строится следующим образом.

В качестве наиболее общего понятия или категории берется понятие, имеющее наибольший объем и, соответственно, наименьшее содержание.

Это самый высокий уровень абстракции для данной иерархии.

Затем данное общее понятие конкретизируется, то есть уменьшается его объем и увеличивается содержание.

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

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

Объект - предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью.

Объект в контексте объектно- ориентированного проектирования  рассматривается,  как экземпляр соответствующего класса.

 

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

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

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

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

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

Большинство моделей объектно - ориентированного проектирования близки по возможностям, но имеют отличия в основном в форме представления.

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

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

В этой связи известные специалисты Г.Буч, Д.Рамбо и И.Джекобсон при поддержке фирмы Rational Software Corporation провели работу над унифицированной моделью и методом, получившим название UML (Unified Modeling Language- унифицированный язык моделирования).

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

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

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

Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира.

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

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

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

В объектно - ориентированном подходе основная категория объектной модели - класс - объединяет в себе на элементарном уровне как данные, так и операции, которые над ними выполняются (методы).

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

 

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

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

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

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

 

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

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

Отдельная диаграмма классов представляет определенный ракурс структуры классов.

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

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

 

Общая характеристика языка UML

 

UML (Unified Modeling Language) – унифицированный язык графического моделирования.

Он был разработан по инициативе компании Rational Software.

Основные разработчики Гради Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джим Рамбо (Jim Rumbaugh).

Язык UML предназначен для описания, визуализации и документирования объектно-ориентированных систем в процессе их разработки.

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

 

Главными в разработке UML (Unified Modeling Language) были следующие цели:

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

* снабдить исходные понятия языка UML возможностью расширения и специализации базовых концепций для более точного представления моделей систем в конкретной предметной области;

* обеспечить независимость от конкретных языков программирования и процессов разработки;

* обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

* стимулировать рост рынка объектно-ориентированных инструментальных средств;

* интегрировать лучший практический опыт.

 

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

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

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

Это не язык программирования, но на его основе можно генерировать код.

Примером программной системы, поддерживающей язык UML, является система Rational Rose компании Rational Software.

Семантика определяется для двух видов объектных моделей: структурных моделей и моделей поведения.

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

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

Диаграммы языка UML

 

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

В  терминах языка UML определены следующие виды диаграмм:

Диаграмма вариантов использования (use case diagram)

Диаграмма классов (Class diagrams)

Диаграммы поведения (Behavior diagrams)

Диаграмма состояний (State chart diagrams)

Диаграмма деятельности (Activity diagrams)

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

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

Диаграмма кооперации (Collaboration diagrams)

Диаграммы реализации (Implementation diagrams)

Диаграмма компонентов (Component diagrams)

Диаграмма развертывания (Deployment diagrams)

 

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

При этом в качестве самостоятельных представлений в языке UML используются следующие диаграммы:

1. Диаграмма вариантов использования.

2. Диаграмма классов.

3. Диаграмма состояний.

4. Диаграмма деятельности.

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

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

7. Диаграмма компонентов.

8.  Диаграмма развертывания.

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

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

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

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

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

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

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

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

 

 

В ранней литературе по UML в качестве отдельной диаграммы рассматривалась еще диаграмма объектов.

Однако в версии 1.3 она не включена в перечень канонических диаграмм, поскольку ее элементы могут присутствовать на диаграммах других типов

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

 

Диаграмма вариантов использования

 

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

Для облегчения этого процесса аналитики используют диаграммы вариантов использования или прецедентов (Use case diagrams).

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

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

Основные элементы диаграммы отображены на рисунке.

 

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

 

Не указывается, как достигается результат, а лишь что выполняется.

Пользователи изображаются в виде стилизованных фигурок (актеров - actors).

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

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

Сообщение представляет собой запрос актером сервиса от системы и получение этого сервиса.

Пример диаграммы

 

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

Отношение – семантическая связь между отдельными элементами модели.

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

* ассоциации;

* включения;

* расширения;

* обобщения.

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

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

Отношение расширения позволяет выразить связи между двумя вариантами использования.

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

 

Диаграммы классов

 

Диаграммы классов (Class diagrams)   описывает структуру системы через иерархию классов и зависимости между ними.

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

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

* не содержащие ни одного экземпляра - класс становится служебным (Abstract);

* содержащие ровно один экземпляр (Singleton);

* содержащие заданное число экземпляров;

* содержащие произвольное число экземпляров.

В зависимости от этого в языке UML можно выделить конкретные и абстрактные классы.

Конкретный класс – класс на основе которого могут быть - непосредственно созданы экземпляры или объекты.

Абстрактный класс – класс, который не имеет экземпляров или объектов (нельзя создавать экземпляры).

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

Множество допустимых значений атрибута образует домен.

Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса.

Операции представляют собой процессы, реализуемые классом.

Очевидное соответствие существует между операциями и методами над  классом.

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

Исполнение операции обычно связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.

Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса

 

 

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

 

 

Примеры отношений: ассоциация, обобщение, зависимость, агрегация  и др.

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

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

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

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

Обобщение – это отношение между общей сущностью родителем (класс " клиент ") и ее конкретным воплощением потомком (классы " корпоративный клиент " или " частный клиент ").

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

При этом он наследует свойства родителя (его атрибуты и операции).

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

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

Стрелка указывает на более общий класс - класс предок, а ее начало исходит из класса потомок или подкласса.

От одного класса предка одновременно могут - наследовать несколько классов потомков.

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

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

Направлено от клиента к исполнителю.

 

 

Диаграммы состояний

 

Диаграммы состояний (State chart diagram) описывают поведение объекта во времени, моделируют все возможные изменения в состоянии объекта, вызванные внешними воздействиями со стороны других объектов или извне.

Диаграммы состояний применяются для описа­ния поведения объектов и для описания операций классов.

 

 

Этот тип диаграмм опи­сывает изменение состояния одного класса или объекта.

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

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

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

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

Диаграмма состояний - диаграмма, которая представляет конечный автомат.

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

 

Диаграммы деятельности

 

Диаграммы деятельности (Activity diagrams)  - для моделирования динамического поведения системы в рамках различных вариантов использования.

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

Это блок – схемы или структурные схемы алгоритмов.

Она дополняет диаграмму состояний элементами для построения алгоритмических схем.

Они особенно важны при моделировании функциональности системы и выделяют поток управления между объектами.

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

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

 

Диаграмма деятельности - обработка заказа

 

 

 

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

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

Тем самым реализуется процедурное, синхронное управление, обусловленное завершением внутренних действий.

Основными элементами диаграмм деятельности являются:

* овалы, изображающие действия объекта;

* линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И");

* ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");

* стрелки - отражают последовательность действий, могут иметь метки условий.

Любая деятельность может быть подвергнута декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания).

 

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

 

Диаграмма последовательности (Sequence diagrams) - вид диаграмм, который  используется для точного определения логики сценария выполнения прецедента.

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

Она дает наглядное представление порядка передачи сообщений во времени

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

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

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

Названия подчеркиваются.

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

 

 

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

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

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

Второе измерение - вертикальная временная ось.

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

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

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

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

 

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

 

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

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

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

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

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

Сообщения упорядочены по времени появления.

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

Содержат имя объекта, его класс и, возможно, значение атрибутов.

 

 

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

На кооперативной диаграмме экземпляры объектов показаны в виде пиктограмм.

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

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

Одним из главных свойств любой диаграммы взаимодействия является ее простота.

Посмотрев на диаграмму, можно легко увидеть все сообщения.

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

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

Один из них состоит в использовании отдельных диаграмм для каждого сценария.

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

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

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

Диаграмма компонентов

Диаграмма компонентов (Component diagram) - статическая структурная диаграмма, показывает разбиение системы на структурные компоненты и связи (зависимости) между компонентами.

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

Пример диаграммы компонентов

 

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

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

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

Поэтому для взаимодействия с ним необходим интерфейс (инструмент Interface).

Его название – вне изображения.

Ранее это были методы и данные.

У одного компонента может быть несколько интерфейсов.

 

Связи между компонентами могут быть двух видов.

1. Supports – для связи между компонентом и интерфейсом.

Отображается прямой линией без направления. 

2. Dependancy - пунктирная линия со стрелкой от пользователя к компоненту – услуге (включая и интерфейс).

 

Диаграммы компонентов в UML 2.0 имеют значительные изменения.

Появилось понятие порта.

Удален элемент подсистема.

Появилось понятие артефакта  (для двоичных файлов, таблиц БД, документов, электронной почты и др. реальных объектов) и класса.

Артефакт связан с файлом через свойство имя (Filename).

Класс связан со своей реализацией через свойство Implements.

Введены новые типы связей классов и интерфейсов.

Например, связь Delegation Connectors позволяет соединить компонент с классом, который определяет внутреннюю структуру компонента.

Если компонент имеет реализацию, то между компонентом и артефактом прокладывается связь типа Realization.

 

 

 

Диаграмма развертывания

 

Диаграмма развёртывания (размещения) (Deployment diagram) - служит для моделирования работающих узлов.

В диаграммах развертывания показ<