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

2.2.Диаграмма вариантов использования USE CASE DIAGRAM

Диаграмму вариантов использования имеет смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на последующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно, ее можно использовать для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).

На диаграмме использования изображаются:

• акторы — группы лиц или систем, взаимодействующих с нашей системой;
• варианты использования (прецеденты) — сервисы, которые наша система предоставляет акторам;
• комментарии;
• отношения между элементами диаграммы.

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

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

Дополнить прецеденты словесным описанием (сценарием):

• для каждого прецедента создать разделы: «главная последовательность» и «альтернативные последовательности»;
• при составлении сценария нужно упорно задавать заказчику вопросы «что происходит?», «что дальше?», «что еще может происходить?» и записывать ответы на них.

Сценарии являются очень важной частью диаграмм использования, хотя их формат и непорядочен. Ряд авторов предлагает использовать псевдокод для представления сценария и даже сразу строить диаграммы деятельности или взаимодействия, но, наиболее предпочтительным вариантом на этапе построения use-case диаграмм является текстовый, описывающий систему с точки зрения эксплуататора (т.к. именно этот формат будет наиболее понятен заказчику, с которым вам предстоит согласовывать техническое задание).

Рассмотрим разработку диаграмм вариантов использования на примере -пусть заказчик дал нам следующее техническое задание:

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

Пример диаграммы использования

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

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

2.3.Диаграмма классов USE CASE DIAGRAMS

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

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

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

Ключевым элементом диаграммы классов является класс.

Обозначается значком:

Класс состоит из двух частей – заголовка с именем класса и тела с описанием его полей (Атрибуты – в терминах UML) и методов (Операции - в терминах UML).

Абстрактные классы отличаются наклонным написанием заголовка:

Под атрибутами класса в терминологии UML понимают его поля.

Атрибуты записываются с указанием доступности, имени и типа.

Знак минус означает, что атрибут приватный (private).

Знак плюс означает, что атрибут публичный (public).

Знак решетка означает, что атрибут защищенный(protected).

После имени следует указание типа атрибута.

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

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

Абстрактные методы записываются наклонным курсивом

Кроме классов, не мало важным элементом диаграмм классов считаются интерфейсы.

Интерфейс обозначается так:

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

Перечисление обозначается так:

Обычно перечисление указывается с росписью возможных значений

На диаграмме классов начертаны не только классы, интерфейсы и пр., но и их взаимосвязи.

Взаимосвязи бывают различных типов и отображаются, соответственно, по-разному.

Генерализация или наследование (Generalize) обозначается так:

На примере показано, что два класса являются наследниками обобщенного класса.

Реализация (Realize) – означает, что данный класс реализует данный интерфейс:

Ассоциация (Associate). Самая востребованная взаимосвязь между классами. У нее достаточно широкое значение и может пояснять следующее:

1.Один класс осуществляет взаимодействие с другим любым способом. 
 

2.Один класс включает в себя субъект другого класса. 
 
Видим, что перечисление Status включено в класс User, при этом имя поля Status, с областью видимости public. 

3.Один класс включает в себя несколько субъектов другого класса. 
 

Если Ассоциация не может быть реализована без дополнительных классов, то она реализуется, принимая помощь дополнительных классов ассоциации, которые способны решить эту задачу. 
Обозначается это следующим образом:

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

Агрегация (Aggregate) - означает, что объекты одного класса могут быть включены в объекты другого класса и при этом вложенный объект может находиться в нескольких объектах-контейнерах. Если объект контейнер удаляется, то вложенный объект не удаляется.

Кроме стандартного значка класса, есть дополнительные, которые применяются для некоторых типов классов. Здесь приведены три чаще всего используемых обозначения, которые применяются для работы с шаблоном «Модель-Представление-Контроллер»:

1.Класс-сущность (Entity) – обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах. 
 

2. Класс-контроллер (Controller) – как правило, используется для классов, которыми пользуются для выполнения неких операций над объектами. 
 

3. Класс - Разграничитель (Boundary) – обычно используется для классов, разделяющих внутреннюю структуру системы от внешней среды. Это могут быть как WebServices, так пользовательский интерфейс и др. 

2.4.Диаграмма взаимосвязи INTERACTION DIAGRAMS

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

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

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

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

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

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

3. Средства реализации объектно-ориентированного моделирования ИС

3.1. IBM RATIONALROSE

Все продукции Rational Rose поддерживают язык Unified Modeling Language (UML), но при этом, эти продукции различаются технологиями реализации, которые они поддерживают.  Rational Rose - среда моделирования, которая поддерживает генерацию кода из моделей, написанных на языке Ada, ANSI C++, C++, CORBA, Java/J2EE, Visual C++ и Visual Basic.

IBM Rational Rose - доступное средство визуального моделирования, как правило, считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite (для виртуализации десктопов). Предназначен для моделирования ПС с использованием крупного спектра инструментальных средств и платформ. Инструментальное средство IBM Rational Rose увеличивает шансы моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

Являясь простым и мощным решением для визуальной разработки ИС любого класса, Rational Rose позволяет создавать, изменять и проверять исправность модели. Rational Rose объединяет команду разработчиков на основе многофункционального языка моделирования UML, определяющего стандартную графическую атрибутику для описания архитектуры ПО. Любые респонденты проекта - аналитики, специалисты по моделированию, разработчики и др. - могут использовать модели, построенные в Rational Rose, для большей оперативности создания результативного продукта.

3.2. SPORX SYSTEMS ENTERPRASE ARCHITECT

Enterprise Architect - это платфора для UML-моделирования и проектирования нового поколения. 

Enterprise Architect bvttncz в вариантах для Windows и Linux и служит неплохим средством для UML-моделирования, с имеющейся возможностью многопользовательской работы и доверительным интерфейсом. В этой программе изобилие функций, которые обычно распределены между несколькими приложениями, включая объективные возможности по генерации документации, поддержку плагинов, генерацию XSD-схем, HTML и поддержку для таких языков программирования, как C++, Java, PHP, Visual Basic, VB.Net, Delphi или C#.