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

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

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

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

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

2.3 Методологии объектно-ориентированного подхода

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

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

RUP (Rational Unified Process);
RAD (Rapid Application Development);
OpenUP.

Одной из самых известных используемых методологий разработки является RUP (Rational Unified Process). RUP непосредственно ориентирован на объектно-ориентированный подход к проектированию. Модели, которые создаются по этой методологии отлично ложатся на объектно-ориентированное мышление и могут быть представлены с помощью стандарта UML.

В основе процесса проектирования RUP лежат 2 основных процесса [7, с. 115]:

Поток работ;
Жизненный цикл разрабатываемой системы.

Первый процесс представляет статический аспект проектирования, заключающийся в непосредственных рабочих процессах. Жизненный цикл системы отражает динамический аспект проектирования системы в виде итераций, циклов и стадий [7, с. 115].

Также сам процесс проектирования включает в себя два аспекта [7, с. 115]:

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

В качестве основных принципов RUP выступают [5]:

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

Жизненный цикл RUP (Рисунок 1), состоит из следующий процессов [7, с. 109]:

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

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

Рисунок 1

Методология RAD — одна из самых распространенных методологий разработки ПО в настоящее время, которая реализует спиральные модели жизненного цикла. Основными особенностями методологии являются [7, с. 102]:

Короткий, но тщательно проработанный график работ;
Небольшая команда инженеров;
Цикличность разработки.

Модель ИС, созданная по технологии RAD, позволяет понимать текущий статус и прогресс и регулировать трудозатраты и вложения после каждой итерации.

Основными этапами RAD методологии являются [7, с. 103]:

Бизнес моделирование. На этом этапе исследуются информационные потоки между бизнес-процессами.
Моделирование данных. Информационные потоки отображаются набором объектов данных. Определяются характеристика этих объектов и связи между ними.
Моделирование обработки. Определяются модели и процедуры преобразования объектов данных. Определение алгоритмов поиска, создания и удаления данных.
Генерация приложений. С помощью объектно-ориентированных методов и систем программирования, а также CASE-средств создаются приложения ИС и продукты.
Тестирование и объединение.

Несмотря на очевидные преимущества, такие как возможности расширения прототипов, сокращения числа итераций, упрощения создания проектной документации и существенного снижения сроков разработки, RAD-технологии имеют недостатки. При разработке больших проектов требуются существенные людские ресурсы, а сам проект должен легко структурироваться на функционально независимые подсистемы. [7, с. 104]

Одной из технологий, предоставляющих большую гибкость, чем RUP или RAD, является технология OpenUP. Как и RUP, OpenUP использует принципы итеративности и инкрементальности в рамках структурированного жизненного цикла. OpenUP предлагает [7, с. 113]:

Концепцию микрошагов;
Концепцию раннего тестирования;
Методику гибкого моделирования;
Упрощенный RUP процесс;
Шаблоны различного вида.

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

3. Язык UML

3.1 Общие сведения об языке UML

Унифицированный язык моделирования UML (Unified Modelling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. [3, с. 177] В настоящее время для объектно-ориентированного моделирования проблемной области UML фактически является стандартом по объектно-ориентированным технологиям.

Словарь UML включает три вида строительных блоков:

Сущности;
Связи;
Диаграммы.

Сущности (things) — это абстракции, которые являются основными элементами модели, связи (relationships) соединяют их между собой, а диаграммы (diagrams) группируют представляющие интерес наборы сущностей. [1, с. 32]

Основным инструментом представления модели UML являются диаграммы. Диаграмма UML — это нагруженный связный граф, вершины которого нагружаются элементами модели, а ребра – отношениями между элементами.

Одна диаграмма способна отобразить лишь отдельную черту системы, поэтому используют набор диаграмм. Этот набор обеспечивает визуальное представление программной системы с разных точек зрения. Объединение разных точек зрения дает полную картину, достаточную для решения конкретных задач разработки ПО. [6, с. 211]

Теоретически диаграмма может включать в себя любую комбинацию сущностей и связей. На практике, однако, используется лишь небольшое число общих комбинаций, состоящих из пяти наиболее часто применяемых представлений архитектуры программных систем. По этой причине UML включает 13 видов диаграмм. [1, с. 40]. Однако, на практике чаще всего используют меньше. Наиболее широкое распространение получили:

Диаграмма классов;
Диаграмма компонентов;
Диаграмма вариантов использования;
Диаграмма взаимодействия;
Диаграмма состояний;
Диаграмма деятельности;
Диаграмма размещения;
Диаграмма пакетов.

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

Классы;
Интерфейсы;
Зависимости.

Для группировки классов, обладающих некоторой общностью, применяются пакеты. Пакет — общий механизм для организации элементов модели в группы. Пакет может включать другие элементы. Каждый элемент модели может входить только в один пакет. Пакет является средством организации модели в процессе разработки, повышения ее управляемости и читаемости, а также единицей управления конфигурацией. Если между любыми двумя классами, находящимися в разных пакетах, существует некоторая зависимость, то имеет место зависимость и между этими двумя пакетами. Таким образом, диаграмма пакетов (Рисунок 3) представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. [5]

Рисунок 2

Рисунок 3

Диаграммы вариантов использования — это один из видов диаграмм UML, предназначенных для моделирования динамических аспектов систем. Диаграммы вариантов использования — основной вид диаграмм при моделировании поведения системы, подсистемы или класса. Каждая из них показывает набор вариантов использования и действующих лиц в их взаимодействии. [1, с. 253]

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

Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. [5] Пример диаграммы использования представлен на Рисунке 4.

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

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

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

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

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

Диаграмма последовательности — это диаграмма взаимодействия, которая подчеркивает временной порядок сообщений. Изображается как таблица, в которой представлены объекты, расположенные вдоль оси X, и сообщения, упорядоченные по ходу времени – вдоль оси Y.

Рисунок 4

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

Пример диаграммы последовательности изображен на Рисунке 5, пример диаграммы коммуникации изображен на Рисунке 6.