Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf

Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом ATM Screen (экран ATM), потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance являются закрытыми атрибутами класса Account. Кроме того, операции Deduct Funds и Verify Funds также закрыты для этого класса.

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

Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.

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

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

Информационное (informative) сообщение - сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.

Сообщение-запрос (interrogative) - сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение - сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Рассмотрим диаграммы последовательности.

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

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

рис. №22 Пример диаграммы последовательности

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения, этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" (account) и инициализирует экран ATM. Экран, в свою очередь, запрашивает у Джо его регистрационный номер. Он вводит число 1234. Экран проверяет номер у объекта "Счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и он выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо выбирает 20 долларов. Затем экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "Счет Джо". Во-первых, осуществляется проверка, что на этом счету лежит, по крайней мере, 20 долларов. Во-вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию выдать 20 долларов наличными, а также чек. Наконец, все тот же объект "Счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо 20 долларов. Глядя на эту диаграмму, пользователи могут увидеть специфику их работы. Аналитики увидят последовательность (поток) действий, разработчики - объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию, и, кроме того, можно показать само-делегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Диаграммы последовательности существенно помогают разобраться в процессе поведения системы. [2]

Глава № 2. Проектирования информационной системы

Рассмотрим пример проектирования информационной системы. В качестве задачи стоит разработка системы проката велосипедов. В качестве среды разработки будем использовать программное обеспечение от компании IBM Rational Rose.

Рассмотрим основные моменты:

Rational Rose представляет собой CASE средство проектирования и разработки информационных систем и программного обеспечения для управления предприятиями. Как и другие CASE средства (ARIS, BPwin, ERwin) его можно применять для анализа и моделирования бизнес процессов. Первая версия этого продукта была выпущена компанией Rational Software. В дальнейшем Rational Rose был куплен IBM.

Принципиальное отличие Rational Rose от других средств заключается в объектно-ориентированном подходе. Графические модели, создаваемые с помощью этого средства, основаны на объектно-ориентированных принципах и языке UML (Unified Modeling Language). Инструменты моделирования Rational Rose позволяют разработчикам создавать целостную архитектуру процессов предприятия, сохраняя все взаимосвязи и управляющие воздействия между различными уровнями иерархии. Моделирование бизнес процессов в Rational Rose выполняется за счет применения различных аспектов. Каждый из этих аспектов концентрирует внимание на определенных характеристиках и возможностях процессов.

К таким аспектам относятся:

2.1 Аспекты моделирования Rational Rose

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

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

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

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

За счет применения различных аспектов Rational Rose предоставляет пользователям (бизнес аналитикам, инженерам, техническим специалистам и руководителям) возможность создавать, анализировать, изменять и управлять моделями, используя единый объектно-ориентированный подход и единый язык моделирования. [3]

2.3 Характеристика предметной области

Общая характеристика

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

Актуальность разрабатываемой информационной системы

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

Процесс моделирования

Создание диаграммы прецедентов (use case)

Диаграмма прецедентов (use case diagram) – это графическое представление всех или части актеров, прецедентов и их взаимодействий в системе. В каждой системе обычно есть главная диаграмма прецедентов, которая отображает границы системы (актеров) и основное функциональное поведение системы.

Рис. №1 Диаграмма прецедентов

На рисунке №1 представлена диаграмма претендентов. Опишем состав диаграммы:

Основные действующие лица (актеры)

Клиент

Менеджер по аренде

Кассир

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

Взаимодействие клиента и кассира показано в процессе оплаты.

Создание диаграммы взаимодействия (последовательности).

Рис. №2 Диаграмма взаимодействия

На приведенной выше диаграмме выделены следующие объекты:

- Клиент и его взаимодействие с магазином велопроката:

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

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

- Кассир взаимодействует с клиентом на этапе оплаты услуг.

Создание диаграммы классов

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

Рис. №3 Диаграмма классов

На приведенной выше диаграмме выделены следующие объекты(классы):

- Клиент, данный класс имеет следующие атрибуты: ID номер (индивидуальный номер клиента), ФИО, Адрес, Телефон и Почта.

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

ID номер (индивидуальный номер клиента), ФИО, Телефон.