Проектирование бизнес систем

Рис. 16 Активный класс

Компоненты и узлы соответствуют физическим сущностям системы. Компонент (Component) - это физическая заменяемая часть системы, соответствующая некоторому набору интерфейсов и обеспечивает его реализацию (рис. 17). Компонент - это физическая упаковка логических элементов, (классов, интерфейсов и кооперации), например компоненты СОМ+ или Java Beans, а также файлы исходного кода.

Рис. 17 Компонент

Узел (Node) - это элемент, представляющий вычислительный ресурс, обладающий памятью и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой (рис. 18).

Рис. 18 Узел



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

Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели. Существует всего два типа поведенческих сущностей.

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

Рис. 19 Сообщение

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



Рис. 20 Состояние

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

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

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

Рис. 21 Пакеты

Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.

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

Примечание (Note) - это символ для изображения комментариев, присоединенных к элементу или группе элементов (рис. 22).



Рис. 22 Примечание

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

Отношения

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

Зависимость (Dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой (рис. 23).

Рис. 23 Отношения зависимости

Ассоциация (Association) - отношение, описывающее совокупность связей между объектами. Разновидностью ассоциации является агрегирование (Aggregation) - структурное отношение между целым и его частями (рис. 23). Графическое изображение ассоциации может включать кратность и имена ролей (рис 24.)

Рис. 24 Имена ассоциаций

Обобщение (Generalization) - это отношение "специализация/обобщение"

(рис. 25), при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent).

Рис. 25 Обобщение



Наконец, реализация (Realization) - это отношение между классификаторами, при котором один классификатор определяет "контракт", а другой гарантирует его выполнение (рис. 26).

Рис. 26 Реализация

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

Диаграммы

Диаграмма в UML - это графическое представление набора элементов, изображаемое в виде связанного графа с вершинами (сущностями) и ребрами (отношениями), используемое для визуализации системы с разных точек зрения. В UML выделяют 8 типов диаграмм (рис. 27).

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



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

На диаграмме вариантов использования (Use case diagram) представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Они используются при моделировании поведения системы.

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

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

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

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

На диаграмме развертывания (Deployment diagram) представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов.



Лекция 4. Свойства информационных систем в бизнесе

Диаграммы случаев использования (use case diagrams).

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

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

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

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

Рис. 28 Графическое обозначение варианта использования

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

Рис. 29 Графическое обозначение актера

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

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

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

Рис. 30 Графическое изображение интерфейсов на диаграммах вариантов использования

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

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

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

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

Рис. 32 Примеры примечаний в языке UML

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

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

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

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

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

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

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

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



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

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

Отношение включения между двумя вариантами использования указывает, что поведение одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает"), как показано на рис. 36.

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

При моделировании возникает необходимость в указании количества объектов, связанных посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде (рис. 37). Кратность указывает на то, столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), указать диапазон: "ноль или единица" (0..1), "много" (0..*), "единица или больше" (1..*). Разрешается также указывать определенное число (например, 3).

Рис. 37 Кратность

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

Рассмотрим диаграмму вариантов использования отражающую систему работы банковского автомата (Automated Teller Machine, ATM) (рис. 38).

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

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



Лекция 5. Описание основной структуры и этапов анализа

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

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

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

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

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

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

Рис. 39 Графическое изображение состояния действия

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

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

Ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 40).

В качестве примера рассмотрим фрагмент алгоритма нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду: а*х*х + Ь*х + с = 0 необходимо вычислить его дискриминант. Причем, в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной расчетной формулы.

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

Рис. 40 Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения

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



Рис. 41 Разделения и слияния параллельных потоков управления

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

Рис. 42 Вариант диаграммы деятельности с дорожками

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

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

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

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

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



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

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



Лекция 7-8. Описание основной структуры и этапов анализа

Диаграммы развертывания (deployment diagram)

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

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

Элементы диаграмм развертывания

К основным элементам диаграммы развертывания относятся узлы и соединения.

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

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

Рис. 44 Графическое изображение узла на диаграмме развертывания

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

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

Рис. 45 Помеченные значения

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

Рис. 46 Графическое изображение узла-экземпляра с дополнительной информацией в форме помеченного значения

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



Рис. 47 Фрагмент диаграммы развертывания с соединениями между узлами

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

Рис. 48 Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем компонентами

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

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



Рис. 49 Диаграмма развертывания для системы удаленного обслуживанияклиентов банка

На диаграмме развертывания узлами системы являются удаленный терминал (узел-тип) и сервер банка (узел-экземпляр). Указана зависимость компонента реализации диалога "dialog.exe" на удаленном терминале от интерфейса lAuthorise, реализованного компонентом "main.exe", который, в свою очередь, развернут на анонимном узле-экземпляре "Сервер банка". Последний зависит от компонента базы данных "Клиенты банка", который развернут на этом же узле. Примечание указывает на необходимость использования защищенной линии связи для обмена данными в данной системе. Другой вариант записи этой информации заключается в дополнении диаграммы узлом со стереотипом "закрытая сеть".



Лекция 8. Средства разработки систем

Диаграммы компонентов (component diagram)

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

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

• визуализации общей структуры исходного кода программной системы;

• спецификации исполнимого варианта программной системы;

• обеспечения многократного использования отдельных фрагментов программного кода;

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

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



Основные графические элементы диаграммы компонентов

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

Рис. 50 Графическое изображение компонента в языке UML

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

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

• компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций: динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp.

• компоненты-рабочие продукты: файлы с исходными текстами программ, например, с расширениями h или срр для языка C++.

• компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе.

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

а) б)

Рис. 51 Графическое изображение интерфейсов на диаграмме компонентов

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

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

В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 52). Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем "main.exe" зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем "image.java". Для второго компонента этот же интерфейс является экспортируемым.

Рис. 52. Фрагмент диаграммы компонентов с отношением зависимости

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



Рис. 53 Графическое изображение зависимости между компонентом и классами



Лекция 9. Средства и технологии моделирования

Диаграммы коммуникаций (communication diagrams).

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

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

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

Проще всего привести описание диаграммы коммуникаций на примере:

Рис. 54. Графическое изображение диаграмм коммуникаций в UML

На примере видим, что актор User взаимодействует с экземпляром страницы LoginPage, который в свою очередь работает с классом SecutiryManager, который оперирует объектами типа User.

Элементы диаграммы коммуникаций могут быть связаны отношением «Ассоциация». Как я уже указывал выше Ассоциация имеем достаточно широкое значение и может трактоваться по разному (см. Диаграммы классов).

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

Рис. 55. Пример нумерованных диаграмм коммуникаций



Лекция 10. Моделирование требований

Диаграммы последовательности (sequence diagram)

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

Объекты диаграммы последовательности

менеджмент дизайн интерфейс бизнес

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

Рис. 56 Графические примитивы диаграммы последовательности

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то его линия жизни должна начинаться в верхней части диаграммы и заканчиваться в нижней части (объекты 1 и 2 на рис. 56). Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены, чтобы освободить занимаемые ими ресурсы. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X" (объект 3 на рис. 56). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность (объект 6 на рис. 57).

Рис. 57 Варианты линий жизни и фокусов управления объектов

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

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



Рис. 58 примеры сообщений

Простое сообщение используется по умолчанию. Означает, что все сообщения выполняются в одном потоке управления (рис. 58, 1).

Синхронное (synchronous) применяется, когда клиент посылает сообщение и ждет ответа пользователя (рис. 58, 2).

Сообщение с отказом становиться в очередь (balking): клиент посылает сообщение серверу и, если сервер не может немедленно принять сообщение, оно отменяется (рис. 58, 3).

Сообщение с лимитированным временем ожидания (timeout): клиент посылает сообщение серверу, а затем ждет указанное время; если в течение этого времени сервер не принимает сообщение, оно отменяется (рис 58, 4).

Асинхронное сообщение (asynchronous): клиент посылает сообщение серверу и продолжает свою работу, не ожидая подтверждения о получении (рис. 58, 5).

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

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

Эта диаграмма последовательности отображает поток событий в рамках варианта использования "Снять деньги". В верхней части диаграммы показаны все действующие лица и объекты, требуемые системе для выполнения варианта использования "Снять деньги". Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме Последовательности показаны именно объекты, а не классы. Классы представляют собой типы объектов. Объекты конкретны; вместо класса Клиент на диаграмме Последовательности представлен конкретный клиент Джо.Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения - этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет" (account) и инициализирует экран ATM. Экран запрашивает у клиента его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет" и обнаруживает, что он правильный. Затем экран предоставляет клиенту меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и клиент указывает 20$. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет". Во-первых, осуществляется проверка, что на этом счету лежат, по крайней мере, 20$. Во- вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию выдать чек и $20 наличными. Наконец все тот же объект "счет " дает устройству для чтения карточек инструкцию вернуть карточку.



Рис. 59 Диаграмма последовательности для снятия клиентом 20$

Таким образом, диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на примере снятия клиентом 20$. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики - объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.



Лекция 11-12. Моделирование данных и процессов. Моделирование объектов.

Временные диаграммы (timing diagrams).

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

Рис. 60. Пример временной диаграммы



На рис. 60. показан фрагмент работы системы AccessControl, которая управляет открытием/блокированием двери в помещение по предъявлению человеком электронного ключа. На рисунке показано три компоненты этой системы. Первая, panel, является устройством, у которого есть дисплей для отображения текущего состояния всей системы и устройство считывания электронного ключа. Исходно panel находится в состоянии locked (соответствующая надпись отображается и на дисплее). После того как человек приложил к этому устройству электронный ключ и устройство считало с него информацию, panel посылает эту информацию в виде сообщения verify второй компоненте - процессору ( access_processor ) - и переходит в состояние waiting. Процессор до получения сообщения verify находится в состоянии idle, а после получения этого сообщения он переходит в состояние verifying. После успешного окончания проверки данных электронного ключа процессор посылает компонентам panel и door сообщения unlock и переходит в состояние enable. Компонента panel переходит в состояние open. Третья компонента, door (собственно, сама дверь), до этого находилась в состоянии locked и, получив сообщение unlock, открывается (переходит в состояние unlock ). Открытой она остается ровно 5 секунд, после чего процессор присылает ей команду lock и она закрывается - снова переходит в состояние locked. Одновременно процессор посылает команду lock также и компоненте panel, которая переходит в свое исходное состояние locked и отображает слово "locked" на дисплее.

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

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



Лекция 14. Проектирование пользовательского интерфейса

Диаграммы схем взаимодействия (interaction overview diagram)

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

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

Взаимодействие происшествий

Взаимодействие происшествий - это ссылки к существующим диаграммам взаимодействия. На них указывается названия фрейм ссылки с обозначением «ref» в верхнем левом углу. Название диаграммы на которую ведется ссылка указывается по центру фрейма.

Рис. 61. Взаимодействие происшествий

Элемент взаимодействия

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

Рис. 62. Элемент взаимодействия

Объединяя все вместе

Все элементы диаграмм активности (fork, join, merge, и т.д.) могут быть использованы в диаграммах схем взаимодействия для логического отображения диаграмм более низкого уровня. На текущем примере показан пример процесса продаж, с под-процессом взаимодействия происшествий.

Рис. 63. Пример процесса продаж, с под-процессом взаимодействия происшествий



На следующем примере показан пример процесса плановой проверки, с под-процессом элемента взаимодействия

Рис. 64 . Пример процесса плановой проверки, с под-процессом элемента взаимодействия



Лекция 13. Технико-экономический анализ системы

Типовая проверка и дизайн.

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

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

1. Описание потребностей и их анализ

2. Дизайн программного продукта

3. Разработка

4. Проверка

5. Выпуск и внедрение продукта

6. Обслуживание продукта

Описание потребностей и их анализ

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

Дизайн программного продукта

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

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

· Надёжность

· Возможность внесения изменений

· Понятность

· Возможность повторного использования.

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

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

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

На этапе дизайна приходится решать также, на сколько и на какие части делится программный продукт. При делении на части необходимо особенно учитывать требование повторного использования - в случае слишком больших частей их повторное использование может оказаться сложной задачей, а в случае частей слишком малого объема изначальные затраты на разработку могут стать нецелесообразно большими. На сегодняшний день имеется мало программного обеспечения, где возможно монолитное решение. Для деления программного решения на части используются два подхода: сверху-вниз (англ. top-down) и снизу-вверх (англ.bottom-up).

...