Диаграмма деятельности модели «Страховая компания»

Диаграмма деятельности (activity diagram) — это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.

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

Рис. 2. Обслуживание клиента. Диаграмма деятельности.

Диаграмма классов модели «Страховая компания»

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

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

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

Атрибут — это элемент информации, связанный с классом. Из диаграммы видно, например, атрибут класса ID является закрытым, т. е. он не виден никаким другим классам. Остальные атрибуты этого класса — видимые.

Операции реализуют связанное с классом поведение. Операция включает три части — имя, параметры и тип возвращаемого значения.

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

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

Изменение структуры класса T_ADR влечет за собой изменение класса персона через структуру соответствующего атрибута (адрес).

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

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

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

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

Рис. 3. Диаграмма классов «Страховая компания».