710400 «Программная инженерия»

Бишкек - 2015

Цель работы: проектирование и генерация базы данных.

Очень важным свойством модели "сущность-связь" является то, что она может быть представлена в виде графической схемы. Это значительно облегчает анализ предметной области. Существует несколько вариантов обозначения элементов диаграммы "сущность-связь", каждый из которых имеет свои положительные черты. Здесь мы будем использовать некий гибрид нотаций Чена (обозначение сущностей, связей и атрибутов) и Мартина (обозначение степеней и кардинальностей связей). В таблице 2.1 приводится список используемых здесь обозначений.

Таблица 2.1

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

В процессе построения диаграммы можно выделить несколько очевидных этапов:

1. Идентификация представляющих интерес сущностей и связей.

2. Идентификация семантической информации в наборах связей (например, является ли некоторый набор связей отображением 1:n).

3. Определение кардинальностей связей.

4. Определение атрибутов и наборов их значений (доменов).

5. Организация данных в виде отношений "сущность-связь".

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

Выделим интересующие нас сущности и связи:

1. Прежде всего преприятие состоит из отделов, в которых работают сотрудники. Оклад каждого сотрудника зависит от занимаемой им должности (инженер, ведущий инженер, бухгалтер, уборщик и т.д.). Далее предположим, что на нашем предприятии допускается совместительство должностей, т.е. каждый сотрудник может иметь более чем одну должность (и работать более чем в одном отделе), причем может занимать неполную ставку. В то же время, одну и ту же должность могут занимать одновременно несколько сотрудников. В результате этих рассуждений мы должны ввести наборы сущностей

o ОТДЕЛ(ИМЯ_ОТДЕЛА),

o СОТРУДНИК(ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ),

o ДОЛЖНОСТЬ(ИМЯ_ДОЛЖНОСТИ, ОКЛАД),

и и набор связей РАБОТАЕТ_В с атрибутом ставка между ними. Атрибут ставка может принимать значения из интервала ]0,1] (больше нуля, но меньше или равен единице), он определяет какую часть должностного оклада получает данный сотрудник.

Как уже отмечалось выше, каждый n-арный набор связей можно заменить несколькими бинарными наборами. Сейчас как раз представляется удобный случай, чтобы оценить преимущества каждого из этих способов представления связей.

o Тренарная связь, показанная здесь, безусловно несет более полную информацию о предметной области. Действительно, она однозначно отображает тот факт, что оклад сотрудника зависит от его должности, отдела, где он работает, и ставки. Однако, в этом случае возникают некоторые проблемы с определением степени связи. Хотя, как было сказано, каждый работник может занимать несколько должностей, а в штате каждого отдела существуют вакансии с различными должностями, тем не менее класс принадлежности сущности ДОЛЖНОСТЬ на приведенном рисунке установлен в (1,1). Это объясняется тем, что ДОЛЖНОСТЬ ассоциируется фактически не с сущностями СОТРУДНИК и ОТДЕЛ, а со связью между ними. Обозначать этот факт предлагается так, как это показано на следующей диаграмме:

Здесь сущности СОТРУДНИК, ОТДЕЛ и связь РАБОТАЕТ_В аггрегируются в некую новую абстрактную сущность, которая ассоциируется с сущностью ДОЛЖНОСТЬ с помощью связи степени n:1. (Это обозначение заимствовано из книги Silberschatz, Korth and Sudarshan Database System Concepts, 1997).

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

В этом случае для адекватного описания семантики предметной области необходимо ввести еще одну сущность ШТАТНАЯ_ЕДИНИЦА, которая фактически заменяет собой связь РАБОТАЕТ_В в абстрактной сущности и поэтому имеет атрибут ставка.

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

2. Перечисли ряд объектов, описанных в предыдущем праграфе, которые будут полезны при моделировании данных рассматриваемого предприятия. Им соответствуют следующие сущности:

o ЗАКАЗЧИК(ИМЯ_ЗАКАЗЧИКА,АДРЕС)

o КОНТРАКТ(НОМЕР,СРОК_НАЧАЛА,СРОК_ОКОНЧАНИЯ,СУММА)

o РАБОЧАЯ ГРУППА(ПРОЦЕНТ_ВОЗНАГРАЖДЕНИЯ)

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

Как правило, один из членов рабочей группы является руководителем по отношению к другим сотрудникам, входящим в ее состав. Для отражения этого факта мы должны ввести связь "руководит" с кардинальностью 1,1:0,n между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА (сотрудник может руководить в произвольном числе рабочих групп, но каждая рабочая группа имеет одного и только одного руководителя).

3. Рассмотрим теперь более внимательно информационный объект "заказчик". На практике очень часто возникает необходимость различать национальную прнадлежность юридических лиц, с которыми предприятие вступает в договорные отношения. Это свзано с тем, что для зарубежных фирм необходимо хранить, например, сведения о валюте, в которой осуществляются расчеты, языке, на котором подписан котракт и т.д. В свою очередь, для отечественных компаний необходимо иметь сведения о их форме собственности (частная или государственная), поскольку от этого может зависеть порядок налогообложения средств, полученных за выполнение работ по контракту.

Таким образом, мы приходим к выводу, что необходимо ввести в рассмотрение еще два непересекающихся множества ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ(ВАЛЮТА, ЯЗЫК) и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ(ФОРМА_СОБСТВЕННОСТИ), объединение которых составляет полное множество ЗАКАЗЧИК. Ассоциацию между этими объектами называют отношением наследования или иерархической связью, так как сущности ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ наследуют атрибуты сущности ЗАКАЗЧИК(ИМЯ_ЗАКАЗЧИКА, АДРЕС). Для того, чтобы определить к какому подмножеству относится конкретная сущность из набора ЗАКАЗЧИК (и, соответственно, какой набор атрибутов она имеет) необходимо ввести атрибут "национальная принадлежность", называемый дискриминантом. Этот тип связи предлагается отображать на диаграмме следующим образом:

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

1. Как изменится диаграмма "сущность - связь" в том случае, если процент вознаграждения по всем контрактам будет одинаков?

2. Что изменится в диаграмме, если будет запрещено совместительство должностей, т.е. каждый сотрудник будет иметь право занимать только одну должность со ставкой 1?

ЛАБОРАТОРНАЯ РАБОТА №2

Объектно-ориентированный подход к разработке сложных систем.

UML. Диаграмма вариантов использования

Цель работы: состоит в отображении функциональных возможностей системы и требований в UML.

Теоретические сведения

1. Сущность объектно - ориентированного подхода к проектированию ПО

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

В настоящее время для объектно-ориентированного моделирования проблемной области (Unified Modelling Language) широко используется язык моделирования UML.

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

1. диаграммы вариантов использования (Use case Diagrams) - для моделирования бизнес - процессов организации (требований к системе);

2. диаграммы классов (Class Diagram)- для моделирования статической структуры классов системы и связи между ними;

3. диаграммы поведения:

3.1. диаграммы состояний (Statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

3.2. диаграммы деятельности (Activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования (отображают потоки работ во взаимосвязанных прецедентах использования);

3.3. диаграммы взаимодействия (interaction diagrams) - для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия:

3.3.1. диаграммы последовательности (sequence diagrams) -последовательность сообщений;

3.3.2. кооперативные диаграммы (collaboration diagrams) - пространственное расположение объектов, чтобы показать их статическое взаимодействие;

4. диаграммы реализации (implementation diagrams):

4.1. диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы (отображаются физические модули программного кода);

4.2. диаграммы размещения или развертывания (deployment diagrams) - для моделирования физической архитектуры системы (отображает распределение объектов по узлам вычислительной сети).

2. Диаграмма вариантов использования

О вариантах использования

Варианты использования объясняют определенную часть функциональных возможностей системы, компонента или даже класса. Каждый вариант использования должен иметь название, которое состоит обычно из нескольких слов, описывающее требуемые функциональные возможности, типа «просмотр журнала регистрации ошибок».

Рис. 3.1. Простой вариант использования

О действующих лицах

По определению UML вариант использования должен быть инициирован кем-то или чем-то вне содержания варианта использования. Эта заинтересованная сторона называется действующее лицо. Действующее лицо не обязательно должно быть человеком-пользователем; любая внешняя система, время, или элемент вне варианта использования могут вызвать начало варианта использования (или получателя результатов варианта использования) и должны быть смоделированы в качестве действующего лица (актера). Например, это очень типично моделировать системные часы как действующее лицо, которое вызывает вариант использования в заданное время или интервал.

Рис. 3.2. Действующее лицо, использующее представление фигуры человечка

Об ассоциациях действующее лицо / вариант использования

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

Рис. 3.3. Действующее лицо, ассоциированное с вариантом использования Заказ товара (Order Item)

Определение границ системы

Варианты использования отображают функциональные возможности определенного субъекта. Все, что не относится к субъекту, считается вне границ системы и должно моделироваться в виде действующего лица. Эта методика очень полезна при определении содержания и назначения ответственностей при проектировании системы, подсистемы или компонента. Например, если вы моделируете систему банкоматов, ваши обсуждения проектирования часто уходят от центральной темы подробностей серверной части банковской системы, модель варианта использования с ясно определенными границами системы будет идентифицировать банковскую систему в качестве действующего лица и поэтому за пределами содержания проблемы.

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

Размещено на http://www.allbest.ru/

Рис. 3.4. Диаграмма варианта использования, демонстрирующая границы системы для банкомата

Идентификация функциональных возможностей действующими лицами

Нет необходимости, чтобы действующие лица имели взаимнооднозначное отображение к физическим объектам; фактически, они не должны быть физическими объектами вообще. Определение UML позволяет действующим лицам играть роли потенциальных пользователей системы. Например, системный администратор может быть единственным физическим пользователем системы, но при этом данный администратор может исполнять несколько ролей. Может быть полезным рассмотреть систему с точки зрения администратора базы данных, администратора резервного копирования, администратора развертывания и так далее. Точно идентифицируя несколько ролей действующих лиц, которые могут использовать систему, часто вы можете обнаружить варианты использования, которые проскочили бы незамеченными. Рис. 3 показывает типовую диаграмму, содержащую три типа администраторов и варианты использования.

Размещено на http://www.allbest.ru/

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

В дополнение к связям между действующими лицами и вариантами использования существуют два других типа связей: «использование» (uses) и «расширение» (extends) между вариантами использования.

Связь типа «расширение» применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку. Эту связь используют при описании изменений в нормальном состоянии объекта.

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

Пример вариантов использования для торговой организации представлен на нижеследующем рисунке.

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

Пример построения диаграммы вариантов использования на стадии формирования требований к автоматизированной системе учета и регистрации налогоплательщиков - организаций

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

1. Кто использует систему?

2. Кто отвечает за эксплуатацию системы?

3. Какие другие системы взаимодействуют с данной системой?

Варианты использования идентифицируются исходя из следующих соображений:

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

ЛАБОРАТОРНАЯ РАБОТА №3

Диаграммы взаимодействий.

Цель работы: ознакомить с UML 2.0. Научить отображать процессы и потоки событий.

3.1 Что такое взаимодействия?

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

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

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

3.2 Об участниках взаимодействия

Вы можете показывать элементы взаимодействия с помощью прямоугольника, называемого «линией жизни» (lifeline). Когда «линия жизни» используется в диаграммах последовательности, то он имеет пунктирную линию, свисающую вниз от прямоугольника, который показывает, как долго объект фактически уже существует. Когда используется в других обозначениях диаграммы взаимодействия, типа диаграмм связи, «линия жизни» представляет собой просто прямоугольник. Вы указываете название участника в прямоугольнике с помощью следующего обозначения:

object__name [ selector ] : class name ref decomposition

где:

Вы можете показывать разрушение участника (элемента) во время взаимодействия, используя символ остановки. Обычно этому предшествует сообщение «destroy» («уничтожить») к объекту, хотя это не обязательно. Разместите X внизу «линии жизни», где объект прекращает свое существование.

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

Размещено на http://www.allbest.ru/

Рис. 4.1. Взаимодействие HashMap с использованием локальных переменных

3.3 О сообщениях

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

Наиболее общим применением сообщений является представление вызовов методов между двумя объектами. Когда сообщения используются для показа вызова метода, вы можете описать параметры, передаваемые методу, в синтаксисе сообщения. Параметры могут быть следующие:

* атрибуты объекта-отправителя

* постоянные

* символические значения (выражения, показывающие, какие могут быть легальные значения)

* явные параметры прилагаемого взаимодействия

* атрибуты класса, владеющего прилагаемым взаимодействием

Синтаксис для сообщения следующий:

attribute = signal_or_operation_name(arguments) : return_value

В диаграмме последовательности сообщение изображается в виде сплошной линии, указывающей от линии жизни отправителя к линии жизни получателя. Если сообщение является асинхронным сообщением (т.е. вызывающий объект (caller) не блокирует ожидание для получателя, чтобы обработать сообщение), вы размещаете открытую стрелку - указатель в конце линии получателя.

Размещено на http://www.allbest.ru/

Рис.4.2. Асинхронное сообщение между объектами

Когда вы возвращаете книгу в библиотеку, вы обычно не ждете библиотекаря, чтобы возвратить книгу на полки. Вместо этого вы оставляете книгу в приемной библиотеки (CirculationDesk) и дальше продолжаете свой путь. Открытая стрелка-указатель означает, что вызывающий объект (AverageJoe) не ждет любой ответ из приемной библиотеки.

Поскольку асинхронные сообщения не требуют, чтобы отправитель ждал, когда сообщение будет доставлено, в зависимости от механизма доставки асинхронные сообщения могут прибывать не по порядку. Например, два пакета сети могут выбрать различные маршруты к тому же самому пункту назначения с разным временем пребывания. Вы можете показать внеочередность указывая точку приема первого сообщения, ниже точки приема второго сообщения, как показано на рисунке 4.3.

Размещено на http://www.allbest.ru/

Рис. 4.3. Не принимаемые асинхронные сообщения

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

Размещено на http://www.allbest.ru/

Рис. 4.4. Вызов метода и результирующее значение возврата

Когда сообщение представляет процесс создания объекта, вы показываете пунктирную линию с открытой стрелкой, указывающей на линию жизни недавно созданного объекта. В соответствии с соглашением сообщение обычно помечено некоторой вариацией создания. Если не имеется никаких аргументов к сообщению, вы можете просто маркировать сообщение ключевым словом «create», как на рисунке 4.4. Если имеются аргументы, вы представляете их в качестве параметров create() сообщения. Если имеется особенная причина в показе сообщения создания с помощью различного ярлыка (например, фабричного метода), вам следует воспользоваться этим. Рисунок 4.5. показывает пример, который создает экземпляр класса UserAccount.

Размещено на http://www.allbest.ru/

Рис. 4.5. Показ инициализации объекта

Вы можете объяснить обнаруженное сообщение, начиная его от черного круга, нежели от линии жизни отправителя. На рис. 4.5. объясняется пример найденного сообщения. CircuitBreaker все равно, откуда пришла волна тока; он должен отключить ток при любых условиях.

Размещено на http://www.allbest.ru/

Рис. 4.6. Пример обнаруженного сообщения

Соответственно, вы можете выразить потерянное сообщение завершением стрелки сообщения в черном круге вместо линии жизни получателя. Рис. 4.7. демонстрирует рабочую станцию, посылающую ping-сообщение, которое по некоторым причинам не было получено.

Размещено на http://www.allbest.ru/

Рис. 4.7. Пример утерянного сообщения

3.4 Случаи выполнения

С помощью случаев выполнения можно объяснить вовлеченность объекта в выполнение некоторого типа действия (обычно вызов метода) в течение измеримого количества времени. Случаи выполнения показаны серыми или белыми прямоугольниками на линии жизни. На практике общепринято называть случаи выполнения в качестве «центра управления», так как они объясняют, что объект занят (система сфокусирована на нем) в течение некоторого периода времени.

Размещено на http://www.allbest.ru/

Рис. 4.8. Несколько примеров случаев выполнения

3.5 Объединенные Фрагменты

Часто специфическая последовательность возникновения событий имеет специальные ограничения или свойства. Например, вы можете иметь критический интервал в пределах вашего взаимодействия, где набор вызовов метода должен выполнить согласно частям (atomically) или выполнить петлю, которая выполняет итерации согласно содержанию коллекции. UML определяет эти меньшие части, как фрагменты взаимодействия.

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

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

Объединенный фрагмент обозначается в виде прямоугольника с оператором взаимодействия в шестиугольнике в верхнем левом углу и операндов взаимодействия внутри прямоугольника. Код должен быть выполнен автоматически в результате операнда взаимодействия "critical".

Размещено на http://www.allbest.ru/

Рис. 4.9. Пример объединенного фрагмента

3.5.1 О граничных условиях

Фрагмент взаимодействия может иметь граничное условие, которое срабатывает, когда фрагмент имеет силу (может быть выполнен); как при условии «if-then». Синтаксис для граничного условия простой:

[boolean_expression]

Граничное условие размещается выше первого возникновения события в относящемся фрагменте взаимодействия и на вершине связанной лини жизни. На рис. 63 представлен альтернативный оператор взаимодействия, который моделирует условие «if-else».

Размещено на http://www.allbest.ru/

Рис. 4.10. Пример альтернативного оператора.

ЛАБОРАТОРНАЯ РАБОТА №4

Диаграмма классов (class diagram)

Цель работы: разработка логической модели системы в виде диаграммы классов с CASE-инструментариями в языке UML

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

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

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

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

Таким образом, построение диаграмм классов можно рассматривать в различных аспектах:

· концептуальный аспект - диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Концептуальную модель можно рассматривать как не зависимую от средств реализации (языка программирования);

· аспект спецификации - модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);

· аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

При построении диаграммы необходимо выбрать единственный аспект. При чтении диаграммы следует выяснить, в соответствие с каким аспектом она строилась.

Класс

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5.1). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

Рис. 5.1. Графическое изображение класса на диаграмме классов

Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса (рис. 5.1, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис. 5.1, б) и операциями (рис. 5.1, в).

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

Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется горизонтальной линией, чтобы сразу отличить класс от других элементов языка UML. Примеры графического изображения классов на диаграмме классов приведены на рис. 5.2. В первом случае для класса "Прямоугольник" (рис. 5.2, а) указаны только его атрибуты - точки на координатной плоскости, которые определяют его расположение. Для класса "Окно" (рис. 5.2, б) указаны только его операции, секция атрибутов оставлена пустой. Для класса "Счет" (рис. 5.2, в) дополнительно изображена четвертая секция, в которой указано исключение - отказ от обработки просроченной кредитной карточки.

база данные диаграмма проектирование

Рис.5.2. Примеры графического изображения классов на диаграмме

Имя класса

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

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

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

Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется наклонный шрифт (курсив). В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом. Данное обстоятельство является семантическим аспектом описания соответствующих элементов языка UML.

Примечание

В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель - двойное двоеточие "::". Синтаксис строки имени класса в этом случае будет следующий <Имя_пакета>::<Имя_класса>. Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем "Банк", то класс "Счет" в этом банке может быть записан в виде: "Банк::Счет".

Атрибуты класса

Во второй сверху секции прямоугольника класса записываются его атрибуты (attributes) или свойства. Рассмотрим класс Клиент.

На концептуальном уровне наличие атрибута «Имя клиента» указывает на то, что Клиенты обладают именами. На уровне спецификаций этот атрибут указывает на то, что объект Клиент может сообщить свое имя и обладает некоторым его определения. На уровне реализации Клиент содержит поле (называемое также переменной или элементом данных), соответствующее его имени.

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

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

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и, соответственно, отображается при помощи специальных символов:

· Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

· Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.

· И, наконец, знак "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

Квантор видимости может быть опущен. В этом случае его отсутствие просто означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как public или private. Однако вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private.

Примечание

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

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

Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. В общем случае кратность записывается в форме строки текста в квадратных скобках после имени соответствующего атрибута:

[нижняя_граница1 .. верхняя_граница1, нижняя_граница2.. верхняя_граница2, ..., нuжняя_гpaнuцak .. верхняя_границаk],

где нижняя_граница и верхняя_граница являются положительными целыми числами, каждая пара которых служит для обозначения отдельного замкнутого интервала целых чисел, у которого нижняя (верхняя) граница равна значению нижняя_граница (верхняя_граница). В целом данное условное обозначение кратности соответствует теоретико-множественному объединению соответствующих интервалов. В качестве верхней_границы может использоваться специальный символ "*", который означает произвольное положительное целое число. Другими словами, это означает неограниченное сверху значение кратности соответствующего атрибута.

Значения кратности из интервала следуют в монотонно возрастающем порядке без пропуска отдельных чисел, лежащих между нижней и верхней границами. При этом придерживаются следующего правила: соответствующие нижние и верхние границы интервалов включаются в значение кратности. Если в качестве кратности указывается единственное число, то кратность атрибута принимается равной данному числу. Если же указывается единственный знак "*", то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем.

В качестве примера рассмотрим следующие варианты задания кратности атрибутов.

· [0..1] означает, что кратность атрибута может принимать значение 0 или 1. При этом 0 означает отсутствие значения для данного атрибута.

· [0..*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное 0. Эта кратность может быть записана короче в виде простого символа - [*].

· [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 тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс.

Можно привести следующие примеры задания имен и типов атрибутов классов:

· цвет: Соlоr - здесь цвет является именем атрибута, Color - именем типа данного атрибута. Указанная запись может определять традиционно используемую RGB-модель (красный, зеленый, синий) для представления цвета. В этом случае имя типа Color как раз и характеризует семантическую конструкцию, которая применяется в большинстве языков программирования для представления цвета.

· имя_сотрудника [1..2] : String - здесь имя_сотрудника является именем атрибута, который служит для представления информации об имени, а возможно, и отчестве конкретного сотрудника. Тип атрибута String (Строка) как раз и указывает на тот факт, что отдельное значение имени представляет собой строку текста из одного или двух слов (например, "Кирилл" или "Дмитрий Иванович"). Поскольку во многих языках программирования существует тип данных String, использование соответствующего англоязычного термина не вызывает недоразумения у большинства программистов. Однако, хотя в языке UML все термины даются в англоязычном представлении, использование в качестве типа атрибута Строка в данной ситуации не исключается и определяется только соображениями удобства.

· видимость:Boolean - здесь видимость есть имя абстрактного атрибута (курсив здесь не случаен), который может характеризовать наличие визуального представления соответствующего класса на экране монитора. В этом случае тип Boolean означает, что возможными значениями данного атрибута является одно из двух логических значений: истина (true) или ложь (false). При этом значение истина может соответствовать наличию графического изображения на экране монитора, а значение ложь - его отсутствию, о чем дополнительно указывается в пояснительном тексте. Поскольку кратность атрибута видимость не указана, она принимает значение 1 по умолчанию. В этой ситуации англоязычное имя типа атрибута вполне оправдано наличием соответствующего базового типа в языках программирования. Абстрактный характер данного атрибута обозначается курсивным текстом в записи данного атрибута.

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

Исходное значение служит для задания некоторого начального значения для соответствующего атрибута в момент создания отдельного экземпляра класса. Здесь необходимо придерживаться правила принадлежности значения типу конкретного атрибута. Если исходное значение не указано, то значение соответствующего атрибута не определено на момент создания нового экземпляра класса. С другой стороны, конструктор соответствующего объекта может переопределять исходное значение в процессе выполнения программы, если в этом возникает необходимость.

В качестве примеров исходных значений атрибутов можно привести следующие дополненные выше варианты задания атрибутов:

· цвет:Соlоr = (255, 0, 0) - в RGB-модели цвета это соответствует чистому красному цвету в качестве исходного значения для данного атрибута.

· имя_сотрудника[1..2]:String = Иван Иванович - возможно, это нетипичный случай, который, скорее, соответствует ситуации имя_руководителя[2]:81пп§ = Иван Иванович.

· видимость:Вооlеаn = истина - может соответствовать ситуации, когда в момент создания экземпляра класса создается видимое на экране монитора окно, соответствующее данному объекту.

· форма:Многоугольник = прямоугольник - вряд ли требует комментариев, поскольку здесь речь идет о геометрической форме создаваемого объекта.

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

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

Например, если некоторый атрибут задан в виде форма: Прямоугольник. то это будет означать, что все объекты данного класса могут иметь несколько различных форм, каждая из которых является прямоугольником. Другим примером может служить задание атрибута в виде номер_счета:Integer. что может означать для объекта Сотрудник наличие некоторого подмножества счетов, общее количество которых заранее не фиксируется.

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в программе при работе с данным типом объектов. Фигурные скобки как раз и обозначают фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем. Отсутствие строки-свойства по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе. Например, строка-свойство в записи атрибута заработная_плата:Currency = = {$500} может служить для обозначения фиксированной заработной платы для каждого объекта класса "Сотрудник" определенной должности в некоторой организации. С другой стороны, запись данного атрибута в виде зара-ботная_плата: Currency = $500 означает уже нечто иное, а именно - при создании нового экземпляра Сотрудник (аналогия - прием на работу нового сотрудника) для него устанавливается по умолчанию заработная плата в $500. Однако для отдельных сотрудников могут быть сделаны исключения как в большую, так и в меньшую сторону, о чем необходимо позаботиться дополнительно в программе.

Операция

В третьей сверху секции прямоугольника записываются операции или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию (процессы, реализуемые классом) Совокупность операций характеризует функциональный аспект поведения класса.

На уровне спецификаций операции соответствуют общим методам над типом. В модели реализации может потребоваться отражение уровней секретности и защиты операций.

Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство данной операции:

<квантор видимости><имя операции>(список параметров):

<выражение типа возвращаемого значения>{строка-свойство}

Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и, соответственно, отображается при помощи специального символа. Символ "+" обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает операцию с областью видимости типа защищенный (protected). И, наконец, символ "-" используется для обозначения операции с областью видимости типа закрытый (private).

Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private.

Примечание

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

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

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

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

Здесь вид параметра - есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра. Выражение типа является зависимой от конкретного языка программирования спецификацией типа возвращаемого значения для соответствующего формального параметра. Наконец, значение по умолчанию в общем случае представляет собой выражение для значения формального параметра, синтаксис которого зависит от конкретного языка программирования и подчиняется принятым в нем ограничениям.

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

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

Операция с областью действия на весь класс показывается подчеркиванием имени и строки выражения типа. По умолчанию под областью операции понимается объект класса. В этом случае имя и строка выражения типа операции не подчеркиваются.