Глава 1. Что такое визуальное моделирование
Глава 1. Что такое визуальное моделирование
Визуальным моделированием (visual modeling) называется способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах: заказчику, эксперту, аналитику, проектировщику, автору документации, программисту и др. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создаваемых систем.
Модель (model) — это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных деталях, тем самым делая ее более понятной. Абстрагирование — одна из основных способностей человека, которая позволяет разбираться в сложных вещах. Инженеры, артисты, ремесленники используют модели на протяжении тысячи лет, чтобы сначала проверить изделие или замысел, а потом приступить к его реализации. Разработка программного обеспечения — не исключение. Для построения сложной системы необходимо сначала разделить ее на несколько абстрактных представлений и построить модели, используя принятые обозначения — нотацию (notation). Затем убедиться, что модели удовлетворяют всем потребностям системы, и постепенно добавлять детали для перехода от моделей к реализации.
Мы строим модель сложной системы, потому что не можем охватить и понять проект целиком. Существуют пределы в понимании сложных вещей. Это можно продемонстрировать на примере архитектуры. Если вы хотите построить сарай во дворе, вам достаточно просто начать строительство. Когда вы планируете построить новый дом, вам наверняка потребуется чертеж. А для возведения небоскреба он будет просто необходим. Этот же пример можно привести для программного обеспечения. Изучая работу отдельной формы в Visual Basic, программист не сумеет представить схему проекта целиком. Создание модели позволяет представить общую картину взаимодействия узлов системы без углубления в детали реализации отдельных элементов.
Модели помогают нам организовывать, отображать, понимать и создавать сложные вещи. Они призваны помочь в решении трудных задач при разработке программ сегодня и в будущем.
Треугольник успеха
Я часто использую треугольник успеха (triangle for success), показанный на рис. 1.1, чтобы изобразить средства, необходимые для успешного проекта. Вам потребуются все три грани — три составляющие — нотация, процесс и инструмент. Можно изучить нотацию, но если вы не знаете, как ее применить (организовать процесс), то, вероятно, потерпите неудачу. У вас могут быть хорошо организованные процессы, но если вы не сумеете описать порядок их взаимодействия (используя нотацию), то, скорее всего, вам не удастся довести проект до конца. И наконец, если вы неправильно определите орудия труда (инструменты), вас наверняка постигнет неудача.
Рис. 1.1. Треугольник успеха
Роль нотации
Нотация является важной составляющей любой модели — она служит связующим звеном между процессами. «Нотация выполняет три функции:
? является языком для описания взаимодействий, которые неочевидны или не могут быть получены непосредственно из кода;
? обеспечивает достаточную семантику, позволяющую охватить важные стратегические и тактические решения;
? предлагает конкретную форму, помогающую человеку рассуждать о предметной области, а средствам моделирования воплощать описанные идеи»[1].
Унифицированный язык моделирования (Unified Modeling Language — UML) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию. Определенные элементы нотации (например, классы, связи, агрегаты, наследование) используются на этапе анализа. Другие элементы (индикаторы реализации и свойства) вводятся на стадии проектирования.
История UML
В 90-е годы появилось большое количество различных методологий с собственными наборами нотаций. Самые популярные — ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону). Каждая из них имела свои преимущества. Методика ОМТ отличалась хорошими средствами анализа и слабыми сторонами в проектировании, а методика Booch 1991, наоборот, более подходила для проектирования, чем для анализа. В методике OOSE основное внимание уделено развитым средствам поведенческого анализа, а в других областях отмечено много недостатков.
Спустя некоторое время Буч опубликовал второе издание, в котором собрал лучшие идеи и решения в области анализа, предлагавшиеся в том числе Рамбо и Джекобсоном. В свою очередь, Рамбо написал серию статей, известных как методика ОМТ-2, куда вошли предложения Буча в области проектирования. Перечисленные методики были достаточно похожи, но отличались разными нотациями — один и тот же символ имел в них различные значения. Например, закрашенный круг был индикатором множественности в методике ОМТ и символом агрегата в нотации Буча. Вы, наверное, слышали фразу «война методов», употреблявшуюся в период, когда класс обозначался либо в виде облака, либо в виде прямоугольника? Трудно понять, что же лучше.
Конец войне методов положила нотация, принятая в языке UML. «Язык UML служит для определения, отображения и описания элементов объектно-ориентированных систем в процессе их создания. Он объединяет объектную модель, нотации Буча и ОМТ, а также лучшие идеи, предложенные авторами других методик (рис. 1.2). Таким образом, язык UML является стандартом де-факто в области объектно-ориентированного анализа и проектирования»[2].
Универсальный язык UML — это попытка стандартизировать инструменты анализа и проектирования семантических моделей, синтаксических нотаций и диаграмм. Первая общедоступная версия (0.8) появилась в октябре 1995 года. Джекобсон и другие разработчики предложили несколько вариантов, которые были реализованы в последующих двух версиях (0.9 — в июле и 0.91 — в октябре 1996 года). Версия 1.0 была представлена для стандартизации в ассоциацию Object Management Group (OMG) в июле 1997 года. Дополнительные улучшения сделаны в версии 1.1, которая вышла в сентябре того же года, а в ноябре UML был утвержден ассоциацией OMG в качестве стандартного языка моделирования.
Рис. 1.2. Составные части языка UМL
Роль процессов
Успешно разработанный проект удовлетворяет или превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и может быть адаптирован к изменению условий. Жизненный цикл разработки должен способствовать творческим и новаторским идеям. В то же время для своевременного завершения процесс разработки должен контролироваться. «Творчество естественно для создания всех хорошо структурированных объектно-ориентированных архитектур, но если разработчиков не контролировать, то они, возможно, никогда не достигнут конечного результата. Значит, для эффективной работы коллектива нужна дисциплина. Но слишком жесткая дисциплина приводит к развитию бюрократии, которая, в свою очередь, душит новаторские идеи»[3]. Правильно управляемый итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль и поддерживает творческий процесс на нужном уровне.
Что такое итеративная и инкрементальная разработка
В итеративном и инкрементальном жизненном цикле (см. рис. 1.3) разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса: построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение. Разработчики допускают, что не все требования к системе известны в начале жизненного цикла. Корректировки возможны на любом этапе.
Рис. 1.3. Итеративная и инкрементальная разработка
Такой тип жизненного цикла позволяет уменьшить риск. Технические риски оцениваются и группируются по приоритетам на ранней стадии цикла и корректируются во время разработки каждой версии. Риски закреплены за каждой версией таким образом, что успешное завершение версии уменьшает риск, закрепленный за ней. Процесс планируется так, чтобы наибольшие риски были рассмотрены в первую очередь. Построение системы подобным образом выявляет и уменьшает риски на раннем этапе жизненного цикла. Результат такой модели жизненного цикла — уменьшение риска и затрат[4].
Методология Rational Unified Process
Для поддержки управления итеративным и инкрементальным жизненным циклом разработки используется методика Rational Unified Process, с помощью которой можно подробно описать технические и организационные аспекты создания программного обеспечения на стадиях определения требований к системе, анализа и проектирования.
Методология Rational Unified Process структурирована в двух направлениях:
? время (разделение жизненного цикла на фазы и версии);
? компоненты процесса (создание необходимого набора средств для выполнения четко определенных задач).
Оба направления должны быть хорошо проработаны для получения успешного проекта.
Работа над проектом состоит из следующих временных этапов:
? задумка (inception) — определение общей идеи проекта;
? проработка (elaboration) — планирование необходимых работ и ресурсов, указание особенностей и создание архитектуры;
? создание (construction) — построение продукта при помощи серии последовательных версий;
? переходный период (transition) — поставка продукта пользователям (производство, распространение, обучение).
В разрезе компонентов процесс делится на следующие стадии:
? построение бизнес-модели (business modeling) — определение необходимых возможностей системы и потребностей пользователей;
? определение требований к системе (requirements) — изложение общей идеи системы совместно с функциональными и нефункциональными условиями ее работы;
? анализ (analysis) и проектирование (design) — описание способов исполнения системы на этапе реализации;
? реализация (implementation) — кодирование и генерация работающих программных модулей системы;
? тестирование (test) — проверка функционирования системы;
? внедрение (deployment) — поставка системы конечным пользователям и их обучение.
Каждая стадия в разрезе компонентов процесса обычно применяется к конкретной фазе временного направления (см. рис. 1.4.). Однако степень применения каждого компонента зависит от этапа разработки. Например, вы можете испытать концептуальный прототип системы на стадии задумки, и тогда вам потребуется не только определение требований — необходимо будет провести анализ, проектирование, реализацию и тестирование, чтобы завершить создание прототипа. Важность анализа выявляется на этапе проработки.
Рис. 1.4. Стадии разработки
Сначала предпочтительно выпустить несколько версий. Они обычно используются для проверки аналитических решений в области архитектуры системы. Таким образом, вы не только анализируете проблему. На стадии создания система строится с помощью серии версий. При любой структуре разработки дополнительные вопросы всегда возникают неожиданно, что требует проведения нового анализа.
Диаграмма должна быть основным руководством для отражения жизненного цикла вашего проекта. Основная мысль заключается в следующем: если вы только думаете над тем, что собираетесь создавать, в то время когда уже пишете код, вероятно, у вас возникнут проблемы. Заметьте, что тестирование применяется в ходе всего итерационного процесса. То есть вы не ждете, когда весь код будет написан для проверки его работы.
В этой книге применяется упрощенная версия Rational Unified Process, в которой сделан акцент на использовании языка UML для получения и документального описания решений на стадиях задумки и проработки проекта. В последних главах кратко рассказывается об этапе создания. Несмотря на то что тестирование — неотъемлемая часть процесса разработки, его описание выходит за рамки данной книги.
Пакет Rational Rose
Методы создания программного обеспечения должны поддерживаться соответствующими инструментами разработки. Когда я впервые начала заниматься объектно-ориентированным моделированием, моими инструментами были бумага и карандаш. Теперь в продаже имеются более удобные программные инструменты — не только простые графические редакторы, но и сложные пакеты объектного моделирования. В этой книге для моделирования используется программа Rational Rose. На каждом этапе моделирования приводится описание необходимых действий.
Семейство продуктов Rational Rose призвано обеспечить разработчика программ полным набором инструментов визуального моделирования для эффективного решения сложных бизнес-задач с использованием архитектуры клиент/ сервер, распределенных сред и систем реального времени. В продуктах Rational Rose отражен универсальный стандартизированный подход к построению моделей, позволяющий программистам моделировать логику приложений, а не программистам — бизнес-процессы. Демонстрационную версию пакета Rational Rose можно получить на сайте компании Rational Software Corporation по адресу: www.rational.com.
Хотя в этой книге в качестве инструмента моделирования используется Rational Rose, ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler. Этот продукт предназначен специально для начинающих разработчиков и предоставляет следующие возможности:
? описывать и проектировать бизнес-объекты с последующим отображением их на программные компоненты;
? разделять сервисы в трехзвенной сервисной модели;
? распределять компоненты в сети;
? генерировать исходные модули на Visual Basic по созданной модели;
? использовать возвратное проектирование для создания модели по существующим компонентам и приложениям;
? синхронизировать модели с кодом.
Пакет Rational Rose по сравнению с Microsoft Visual Modeler позволяет анализировать требования к бизнес-системе и бизнес-сценарии с помощью диаграмм последовательности действий и диаграмм взаимодействий, моделировать состояния, генерировать код и поддерживать встроенный скрипт для доступа к внутренним компонентам программы.
Резюме
Визуальное моделирование — это способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах: заказчику, эксперту, аналитику, проектировщику, автору документации, программисту и др. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создаваемых систем.
Нотация — важная составляющая любой модели, своего рода связующее звено между процессами. Унифицированный язык моделирования (UML) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию.
Успешно разработанный проект удовлетворяет или превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и может быть адаптирован к изменению условий. Жизненный цикл разработки должен способствовать творческим и новаторским идеям. Правильно управляемый итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль и поддерживает творческий процесс на нужном уровне. В итеративном и инкрементальном жизненном цикле разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса: построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение.
В качестве средства управления итеративным и инкрементальным жизненным циклом разработки применяется методика Rational Unified Process, с помощью которой можно подробно описать технические и организационные аспекты разработки программного обеспечения на стадиях определения требований к системе, анализа и проектирования. В этой книге используется упрощенная версия Rational Unified Process.
Семейство продуктов Rational Rose призвано обеспечить разработчика программ полным набором инструментов визуального моделирования для эффективного решения сложных бизнес-задач с использованием архитектуры клиент/сервер, распределенных сред и систем реального времени.
Данный текст является ознакомительным фрагментом.