Похожие работы
|
Лекция: Основные понятия технологии проектирования информационных систем (ИС) Предмет - страница №16/16
Синтаксис и семантика основных объектов UMLКлассыКлассы — это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой. В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Если используется составное имя (в начале имени добавляется имя пакета, куда входит класс), то имя класса должно быть уникальным в пакете. Атрибут — это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. На рис. 11.1 приведено графическое изображение класса «Заказ» в нотации UML. Рис. 11.1. Изображение класса в UML Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным): < признак видимости> <�имя атрибута> : <�тип данных> = <�значение по умолчанию> Видимость свойства указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости:
Еще одной важной характеристикой атрибутов и операций классов является область действия. Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами:
Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов:
Принципиальное назначение классов характеризуют стереотипы. Это, фактически, классификация объектов на высоком уровне, позволяющая определить некоторые основные свойства объекта (пример стереотипа — класс «действующее лицо»). Механизм стереотипов является также средством расширения словаря UML за счет создания на основе существующих блоков языка новых, специфичных для решения конкретной проблемы. Диаграммы классовКлассы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними. Классы отображают типы объектов системы. Между классами возможны различные отношения, представленные на рис. 11.2:
Рис. 11.2. Отображение связей между классами Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса «товар») может повлиять на использующий его элемент (класс «строка заказа»). Часто зависимости показывают, что один класс использует другой в качестве аргумента. Обобщение — это отношение между общей сущностью (родителем — класс «клиент») и ее конкретным воплощением (потомком — классы «корпоративный клиент» или «частный клиент»). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у(?) родителя, замещает(?) операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым. Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рис. 11.3). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.
Такого рода ассоциация является простой и отражает отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа «часть-целое», то используется специальный тип ассоциации — агрегирование. В такой ассоциации один из классов имеет более высокий ранг (целое — класс «заказ», рис. 11.2) и состоит из нескольких меньших по рангу классов (частей — класс «строка заказа»). В UML используется и более сильная разновидность агрегации — композиция, в которой объект-часть может принадлежать только единственному целому. В композиции жизненный цикл частей и целого совпадают, любое удаление целого обязательно захватывает и его части. Для ассоциаций можно задавать атрибуты и операции, создавая по обычным правилам UML классы ассоциаций. Диаграммы использованияДиаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:
Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актерами, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы. На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 11.4). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. На рис. 11.4 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа. Рис. 11.4. Связи на диаграммах прецедентов Динамические аспекты поведения системы отражаются приведенными ниже диаграммами. В отличие от некоторых подходов объектного моделирования, когда и состояние, и поведение системы отображаются на диаграммах классов, UML отделяет описание поведения в диаграммы взаимодействия. В UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений между объектами выносится на диаграммы взаимодействия. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках одного варианта использования. Прямоугольники на диаграмме представляют различные объекты и роли, которые они имеют в системе, а линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения. Существуют два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы. Диаграммы последовательностейЭтот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают «время жизни» объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта. Рис. 11.5. Диаграмма последовательности обработки заказа
Рис. 11.6. Кооперативная диаграмма прохождения заказа Сообщения появляются в той последовательности, как они показаны на диаграмме — сверху вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной «линии жизни». На диаграммы может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения. Кооперативные диаграммыНа кооперативных диаграммах объекты (или классы) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией. Диаграммы состоянийДиаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий.Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах. Прямоугольниками представляются состояния, через которые проходит объект во время своего поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта. Имеется также два вида псевдо-состояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел. Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рис. 11.7): Рис. 11.7. Диаграмма состояний объекта «заказ» < Событие> <[Условие]> < / Действие>. На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии. Синтаксис метки деятельности: выполнить/< деятельность >. Диаграммы деятельностиДиаграмма деятельности — это частный случай диаграммы состояний. На диаграмме деятельности представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов. Основными элементами диаграмм деятельности являются (рис. 11.8):
На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы. Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания). Диаграммы компонентовДиаграммы компонентов позволяют изобразить модель системы на физическом уровне. Элементами диаграммы являются компоненты — физические замещаемые модули системы. Каждый компонент является полностью независимым элементом системы. Разновидностью компонентов являются узлы. Узел — это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Узлы делятся на два типа:
Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML. Компонентом может быть любой достаточно крупный модульный объект, такой как таблица или экстент базы данных, подсистема, бинарный исполняемый файл, готовая к использованию система или приложение. Таким образом, диаграмму компонентов можно рассматривать как диаграмму классов в более крупном (менее детальном) масштабе. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Основное назначение диаграмм компонентов — разделение системы на элементы, которые имеют стабильный интерфейс и образуют единое целое. Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем. На рис. 11.9 показана упрощенная схема элементов фрагмента корпоративной системы. «Коробки» представляют собой компоненты — приложения или внутренние подсистемы. Пунктирные линии отражают зависимости между компонентами.
Каждый компонент диаграммы при необходимости документируется с помощью более детальной диаграммы компонентов, диаграммы сценариев или диаграммы классов. Пакеты UMLПакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить диаграммы различного типа и назначения. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда — описание содержимого. Диаграмма пакетов содержит пакеты классов и зависимости между ними. Зависимость между двумя пакетами имеет место в том случае, если изменения в определении одного элемента влекут за собой изменения в другом. По отношению к пакетам можно использовать механизм обобщения (см. выше раздел «Диаграммы классов» ). 12. Лекция: Этапы проектирования ИС с применением UML Основные типы UML-диаграмм, используемые в проектировании информационных систем. Взаимосвязи между диаграммами. Поддержка UML итеративного процесса проектирования ИС. Этапы проектирования ИС: моделирование бизнес-прецедентов, разработка модели бизнес-объектов, разработка концептуальной модели данных, разработка требований к системе, анализ требований и предварительное проектирование системы, разработка моделей базы данных и приложений, проектирование физической реализации системы. UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм. На этапе создания концептуальной модели для описания бизнес-деятельности используются модели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов – модели бизнес-объектов и диаграммы последовательностей. На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использованием диаграмм классов, диаграмм последовательностей и диаграмм состояний. На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания. Ниже приводятся определения и описывается назначение перечисленных диаграмм и моделей применительно к задачам проектирования ИС (в скобках приведены альтернативные названия диаграмм, использующиеся в современной литературе). Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде. Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента. Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams). Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое. Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами. Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п. Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС. Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС. На рис. 12.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение «является источником входных данных для...» (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.
Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML. Разработка модели бизнес-прецедентовМодель бизнес-прецедентов описывает бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на деятельность организации извне. Проектирование системы начинается с изучения и моделирования бизнес-деятельности организации. На этом этапе вводится и отображается в модели ряд понятий, свойственных объектно-ориентированному подходу: Исполнитель (Действующее лицо, Actor) – личность, организация или система, взаимодействующая с ИС; различают внешнего исполнителя (который использует или используется системой, т.е. порождает прецеденты деятельности) и внутреннего исполнителя (который обеспечивает реализацию прецедентов деятельности внутри системы). На диаграмме исполнитель представляется стилизованной фигуркой человека. Прецедент – законченная последовательность действий, инициированная внешним объектом (личностью или системой), которая взаимодействует с ИС и получает в результате некоторое сообщение от ИС. На диаграмме представляется овалом с надписью, отражающей содержание действия. Класс — описание совокупности однородных объектов с их атрибутами, операциями, отношениями и семантикой. На диаграмме представляется прямоугольником, содержащим описания атрибутов и операций класса. Ассоциация – связь между двумя элементами модели. На диаграмме представляется линией. Обобщение – связь между двумя элементами модели, когда один элемент (подкласс) является частным случаем другого элемента (суперкласса). На диаграмме представляется стрелкой. Агрегация – отношение между элементами модели, когда один элемент является частью другого элемента (агрегата). На диаграмме представляется стрелкой с ромбовидным концом. Для иллюстрации этапов разработки проекта использованы адаптированные материалы проекта ИС медицинского центра [рис. 12.1]. Назначение ИС – автоматизация ведения и использования клинических записей о пациентах. В настоящее время эта работа производится вручную персоналом центра. На рис. 12.2 представлена общая модель деятельности центра в виде диаграммы прецедентов. Прецедент «Обслуживание пациента» реализуется через множество других, более ограниченных прецедентов (рис. 12.3), отражающих детализацию представления функционирования центра. Рис. 12.2. Общая диаграмма деятельности медицинского центра по обслуживанию пациента Рис. 12.3. Модель бизнес-прецедентов, составляющих обслуживание пациента Для включения в диаграмму выбранные прецеденты должны удовлетворять следующим критериям:
Исходя из цели создания системы, для дальнейшего исследования и моделирования отбираются только те бизнес-прецеденты, которые связаны с использованием клинических записей. Выполнение прецедента описывается с помощью диаграмм видов деятельности, которые отображают исполнителей и последовательность выполнения соответствующих бизнес-процессов (рис. 12.4).
Несмотря на то, что оказание медицинской помощи предусматривает множество разнообразных действий исполнителей, для нашей задачи существенными являются только процессы обмена информацией между этими исполнителями, и именно они отображаются в создаваемых моделях. Поэтому на диаграмме отражен процесс оценки состояния пациента на основании имеющейся в центре информации о нем. Общее поле диаграммы деятельности делится на несколько «плавательных дорожек», каждая из которых содержит описание действий одного из исполнителей. Основными элементами диаграмм видов деятельности являются обозначения состояния («начало», «конец»), действия (овал) и момента синхронизации действий (линейка синхронизации, на которой сходятся или разветвляются несколько стрелок). Диаграмма подходит для описания действий как внешнего, так и внутреннего специалиста центра. Этап завершается после разработки диаграмм видов деятельности для всех выделенных в модели бизнес-прецедентов. Естественно, на последующих этапах анализа и проектирования будут выявлены какие-то важные подробности в описании деятельности объекта автоматизации. Поэтому разработанные на данном этапе модели будут еще неоднократно корректироваться. Разработка модели бизнес-объектовСледующим этапом проектирования ИС является разработка модели бизнес-объектов, которая показывает выполнение бизнес-процессов организации ее внутренними исполнителями. Основными компонентами моделей бизнес-объектов являются внешние и внутренние исполнители, а также бизнес-сущности, отображающие все, что используют внутренние исполнители для реализации бизнес-процессов. Пример модели бизнес-объектов для прецедента «Ответ на запрос» приведен на рис. 12.5. Рис. 12.5. Модель бизнес-объектов прецедента «Ответ на запрос» В этой диаграмме появилось новое действующее лицо – отправитель запроса. На самом деле с запросом о состоянии пациента могут обращаться в систему многие из действующих лиц: юрист, страховая компания, технический персонал и даже сам пациент. Таким образом, понятие «Отправитель запроса» служит для обобщенного представления всех этих действующих лиц при описании прецедента «Ответ на запрос» (рис. 12.6). «Отправитель запроса» становится суперклассом по отношению к обобщаемым понятиям (подклассам).
Для детального описания выполнения бизнес-процессов обычно используются диаграммы последовательностей (рис. 12.7).
Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. Результатом этого этапа являются согласованные с заказчиком и достаточно подробные описания действий специалистов организации, внедряющей ИС, необходимые для обеспечения исполнения ее функций. Разработка концептуальной модели данныхЗатем на основе информации, выявленной на этапах бизнес-моделирования, выполняется разработка концептуальной модели данных, которые будут использоваться в разрабатываемой системе. На рис. 12.8 представлена в виде диаграммы классов модель данных для объекта «Клинические записи». Рис. 12.8. Концептуальная модель данных Модель показывает, что клинические записи включают (агрегируют) ряд блоков. При этом «минимальный набор данных» и «план лечения» могут быть включены в каждую клиническую запись в единственном экземпляре, а блоки «результаты анализов», «предписания врача», «ход лечения» могут повторяться неограниченное число раз. Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым. Поскольку пациент может предварительно проходить лечение в других учреждениях, или несколько раз проходить лечение в центре, появляются дополнительные разновидности (подклассы) клинических записей: внешние, старые внутренние, новые внутренние. Этот этап завершает процедуры бизнес-моделирования и позволяет представить команде проектировщиков в едином формате ту информацию, которая будет необходима для создания системы. Разработанные диаграммы являются отправной точкой в процессах проектирования баз данных и приложений системы, обеспечивают согласованность действий бизнес-аналитиков и разработчиков в процессе дальнейшей работы над системой. Эти диаграммы, конечно же, будут претерпевать изменения в процессе последующего проектирования, однако эти изменения будут фиксироваться в формате, уже привычном для всей команды разработчиков, и будут автоматически отражаться в последующих моделях. Разработка требований к системеНа этапе формирования требований, прежде всего, необходимо определить область действия разрабатываемой системы и получить точное представление о желаемых возможностях системы. Основой разработки требований является модель системных прецедентов, отражающая выполнение конкретных обязанностей внутренними и внешними исполнителями с использованием ИС. Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания прецедентов, содержащие определения используемых данных и точную последовательность их выполнения. Описание осуществляется в соответствии с принятым в организации шаблоном, который обычно включает следующие разделы:
В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в таблица 12.1.
На рис. 12.9 представлена модель системных прецедентов для бизнес-прецедента «Оказание медицинской помощи». Исходя из цели создания системы, в модели системных прецедентов отражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением клинических записей. Рис. 12.9. Модель системных прецедентов Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС. Внутренний исполнитель «Персонал центра» (см. рис. 12.4, рис. 12.7) и выполняемый им ручной процесс преобразован в системный прецедент «Предоставление доступа к клиническим записям». Внешние исполнители (например, «Производитель медицинского оборудования») непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей. В модели отражены два специальных типа связи между прецедентами (на рис. 12.9 соответствующие прецеденты выделены тенью):
Прецедент «Проверка прав доступа» впервые появился на диаграммах и реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение (рис. 12.10). В результате в проектируемой ИС появляются два новых объекта – программный модуль «Менеджер защиты» и информационный блок «Набор прав». Рис. 12.10. Диаграмма последовательностей для прецедента «Проверка прав» Таким образом, результатом разработки модели системных прецедентов является не только исчерпывающий перечень функций, которые должны быть реализованы в проектируемой системе, но и подробное описание необходимой реализации этих функций. Анализ требований и предварительное проектирование системы.Основные задачи этапа:
Основным инструментом на данном этапе являются диаграммы классов системы, которые строятся на основе разработанной модели системных прецедентов. Одновременно на этом этапе уточняются диаграммы последовательностей выполнения отдельных прецедентов, что приводит к изменениям в составе объектов и диаграммах классов. Это естественное отражение средствами UML итеративного процесса разработки системы. Диаграммы классов системы заполняются объектами из модели системных прецедентов. Они содержат описание этих объектов в виде классов и описание взаимодействия между классами. Диаграмма классов, описывающая процедуры защиты доступа к данным, приведена на рис. 12.11. Рис. 12.11. Диаграмма классов «Защита доступа» Таким образом, в результате этого этапа проектирования появляется достаточно подробное описание состава и функций проектируемой системы, а также информации, которую необходимо использовать в базе данных и в приложениях. Поскольку диаграммы классов строятся на основе разработанных ранее бизнес-моделей, появляется уверенность в том, что разрабатываемая система будет действительно удовлетворять исходным требованиям заказчика. В то же время, благодаря своему синтаксису, диаграммы классов оказываются хорошим средством структурирования и представления требований к функциональности, интерфейсам и данным для элементов проектируемой системы. Разработка моделей базы данных и приложенийНа этом этапе осуществляется отображение элементов полученных ранее моделей классов в элементы моделей базы данных и приложений:
Поскольку модели базы данных и приложений строятся на основе единой логической модели, автоматически обеспечивается связность этих проектов (рис. 12.12). Рис. 12.12. Связь между проектами базы данных и приложений В модель базы данных отображаются только перманентные классы, из которых удаляются атрибуты, не отображаемые в столбцах (например, атрибут типа «Общий объем продаж», который получается суммированием содержимого множества полей базы данных). Некоторые атрибуты (например, АДРЕС) могут отображаться в множество столбцов (СТРАНА, ГОРОД, УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС). Для каждого простого класса в модели базы данных формируется отдельная таблица, включающая столбцы, соответствующие атрибутам класса. Отображение классов подтипов в таблицы осуществляется одним из стандартных способов:
В первом случае для каждого из классов создается отдельная таблица, между которыми затем устанавливаются необходимые связи. Во втором случае создается таблица для суперкласса, а затем в каждую таблицу подклассов включаются столбцы для каждого из атрибутов суперкласса. В третьем – создается единая таблица, содержащая атрибуты как суперкласса, так и всех подклассов (рис. 12.13). При этом для выделения исходных таблиц подклассов в результирующую таблицу добавляется один или более дополнительных столбцов (на рисунке показан курсивом). Рис. 12.13. Преобразование иерархии в таблицу Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile for Database Design), который включает следующие основные компоненты диаграмм:
На рис. 12.14 представлен фрагмент модели базы данных — две таблицы, соответствующие классам «пациент» (рис. 12.3, рис. 12.6) и «минимальный набор данных» (рис. 12.8). Связь между ними обязательная, поскольку «минимальный набор данных» не может существовать без «пациента». Рис. 12.14. Фрагмент модели базы данных На диаграммах указываются дополнительные характеристики таблиц и столбцов:
Результатом этапа является детальное описание проекта базы данных и приложений системы. Проектирование физической реализации системыНа этом этапе проектирования модели баз данных и приложений дополняются обозначениями их размещения на технических средствах разрабатываемой системы. На рис. 12.15 приведено изображение разделения таблицы «пациент» на три экстента (<>) в соответствии с первой буквой фамилии пациента. Рис. 12.15. Экстенты таблицы «Пациент» Основными понятиями UML, которые используются на данном этапе, являются следующие:
Диаграммы развертывания позволяют отобразить на единой схеме различные компоненты системы (программные и информационные) и их распределение по комплексу технических средств (рис. 12.16). Рис. 12.16. Фрагмент диаграммы развертывания ИС Таким образом, при проектировании сложной ИС она разделяется на части, и каждая из них затем исследуется и создается отдельно. В настоящее время используются два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция. С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: «Программа = Данные + Алгоритмы». При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой «обрабатывающие центры» (функции), а связи между узлами описывают движение данных. При объектном разбиении в системе выделяются «активные сущности» – объекты (или компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствующие функции (методы) объекта. Если при проектировании ИС разбивается на объекты, то для ее визуального моделирования следует использовать UML. Если в основу проектирования положена функциональная декомпозиция ИС, то UML не нужен и следует использовать рассмотренные ранее структурные нотации. В то же время, при выборе подхода к разработке ИС следует учитывать, что визуальные модели все более широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. Они хорошо приспособлены для решения таких часто возникающих при создании систем задач как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки ИС, устойчивость к сбоям и т.п. Визуализированные средствами UML модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Они обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. << предыдущая страница |
|