Технология разработки программного обеспечения

При разработке моделей требуется более сложный инструментарий, чем при составлении эскизов, так как необходимо поддерживать детальность, соответствующую требованиям поставленной задачи. Специализированные CASE-средства (computer-aided software engineering - автоматизированная разработка программного обеспечения) попадают в эту категорию, хотя сам этот термин стал почти ругательным, и поставщики стараются его избегать. Инструменты прямой разработки поддерживают рисование диаграмм и копирование их в репозиторий с целью сохранения информации. Инструменты обратного проектирования читают исходный код, записывают его интерпретацию в репозиторий и генерируют диаграммы. Инструменты, позволяющие выполнять как прямую, так и обратную разработку, называются двухсторонними (round-trip).

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

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

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

Один из интересных вопросов, касающихся UML как языка программирования, - это вопрос о моделировании логики поведения. UML 2 предлагает три способа моделирования поведения: диаграммы взаимодействия, диаграммы состояний и диаграммы деятельности. Все они имеют своих сторонников в сфере программирования.

Другая точка зрения разработчиков на UML находится где-то между его применением для концептуального моделирования и его применением для моделирования программного обеспечения. Большинство разработчиков используют UML для моделирования программного обеспечения. С точки зрения программного обеспечения элементы UML практически непосредственно отображаются в элементы программной системы.

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

Нет строгих правил выбора точки зрения. Поскольку проблему можно рассматривать под разными углами зрения, то и способов применения существует довольно много. Некоторые инструменты автоматически преобразуют исходный код в диаграммы, трактуя UML как альтернативный вид исходного кода. Это в большей степени программный ракурс. Если же диаграммы UML применяются для того, чтобы проверить и понять различные значения терминов «пул активов» (asset pool) с группой бухгалтеров, то следует принять точку зрения значительно более близкую к концептуальной.

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

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

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

 

3.2 Архитектура, управляемая моделью, и исполняемый UML

Когда говорят о UML, часто упоминают об MDA (Model Driven Architecture - архитектура, управляемая моделью). По сути дела, MDA представляет собой стандартный подход к использованию UML в качестве языка программирования; этот стандарт находится под управлением группы OMG, как и сам UML. Создавая систему моделирования, соответствующую MDA, поставщики могут разработать модели, способные работать и в MDA-совместимом окружении.

Говоря об MDA, часто подразумевают и UML, поскольку MDA использует UML в качестве основного языка моделирования. Но, конечно, вы не обязаны следовать MDA, применяя UML.

MDA разделяет процесс разработки на две основные части. Разработчики моделей представляют конкретное приложение, создавая PIM (Platform Independent Model - модель, не зависящая от платформы). PIM – это модель UML, не зависящая от какой-то конкретной технологии. Затем инструменты могут превратить PIM в PSM (Platform Specific Model - модель, зависящая от платформы). PSM – это модель системы, нацеленная на определенную среду выполнения. Другие инструменты берут PSM и генерируют код для этой платформы. В качестве PSM можно использовать UML, но это необязательно.

Поэтому если вы хотите создать систему складского учета с использованием MDA, вам придется начать с единой модели PIM вашей системы. Затем при желании запустить эту систему складского учета в J2EE или .NET вы должны будете использовать инструменты каких-либо производителей для создания двух моделей PSM - по одной на каждую из этих двух платформ.

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

Стив Меллор (Steve Mellor) долгое время активно работал в этой области и с недавнего времени стал употреблять термин исполняемый UML (Executable UML). Исполняемый UML похож на MDA, но использует немного другую терминологию. Точно вы начинаете с модели, не зависящей от платформы, которая эквивалентна MDA-модели PIM. Однако на следующем этапе применяется компилятор модели (Model Compiler), для того чтобы за один прием превратить UML-модель в готовую к развертыванию систему; поэтому модель PSM не нужна. Как и предполагает термин компилятор, этот этап полностью автоматизирован.

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

Исполняемый UML не использует полный стандарт UML; многие конструкции языка считаются ненужными и не применяются. Поэтому исполняемый UML проще, чем полный.

 

3.3 История UML

В 80-х годах объекты начали выходить из исследовательских лабораторий и делать свои первые шаги в направлении «реального» мира. Язык Smalltalk был реализован на платформе, пригодной для практического использования; появился на свет и С++. В то же время разработчики начали задумываться об объектно-ориентированных языках графического моделирования.

Основные книги по объектно-ориентированным языкам графического моделирования появились между 1988 и 1992 годами. Ведущими фигурами в этом деле были Гради Буч (Grady Booch), Питер Коуд (Peter Coad), Айвар Джекобсон (Ivar Jacobson) (Objectory), Джим Оделл (Jim Odell), Джим Рамбо (Jim Rumbaugh) (ОМТ), Салли Шлаер (Sally Shlaer) и Стив Меллор (Steve Mellor), Ребекка Вирфс-Брок (Rebecca Wirfs-Brock) (Responsibility Driven Design).

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

Катастрофическим событием, инициировавшим появление UML, стали уход Джима Рамбо из GE и его встреча с Гради Бучем в Rational (теперь это подразделение IBM). С самого начала было ясно, что союз Буч/Рамбо может создать критическую массу этого бизнеса.

К конференции OOPSLA '95 Гради Буч и Джим  Рамбо подготовили свое первое публичное описание их совместного метода - версию 0.8 документации по Унифицированному методу (Unified Method). И что более существенно, они объявили, что фирма Rational Software купила Objectory и что Айвар Джекобсон должен присоединиться к Унифицированной команде. На следующий год процесс стал более открытым. Появилась идея создать язык UML, который бы позволил CASE-средствам свободно обмениваться моделями.

Мэри Лумис (Mary Loomis) и Джим Оделл возглавили инициативную группу, созданную для решения поставленной задачи. В январе 1997 года различные организации представили на рассмотрение свои предложения по стандартизации методов, которые бы способствовали обмену моделями. Фирма Rational сотрудничала с несколькими организациями и в соответствии со своим планом представила версию 1.0 документации по UML - первое создание, соответствующее имени Унифицированный язык моделирования (Unified Modeling Language). Группа OMG приняла окончательную версию 1.1 в качестве официального стандарта OMG. Позднее были созданы другие версии. Версия 1.2 была целиком косметическая, версия 1.3 - более значимой. В версию 1.4 было введено множество детализированных понятий о компонентах и профилях, а в версию 1.5 добавили семантику действия.

 

3.4 Диаграммы UML

UML 2 описывает 13 официальных типов диаграмм, перечисленных в табл. 1, классификация которых приведена на рис. 7.

 

Таблица 1.

Официальные типы диаграмм UML

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

Рис. 7. Классификация типов диаграмм UML

 

3.5 Процесс разработки с использованием UML

3.5.1 Анализ требований

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

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

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

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

3.5.2. Проектирование

При разработке модели вы можете широко применять диаграммы. Можно использовать больше нотаций и при этом быть более точным. Вот некоторые полезные приемы:

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