Информационные системы
Шрифт:
Примечание.
Относительно имен компонентов диаграмм разработчиками программного обеспечения выработана рекомендация: изначально, при построении основ системы использовать имена компонентов на русском языке, что делает разработку более понятной. В дальнейшем постепенно, а к завершению разработки полностью, заменить названия английскими, которые могут быть восприняты компиляторами.
Между компонентами диаграммы прецедентов могут существовать различные отношения. Отношения могут быть между пользователями и прецедентами, между несколькими пользователями. Пользователь может взаимодействовать с несколькими прецедентами.
Ниже
• Отношение ассоциации (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. Прием пациента в больницу.
Диаграмма прецедентов в таком виде наглядно представляет первичные требования заказчика – в данном случае медицинского учреждения. Совокупность таких диаграмм в идеале должна полностью описывать требования к функциональности системы. На практике требования могут изменяться. Графическое представление требований к системе значительно
Примечание.
На диаграммах прецедентов не указывается, в какой последовательности выполняются операции. Данная информация может содержаться на диаграммах активности, взаимодействия и состояний.
Пакеты.
Для сложных систем возникает необходимость разбиения их на несколько составляющих, причем таким образом, чтобы это разбиение отражалось в обозначении компонентов. Для этих целей в языке UML служат пакеты (рис. 3.7).
Рис. 3.7. Графическое изображение пакета.
Компоненты, относящиеся к определенному пакету, могут быть доступны вне пакета, если указать имя компонента и его принадлежность определенному пакету через двойное двоеточие, например:
Эта запись означает, что пакет образует собственное пространство имен.
Как правило, элементы модели, входящие в пакет, логически связаны между собой.
Если количество классов в системе достаточно велико, иногда прибегают к построению диаграмм пакетов, разбивая систему на части на более высоком уровне, чем диаграммы классов.
Диаграмма классов.
Под классом в языке UML понимается множество объектов, обладающих одинаковой структурой, свойствами, отношениями с другими объектами.
Графически в самом общем виде класс представляется в виде прямоугольника с четырьмя секциями (на рис. 3.8, а показан формат, на рис. 3.8, б – пример). Любая из секций, кроме секции имени класса, может отсутствовать. В этом случае она не изображается либо оставляется пустой. Как правило, на начальном этапе проектирования разработчик располагает только общими представлениями о будущей структуре системы. В дальнейшем, по мере разработки, уточняются роли, свойства каждого класса, что находит отражение на соответствующих диаграммах классов.
Абстрактным классом называется класс, который не имеет экземпляров. Абстрактные классы весьма удобно использовать при конструировании иерархии в качестве промежуточных классов. Все, что касается абстрактных классов, в языке UML выделяется курсивом (в нотации Буча абстрактный класс помечается буквой A в треугольнике, обращенном вершиной вниз).
Рис. 3.8. Графическое изображение класса.
Имя класса в языке UML принято писать полужирным шрифтом в самой верхней секции графического изображения класса (имя абстрактного класса – полужирным шрифтом и курсивом). Здесь же указывается информация об отношениях этого класса к абстрактным классам, от которых он образован, а также служебная информация о процессе проектирования класса (лицо, ответственное за проектирование класса, язык реализации, номер версии и т. д.).
Свойства класса определяют состояние экземпляров класса (объектов). В общем виде формат записи свойства можно представить в виде строки:
Ниже перечислены аргументы этой строки.
• видимость – видимость свойства для других классов. Допустимые значения:
– public (или знак +) – свойство класса доступно любому другому классу;
– protected (или знак #) – свойство класса доступно только экземплярам этого класса и потомкам данного класса;