ФИНЭКОСОФТ

Дмитрий А. Лесин, сертифицированный специалист IBM, компания "Финэко Софт"

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

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

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

Визуальная модель способна значительно помочь в:

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

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

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

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

Подобно вербальному языку и другим средствам общения для успешного применения моделирования крайне важно наличие единого словаря или стандарта, в рамках которого унифицированы отдельные элементы нотации. Это позволит гарантировать, что результат работы одного специалиста в области моделирования будет однозначно интерпретирован любым другим специалистом, владеющим этой же нотацией. Т.е. разработчики будут способны эффективно "общаться" друг с другом, используя унифицированные "термины" графической нотации. Таким стандартом в области разработки объектно-ориентированных систем, доказавшем свою эффективность в огромном количестве проектов, является UML (Unified Modeling Language -- Унифицированный язык моделирования), продвигаемый организацией Object Management Group (OMG).

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

Впоследствии, в 90-е годы образовалась инициативная группа: Гради Буч (Grady Booch), Айвар Якобсон (Ivar Jacobson) и Джеймс Рамбо (James Rumbaugh), которые объединили свои методы и согласовали с остальными авторами других методов включение их разработок в единый стандарт, названный UML. Таким образом, в UML вошли такие подходы, как:

• Язык моделирования Буча (Booch notation)
• OOSE (Object Oriented Software Engineering) от Айвара Якобсона
• OMT (Object Modeling Technique) от Джеймса Рамбо
• Recursive Design от Салли Шлеер (Sally Shlaer) и Стива Меллора (Steve Mellor)
• CRC (Class-Responsibility-Collaboration) карточки от Бека (Beck) и Каннингхема (Cunningham)
• Концепции Джима Оделла (Jim Odell) и Джеймса Мартина (James Martin)
• И другие

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

Существует огромное число инструментальных средств, поддерживающих моделирование с помощью UML 2.0. Среди наиболее мощных коммерческих продуктов: IBM Rational Software Modeler, IBM Rational Software Architect, IBM Rational System Developer, IBM Rational Rose, IBM Rational Rose Realtime, IBM Rational System Architect и многие другие. С помощью них можно моделировать локальные и распределенные программные и аппаратные системы, любые вариации программно-аппаратных комплексов. А благодаря встроенным возможностям по расширению UML, он может быть применен практически для моделирования любых объектов и систем реального мира, необязательно только при разработке в области информационных технологий.

Перечисленные выше продукты позволяют выполнять генерацию объектно-ориентированного (C++, Java, C# и т.д.) и процедурного (Fortran, VB, COBOL и т.д.) кода а, кроме того, поддерживать синхронизацию кода с моделями при умелом использовании возможностей инструментов. Использование профайлов UML позволяет специализировать его для работы, например, с транзакционными системами (transactional systems), системами реального времени (real-time systems), отказоустойчивыми системами (fault-tolerant systems) и др.

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

Диаграммы UML

В UML 2.0 определены тринадцать типов диаграмм, разделенных на три подгруппы. Шесть диаграмм позволяют описать статические аспекты архитектуры (диаграммы классов, объектов и компонент, композитные структурные диаграммы, диаграммы пакетов и развертывания), три - основные типы поведения (диаграммы сценариев использования, деятельностей и состояний) и четыре представляют различные аспекты взаимодействия (обычно рассматриваются, как подгруппа диаграмм поведения, к которой относятся диаграммы последовательностей, коммуникации объектов, временные диаграммы и обзорные диаграммы взаимодействия).

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

• Диаграммы сценариев использования (Use case diagrams): эти диаграммы используются для выявления основных функций и процессов, которые кладутся в основу функционирования разрабатываемой системы. Ключевыми элементами являются актеры или действующие лица (actors) и сценарии использования или процессы (use cases). Диаграммы сценариев использования показывают, какие актеры с какими сценариями использования взаимодействуют.
• Диаграммы классов (Class diagrams): диаграммы классов позволяют описать, как функции системы реализуются на уровне ее строительных блоков - классов. Любой из классов может участвовать в реализации одного или нескольких сценариев использования, также как любой сценарий использования может быть реализован в одном или более классах. Классы могут иметь уникальные наборы атрибутов (attributes), которыми описываются состояния производных объектов. Кроме того, классы включают наборы методов (methods), в которых заключено описание возможного поведения производных объектов.
• Диаграммы объектов (Object diagrams): можно рассматривать диаграммы объектов, как производные от диаграмм классов. Объект - это экземпляр класса. Классы описывают объекты, которые порождаются на основе указанных описаний в реально работающей системе. Объект обладает состоянием, которое определяется конкретными значениями атрибутов в любой момент времени его жизни. На объектных диаграммах показываются важные для представления объекты и все активные связи с другими объектами, существующие в работающей системе в определенный момент времени.
• Диаграммы состояний (State diagrams): диаграмма состояний описывает в графическом виде различные состояния и переходы между ними, включая условия возникновения этих переходов. Каждое состояние может быть, в свою очередь, описано другой аналогичной диаграммой, т.е. быть составным.
• Диаграммы деятельностей (Activity diagrams): процессы, имеющие место в работающей системе фиксируются с помощью диаграмм деятельностей. Эти диаграммы очень похожи на диаграммы состояний, но ключевыми элементами здесь являются не состояния, а деятельности (activities), действия (actions), переходы между ними (transitions), а также, как и на диаграммах состояний -- начальное (initial state) и конечные состояния (final states) и условия переходов (guard conditions). Вообще, разрешается создавать комбинированные диаграммы состояний и деятельностей.
• Диаграммы последовательностей (Sequence diagrams): диаграмма последовательностей описывает цепочку возникающих в работающей системе взаимодействий между ее различными объектами. Важным аспектом таких диаграмм является то, что информация на них упорядочена во времени. Они описывают пошаговые операции между объектами или, если быть более точными, процедуры обмена сообщениями между объектами работающей системы.
• Диаграммы коммуникации (Communication diagrams): родоначальниками диаграмм коммуникации являются диаграммы взаимодействия объектов (collaboration diagrams) из версий UML до 2.0. По-сути, это другой способ представления информации, показанной на диаграмме последовательностей. В отличие от последней диаграмма коммуникации делает фокус на представлении группы взаимодействующих объектов и связей между ними, образующихся, если объекты общаются друг с другом посредством отсылки и приема сообщений. Также диаграммы коммуникаций подобны диаграммам объектов, но на них дополнительно могут быть показаны отсылаемые сообщения, причем допускается даже с указанием нумерации, описывающей порядок их следования во времени.
• Компонентные диаграммы (Component diagrams): компонентные диаграммы отображают высокоуровневые части системы, из которых она собрана, и как эти части связаны друг с другом. Эти высокоуровневые части являются структурными блоками, из которых выполняется сборка системы подобно тому, как кирпичное здание собирается из множества кирпичей.
• Диаграммы развертывания (Deployment diagrams): в диаграммах развертывания отображается программно-аппаратная реализация системы в терминах подсистем, модулей, серверов и т.д.

Открытый ресурс, посвященный развитию UML и содержащий большие объемы необходимой информации, включая документацию доступен на одном из сайтов Object Management Group (OMG) по ссылке: http://www.uml.org/

***

В Каталоге Центра IT обучения "Institutio" представлено несколько специализированных программ обучения по визуальному моделированию на UML, отличающихся друг от друга включенными в них модулями:

1. PUML0001, Визуальное моделирование с использованием UML v2 (полный курс, включающий рассмотрение подходов к визуальному моделированию от бизнес-моделирования и проектированием конечных объектно-ориентированных архитектурных решений), 4 дня
2. PUML0002, Бизнес и функциональное моделирование с использованием UML v2 (курс, включающий рассмотрение верхнеуровневых подходов бизнес-моделирования и моделирования сценариев использования), 2 дня
3. PUML0003, Анализ и проектирование с использованием UML v2 (курс, включающий рассмотрение подходов анализа и проектирования конечных объектно-ориентированных архитектурных решений), 2 дня