UML – история, назначение, состав и структура

⇐ ПредыдущаяСтр 23 из 30Следующая ⇒

Разработка модели сложной программной системы перед непосредственной ее реализацией является такой же неотъемлемой частью всего проекта, как чертеж является основой для постройки большого здания. Хорошая модель является основой для беспрепятственного взаимодействия в команде разработчиков и гарантирует общий успех начатого проекта. Построение модели необходимо, потому что невозможно охватить с первого взгляда как всю систему в целом, так и отдельные ее функциональные части. По мере роста разрабатываемых систем все больше проявляется необходимость в наличии хорошего средства моделирования. Существует большое число факторов, влияющих на общий успех разработки, но присутствие строгого стандарта на язык моделирования является первостепенным фактором.

До появления UML в мире не существовало четко выраженного лидера среди средств моделирования. Пользователи должны были выбирать из множества похожих друг на друга техник моделирования с незначительными отличиями в выразительной мощи. Многие языки разделяли общепринятые концепции моделирования, зачастую интерпретируя их на свой лад. Такая разобщенность и ограниченность языков моделирования могла лишь оттолкнуть потенциального разработчика от использования объектно-ориентированного подхода при разработке сложных программных систем. Поддержка по сути своей похожих, но имеющих небольшие различия языков моделирования вызывала проблемы взаимодействия из-за наличия разного формата моделирования. Ситуация на рынке средств моделирования была названа " войной методов".

В середине 90-х годов стали появляться новые улучшенные версии существующих методологий - особо можно выделить технику Booch'93, дальнейшее развитие OMT, и Fusion. Эти методы начали смешивать техники друг друга, в результате появилось несколько широко известных методологий, включая OOSE, OMT-2 и Booch'93. Но, в целом, каждый из них обладал своей спецификой и оставался обособленным от других, при этом обладая определенной силой.

Промышленный мир ожидал единого языка, который бы смог соответствовать высоким целям и задачам, предъявляемых современным рынком программных средств.

Многие компании - производители ПО, понимая сложившиеся проблемы, выступили в поддержку создания UML - единого стандарта ОО моделирования.

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method. Позднее в конце 1995 года к Rational присоединился Ivar Jacobson со своей компанией Objectory, и в новую технику был добавлен метод OOSE (Object-Oriented Software Engineering). В июне 1996 года был выпущен UML 0.9, а в октябре - предложен UML 0.91. После этого начался сбор реакции компаний-производителей программного обеспечения на это предложение.

К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. Это объединение стало мощным катализатором для продолжения работы по унификации методов. Как результат объединенных усилий, после проведения многочисленных экспертиз и консультаций, в январе 1997 года был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. Каждый из партнеров по OMG внес различный вклад в проект. Например, Hewlett-Packard обеспечивал связь между моделями UML и концепцией повторного использования, IBM разрабатывал язык OCL (Object Constraint Language), описывающий семантику языка, Microsoft развивал концепцию компонентного программирования и использования UML в репозитории, Oracle расширил рамки UML для моделирования бизнеса. Список велик, ведь каждая компания преследовала свои определенные цели, но соотнося их с общими пожеланиями. В результате в выигрыше остался каждый из участников проекта.

UML прошел долгий путь от разобщенных методов и техник, преодолев первые попытки унификации, всеобщего обсуждения и оценки, в настоящее время претендуя на роль промышленного стандарта моделирования. В ноябре 1997 года OMG приняла UML как основную спецификацию для OMA (Object Modeling Architecture), " предоставляя разработчикам, работающим с любыми программными языками и на любых платформах, общий язык моделирования для построения распределенных приложений, внося необходимую согласованность в развитие этой сложной дисциплины" (Ричард Соли, председатель и исполнительный директор OMG).

UML не является чьей-либо собственностью и открыт для всех. Хотя UML является строго определенным языком, он не ставит барьеров на пути развития средств моделирования. UML может быть расширен без переопределения своего ядра. Предполагается использовать UML как основу для создания средств визуального моделирования и дальнейшей симуляции построенной модели.

Создатели языка и их партнеры выдвинули следующий набор целей, которым должен следовать проект по унификации методов моделирования:

· Предоставить пользователям готовый, мощный язык моделирования - общепринятые идеи должны быть включены в стандарт прямо, без промежуточных уровней, иначе невозможен будет обмен моделями без потери информации.

· Обеспечить механизмы расширения и специализации средств моделирования - UML развивается и будет развиваться, при этом не желательно переопределять ядро языка каждый раз заново. Поэтому концепции UML должны допускать расширение для нестандартных ситуаций и специализацию для конкретных предметных областей.

· Обеспечить независимость от языка программирования и модели процесса - UML должен поддерживать все разумные языки программирования и модели процесса разработки ПО, принятой на конкретном предприятии.

· Дать формальное обоснование языка моделирования - формализация языка должна присутствовать, но в разумных пределах, чтобы не мешать легкости восприятия и простоте применения.

· Расширить рынок ОО инструментов - UML должен обеспечивать интероперабельность для объектно-ориентированных средств.

· Использовать наилучшие практические методы - UML собирает лучшее, что есть в мире средств моделирования, и интегрирует.

Унифицированный Язык Моделирования (Unified Modeling Language - UML) предназначен для спецификации, визуализации, конструирования и документирования отчуждаемых материалов существенно программных систем.

Прежде всего, UML наследует техники Booch, OMT и OOSE.

Во-вторых, перекрывает их.

В-третьих, надо отметить, что UML - это стандарт языка, а не стандарт процесса.

UML - квинтэссенция концепций моделирования, по которым был достигнут консенсус в среде ведущих мировых компаний-разработчиков ОО программного обеспечения, а именно:

· Соглашение о семантике и нотациях для разнообразных аспектов современного моделирования в лаконичной форме;

· Определение достаточной семантики для ожидаемых новых технологий: компонентное программирование, распределенные вычисления и т.д.;

· Реализация механизма расширения для наращивания будущих методов моделирования поверх UML;

· Определение достаточной семантики для организации репозитория моделей.

Говоря о назначении и широких возможностях UML, нельзя забывать о том, что это всего лишь язык моделирования, т. е. средство моделирования, которым надо уметь пользоваться, знать, когда и где применять ту или иную модельную технику, четко представлять себе порядок проектирования и структуру создаваемой модели. На такие вопросы может дать ответы строгая методология, в основу которой положено некоторое стандартное средство моделирования, например, UML.

UML - это стандарт языка моделирования, а не методология моделирования. Чтобы ясно представлять себе это, рассмотрим те вопросы, которые лежат вне предметной области UML:

· Языки программирования - UML - язык визуального моделирования и не предназначен для визуального программирования, хотя инструментальное средство, поддерживающее нотации UML, может реализовывать кодогенерацию на основе построенных моделей.

· Инструментальные средства - UML не является спецификацией для разработки инструментального средства. В UML определена только модель семантики, но не определены модели интерфейса, хранения и поддержки времени выполнения. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о поддержке UML - среди них можно выделить: Rational Rose, Select Enterprise, Platinum и Visual Modeler.

· Модель процесса - предприятия используют UML как единый язык при разработке всех компонентов проекта, но процесс разработки может быть реализован по-разному. Хотя наблюдается сходимость моделей процессов для разных организаций, но общего соглашения по данному вопросу не найдено. UML не навязывает свою модель процесса, но при разработке языка авторы имели в виду процесс, обладающий следующими свойствами: управляемый прецедентами, итеративный и инкрементальный.

Рассмотрим структуру языка с точки зрения компонент, составляющих его описание. Определение UML, является самодостаточным и включает в себя следующие документы: Семантика UML, Нотация UML, Спецификации языка OCL (Object Constraint Language) и Расширение UML.

Семантика UML

Описание семантики UML происходит на уровне метамодели и представляется тремя согласованными способами:

Абстрактный синтаксис - метамодель UML разбита на 9 взаимосвязанных пакетов, каждый из которых описывается диаграммами классов UML. Метамодель вмещает в себя около 50 классов, более 100 ассоциаций и 1000 ограничений.

Правила состоятельности - правила описываются английской прозой и с использованием языка ограничений OCL, объектно-ориентированного языка с равенством и ограниченными кванторами.

Описание элементов моделирования (семантика) - выполнено в английской прозе.

Рассмотренные три описания в совокупности образуют формальное определение UML, более формальное определение потребовало бы сложной математики, что в конечном итоге затруднило бы использование языка, хотя и добавило бы строгости определениям.

Определяемые пользователем расширения UML возможны благодаря наличию следующих встроенных в язык механизмов:

Стереотипы - позволяют определить подклассы существующих элементов моделирования, сохраняя форму, но вкладывая новое содержание и добавляя новые свойства;

Тэгированные значения - позволяют определять новые свойства элементов моделирования, что дает возможность привязать модели совершенно произвольную информацию;

Ограничения - позволяет определить подмножество элементов моделирования, наделенное определенными свойствами (например, упорядоченность). Могут быть описаны с помощью OCL.

⇐ Предыдущая 18 19 20 21 222324 25 26 27 Следующая ⇒