Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование (1158625), страница 7
Текст из файла (страница 7)
Это является необходимымусловием, поскольку данная модель должна обеспечивать достаточнополную базу для трансформации в PSM, из которой может быть сгенерирован код. В определении «платформонезависимый» немного смысла, пока точно не указаны платформы, от которых необходимо обеспечить независимость! Разные инструменты MDA поддерживают разныеуровни независимости от платформы.MDAМашинно!независимаямодель (CIM)Платформо!независимаямодель (PIM)проецированиеПлатформо!зависимаямодель (PIM)генерированиеКодразверты!ваниеРис. 1.3. Модель MDA1.5.
Почему «унифицированный»?29PIM дополняется характерной для конкретной платформы информацией для создания 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модели есть два аспекта:• Статическая структура – описывает, какие типы объектов важныдля моделирования системы и как они взаимосвязаны.• Динамическое поведение – описывает жизненные циклы этих объектов и то, как они взаимодействуют друг с другом для обеспечениятребуемой функциональности системы.Эти два аспекта модели UML идут рука об руку, и ни один из них не является понастоящему полным без другого.UML моделирует мир как системы взаимодействующих объектов.
Объект –это цельный блок, состоящий из данных и функциональности.311.7. Структура UMLОбъекты (и классы) будут подробно рассмотрены в главе 7. До тех порбудем считать, что объект единым целым блока данных и поведения.Иначе говоря, объекты содержат информацию и могут выполнятьфункции.1.7. Структура UMLПонимание работы UML как визуального языка начинается с рассмотрения его структуры. Она показана на рис.
1.4 (как выяснится позже,это действительная UMLдиаграмма). Эта структура включает:• строительные блоки – основные элементы, отношения и диаграммы UMLмодели;• общие механизмы – общие UMLпути достижения определенныхцелей;• архитектура – UMLпредставление архитектуры системы.Понимание структуры UML дает нам представление о структуре всегоизложенного в книге материала. Наличие структуры также указываетна то, что сам UML – это спроектированная система с собственной архитектурой.
Кстати, UML был смоделирован и спроектирован с помощью UML! Этим проектом является метамодель UML.UMLСтроительные блокиОбщие механизмыАрхитектураРис. 1.4. Структура UML1.8. Строительные блоки UMLСогласно «The Unified Modeling Language User Guide» [Booch 2], UMLсостоит всего из трех строительных блоков (рис. 1.5):• Сущности – это сами элементы модели.• Отношения связывают сущности. Отношения определяют, как семантически связаны две или более сущностей.• Диаграммы – это представления моделей UML. Они показываютнаборы сущностей, которые «рассказывают» о программной системе и являются нашим способом визуализации того, что будет делать система (аналитические диаграммы) или как она будет делатьэто (проектные диаграммы).32Глава 1. Что такое UML?Строительные блокиСущностиОтношенияДиаграммыРис. 1.5. Строительные блоки UMLВ следующих трех разделах типы строительных блоков рассматриваются немного подробнее.1.8.1.
Сущности«Сущности» – это существительные UMLмодели.Все UMLсущности можно разделить на:• структурные сущности – существительные UMLмодели, такие каккласс, интерфейс, кооперация, прецедент, активный класс, компонент, узел;• поведенческие сущности – глаголы UMLмодели, такие как взаимодействия, деятельности, автоматы;• группирующая сущность – пакет, используемый для группировкисемантически связанных элементов модели в образующие единоецелое модули;• аннотационная сущность – примечание, которое может быть добавлено к модели для записи специальной информации, очень похожее на стикер.Все эти сущности и то, насколько успешно они используются в UMLмоделировании, рассматривается в части 2.1.8.2.
ОтношенияОтношения позволяют показать взаимодействие в пределах моделидвух или более сущностей. Для понимания роли, которую отношенияиграют в моделях UML, достаточно представить отношения между членами отдельной семьи. Отношения в модели UML позволяют зафиксировать значимые (семантические) связи между сущностями. Например, в табл. 1.1 представлены UMLотношения, применяемые к структурным и группирующим сущностям модели.Правильное понимание семантики различных типов отношений является очень важной частью моделирования UML.
Однако мы отложимподробное описание этих семантик до следующих разделов книги.331.8. Строительные блоки UMLТаблица 1.1ТипотношенияUMLсинтаксис Краткаяисточник цель семантикаРазделЗависимостьИсходный элемент зависит от целевого 9.5элемента и изменение последнего можетповлиять на первый.АссоциацияОписание набора связей между объектами. 9.4АгрегацияЦелевой элемент является частью исход 18.4ного элемента.КомпозицияСтрогая (более ограниченная) формаагрегирования.ВключениеИсходный элемент содержит целевой эле 11.4мент.ОбобщениеИсходный элемент является специализа 10.2цией более обобщенного целевого элемента и может замещать его.РеализацияИсходный элемент гарантированно вы 12.3полняет контракт, определенный целевым элементом.18.51.8.3. ДиаграммыДиаграммы – это только представления модели.Во всех инструментальных средствах UMLмоделирования новые сущности или новые отношения при создании добавляются в модель.