Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
 Скачать 3.17 Mb.
|
|
Диаграммы последовательностей Этот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассо- циированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают «время Рис. 9.4: Связи на диаграммах прецедентов жизни» объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта. • вводятся строки заказа; • по каждой строке проверяется наличие товара; • если запас достаточен — инициируется поставка; • если запас недостаточен — инициируется дозаказ (повторный заказ). Сообщения появляются в той последовательности, как они показаны на диаграмме — сверху вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной «линии жизни». На диаграммы может быть добавлена управляющая информация: описание условий, при кото- рых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения. Кооперативные диаграммы На кооперативных диаграммах объекты (или классы) показываются в виде прямоугольников, а стрел- ками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использова- ния. Временная последовательность сообщений отражается их нумерацией. Диаграммы состояний Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объ- Рис. 9.5: Диаграмма последовательности обработки заказа Рис. 9.6: Кооперативная диаграмма прохождения заказа екта в результате некоторых событий.Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах. Прямоугольниками представляются состояния, через которые проходит объект во время своего поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки пред- ставляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта. Имеется также два вида псевдо-состояний: начальное состояние, в котором нахо- дится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел. Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рис. 9.7 ): <Событие> <[Условие]> < / Действие>. На диаграммах также отображаются функции, которые выполняются объектом в определенном со- стоянии. Синтаксис метки деятельности: выполнить/< деятельность >. Диаграммы деятельности Диаграмма деятельности — это частный случай диаграммы состояний. На диаграмме деятельно- сти представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов. Основными элементами диаграмм деятельности являются (рис. 9.8 ): • овалы, изображающие действия объекта; Рис. 9.7: Диаграмма состояний объекта «заказ» Рис. 9.8: Диаграмма деятельности — обработка заказа • линейки синхронизации, указывающие на необходимость завершить или начать несколько дей- ствий (модель логического условия «И»); • ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия «ИЛИ»); • стрелки — отражают последовательность действий, могут иметь метки условий. На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы. Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания). Диаграммы компонентов Диаграммы компонентов позволяют изобразить модель системы на физическом уровне. Элементами диаграммы являются компоненты — физические замещаемые модули системы. Каж- дый компонент является полностью независимым элементом системы. Разновидностью компонентов являются узлы. Узел — это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Узлы делятся на два типа: • устройства — узлы системы, в которых данные не обрабатываются. • процессоры — узлы системы, осуществляющие обработку данных. Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML. Компонентом может быть любой достаточно крупный модульный объект, такой как таблица или экстент базы данных, подсистема, бинарный исполняемый файл, готовая к использованию систе- ма или приложение. Таким образом, диаграмму компонентов можно рассматривать как диаграмму классов в более крупном (менее детальном) масштабе. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Основное назначение диаграмм компонентов — разделение системы на элементы, которые имеют стабильный интерфейс и образуют единое целое. Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем. На рис. 9.9 показана упрощенная схема элементов фрагмента корпоративной системы. «Коробки» представляют собой компоненты — приложения или внутренние подсистемы. Пунктирные линии отражают зависимости между компонентами. Каждый компонент диаграммы при необходимости документируется с помощью более детальной диаграммы компонентов, диаграммы сценариев или диаграммы классов. Пакеты UML Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить диаграммы различного типа и назначения. В отличие от компонентов, существую- щих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Изображается пакет в виде папки с закладкой, содержащей, как пра- вило, только имя и иногда — описание содержимого. Диаграмма пакетов содержит пакеты классов и зависимости между ними. Зависимость между двумя пакетами имеет место в том случае, если изменения в определении одного элемента влекут Рис. 9.9: Диаграмма компонентов фрагмента КИС за собой изменения в другом. По отношению к пакетам можно использовать механизм обобщения (см. выше раздел «Диаграммы классов» ). Контрольные вопросы 1. Укажите основные свойства языка моделирования UML Является основой CASE-средств нижнего уровня (lower CASE tools) Является языком визуального моделирования, который обеспечивает разработку репрезента- тивных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС Содержит механизмы расширения и специализации базовых концепций языка 2. Что представляет собой класс в UML? Описание объекта Описание совокупности однородных объектов Описание связи между объектами 3. Что такое «атрибут класса»? Наименование класса Свойство объектов класса, которое может принимать множество значений Числовая характеристика допустимого количества объектов в классе 4. Что определяет свойство «видимость атрибута»? Возможность отображения атрибута в экранных формах Область действия атрибута Возможность использования атрибута другими классами 5. Укажите возможные значения видимости свойства класса Abstract (служебный) Protected (защищённый) Private (закрытый) Singleton (единственный) 6. Укажите возможные типы отношений между классами UML Иерархия Ассоциация Зависимость Обобщения 7. Определите назначение диаграммы использования Описывает взаимосвязи между объектами системы Определяет последовательность действий при выполнении некоторой функции Описывает функциональность ИС, которая будет видна пользователям системы 8. Определите назначение диаграмм последовательностей Описывают последовательные изменения состояния системы Используются для точного определения логики сценария выполнения прецедента Отражают переходы потока управления от одной деятельности к другой внутри системы 9. В каких случаях целесообразно использовать диаграммы деятельности? Для описания потока сообщений, которыми обмениваются объекты Для описания взаимодействия пользователей с системой Для описания поведения, включающего в себя множество параллельных процессов Набрано баллов 10 Этапы проектирования ИС с применением UML UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм. На этапе создания концептуальной модели для описания бизнес-деятельности используются мо- дели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов – модели бизнес-объектов и диаграммы последовательностей. На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использо- ванием диаграмм классов, диаграмм последовательностей и диаграмм состояний. На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания. Ниже приводятся определения и описывается назначение перечисленных диаграмм и моделей при- менительно к задачам проектирования ИС (в скобках приведены альтернативные названия диаграмм, использующиеся в современной литературе). Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщен- ная модель функционирования системы в окружающей среде. Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес- 3 процесса или поведения системы в рамках прецедента. Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или коопера- тивных диаграмм (collaboration diagrams). Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее ком- понентов при переходе из одного состояния в другое. Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами. Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таб- лицы, столбцы, ограничения и т.п. Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС. Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС. На рис. 10.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..."(например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последо- вательности). Приведенная схема является наглядной иллюстрацией итеративного характера разра- ботки моделей с использованием UML. Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML. Рис. 10.1: Взаимосвязи между диаграммами UML 10.1 Разработка модели бизнес-прецедентов Модель бизнес-прецедентов описывает бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на деятельность организации извне. Проектирование системы начинается с изучения и моделирования бизнес-деятельности органи- зации. На этом этапе вводится и отображается в модели ряд понятий, свойственных объектно- ориентированному подходу: Исполнитель (Действующее лицо, Actor) – личность, организация или система, взаимодейству- ющая с ИС; различают внешнего исполнителя (который использует или используется системой, т.е. порождает прецеденты деятельности) и внутреннего исполнителя (который обеспечивает ре- ализацию прецедентов деятельности внутри системы). На диаграмме исполнитель представляется стилизованной фигуркой человека. Прецедент – законченная последовательность действий, инициированная внешним объектом (лич- ностью или системой), которая взаимодействует с ИС и получает в результате некоторое сообщение от ИС. На диаграмме представляется овалом с надписью, отражающей содержание действия. Класс — описание совокупности однородных объектов с их атрибутами, операциями, отношениями и семантикой. На диаграмме представляется прямоугольником, содержащим описания атрибутов и операций класса. Ассоциация – связь между двумя элементами модели. На диаграмме представляется линией. Обобщение – связь между двумя элементами модели, когда один элемент (подкласс) является частным случаем другого элемента (суперкласса). На диаграмме представляется стрелкой. Агрегация – отношение между элементами модели, когда один элемент является частью другого элемента (агрегата). На диаграмме представляется стрелкой с ромбовидным концом. Для иллюстрации этапов разработки проекта использованы адаптированные материалы проекта ИС медицинского центра (рис. 10.2 ). Назначение ИС – автоматизация ведения и использования клинических записей о пациентах. В настоящее время эта работа производится вручную персоналом центра. На рис. 10.2 представлена общая модель деятельности центра в виде диаграммы прецеден- тов. Прецедент "Обслуживание пациента"реализуется через множество других, более ограниченных прецедентов (рис. 10.3 ), отражающих детализацию представления функционирования центра. Для включения в диаграмму выбранные прецеденты должны удовлетворять следующим критериям: • прецедент должен описывать, ЧТО нужно делать, а не КАК; • прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ; • прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ; • последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИ- МУЮ цепочку. Исходя из цели создания системы, для дальнейшего исследования и моделирования отбираются только те бизнес-прецеденты, которые связаны с использованием клинических записей. Выполнение прецедента описывается с помощью диаграмм видов деятельности, которые отобража- ют исполнителей и последовательность выполнения соответствующих бизнес-процессов (рис. 10.4 ). Несмотря на то, что оказание медицинской помощи предусматривает множество разнообразных действий исполнителей, для нашей задачи существенными являются только процессы обмена инфор- мацией между этими исполнителями, и именно они отображаются в создаваемых моделях. Поэтому на диаграмме отражен процесс оценки состояния пациента на основании имеющейся в центре ин- формации о нем. Общее поле диаграммы деятельности делится на несколько "плавательных дорожек каждая из которых содержит описание действий одного из исполнителей. Основными элементами диаграмм Рис. 10.2: Общая диаграмма деятельности медицинского центра по обслуживанию пациента Рис. 10.3: Модель бизнес-прецедентов, составляющих обслуживание пациента Рис. 10.4: Диаграмма видов деятельности для прецедента “Оказание медицинской помощи” видов деятельности являются обозначения состояния ("начало "конец"), действия (овал) и момента синхронизации действий (линейка синхронизации, на которой сходятся или разветвляются несколь- ко стрелок). Диаграмма подходит для описания действий как внешнего, так и внутреннего специалиста центра. Этап завершается после разработки диаграмм видов деятельности для всех выделенных в мо- дели бизнес-прецедентов. Естественно, на последующих этапах анализа и проектирования будут выявлены какие-то важные подробности в описании деятельности объекта автоматизации. Поэтому разработанные на данном этапе модели будут еще неоднократно корректироваться. 10.2 Разработка модели бизнес-объектов Следующим этапом проектирования ИС является разработка модели бизнес-объектов, которая пока- зывает выполнение бизнес-процессов организации ее внутренними исполнителями. Основными ком- понентами моделей бизнес-объектов являются внешние и внутренние исполнители, а также бизнес- сущности, отображающие все, что используют внутренние исполнители для реализации бизнес- процессов. Пример модели бизнес-объектов для прецедента "Ответ на запрос"приведен на рис. 10.5 В этой диаграмме появилось новое действующее лицо – отправитель запроса. На самом деле с запросом о состоянии пациента могут обращаться в систему многие из действующих лиц: юрист, страховая компания, технический персонал и даже сам пациент. Таким образом, понятие "Отпра- витель запроса"служит для обобщенного представления всех этих действующих лиц при описании прецедента "Ответ на запрос"(рис. 10.6 ). "Отправитель запроса"становится суперклассом по отноше- нию к обобщаемым понятиям (подклассам). Для детального описания выполнения бизнес-процессов обычно используются диаграммы последовательностей (рис. 10.7 ). Рис. 10.5: Модель бизнес-объектов прецедента “Ответ на запрос” Рис. 10.6: Обобщение классов Рис. 10.7: Диаграмма последовательностей для прецедента “Ответ на запрос” Основными элементами диаграммы последовательностей являются обозначения объектов (пря- моугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. Результатом этого этапа являются согласованные с заказчиком и достаточно подробные описания действий специалистов организации, внедряющей ИС, необходимые для обеспечения исполнения ее функций. |