Раздел 6. Технологии объектно-ориентированного проектирования

UML

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

В 1994 году было положено начало формированию стандартного языка для объектно-ориентированного анализа и моделирования. Данный язык получил наименование «Unified Modeling Language» (UML) — унифицированный язык моделирования. Основными авторами языка стали Г. Буч (Booch), А. Джекобсон (Jacobson), Д. Рамбо (Rumbaugh). Каждый из них являлся автором своего объектно-ориентированного метода: Booch, OOSE (Object-Oriented Software Engineering) и OMT (Object Modeling Technique) соответственно. Поэтому UML вобрал в себя значительную часть нотации этих методов.

В 1997 году версия 1.0 языка была принята консорциумом OMG (Object Management Group) в качестве стандарта на язык объектно-ориентированного анализа и проектирования, а также бизнес-моделирования.

По состоянию на 2003 год базовой версией языка является версия 2.0 (одобрена в июне месяце).

Основное содержание процесса проектирования с использованием UML

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

Последовательность и содержание этапов при проектировании ИС в рамках объектно-ориентрованного подхода следующие:

- анализ требований, или точное определение требований к ИС, во время которого определяются основные выполняемые системой действия с внешней точки зрения (обычно с точки зрения пользователей);

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

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

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

Совокупности UML-диаграмм определенного типа задают основные виды на всю архитектуру ИС:

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

- вид с точки зрения проектирования (design view) описывает классы, интерфейсы и их взаимоотношения, что составляет словарь предметной области и ИС; данный вид содержит как статические (классы), так и динамические (взаимоотношения) составляющие;

- вид с точки зрения процессов (process view) охватывает нити управления и процессы, т.е. описывает параллелизм и синхронизацию действий в ИС;

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

- вид с точки зрения развертывания (deployment view) охватывает аппаратуру ИС и физическое размещение программных компонент ИС.

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

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

Основные диаграммы

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

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

Диаграмма прецедентов использования (use case diagram)

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

Каждая такая диаграмма — это описание сценария поведения, которому следуют действующие лица, или актеры (actors). Пример:

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

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

Диаграмма классов (class diagram)

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

Пример (моделирование части графической библиотеки):

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

Диаграмма состояний (statechart diagram)

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

Пример (поведение T-триггера):

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

Диаграмма деятельности (activity diagram)

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

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

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

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

Этот тип диаграмм входит в группу так называемых диаграмм взаимодействия (interaction diagrams). Кроме диаграмм последовательности, эта группа включает в себя диаграммы сотрудничества, или кооперации (collaboration diagram). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе, в то время как диаграммы состояний и диаграммы деятельности ориентированы на описание поведения одного объекта или процесса.

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

Пример:

Следует обратить внимание, что на диаграмме отображается не класс «Контроллер», а объект класса «Контроллер», поскольку класс ­— это абстрактное понятие, и он не может принимать участие в обмене сообщениями.

Диаграмма сотрудничества (collaboration diagram)

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

Пример:

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

Диаграмма компонентов (component diagram)

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

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

Пример:

Диаграмма развертывания (deployment diagram)

Этот вид диаграмм предназначен для анализа аппаратной части систе­мы и позволяет описать топологию аппаратных средств ИС.

Пример: