Характеристика диаграмм последовательности. Рассмотренные диаграммы деятельности используются для спецификации динамики поведения программных систем, время в явном виде в них не присутствует. Однако временной аспект поведения может им существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности.
Диаграмма последовательности системы — графическая модель, которая для определенного сценария варианта использования показывает динамику взаимодействия объектов во времени. Для построения диаграммы последовательности системы необходимо:
• идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни;
• из описания варианта использования определить множество системных событий и их последовательность;
• изобразить системные события в виде линий со стрелкой на конце между линиями жизни действующих лиц и системы, а также указать имена событий и списки передаваемых значений.
На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения.
Одно измерение — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается линией, что является признаком объекта, представляющим собой экземпляр класса (рис. 4.12).
Не исключается ситуация, когда имя объекта может отсутствовать на диаграмме последовательности. В этом случае указывается только имя класса, а сам объект считается анонимным. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 4.12). правее:изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом.
Второе измерение диаграммы последовательности — вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируется раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже».
Линия жизни объекта служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности.
Построение диаграммы последовательности целесообразно начинать с выделения из всей совокупности тех и только тех классов, объекты которых участвуют в моделируемом взаимодействии. После этого все объекты наносятся на диаграмму с соблюдением некоторого порядка инициализации сообщений. Здесь необходимо установить, какие объекты будут существовать постоянно, а какие временно — только на период выполнения ими требуемых действий. Когда объекты определены, можно приступать к спецификации сообщений. При этом следует учитывать роли, которые сообщения играют в системе.
Пример построения диаграммы последовательности. Для того чтобы более точно учитывать временной аспект поведения системы при моделировании процессов, описывающих взаимодей ие, можно построить диаграммы последовательности. В качестве примера построим диаграмму последовательности для реализации варианта использования «Продажа товара» в информационной системе «Склад оптовой торговли» (рис. 4.13).
Данная диаграмма содержит два объекта и одного актера.: Объекты не являются постоянно активными, что показано с помощью соответствующих фокусов управления. В качестве имен сообщений указаны имена операций, которые специфицированы у соответствующих классов. Предложения — условия некоторых сообщений записаны обычным текстом в квадратных скобках. Эти условия отражают возможность ветвления процесса продажи и выполнения исключительного сценария соответствующего варианта использования, однако другие варианты использования на данной диаграмме не показаны.
Диаграммы классов.
Диаграммой UML, поясняющей внутреннее устройство системы, является диаграмма классов, описывающая создаваемую программную систему через ее компоненты (классы, объекты), отношения и взаимодействия между ними. В основном диаграммы классов в этих методах применяют на этапе проектирования, для того чтобы показать особенности построения конкретных классов. UML предлагает использовать три уровня диаграмм классов в зависимости от степени их детализации:
· концептуальный уровень, на котором диаграммы классов, называемые в этом случае контекстными, демонстрируют связи между основными понятиями предметной области;
· уровень спецификаций, на котором диаграммы классов отображают интерфейсы классов предметной области, т. е. связи объектов этих классов;
· уровень реализации, на котором диаграммы классов непосредственно показывают поля и методы конкретных классов.
Это три разные модели, связь между которыми неоднозначна. Так, если концептуальная модель определяет некоторое понятие предметной области как класс, то это не означает, что для реализации этого понятия будет использован отдельный класс. Однако во всех трех моделях нас интересуют типы объектов (классы) и их статические отношения, что позволяет использовать единую нотацию.
Каждая из перечисленных моделей используется на конкретном этапе разработки программного обеспечения:
· концептуальная модель — на этапе анализа;
· диаграммы классов уровня спецификации — на этапе проектирования;
· диаграммы классов уровня реализации — на этапе реализации.
Концептуальные модели в соответствии с определением оперируют понятиями предметной области, атрибутами этих понятий и отношениями между ними. Класс при этом традиционно понимают как совокупность общих признаков некоторой группы объектов предметной области. В соответствии с этим определением на диаграмме классов каждому классу соответствует группа объектов, общие признаки которых и фиксирует класс.
На диаграммах класс изображается в виде прямоугольника, внутри которого указано имя класса (рис. 4.14, а). При необходимости допускается указывать характеристики класса, например, атрибуты, используя специальные секции условного обозначения (рис. 4.14, б), а также операции класса (рис. 4.14, в).
В качестве атрибутов представляют некоторые, существенные с точки зрения решаемой задачи характеристики объектов, например, идентифицирующие значения (имя, номер). Для конкретного объекта атрибут всегда имеет конкретное значение (рис. 4.15).
Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой). Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что именно имена классов образуют словарь предметной области при объектно-ориентированном анализе и проектировании.
В первой секции обозначения класса могут находиться ссылки на стандартные шаблоны или абстрактные классы, от которых образован данный класс и соответственно от которых он наследует свойства и методы. В этой секции может приводиться информация о разработчике данного класса и статус состояния разразботки, а также могут записываться и другие общие свойства этого класса, имеющие отношение к другим классам диаграммы или стандартным элементам языка UML.
Примерами имен классов могут быть такие существительные, как «Сотрудник», «Компания», «Руководитель», «Клиент», «Продавец», «Менеджер», «Офис» и многие другие, имеющие непосредственное отношение к моделируемой предметной области и функциональному назначению проектируемой системы.
Класс может не иметь экземпляров или объектов. В этом случае он называется абстракгпным классом, а для обозначения его имени используется наклонный шрифт (курсив). В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом.
В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель — двойное двоеточие «::» Синтаксис строки имени класса в этом случае будет следующий;
<Имя_пакета>::<Имя класса>.
Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем «Банк», то класс «Счет» в этом банке может быть записан в виде: «Банк::чет».
Во второй сверху секции прямоугольника класса записываются его атрибуты (attributes) или свойства. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута,имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения:
<квантор видимости><имя атрибута>[кратность]:
<тип атрибута> = <исхопное значение>{строка-свойство}
Квантор видимости принимает одно из трех возможных значений и отображается при помощи специальных символов:
«+» — атрибут с областью видимости типа общедоступный (public). Атрибут доступен или виден из любого другого класса пакета, в котором определена диаграмма;
«#» — атрибут с областью видимости типа защищенный (protected). Атрибут недоступен или невиден для всех классов за исключением подклассов данного класса;
«— » — атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.
Квантор видимости может быть опущен, в этом случае его отсутствие просто означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как public или private. Однако вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private.
Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и потому должна быть уникальной в пределах данного класса.
Имя атрибута является единственным обязательным элементом, синтаксического обозначения атрибута.
Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. В общем случае кратность записывается в форме строки текста в квадратных скобках после имени соответствующего атрибута. В качестве примера рассмотрим следующие варианты задания кратности атрибутов:
[0..1] означает, что кратность атрибута может принимать значение О или 1. При этом О означает отсутствие значения для данного атрибута;
[О..*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное О. Эта кратность может быть записана короче в виде простого символа — [*]:
[1.:*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное 1;
[1..5] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 4, 5;
[1..3,5,7] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 5, 7;
[1..3,7.. 10) означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 7, 8, 9, 10;
[1..3,7..*] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3. а также любое положительное целое значение большее или равное 7.
Если кратность атрибута не указана, то по умолчанию принимается ее значение равное 1..1, т.е, в точности 1.
Тип атрибута представляет собой выражение, семантика которого определяется языком спецификации соответствующей модели. В нотации UML тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс.
При задании атрибутов могут быть использованы две дополнительные синтаксические конструкции — это подчеркивание строки атрибута и пояснительный текст в фигурных скобках.
Подчеркивание строки атрибута означает, что соответствующий атрибут может принимать подмножество значений из некоторой области значений атрибута, определяемой его типом. Эти значения можно рассматривать как набор однотипных записей или массив, которые в совокупности характеризуют каждый объект класса.
В третьей сверху секции прямоугольника записываются операции, или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка — свойство данной операции:
<квантор видимости><имя операции>(список параметров): <выражение типа возвращаемого значения>{строка-свойство}.
Квантор видимости,как и в случае атрибутов класса, может принимать одно из трех возможных значений и соответственно отображается при помощи специального символа. Символ «+» обозначает операцию с областью видимости типа общедоступный (public). Символ «#» обозначает операцию с областью видимости типа защищенный (protected). И наконец, символ «-» используется для обозначения операции с областью видимости типа закрытый (private).
Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private. Кроме внутреннего устройства или структуры классов, важную роль при разработке программной системы играют различные отношения между классами. которые также могут быть изображены на диаграмме классов:
· отношение ассоциации — наличие произвольной взаимосвязи между классами;
· отношение обобщения — отношение между более общим элементом и более частным элементом (родителем и потомком);
· отношение композиции (рис. 4.16, а) — частный случай отношения агрегации, когда части не могут выступать в отрыве от целого и с уничтожением целого уничтожаются и все его составные части;
· отношение агрегации (рис. 4.16, б) — один из классов представляет собой некоторую сущность, которая включает в себя в качестве составных частей некоторые другие сущности.
Условные обозначения специальных видов ассоциации:а- композиция; б – агрегация.
В контексте языка UML существует специальный класс — интерфейс, у которого имеются только операции и отсутствуют атрибуты. Интерфейсы на диаграмме служат для спецификации таких элементов модели, которые видимы извне, но их внутренняя структура остается скрытой от клиентов.
Процесс разработки диаграммы классов занимает центральное место при разработке проектов сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи зависит не только успех процессов проектирования,но и производительность программы.
Задание
Используя техническое задание из практической работы 1 (см. Приложение), провести анализ требований к программному обеспечению в соответствии с вариантом задания, применяя объектно-ориентированный подход и язык визуального моделирования UML. Результаты оформить в MS Visio.