|
Существует множество технологий и инструментальных средств, с
помощью которых можно реализовать в некотором смысле оптимальный проект ИС,
начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве
случаев эти технологии предъявляют весьма жесткие требования к процессу
разработки и используемым ресурсам, а попытки трансформировать их под
конкретные проекты оказываются безуспешными. Эти технологии представлены
CASE-средствами верхнего уровня или CASE-средствами полного жизненного
цикла (upper CASE
tools или full life-cycle CASE tools). Они не
позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и,
как следствие, многие разработчики перешли на так
называемые CASE-средства нижнего уровня (lower CASE
tools). Однако они столкнулись с новой проблемой —
проблемой организации взаимодействия между различными командами, реализующими
проект.
Унифицированный язык объектно-ориентированного моделирования
Unified Modeling
Language (UML) явился средством достижения компромисса
между этими подходами. Существует достаточное количество инструментальных
средств, поддерживающих с помощью UML жизненный цикл информационных систем, и,
одновременно, UML является достаточно гибким для настройки и поддержки
специфики деятельности различных команд разработчиков.
Мощный толчок к разработке этого направления информационных
технологий дало распространение объектно-ориентированных языков
программирования в конце 1980-х — начале 1990-х годов. Пользователям хотелось
получить единый язык моделирования, который объединил бы в себе всю мощь
объектно-ориентированного подхода и давал бы четкую модель системы, отражающую
все ее значимые стороны. К середине девяностых явными лидерами в этой области
стали методы Booch (Grady
Booch), OMT-2 (Jim
Rumbaugh), OOSE — Object-Oriented
Software Engineering (Ivar Jacobson). Однако эти три
метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа
проблемной области и анализа требований к системе, OMT-2 был наиболее
предпочтителен на стадиях анализа и разработки информационных систем,
Booch лучше всего подходил для стадий дизайна и разработки.
Все шло к созданию единого языка, который объединял бы сильные
стороны известных методов и обеспечивал наилучшую поддержку моделирования.
Таким языком оказался UML.
Создание UML началось в октябре 1994 г., когда Джим
Рамбо и Гради Буч
из Rational Software
Corporation стали работать над объединением своих методов
OMT и Booch. Осенью 1995 г. увидела свет первая
черновая версия объединенной методологии, которую они назвали
Unified Method 0.8. После
присоединения в конце 1995 г. к Rational
Software Corporation
Айвара Якобсона и его фирмы Objectory,
усилия трех создателей наиболее распространенных объектно-ориентированных методологий
были объединены и направлены на создание UML.
В настоящее время консорциум пользователей UML Partners
включает в себя представителей таких грандов информационных технологий, как
Rational Software,
Microsoft, IBM, Hewlett-Packard,
Oracle, DEC, Unisys,
IntelliCorp, Platinum
Technology.
UML представляет собой объектно-ориентированный язык
моделирования, обладающий следующими основными характеристиками:
·
является языком визуального
моделирования, который обеспечивает разработку репрезентативных моделей для
организации взаимодействия заказчика и разработчика ИС, различных групп
разработчиков ИС;
·
содержит механизмы расширения и
специализации базовых концепций языка.
UML — это стандартная нотация визуального моделирования
программных систем, принятая консорциумом Object
Managing Group (OMG) осенью 1997
г., и на сегодняшний день она поддерживается многими объектно-ориентированными
CASE-продуктами.
UML включает внутренний набор средств моделирования (модулей?)
("ядро"), которые сейчас приняты во многих методах и средствах
моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не
каждая концепция необходима в каждой части каждого приложения. Пользователям
языка предоставлены возможности:
·
строить модели на основе средств
ядра, без использования механизмов расширения для большинства типовых
приложений;
·
добавлять при необходимости новые
элементы и условные обозначения, если они не входят в ядро, или
специализировать компоненты, систему условных обозначений (нотацию) и
ограничения для конкретных предметных областей. |