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

унифицированный процесс (Unified Process, UP);

экстремальное программирование (eXtreme Programming, XP);

гибкое моделирование (Agile Modeling, AM).

Базовым средством фиксации (документирования) результатов проектирования систем посредством этих методологий является унифицированный язык моделирования (Unified Modeling Language, UML).

Преимущества и недостатки объектно-ориентированного подхода

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

Описание системы в виде объектов больше соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;

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

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

адаптации системы к изменению существующих или появлению новых требований;

сопровождения системы на разных стадиях жизненного цикла;

повторного использования компонентов;

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

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

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

---

Реализация объектно-ориентированного подхода при проектировании ИС

Постановка задачи

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

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

пользователь (может просматривать данные об услугах и автомоечном комплексе);

Клиент (может записаться на мойку);

администратор (может модифицировать некоторые данные).

Разработанная система должна:

принимать заявки от клиентов автомобильной мойки

обеспечить защиту от несанкционированного доступа к данным

автоматизировать систему приема заявок

предоставлять пользователю и сотрудникам комплекса информацию в удобном для просмотра виде

Выбор средств объектно-ориентированного подхода

UML (Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна генерация исходного кода.

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов, а с 1997 года является стандартом OMG в области визуального объектно-ориентированного моделирования и широко используется на практике, будучи реализован в рамках многих CASE-средств^[1].

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах^[2]:

---

Use case diagram (диаграммы прецедентов);

Activity diagram (диаграммы активности);

Sequence diagram (диаграммы последовательностей действий);

Use case diagram (диаграммы прецедентов)

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

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

Activity diagram (диаграммы активности)

Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

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

Sequence diagram (диаграммы последовательностей действий)

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

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

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Результаты применения объектно-ориентированного подхода

Целью данного этапа является проведение анализа бизнес-процессов заказчика и на основе данного анализа построение модели автоматизированной системы управления (АСУ). Для этого необходимо произвести анализ объектов капитального строительства, графика и объема их финансирования, условия заключаемых договоров и этапы их оплаты. Также необходимо провести анализ роли ответственных лиц (Actors) и т.д. Задача это не простая и требует значительных аналитических усилий и опыта. Результатом этой работы должен быть список ролей в компании заказчика, четкое понимание процесса и список объектов (сущностей), участвующих в этом процессе. Все это и должно найти отражение в диаграммах Rational Rose. Кроме того, необходимо вместе с заказчиком составить список требований к ИС.

---

Используем следующий подход: используем Use case diagram для отображения списка операций, которые должна выполнять наша система; иначе говоря, это требования к системе. Каждый Use case – это некоторый процесс (последовательность действий), поэтому мы должны использовать Sequence diagram для его детализации. На этой диаграмме мы отображаем объекты из предметной области (объекты, участвующие в бизнес-процессе); таким образом, мы получаем экземпляры некоторых классов и их взаимодействие. Sequence diagram отображает сам процесс, статическая картина взаимодействия объектов отображается с помощью Class diagram.

Начнем создавать диаграмму прецедентов – Use case diagram (диаграммы прецедентов). На Use case diagram отображаем взаимодействие между ролями (актерами) и прецедентами (т.е. это случаи использования ИС)^[3].

Прецедент – это некоторый процесс, в котором обычно участвуют несколько объектов.

Диаграмма прецедентов

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

Актер – это роль, которую пользователь играет по отношению к системе.

Актерами являются: Клиент, Пользователь, Администратор.

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

Прецедент- "Запись клиента на мойку"

Краткое описание

Вариант использования " Запись клиента на мойку " позволяет клиенту заполнить форму для заявки на мойку своего автомобиля.

Основной поток

1. Прецедент начинается, когда пользователь заходит на сайт.

2. Пользователь заходит под своим зарегистрированным именем и паролем.

3. На экран выводится сообщение об успешном входе на сайт.

4. Далее клиент переходит по вкладке оформить заявку.

5. На экран выводится форма для оформления заявки, предоставляется возможность заполнить такие поля как: Автомобиль, Услуга, Терминал и дата записи.

6. На экран выводится сообщение об успешно добавленной записи “Запись добавлена”

7. В базу данных добавляется новая запись.

8. Прецедент завершается.

Альтернативный поток А1. Не все данные были введены.

1. Система информирует пользователя, какие данные не были введены и просит ввести эти данные.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

---

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Поток ошибок Е1. Ошибка при отправке данных.

1. В браузере отображается сообщение о ошибке при отправке данных и приглашение ввести данные еще раз.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

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

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

Как правило, описывает поведение только одного варианта использования.

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

Диаграммы последовательности (Sequence diagrams)

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

Рис.2 Диаграмма последовательности для прецедента “Запись клиента на мойку”

Рис.3. Кооперативная диаграмма для прецедента «Запись клиента на мойку»

Процесс проектирования базы данных состоит из следующих отдельных шагов: концептуального проектирования, проектирования логической структуры базы данных, которая поддерживается СУБД и описывает представление пользователя о данных, и выбора физической структуры, которая включает представление данных, методы доступа и физическое группирование данных^[4].

Построим ER-модель системы.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

---