Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Глава 1. Что такое визуальное моделирование
Визуальным моделированием (visual modeling) называется способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах заказчику, эксперту, аналитику, проектировщику, автору документации, программисту и др. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создаваемых систем.
Модель (model) - это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных деталях, тем самым делая ее более понятной Абстрагирование - одна из основных способностей человека, которая позволяет разбираться в сложных вещах. Инженеры, артисты, ремесленники используют модели на протяжении тысячи лет, чтобы сначала проверить изделие или замысел, а потом приступить к его реализации Разработка программного обеспечения - не исключение. Для построения сложной системы необходимо сначала разделить ее на несколько абстрактных представлений и построить модели, используя принятые обозначения - нотацию (notation) Затем убедиться, что модели удовлетворяют всем потребностям системы, и постепенно добавлять детали для перехода от моделей к реализации.
Мы строим модель сложной системы, потому что не можем охватить и понять проект целиком. Существуют пределы в понимании сложных вещей. Это можно продемонстрировать на примере архитектуры. Если вы хотите построить сарай во дворе, вам достаточно просто начать строительство. Когда вы планируете построить новый дом вам наверняка потребуется чертеж. А для возведения небоскреба он будет просто необходим Этот же пример можно привести для Программного обеспечения Изучая работу отдельной формы в Visual Basic, программист не сумеет представить схему проекта целиком Создание модели позволяет представить общую картину взаимодействия узлов системы без углубления в детали Реализации отдельных элементов
Модели помогают нам организовывать, отображать, понимать и создавать сложные вещи. Они призваны помочь в решении трудных задач при разработке программ сегодня и в будущем.
Треугольник успеха Я часто использую треугольник успеха (triangle for success), показанный на с. 1.1, чтобы изобразить средства, необходимые для успешного проекта. Вам потребуются все три грани - три составляющие - нотация, процесс и инструмент. Можно изучить нотацию, но если вы не знаете, как ее применить (организовать процесс), то, вероятно, потерпите неудачу. У вас могут быть хорошо организованные процессы, но если вы не сумеете описать порядок их взаимодействия (используя нотацию), то, скорее всего, вам не удастся довести проект до конца. И наконец, если вы неправильно определите орудия труда г (инструменты), вас .наверняка постигнет не-
•
удача.
Роль нотации
Нотация является важной составляющей любой модели - ока служит связующим звеном между процессами. «Нотация выполняет три функции:
а является языком для описания взаимодействий, которые неочевидны или не могут быть получены непосредственно из кода;
а обеспечивает достаточную семантику, позволяющую охватить важные стратегические и тактические решения;
а предлагает конкретную форму, помогающую человеку рассуждать о предметной области, а средствам моделирования воплощать описанные идеи»1.
Унифицированный язык моделирования (Unified Modeling Language - UML) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию. Определенные элементы нотации (например, классы, связи, агрегаты, наследование) используются на этапе анализа. Другие элементы (индикаторы реализации и свойства) вводятся на стадии проектирования.
История UML
'..••..' . , I 1..'
В 90-е годы появилось большое количество различных методологий (^собственными наборами нотаций. Самые популярные - ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсоиу). Каждая из них имела свои преимущества. Методика ОМТ отличалась хорошими средствами анализа и слабыми сторонами в проектировании, а методика Booch 1991, наоборот, более подходила для проектирования, чем для анализа. В методике OOSE основное внимание уделено развитым средствам поведенческого анализа, а в других областях отмечено много недостатков.
Спустя некоторое время Буч опубликовал второе издание, в котором собрал лучшие идеи и решения в области анализа, предлагавшиеся в том числе Рамбо и Джекобсоном. В свою очередь, Рамбо написал серию статей, известных как
1 Booch, Grady. Objtet Solutions. Redwood City, СЛ: Addison-Wesley, 1995.
методика ОМТ-2, куда вошли предложения Буча в области проектирования. Перечисленные лкмодики ш,иш достаточно похожи, но отличались разными нотациями -один и тот же символ имел в них различные значения. Например, закрашенный круг был индикатором множественности в методике ОМТ и симнолом агрегата в нотации Буча. Вы, наверное, слышали фразу «война методов», употреблявшуюся в период, когда класс обозначался либо в виде облака, либо в виде облака , либо в виде прямоугольника ? Трудно понять, что же лучше.
Конец воине методов положила нотация, принятая в языке UML. «Язык UML служит для определения, отображения и описания элементов объектно-ориентированных систем в процессе их создания. Он объединяет объектную модель, нотации Буча и ОМТ, а также лучшие идеи, предложенные авторами других методик (рис 1.2). Таким образом, язык UML является стандартом де-факто в области объектно-ориентированного анализа и проектирования»1.
Универсальный язык UML - это попытка стандартизировать инструменты анализа и проектирования семантических моделей, синтаксических нотации и диаграмм Первая общедоступная версия (0.8) появилась в октябре 1995 года. Джекобсон и другие разработчики предложили несколько вариантов, которые были реализованы в последующих двух версиях (0.9 - в июле и 0.91 - в октябре 1996 года). Версия 1.0 была представлена для стандартизации в ассоциацию Object Management Group (OMG) в июле 1997 года. Дополнительные улучшения сделаны в версии 1.1, которая вышла в сентябре того же года, а в ноябре UML был утвержден ассоциацией OMG в качестве стандартного языка моделирования.
Роль процессов
Успешно разработанный проект удовлетворяет или превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и может быть адаптирован к изменению условий. Жизненный цикл разработки должен способствовать творческим и новаторским идеям. В то же время для своевременного завершения процесс разработки должен контролироваться. «Творчество естественно для создания всех хорошо структурированных объектно-ориентированных архитектур, но если разработчиков не контролировать, то они, возможно, никогда не достигнут конечного результата. Значит, для эффективной работы коллектива нужна дисциплина. Но слишком жесткая дисциплина приводит к развитию бюрократии, которая, в свою очередь, душит новаторские идеи»1. Правильно управляемый итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль и поддерживает творческий процесс на нужном уровне.
Что такое итеративная
и инкрементальная разработка
В итеративном и инкрементальном жизненном цикле (см. рис. 1.3) разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы Каждая версия состоит из одного или более компонентов процесса; построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение. Разработчики допускают, что не все требования к системе известны в начале жизненного цикла. Корректировки возможны на любом этапе.
Такой тин жизненного цикла позволяет уменьшить риск. Технические риски оцениваются и группируются по приоритетам на ранней стадии цикла и корректируются
во время разпаботки каждой версии. Риски закреплены за каждой версией таким образом, что успешное завершение вераш уменьшает риск закрепленный за ней. Процесс планируется так, чтобы наибольшие риск» были рассмотрены в первую очередь Построение системы подобным образом выявляет и уменьшает риски на раннем этапе жизненного цикла. Результат такой модели жизненного цикла -уменьшение риска и затрат1.
Методология Rational Unified Process
Для поддержки управления итеративным и инкрементальным жизненным циклом разработки используется методика Rational Unified Process, с помощью которой можно подробно описать технические и организационные аспекты создания программного обеспечения на стадиях определения требований к системе, анализа и проектшювляия,
Методология Rational Unified Process структурирована в двух направлениях:
* время (разделение жизненного цикла на фазы и версии)
*компоненты процесса (создание необходимого набора средств для выполнения четко onpeделенных задач)
Оба направления должны быть хорошо проработаны для получения успешного проекта
Работа над проектом состоит из следующих временных этапов:
* задумка ( inception) - определение общей идеи проекта;
* проработка (elaboration) - планирование необходимых работ и ресурсов, указание особенностей и создание архитектуры;
* создание <• construction1) - построение продукта при помощи серии последовательных версий
* перехооныи период (transit • п > - поставка продукта пользователям (производство распространение, обучение).
В разрезе компонентов процесс делится на следующие стадии:
* построение бизнесс-модели (business modeling) - определение необходимых возможностей системы и потребностей пользователей;
* опреаеление требовании к системе (requirements) - изложение общей идеи системы совместно с функциональными и нефункциональными условиями ее работы
* анализ (analysis) и проектиоование (design) - описание способов исполнения системы на тгаце реализации,
* реализация (implementation) - кодирование и генерация работающих программных Модулей системы;
а тестирование (test) - проверка функционирования системы; а внедрение (deployment) - поставка системы конечным пользователям и их обучение.
Каждая стадия в разрезе компонентов процесса обычно применяется к конкретной фазе временного направления (см. рис. 1.4.). Однако степень применения каждого компонента зависит от этапа разработки. Например, вы можете испытать концептуальный прототип системы на стадии задумки, и тогда вам потребуется не только определение требований - необходимо будет провести анализ, проектирование, реализацию и тестирование, чтобы завершить создание прототипа. Важность анализа выявляется на этапе проработки.
Сначала предпочтительно выпустить несколько версий. Они обычно используются для проверки аналитических решений в области архитектуры системы. Таким образом, вы не только анализируете проблему. На стадии создания система строится с помощью серии версий. При любой структуре разработки дополнительные вопросы всегда возникают неожиданно, что требует проведения нового анализа.
Диаграмма должна быть основным руководством для отражения жизненного цикла вашего проекта. Основная мысль заключается в следующем: если вы только думаете над тем, что собираетесь создавать, в то время когда уже пишете код, вероятно, у вас возникнут проблемы. Заметьте, что тестирование применяется в ходе всего итерационного процесса. То есть вы не ждете, когда весь код будет написан для проверки его работы.
В этой книге применяется упрощенная версия Rational Unified Process, в которой сделан акцент на использовании языка UML для получения и документального описания решений на стадиях задумки и проработки проекта. В последних главах кратко рассказывается об этапе создания. Несмотря на то что тестирование - неотъемлемая часть процесса разработки, его описание выходит за рамки данной книги.
Пакет Rational Rose
Методы создания программного обеспечения должны поддерживаться соответствующими инструментами разработки. Когда я впервые начала заниматься объектно-ориентированным моделированием., моими инструментами были бумага и карандаш. Теперь в продаже имеются более удобные программные инструменты - не только простые графические редакторы, но и сложные пакеты объектного моделирования. В этой книге для моделирования используется программа Rational Rose. На каждом этапе моделирования приводится описание необходимых действий.
Семейство продуктов Rational Rose призвано обеспечить разработчика программ полным набором инструментов визуального моделирования для эффективного решения сложных бизнес-задач i" использованием архитеюуры клиент/ сервер, распределенных сред и систем реального времени. В продуктах Rational Rose отражен универсальный стандартизированный подход к построению моделей, позволяющий программистам моделировать логику приложений, а не программистам - бизнес-процессы. Демонстрационную версию пакета Rational Rose можно получить на сайте компании Rational Software Corporation по адресу: www.rational.com.
Хотя в этой книге в качестве инструмента моделирования используется Rational Rose, ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler, Этот продукт предназначен специально для начинающих разработчиков и предоставляет следующие возможности:
. описывать и проектировать бизнес-объекты с последующим отображением
их на программные компоненты;
Q разделять сервисы в трехзвенной сервисной модели;
Q распределять компоненты в сети;
а генерировать исходные модули на Visual Basic по созданной модели;
Q использовать возвратное проектирование для создания модели по существующим компонентам и приложениям;
Q синхронизировать модели с кодом.
Пакет Rational Rose по сравнению с Microsoft Visual Modeler позволяет анализировать требования к бизнес-системе и бизнес-сценарии с помощью диаграмм последовательности действии и диаграмм взаимодействий, моделировать состоя ния, генерировать код и поддерживать встроенный скрипт для доступа к вну-рен ним компонентам программы.
Резюме
Визуальное моделирование - это способ представления идей и проблем реального мира с помощью моделей Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах: заказчику,
эксперту, аналитику, проектировщику, автору документ ашпг программисту и др. Моделирование обеспечивает оолее точную оценку необходимых ресурсов, четкую прораоотку планов и эффективное функционирование создаваемых систем.
Нотация - важная составляющая любой модели, своего рода связующее ;jbc-но между процессами Унифицированный язык моделирования (UML) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию
Успешно разработанный проект удовлетворяет или превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и может быть адаптирован к изменению условий Жизненный цикл разработки должен способствовать творческим и новаторским идеям Правильно управляемый итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль и поддерживает творческий процесс на нужном уровне В итеративном и инкрементальном жизнен -ном цикле разработка осуществляется с помощью серии версий, которые развива ются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение
В качестве средства управления итеративным и инкрементальным жизненным циклом разработки применяется методика Rational Unified Process, с помощью которой можно подробно описать технические и организационные аспекты разработки программного обеспечения на стадиях определения требований к системе, анализа и проектирования. В этой книге используется упрощенная версия Rational Unified Process
Семейство продуктов Rational Дозе призвано обеспечить разработчика программ полным набором инструментов визуального моделирования для эффективного решения сложных бизнес-задач с использованием архитектуры клиент/сервер, распределенных сред и систем реального времени.