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

Уже в настоящее время разработаны средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic и другие. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы. Язык UML может быть расширен без переопределения его ядра.

Язык UML предназначен прежде всего для разработки программных систем. Его использование особенно эффективно в следующих областях:

• Информационные системы масштаба предприятия
• Банковские и финансовые услуги
• Телекоммуникации и транспорт
• Распределенные web-системы

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

Подводя итог анализу методологии ООАП и исторических предпосылок появления UML, можно утверждать следующее. Имеются все основания предполагать, что в ближайшие годы язык UML в его современном виде станет основой для разработки и реализации во многих перспективных инструментальных средствах: в RAD-средствах визуального и имитационного моделирования, а также в CASE-средствах самого различного целевого назначения. Более того, заложенные в языке UML потенциальные возможности могут быть использованы не только для объектно-ориентированного моделирования систем, но и для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.

В данной работе с помощью языка UML проводится моделирование информационной системы обработки заказов.

1.3 Составные части языка UML

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

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

• сущности;
• отношения;
• диаграммы.

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

В UML имеется четыре типа сущностей: структурные, поведенческие, группирующие, аннотационные.

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

Структурные сущности – это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существуют следующие разновидности структурных сущностей:

Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

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

Три другие сущности – активные классы, компоненты и узлы – подобны классам: они описывают совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует два основных типа поведенческих сущностей:

1. Взаимодействие (Interaction) – это поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов.
2. Автомат (State machine) – это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов.

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность – пакет.

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

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

В языке UML также определены четыре типа отношений:

• зависимость;
• ассоциация;
• обобщение;
• реализация.

Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.

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

Ассоциация (Association) – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами.

Обобщение (Generalization) – это отношение «специализация/ обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

Реализация (Realization) – это семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение.

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

• диаграммы классов (Class Diagrams);
• диаграммы объектов (Object Diagrams);
• диаграммы прецедентов/ вариантов использования (Use Case Diagrams);
• диаграммы последовательностей (Sequence Diagrams);
• диаграммы кооперации/ сотрудничества (Collaboration Diagrams);
• диаграммы состояний (Statechart Diagrams);
• диаграммы деятельности (Activity Diagrams);
• диаграммы компонентов (Component Diagrams);
• диаграммы развертывания/ размещения (Deployment Diagrams).

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

• 1. Диаграмма прецедентов или вариантов использования (Use Case Diagram) – для представления системы с точки зрения прецедентов и выявления требований к ней.
  2. Диаграмма классов (Class Diagram) – для моделирования статической структуры системы и взаимосвязи между классами.
  3. Диаграмма последовательности (Sequence Diagram) – для моделирования процессов сообщения между объектами.
  4. Диаграмма компонентов (Component Diagram) – для моделирования иерархии элементов системы.
  5. Диаграмма развертывания или размещения (Deployment Diagram) – для моделирования физической архитектуры системы.

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

2.1 Создание диаграмм вариантов использования

В результате предшествующего проекту исследования было составлено следующее описание предметной области:

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

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

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

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

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

В данном случае роль Актера (Actor) будут играть Компания-посредник, Клиент, Транспортная компания, Банк, Сайт. Каждый вариант использования показывает, как конкретный актер использует систему. Необходимо рассмотреть и виды отношений, которыми они связаны.

Компания-посредник – в рамках данной системы компания продает товары различных производителей, публикует каталог продуктов и рассылает его клиентам, выполняет заказы, доставляя их по адресам клиентов.

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

Сотрудник транспортной компании – обладает следующими полномочиями: доставляет товары по адресам клиентов, информирует компанию-посредника о доставке.

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

include

include Сайт

Компания-посредник

include

include

include

include Клиент

include

include

include

Транспортная компания Информационная система

Банк

Рисунок 1 – Диаграмма вариантов использования

Краткое описание вариантов использования, изображенных на рисунке.

Вариант использования «Выпустить каталог» позволяет компании-посреднику сообщить о предлагаемой продукции либо посылая каталог по почте, либо публикуя его на сайте в Интернет.

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

Вариант использования «Сформировать заказ» подразумевает, что компания-посредник посылает необходимую информацию о клиенте и сам заказ в транспортную компанию.

Вариант использования «Доставить заказ» и «Информировать о доставке» позволяет транспортной компании доставить заказ по адресу клиента в заданный срок, а затем информировать компанию-посредника о результате доставки заказа клиентам.