ВВедение в ИМЛ. Для чего был написан этот курс
 Скачать 3.44 Mb.
|
|
Рис. 6.13. Так в каком же отношении находятся прецедент и кооперация? Из предыдущего абзаца логично следует, что это отношение реализации. Каждый прецедент реализуется одной или несколькими кооперациями. Это, конечно, не означает, что классы жестко распределены по кооперациям: классы, принимающие участие в кооперации, реализующей определенный прецедент, будут участвовать и в других кооперациях. Моделирование при помощи диаграмм прецедентов Модель прецедентов, по сути, является концептуальной моделью системы. В ней, как мы уже не раз отмечали, в общих чертах описывается только поведение (функциональность) системы, а о деталях реализации речь не идет - на данном этапе реализация не важна, гораздо важнее собрать требования к системе и оформить их в наглядном виде, понятном и разработчикам, и заказчику. Итак, подводя итоги, мы можем сформулировать три причины использования прецедентов. Или, вернее, три способа использования прецедентов (не случайно в русском переводе частенько можно встретить словосочетание "вариант использования"!) в ходе работы над системой: • Прецеденты дают возможность аналитикам, пользователям и разработчикам говорить на одном языке: используя прецеденты, аналитики (эксперты в предметной области) могут на основе пожеланий заказчика описать поведение системы с точки зрения пользователя с такой степенью детализации, что разработчики смогут без труда сконструировать "внутренности" системы. В то же время, нотация диаграмм прецедентов настолько проста, что даже неподготовленный пользователь (заказчик) способен понять их смысл и помочь в их уточнении - ведь картинки (а тем более комиксы, каковыми, по сути, являются диаграммы UML) воспринимаются намного легче, чем текст! • Прецеденты позволяют разработчикам понять назначение элемента: система, подсистема или даже класс могут быть сложными образованиями, состоящими из большого числа составных частей и имеющими большое число атрибутов и операций. Моделирование прецедентов позволяет лучше представить себе поведение системы, понять, какие элементы модели играют какие роли в реализации этого поведения, в какие кооперации входят, и какой именно прецедент (функционал системы) реализуют. • Прецеденты являются основой для тестирования элемента в течение всей разработки: модель прецедентов описывает желаемое поведение системы (ее функционал) с точки зрения пользователя. Так что, постоянно сопоставляя предоставляемый элементом (фактический) функционал с имеющимися прецедентами, можно надежно контролировать корректность реализации элемента. Вот вам и надежный источник регрессионных тестов. Кроме этого, появление нового прецедента зачастую заставляет пересмотреть реализацию элемента, дабы убедиться, что она обладает достаточной гибкостью, изменяемостью и масштабируемостью. Прецеденты полезны и для прямого, и для обратного проектирования. При прямом проектировании мы, по сути, осуществляем "перевод" с UML на некий язык программирования. И тестировать созданное приложение следует, основываясь именно на потоках событий, описываемых прецедентами. Обратное проектирование предполагает перевод с языка программирования на язык UML-диаграмм. Такими вещами приходится заниматься в силу ряда причин: • С целью поиска ошибок и чтобы убедиться в адекватности дизайна: отличная идея после первого перевода с UML на язык программирования сделать обратный перевод и сравнить исходные и восстановленные UML-модели (желательно, чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что дизайн системы соответствует модели, никакая информация в ходе перевода не была утеряна, да и попросту выловить некоторые "баги". Такой подход называется обратной семантической трассировкой (или RST - Reverse Semantic Traceability) и разрабатывается компанией INTSPEI ( http://www.intspei.com ) как одна из базовых техник методологии INTSPEI P-Modeling Framework, краткие сведения о которой вы можете найти в приложении к этому курсу. • Когда отсутствует документация: иногда стоит задача модификации существующей системы, код которой плохо документирован. В таком случае перевод с языка программирования на язык UML-диаграмм - отличный способ понять назначение системы и ее частей, функционал, предоставляемый ею, и т. д. И наконец, следует отметить, что, конечно, только диаграмм прецедентов, как и сценариев, ими определяемых, недостаточно, чтобы создать модель поведения системы. Как мы уже не раз упоминали, прецеденты говорят, что делает система, но не говорят, как. Об этом говорят сценарии, но в текстовой форме, что делает их довольно сложными для восприятия. На помощь приходят диаграммы взаимодействий, которые визуализируют сценарии. Таким образом, мы теперь можем дополнить нашу старую "псевдодиаграмму" и на этом успокоиться (): Рис. 6.14. В заключение приведем пару примеров законченных диаграмм прецедентов. Первый пример (смысл которого понятен и без дополнительных пояснений) демонстрирует включение, расширение и наследование прецедентов. Обратите внимание на стрелки, которые направлены к экторам, изображающим шлюзы. Все правильно - ведь система пользуется их услугами при отправке сообщений, в то время как маркетолог, наоборот, пользуется услугами системы, и потому стрелки направлены от него (). Рис. 6.15. Следующие три примера уже по традиции мы позаимствовали с сайта шуток на UML ( http://www.umljokes.com ), продолжая доказывать, что на UML можно шутить - это полноценный язык общения, который можно применять так же, как и любой другой. Первый из примеров - это часть всем известной сказки о "Курочке Рябе", которую автор очень красочно оформил (). Рис. 6.16. Вторая диаграмма, тоже неплохо оформленная, говорит нам о том, что утки очень не любят платить за пиво, предпочитая пить в долг (). Рис. 6.17. Кстати, обратите внимание на рамки диаграммы, показанные на этом примере, - прямоугольник, отделяющий область содержимого диаграммы и имеющий в верхней части специальный раздел для ее имени. И наконец, третья картинка, которая не является хорошим примером диаграммы прецедентов, но просто забавна. Это рассказ о способах поведения, позволяющих гарантированно (!) провалить любой экзамен (): Рис. 6.18. Выводы • Модель прецедентов позволяет описать систему на концептуальном уровне. • Диаграммы прецедентов - отличное средство коммуникаций между экспертами, пользователями и разработчиками, а также основа для тестирования создаваемой системы. • Прецедент - это описание набора последовательных событий (включая возможные варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату. • Эктор - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью. • Прецеденты (как и экторы) могут быть генерализованы, т. е. наследовать и дополнять свойства своих предков. • Прецеденты также могут вступать между собой в отношения включения и расширения, что позволяет разложить прецеденты на более простые составляющие и выделить необязательное поведение. • Каждый прецедент реализуется одной или несколькими кооперациями. • Сценарии специфицируют прецеденты, а диаграммы взаимодействий визуализируют сценарии. Контрольные вопросы • Что такое нефункциональные требования? Как они отображаются на диаграммах прецедентов? • Какие способы изображения экторов вы знаете? • В какие отношения могут вступать экторы между собой? • В чем состоит смысл отношений включения и расширения? • Что такое точка расширения? • Перечислите известные вам причины использования прецедентов. • Как прецеденты применяют в прямом и обратном проектировании? Лекция 8: Обзор CASE-средств для построения диаграмм UML Аннотация: Предметом этого курса является The UML - унифицированный язык моделирования. В предыдущей лекции было рассказано о видах диаграмм UML и даны некоторые рекомендации относительно последовательности их построения. Мы уже знаем, что нотация UML специально разрабатывалась в расчете на то, чтобы диаграммы можно было легко рисовать от руки. Но! Ведь гораздо приятнее рисовать диаграммы с помощью удобного, интуитивно понятного и функционального программного пакета (CASE-средства). В этой лекции мы познакомимся с некоторыми подобными пакетами, а именно: IBM Rational Rose; Borland Together; Microsoft Visio; Sparx Systems Enterprise Architect; Gentleware Poseidon; SmartDraw; Dia; Telelogic TAU G2; StarUML; другие программы. UML - отличное средство моделирования, но, как уже говорилось выше, строить диаграммы на бумаге - не всегда удобно, хотя бы по причине сложностей с редактированием, распространением и т. д. Чтобы облегчить труд проектировщика, были созданы CASE-средства - программы специального вида. CASE-средства помогут вам построить профессионально выглядящие диаграммы, даже если вы не в состоянии провести прямую линию на бумаге! CASE-средства (от Computer Aided Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат использования CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок. Существует немало подобных программ. Выбор CASE-средства "по себе" - личное дело каждого читателя, и мы ни в коей мере не собираемся влиять на него. Мы лишь попытаемся предоставить ему этот выбор, рассмотрев некоторые наиболее достойные внимания, с точки зрения авторов, CASE-средства для построения UML-диаграмм. Причем постараемся рассказать и о признанных лидерах рынка, и о его "аутсайдерах", и о коммерческих "монстрах", и о "легких" программах с открытым исходным кодом. И начнем, пожалуй, с пакета, являющегося фактическим стандартом в области UML-проектирования. IBM Rational Rose Rational Rose - современное и мощное средство анализа, моделирования и разработки программных систем. Rational Rose пригодится при решении практически любых задач проектирования информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Такой арсенал позволит не только спроектировать новую систему, но и доработать старую, произведя процесс обратного проектирования. Для того чтобы наиболее полно покрыть весь сегмент рынка средств проектирования и разработки, выпускается несколько версий продукта: • Rational Rose Modeler Эта версия позволит аналитикам и проектировщикам проводить анализ бизнес-процессов и проектировать систему. Данная редакция, увы, не поддерживает кодогенерацию. • Rational Rose Professional Как видно из названия, это профессиональная редакция продукта. В зависимости от выбранного языка программирования позволяет выполнять прямое и обратное проектирование. Rose Professional заказывается только в определенной конфигурации (например, Rose Professional С++ или Rose Professional С++ DataModeler). Rational Rose Professional, конечно, не создает 100 % исполняемого кода. На выходе разработчик получает каркасный код информационной системы на определенном (заказанном) языке программирования, который впоследствии нужно еще программировать и программировать. Продукт нацелен и на аналитиков, и на разработчиков. • Rational Rose RealTime Версия продукта, созданная специально для получения 100 % исполняемого кода в реальном масштабе времени. Конечно, RealTime позволяет проводить прямое и обратное проектирование на языках С или С++. По заверениям разработчиков, на выходе модель автоматически компилируется и собирается в исполняемый файл. Само собой, продукт предназначен именно для разработчиков. • Rational Rose Enterprise Абсолютно полная версия. Поддерживаются все функции других редакций, за исключением возможности 100 % кодогенерации. Таким образом, эта версия продукта покрывает весь спектр задач по проектированию, анализу и кодогенерации. Это программный пакет для всех участников проекта. • Rational Rose DataModeler Это не конкретный вариант продукта, а функциональность по проектированию баз данных. Функции DataModeler входят в состав Rose Enterprise или Professional. К сожалению, нет бесплатной версии продукта, но для образовательных учреждений все программное обеспечение IBM доступно бесплатно (для использования в учебных целях) в рамках программы IBM Academic Initiative. А как же выглядит это чудо? Не слишком изысканно, но вполне функционально - судите сами ( рис. 7.1 ): Рис. 7.1. В зависимости от поставки, в Rational Rose может быть расширен или сужен набор визуальных компонент (возможных диаграмм). Впрочем, Rational Rose и так достаточно функционален. Вот основные возможности продукта: • прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic; • поддержка технологий COM, DDL, XML; • возможность генерации схем БД Oracle и SQL. Также Rational Rose имеет открытый API, позволяющий самому создавать модули для других языков программирования. На рынке уже имеется достаточное число модулей для популярных языков программирования и RAD-систем, таких как Delphi, ErWin, Jbuilder, VisualCafe, Jdeveloper, VisualAge SmallTalk. Одна из ведущих компаний в области создания дополнительных модулей - Ensemble Systems (http://www.ensemble-systems.com/). Rational Rose много раз признавалось различными изданиями лучшим средством проектирования. Вот только некоторые из них ( рис. 7.2 ): Рис. 7.2. Если вы программировали в MS Visual Studio 6.0, то, возможно, вы уже познакомились с одним из продуктов семейства Rational Rose, поскольку в этот пакет встроен Visual Modeler - усеченный вариант Rational Rose 98. С помощью Visual Modeler можно рисовать диаграммы классов в трех различных нотациях - нотации Буча, ОМТ и на UML. По диаграммам классов можно провести генерацию каркасного кода (на C++, VB или Java). Такая генерация программного кода называется прямым проектированием (forward engineering). Взаимозависимости классов, изображенных на диаграмме классов, отображаются в программном коде. Большой интерес представляет обратное проектирование (reverse engineering), когда по исходному коду восстанавливается диаграмма классов, позволяющая понять структуру программы. Это тоже можно делать с помощью Visual Modeler, причем на основе Microsoft Foundation Classes (MFC)! К ограничениям Visual Modeler относится тот факт, что он не поддерживает диаграммы развертывания, описывая лишь внутреннюю функциональность создаваемой системы. Также Rational Rose интегрируется с Visual Component Manager, репозиторием Microsoft Repository, системой управления версиями Microsoft Visual SourceSafe и Rational ClearCase. Плюс многое-многое другое... Конечно, можно еще долго петь дифирамбы этому продукту, являющемуся, по сути, стандартом де-факто в области UML-проектирования (с субъективной точки зрения авторов, этот продукт не слишком интуитивен и удобен, хотя, без сомнения, сверхфункционален). Честно говоря, как ни парадоксально это звучит, особого впечатления на авторов этот продукт не произвел, возможно, по причине недостаточного с ним знакомства. Думаем, что сами разработчики расскажут о своем продукте гораздо лучше. Предоставим же читателю возможность оценить этот продукт, основываясь на информации "из первых рук"! Вы можете это сделать, посетив такие сайты: http://www-306.ibm.com/software/rational/ Это официальный сайт Rational, где вы сможете найти информацию о Rational Rose и других продуктах Rational (на англ. языке). Также можете попробовать сходить по "старому адресу" - www.rational.com http://interface.ru/ Сайт компании "Интерфейс". Как уверяют авторы ресурса, на сегодняшний день здесь собран самый большой (в Рунете) архив информации по продуктам Rational. Здесь можно найти множество статей, обзоров, руководств и описаний "по теме" и на русском языке. http://sunset.usc.edu/cse/ А здесь можно найти неплохой архив презентаций и статей по темам программной инженерии, в том числе и о Rational Rose (на англ. языке). Borland Together Очень симпатичный (если не сказать больше!) продукт от Borland. Borland Together ControlCenter - это интегрированная платформа разработки, позволяющая упростить и ускорить анализ, дизайн, разработку и развертывание комплексных корпоративных приложений. Эти возможности сочетаются в одном интегрированном решении с поддержкой UML, помогающем командно разрабатывать высококачественные системы быстрее и эффективнее. Технология Borland LiveSource, интегрированная в ControlCenter, автоматически синхронизирует все артефакты, так что изменения в них не прерывают процесс разработки (что очень похоже на концепцию "живых документов" от Microsoft). Таким образом, ситуация, когда модель и код не соответствуют друг другу, теперь невозможна - любые изменения в модели сразу же отображаются в коде и |