На пути к применению UML

 

Введение

 

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

 

Средина 90-х годов знаменовалась появлением новых, улучшенных версий существующих методологий. Особо можно отметить технику Booch'93, дальнейшее развитие OMT, а также Fusion, OOSE, OMT-2. Однако до появления промышленного объектно-ориентированного стандарта моделирования — UML (Unified Modeling Language- Унифицированный Язык Моделирования) — в мире не существовало четко выраженного лидера.

 

К концу 1996 г. выяснилось, что ряд крупных компаний готово рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др.

 

UML формировался в следующих направлениях:

  • обеспечение связи между моделями UML и концепцией повторного использования;
  • разработка языка OCL (Object Constraint Language), описывающего семантику языка;
  • разработка концепции компонентного программирования и использования UML в репозиториях (хранилищах);
  • расширение рамок UML для моделирования бизнеса.

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

 

Цели UML

 

Унифицированный язык моделирования (Unified Modeling Language — UML) предназначен для спецификации, визуализации, документирования, анализа и проектирования программных систем. UML — квинтэссенция концепций моделирования, а именно:

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

Структура языка

 

Определение UML включает в себя следующие документы: Семантика UML, Нотация UML, Спецификации языка OCL (Object Constraint Language) и Расширение UML.

 

В язык встроены следующие механизмы:

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

Пакеты — это контейнеры элементов моделирования. Разбиение больших моделей на пакеты позволяет структурировать модели, разделяя их на модули.

 

Модульность модели предполагает наличие модулей со множеством хорошо определенных интерфейсов.

 

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

 

Классы могут иметь следующие стереотипы:

  • Boundary — представляет собой интерфейс к "внешнему миру";
  • Control — класс, отвечающий за управление последовательностями информации;
  • Entity — абстракция какой-либо сущности из реального мира;
  • Exception — класс, представляющий исключительную ситуацию, ошибку;
  • Interface — специфицирует множество видимых снаружи операций.

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

 

Ограничения позволяют определить подмножество элементов моделирования, наделенное определенными свойствами (например, упорядоченность). Могут быть описаны с помощью OCL.

 

Представления языка

 

Семантика языка описывается путем определения связей между синтаксисом и значением.

 

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

 

Способ представления — каждый элемент языка может иметь разное представление в зависимости от используемых методик или инструментальных средств.

 

Типы диаграмм UML

 

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

 

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

  • диаграммы вариантов использования;
  • диаграммы классов.

Поведенческие аспекты разрабатываемой системы:

  • диаграммы состояний;
  • диаграммы активности.

Взаимодействия объектов системы:

  • диаграммы следования;
  • диаграммы кооперации.

Физическая реализация системы:

  • диаграммы компонентов;
  • диаграммы размещения.

Диаграммы вариантов использования

 

Техника вариантов использования (UseCase) была впервые предложена Айваром Якобсоном в 1992 г. Предназначена она для описания предоставляемой функциональности таких сущностей, как системы или подсистемы. Ключевыми элементами являются «Действующие лица» (Actors), взаимодействующие с системой с помощью так называемых вариантов использования (Use Cases). Действующим лицом является любая сущность, взаимодействующая с системой как извне, так и изнутри. Им может быть человек, оборудование, другая система — то, что взаимодействует с системой. В свою очередь вариант использования описывает дискретное множество транзакций, предоставляемое действующему лицу. Экземпляры действующих лиц и вариантов использования взаимодействуют, когда необходимо описать предоставляемый сущностью (системой) сервис.

 

Диаграммы классов

 

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

 

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

 

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

 

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

 

Диаграммы следования

 

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

 

Диаграммы кооперации

 

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

 

Диаграммы состояния

 

Диаграммы состояний, так же как и диаграммы взаимодействия, формируют костяк поведенческой части языка UML, описывают поведение элементов — то есть моделируют все возможные изменения состояний, вызванные внешними воздействиями со стороны других элементов, систем или извне. В отличие от диаграмм взаимодействия, данный тип диаграмм описывает изменение состояния только одной части системы. Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого пусковым условием. Объект перейдет из одного состояние в другое только в случае, если произошло указанное событие и пусковое условие приняло значение «истина».

 

Диаграммы активности

 

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

 

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

 

Диаграммы реализации

 

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

 

Диаграммы компонентов

 

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

 

Диаграммы размещения

 

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

 

Создание моделей с помощью UML

 

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

 

Далее, на основании разрезов диаграмм вариантов использования и приготовленных пре- и постусловий для всех взаимодействий, начинается (с определения классов) создание диаграммы классов. Атрибуты и методы классов определяются ответом на вопрос «С чем имеешь дело?». Впоследствии создаются диаграммы состояний, происходит возврат на новый виток спирали проектирования — к диаграммам вариантов использования, где происходит повторный анализ с учетом появившихся обратных связей.

 

Необходимость методологии по использованию UML

 

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


***

 

Терминология

  • Объектно-ориентированный анализ и проектирование — метод, использующий объектную декомпозицию.
  • Абстракция — «рассмотрение существенных особенностей элемента или группы элементов, при том что несущественные особенности исключаются» (Edward Berard).
  • Абстракция — «процесс определения шаблонов для множества вариаций, абстракция является шаблоном и представляет средство специфицирования вариаций» (Ричард Гэбриель).
  • Инкапсуляция — ограничение всех частей абстракции в рамках контейнера.
  • Иерархия — абстракция, упорядоченная по рангам или уровням.
  • Ассоциация — коллекция связей между объектами.
  • Семантика (синоним — «значение») — значение нотаций (условных обозначений, синтаксиса). Семантика языка, описывается путем определения связей между синтаксисом и значением.
  • Графическая нотация — это отображение визуального представления в семантику языка.
  • Классификатор в UML — элемент, обобщающий в себе понятия класса, абстрактного класса, объекта, интерфейса, типа и т. д.

Литература

  1. Object Management Group, OMG Unified Modeling Language Specification, version 1.3, http://www.omg.org, 2000.
  2. Дейкстра Э. Дисциплина программирования.: Пер. с англ.— М.: Мир, 1978.
  3. Booch G. Object-Oriented analysis and design with applications., 2nd edition.— 1994.
  4. A.S. Evans, S. Cook, S. Mellor, J. Warmer, A. Wills. Advanced Methods and Tools for a Precise UML, 2nd International Conference on the Unified Modeling Language., Colorado, LNCS 1723, 1999.
2004.06.23
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".