UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Глава 1: Что такое UML? Глава 2: Что такое Унифицированный процесс? Глава 4: Моделирование прецедентов Часть 2 Опреде ление тре бований Глава 3: Рабочий поток определения требований изучаем дополнительные методики Глава 6: Рабочий поток анализа Глава 7: Объекты и классы Часть 3 Анализ учимся выявлять классы анализа изучаем отношения изучаем пакеты Часть 4 Проекти рование Часть 5 Реализация Часть 6 Дополни тельные материалы Глава 8: Выявление классов анализа Глава 9: Отношения Глава 11: Пакеты анализа Глава 10: Наследование и полиморфизм Глава 12: Реализация прецедентов изучаем дополнительные методики Глава 13: Дополнительные аспекты реализации прецедентов Глава 14: Диаграммы деятельности Глава 16: Рабочий поток проектирования Глава 17: Проектные классы Глава 15: Дополнительные аспекты диаграмм деятельности Глава 18: Уточнение отношений, выявленных при анализе изучаем дополнительные методики Глава 20: Реализация прецедента – проектирование Глава 19: Интерфейсы и компоненты Глава 21: Конечные автоматы Глава 22: Дополнительные аспекты конечных автоматов изучаем OCL Глава 23: Рабочий поток реализации Глава 24: Развертывание Глава 25: Введение в OCL рассматриваем пример модели изучаем применение XML в прецедентах Приложение 1: Пример модели прецедентов Глава 5: Дополнительные аспекты моделирования прецедентов Рис. 2. I Введение в UML и UP 1 Что такое UML? 1.1. План главы В этой главе представлен краткий обзор истории развития UML и его структуры. Здесь перечислены темы, подробно рассматриваемые в по следующих главах. Те, кто не знаком с UML, должны начать с изучения его истории и ос новных принципов. Если вы уже имеете опыт работы с UML или убеж дены, что достаточно знаете его историю, можете переходить прямо к разделу 1.7 и обсуждению структуры UML. Это обсуждение состоит из трех основных частей, которые можно читать в любом порядке. К ним относятся: строительные блоки UML (1.8), общие механизмы UML (1.9) и архитектура UML (1.10). 1.2. Что такое UML? Унифицированный язык моделирования (Unified Modeling Language, UML) – это универсальный язык визуального моделирования систем. Хотя чаще всего UML ассоциируется с моделированием ОО программ ных систем, он имеет намного более широкое применение благодаря свойственной ему расширяемости. UML объединил лучшие современные технические приемы моделиро вания и разработки программного обеспечения. По сути, язык UML был задуман так, чтобы его можно было реализовать посредством его же инструментальных средств. Фактически это признание того, что большие современные программные системы, как правило, нуждают ся в инструментальной поддержке. UML диаграммы легко восприни маются и при этом без труда генерируются компьютерами. Важно понимать, что UML не предлагает нам какой либо методологии моделирования. Конечно, некоторые методические аспекты подразу меваются элементами, составляющими модель UML, но сам UML пре 24 Глава 1. Что такое UML? ознакомьтесь с общими механизмами UML изучите основы UML 1.2. Что такое UML? 1.3. Рождение UML 1.4. MDA – будущее UML 1.5. Почему «унифицированный»? 1.6. Объекты и UML 1.7. Структура UML изучите историю UML ознакомьтесь со строительными блоками UML ознакомьтесь с архитектурой UML 1.11. Что мы узнали 1.9.4.4. Профили UML 1.9.4.3. Помеченные значения 1.9.4.2. Стереотипы 1.9.3.2. Интерфейс и реализация 1.9. Общие механизмы UML 1.9.4. Механизмы расширения 1.9.4.1. Ограничения 1.9.3. Принятые деления 1.9.3.1. Классификатор и экземпляр 1.10. Архитектура 1.8.2. Отношения 1.8.1. Сущности 1.8.3. Диаграммы 1.9.1. Спецификации 1.9.2. Дополнения 1.8. Строительные блоки UML Ри с. 1 .1. Пл ан гл ав ы 1.3. Рождение UML 25 доставляет собой лишь визуальный синтаксис, который можно ис пользовать для создания моделей. UML это не методология, это унифицированный язык визуального моде лирования. UP – это методология. Унифицированный процесс (Unified Process, UP) – это методология. Она указывает на исполнителей, действия и артефакты, которые необ ходимо использовать, осуществить или создать для моделирования программной системы. UML не привязан к какой либо конкретной методологии или жизнен ному циклу. На самом деле он может использоваться со всеми сущест вующими методологиями. UP использует UML в качестве базового син таксиса визуального моделирования. Следовательно, UP можно рас сматривать как предпочтительный метод для UML, поскольку он луч ше всего адаптирован к нему. Однако сам UML способен предоставить (и предоставляет) поддержку визуального моделирования другим ме тодам. Конкретным примером сложившегося метода, использующего UML в качестве визуального синтаксиса, является метод OPEN (Ob ject oriented Process, Environment, and Notation – объектно ориенти рованный процесс, среда и нотация) (www.open.org.au). Неизменная цель UML и UP – способствовать объединению всего луч шего в опыте разработки программного обеспечения последнего деся тилетия. Для этого UML и UP унифицируют опыт предшествующих языков визуального моделирования и процессов разработки программ ного обеспечения наиболее оптимальным образом. 1.3. Рождение UML До 1994 года в мире ОО методов царил хаос. Существовало несколько конкурирующих языков и методологий визуального моделирования, каждая с собственными преимуществами и недостатками, сторонни ками и противниками. Среди языков визуального моделирования (рис. 1.2) очевидными лидерами были метод Буча (Booch Method), раз работанный Гради Бучем (Grady Booch), и техника объектного модели рования (Object Modeling Technique, OMT) Джеймса Рамбо (James Rumbaugh), которые занимали более половины рынка. Что касается методологий, самую строгую систему создал Айвар Джекобсон (Ivar Jacobson). Несмотря на то, что многие авторы заявляли о создании «метода», фактически это были синтаксисы визуального моделирова ния и наборы более или менее полезных афоризмов и рекомендаций. UML – открытый, принятый в качестве промышленного стандарта язык визуального моделирования, одобренный OMG. 26 Глава 1. Что такое UML? Первую попытку унификации сделал в 1994 году Колеман (Coleman) в своем методе с использованием языка Fusion. Однако несмотря на все ее плюсы, к этой работе не были привлечены авторы создатели состав ляющих методов (Буч, Джекобсон и Рамбо). К тому же книга с описа нием этого подхода появилась на рынке слишком поздно. События раз вивались не в пользу метода с применением языка Fusion. В 1994 году Буч и Рамбо объединились в компании Rational Corporation для рабо ты над UML. В то время это обеспокоило многих из нас, поскольку обеспечивало Rational более половины рынка по разработке подобного рода методов. Однако эти страхи оказались совершенно безоснователь ными, и UML стал открытым промышленным стандартом. В 1996 г. Группа управления объектами (OMG, Object Management Group) выпускает запрос на предложение (request for proposal, RFP) для ОО языка визуального моделирования и предлагает UML. В 1997 г. OMG принимает UML и рождается первый открытый, удовлетворяю щий промышленным стандартам ОО язык визуального моделирования. С этого момента исчезли все конкурирующие методы, и UML, бесспор но, стал стандартным ОО языком моделирования. В 2000 году появилась версия UML 1.4 как существенное расширение UML, достигнутое добавлением семантики действий. Она описывает поведение набора элементарных действий, которые могут быть реали зованы конкретными языками действий. Семантика действий плюс язык действий позволяют детально специфицировать поведенческие элементы модели UML (такие как операции классов) непосредственно в модели UML. Это было серьезным достижением, поскольку сделало спецификацию UML полной в вычислительном отношении, что обес печило возможность делать UML модели исполняемыми. Примером реализации UML, имеющей язык действий, совместимый с семанти кой действий, является xUML, произведенный компанией Kennedy Carter (www.kc.com). Предыстория Fusion 1 я попытка унификации OMT, Буч, CRC Буч и Рамбо (OMT) объединя ются в компании Rational Начинается работа над UML RFP Группы управления объектами (OMG) Предложение UML одобрено OMG 1994 1995 1996 1997 Шлаер/ Меллор Буч Рамбо (OMT) Джекобсон (Objectory) Коуд/Йордон 2004 2003 UML 1.x UML 2.0 Продолжение разработки UML Джекобсон (Objectory) присоединяется к Rational UML становится промышленным стандартом Рис. 1.2. История UML 1.4. MDA – будущее UML 27 В 2005 году, когда еще шла работа над вторым изданием этой книги, была завершена спецификация UML 2.0. Теперь UML – вполне сфор мировавшийся язык моделирования. Прошло почти семь лет с момен та выхода его первой версии, и он доказал свою ценность в сотнях про ектах по разработке программного обеспечения по всему миру. В UML 2 появилось много новых визуальных синтаксических струк тур. Некоторые из них замещают (и уточняют) существующий синтак сис версии 1.x, другие – абсолютно новые и представляют вновь вве денную в язык семантику. UML как всегда предлагает множество ва риантов представления конкретного элемента модели, но не все они бу дут поддерживаться каждым из инструментов моделирования. В этой книге мы пытаемся использовать лишь наиболее распространенные синтаксические варианты и обращаем внимание на те, которые полез ны в обычных ситуациях моделирования. Некоторые синтаксические варианты слишком специализированны, поэтому они не обсуждаются или только упоминаются. Хотя в UML 2 по сравнению с версией UML 1.x внесено множество син таксических изменений, основополагающие принципы остались более или менее неизменными. Разработчики моделей, привыкшие к преды дущим версиям UML, легко перейдут на UML 2. Фактически самые глубокие изменения затронули метамодели UML, с которыми разра ботчики моделей непосредственно не будут иметь дело. Метамодель UML – это модель языка UML, выраженная в подмножестве UML. Она строго определяет синтаксис и семантику всех элементов моделирова ния UML, которые будут рассматриваться в книге. Изменения метамо дели UML во многом касаются повышения точности и согласованно сти спецификации UML. В одной из своих книг Гради Буч говорит: «Если у вас есть хорошая идея, она моя!» В этом заключена вся философия UML: он берет луч шее из того, что было до него, интегрирует и использует в качестве ос новы. Это можно понимать и в более широком смысле: UML объединя ет лучшие идеи «доисторических» методов, отказываясь от их наибо лее специфических деталей. 1.4. MDA – будущее UML Будущее UML может быть определено, согласно недавнему предложе нию OMG, как архитектура, управляемая моделью (Model Driven Ar chitecture, MDA). Хотя наша книга и не посвящена MDA, в этом разде ле будет представлен ее краткий обзор. Более подробную информацию можно найти на веб сайте OMG (www.omg.org/mda) и в книгах «MDA Explained» [Kleppe 1] и «Model Driven Architecture» [Frankel 1]. MDA дает видение того, как разрабатывать програмное обеспечение на основе моделей. Суть этого видения заключается в том, что модели управляют созданием исполняемой программной архитектуры. В на стоящее время уже встречается подобный подход к разработке про 28 Глава 1. Что такое UML? граммного обеспечения, но MDA позволяет точно определить степень автоматизации данного процесса, чего до сих пор удавалось достичь довольно редко. В MDA создание программного обеспечения происходит в результате ряда трансформаций модели при поддержке инструмента моделирова ния MDA. Абстрактная машинно независимая модель (computer inde pendent model, CIM) используется как основа для платформонезависи мой модели (platform independent model, PIM). PIM трансформирует ся в платформозависимую модель (platform specific model, PSM), ко торая преобразуется в код. Понятие модели в MDA является довольно обобщенным, и код рас сматривается как сильно конкретизированный вид модели. Рис. 1.3 иллюстрирует цепочку преобразований модели MDA. CIM – это модель с очень высоким уровнем абстракции, фиксирующая ключевые требования системы и словарь предметной области незави симым от компьютеров способом. Это действительно модель той части бизнес процесса, которую предполагается автоматизировать. Такую модель создавать необязательно, и если она разрабатывается, то ис пользуется как основа для выработки PIM. PIM – модель, выражающая семантику деятельности программной системы без ориентации на какую либо базовую платформу (такую как EJB, .NET и т. д.). PIM обычно находится примерно на том же уровне абстракции, что и аналитическая модель, о которой пойдет речь не сколько позже, но является более полной. Это является необходимым условием, поскольку данная модель должна обеспечивать достаточно полную базу для трансформации в PSM, из которой может быть сгене рирован код. В определении «платформонезависимый» немного смыс ла, пока точно не указаны платформы, от которых необходимо обеспе чить независимость! Разные инструменты MDA поддерживают разные уровни независимости от платформы. MDA проецирование разверты вание Платформо независимая модель (PIM) Платформо зависимая модель (PIM) Код генерирование Машинно независимая модель ( CIM) Рис. 1.3. Модель MDA 1.5. Почему «унифицированный»? 29 PIM дополняется характерной для конкретной платформы информа цией для создания PSM. Из PSM генерируется исходный код под опре деленную платформу. В принципе 100% исходного кода и вспомогательных артефактов, та ких как документация, средства тестирования, файлы сборки и деск рипторы развертывания, могут генерироваться из достаточно полной PSM. Если это предполагается, модель UML должна быть полной в вы числительном отношении , иначе говоря, семантика всех операций должна быть определена на языке действий. Как упоминалось ранее, некоторые инструментальные средства MDA уже предлагают язык действий. Например, инструмент iUML компа нии Kennedy Carter (www.kc.com) предоставляет язык спецификации действий (Action Specification Language, ASL), совместимый с семан тикой действий UML 2. Этот язык действий более абстрактный, чем такие языки, как Java и C++, и может использоваться для создания полных в вычислительном отношении моделей UML. Другие инструменты MDA, например ArcStyler (www.io software.com), обеспечивают возможность генерировать от 70 до 90% кода и других артефактов, но тела операций должны быть дописаны на заданном языке программирования (например, Java). В представлении MDA исходный код, такой как код на Java или C#, – это просто «машинный код», получающийся в результате компиля ции моделей UML. Этот код генерируется в случае необходимости пря мо из PSM. По существу, ценность кода при разработке с применением MDA значительно ниже, чем в UML моделях. MDA превращает моде ли UML из прообраза создаваемого вручную исходного кода в основной механизм производства кода. Во время подготовки книги к печати все больше и больше производи телей инструментальных средств моделирования добавляли поддерж ку MDA в свои продукты. Самую свежую информацию можно найти на веб сайте OMG, посвященном MDA. Существует также несколько многообещающих, использующих MDA инициатив с открытым исход ным кодом, например Eclipse Modeling Framework (www.eclipse.org/ emf ) и AndroMDA (www.andromda.org). В этом разделе мы ограничились «общей картиной» MDA. Cпецифика ция MDA намного глубже, чем здесь было рассмотрено. Более подроб ную информацию можно найти по ссылкам, приведенным в начале этого раздела . 1.5. Почему «унифицированный»? Унификация UML носит не только исторический характер. UML при лагает усилия (и в основном успешно) в унификации нескольких раз ных областей. 30 Глава 1. Что такое UML? • Жизненный цикл разработки: UML предоставляет визуальный синтаксис для моделирования на протяжении всего жизненного цикла разработки программного обеспечения – от постановки тре бований до реализации. • Области приложений: UML используется для моделирования всех аспектов – от аппаратных встроенных систем реального времени до систем поддержки принятия решений. • Языки реализации и платформы: UML является независимым от языков и платформ. Естественно, он прекрасно поддерживает чис тые ОО языки (Smalltalk, Java, C# и др.), но также эффективен и для гибридных ОО языков, таких как C++, и основанных на кон цепции объектов, таких как Visual Basic. UML также используется для создания моделей, реализуемых на неОО языках программиро вания, таких как С. • Процессы разработки: хотя UP и его разновидности, вероятно, яв ляются предпочтительными процессами разработки ОО систем, UML может поддерживать (и поддерживает) множество других процессов разработки ПО. • Собственные внутренние концепции: UML поистине стойко стре мится сохранить последовательность и постоянство применения не большого набора своих внутренних концепций. До сих пор это не всегда удавалось, но в этом направлении наблюдается заметный прогресс по сравнению с предыдущими попытками. 1.6. Объекты и UML Основная идея UML – возможность моделировать программное обеспе чение и другие системы как наборы взаимодействующих объектов. Это, конечно же, замечательно подходит для ОО программных систем и языков программирования, но также очень хорошо работает и для бизнес процессов и других прикладных задач. В UML модели есть два аспекта: |