Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (Сущность объектно-ориентированного подхода).pdf

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

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

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

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

Система объектно-ориентированных моделей в соответствии с языком UML включает в себя диаграммы, показанные на рисунке 1. [10].

Рисунок 1 – Виды диаграмм UML

Построение диаграммы прецедентов

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

описания бизнес-деятельности в виде моделей отдельных бизнес-прецедентов. Можно с помощью нескольких диаграмм представить модель на нескольких уровнях функционирования. На контекстной модели, представленной на рисунке 2, отображается обобщённый прецедент и участвующие классы. Класс «Преподаватели» является суперклассом.

декомпозиция представлена на рисунке 3.

Рисунок 2 – Диаграмма вариантов использования (Use Case Diagram)

Рисунок 3 – Декомпозиция класса «Преподаватели»

Рисунок 4– Детализация прецедента «Учебный процесс»

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

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

Диаграмма последовательности – диаграмма поведения, на которой для набора объектов на единой временной оси показан жизненный цикл объекта и взаимодействие актёров ИС в рамках определённого прецедента [6].

На рисунке 5 с помощью диаграммы последовательности, детально рассмотрен прецедент «Сбор сведений о проведённых экзаменах и зачётах». Объекты, располагающиеся на одном уровне с актёром «Деканат», являются сущностями данной модели. Той же смысловой нагрузкой обладает кооперативная диаграмма, только на ней нет фиксированного порядка операций относительно времени. Кооперативная диаграмма представлена на рисунке 6.

Рисунок 5 – Диаграмма последовательностей (Sequence Diagram)

Рисунок 6 – Кооперативная диаграмма (Collaboration Diagram)

Построение диаграммы активностей

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

Диаграммы деятельности позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Разработка диаграммы деятельности необходима:

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

Диаграмма активности представляется в виде графа деятельности, вершинами которого являются состояния деятельности, а дуги показывают переходы от одного состояния деятельности к другому [6].

Примеры диаграммы активности для прецедента «Учебный процесс» и «Прохождение ТО» представлены на рисунках 7 и 8 соответственно.

Рисунок 7 – Диаграмма активности (Activity Diagram) для прецедента

«Учебный процесс»

Рисунок 8 – Диаграмма активности для прецедента «Прохождение ТО»

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

Построение диаграммы классов

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

Условно объекты модели можно разделить на несколько пакетов, например «Сущности» и «Границы». На главной диаграмме классов, представленной на рисунке 9, отображены эти пакеты. Пример содержимого пакетов представлено на рисунке 10.

Рисунок 9 – Диаграмма классов – пакеты модели

Рисунок 10 – Диаграмма классов (Class Diagram) «Справочник аптеки»

Построение диаграммы компонентов

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

Диаграмма компонентов, как и диаграмма классов, делится на диаграмму пакетов и собственно диаграмму компонентов. Чаще всего количество пакетов, наименование пакетов и их содержимое совпадает с диаграммой классов за исключением назначения объектов и наличия связей между пакетами. Пример содержимого пакета «Сущности» представлено на рисунке 11. Пример диаграммы компонентов приведен на рисунке 12.

Рисунок 11 – Содержимое пакета «Сущности»

Рисунок 12– Диаграмма компонентов (Component Diagram)

Построение диаграммы размещения

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

Диаграммы размещения используются для моделирования статического представления системы с точки зрения размещения. В основном под этим понимается моделирование топологии аппаратных средств, на которых работает система. По существу, диаграммы размещения – это просто диаграммы классов, сосредоточен-ные на системных узлах [6].

Пример диаграммы размещения представлен на рисунке 13.

Рисунок 13– Диаграмма размещения (Deployment Diagram)

Заключение

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ЭИС.ЖЦ можно представить в виде некоторой последовательности стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д.

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

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