Чтение онлайн

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

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

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

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

Примечание.

При построении UML-диаграмм общепринято использование языка объектных ограничений (Object Constraint Language, ОСL), разработанного фирмой IBM. Язык OCL похож на SQL, но создан специально для навигации и получения данных от объектов. Ввиду ограниченности объема книги мы его рассматривать не будем.

Диаграмма прецедентов.

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

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

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

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

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

Рис. 3.2. Графическое изображение прецедента.

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

Рис. 3.3. Графическое изображение примечания.

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

Примечание.

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

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

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

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

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

В нотации UML английские имена интерфейсов принято начинать с буквы I.

Примечание.

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

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

Ниже перечислены определенные в нотации UML виды отношений между компонентами на диаграммах прецедентов.

• Отношение ассоциации (association relationship) устанавливает роль пользователя в системе. Обозначается сплошной линией между пользователем и прецедентом (рис. 3.5, а).

• Отношение расширения (extend relationship) определяет взаимосвязь прецедента с прецедентом, возможности которого он может использовать. Графически обозначается пунктирной стрелкой с пометкой «extend» от дополняющего прецедента к расширяемому. Случай, изображенный на рис. 3.5, б, говорит, что при определенных условиях прецедент B может быть дополнен прецедентом A. На практике это может означать, например, дополнительные (помимо обычных) меры к идентификации личности человека.

• Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента. Графически обозначается непрерывной стрелкой от общего к частному (рис. 3.5, в).

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

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

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

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

Рис. 3.6. Прием пациента в больницу.

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

Примечание.

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