Приемы объектно-ориентированного анализа и дизайна. Стандартизация и UML

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

UML это стандартная нотация, а не метод

Unified Modeling Language (UML) -- это стандартная нотация для моделирования объектно-ориентированных систем. Она официально поддерживается Object Management Group (OMG) и компаниями, которые входят в эту группу, то есть, другими словами, большинством тех, кто занимается бизнесом в области объектно-ориентированного программного обеспечения.

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

Идея заключается в том, что стандартизуя нотацию, разработчики программного обеспечения могут лучше взаимодействовать друг с другом, если все производители составных компонент также будут использовать UML. Однако различные группы могут использовать тот метод, который они считают нужным, для создания ПО. Было предложено несколько методов, которые используют UML. Rational предложила метод, который называется Objectory (и я слышал, что его переименовали в Unified Process), который базируется на работе Ивара Якобсона (Ivar Jacobson). Метод Fusion от компании HP -- это еще один метод, который часто упоминают.

Должны ли вы использовать UML?

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

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

Также как и для метода, все зависит от того, что вы делаете, и как много условностей вы хотите добавить в процесс разработки вашего ПО. Ищите метод, который разработан под тот тип ПО, которое вы разрабатываете. Процесс, созданный для систем реального времени скорее всего не будет работать для ПО управления предприятием. Существует общая тенденция создавать минималистичную методологию, чтобы сократить "церимониальность" традиционных методов. Это особенно актуально для небольших и средних разработок с парой или десятком разработчиков или даже менее.

Вы можете найти бесплатную информацию о UML на официальном сайте UML, но это избыточный материал, более предназначенный для специалистов по методологии, чем для обычных разработчиков. Но уже начинают появлятся и книги. Я не проводил полное исследование существующих изданий по UML, так что не буду ничего комментировать. Даже если бы я попытался, врядли это был бы беспристрастный обзор, так как я являюсь автором первой книги о UML (UML Distilled), Более старые книги по методам постепенно переходят на UML, например вводная книга Джима Оделла (Jim Odell).

История о том, как все начиналось

Несколько лет назад было сделано несколько попыток провести некоторую стандартизацию в методах ОО - объектно-ориентированного подхода. Analysis and Design Special Interest Group (SIG), входящая в the Object Management Group (OMG) проводила консультации, опубликовала толстый отчет по методам ОО и была вцелом проигнорирована (если не считать открытое письмо, в котором критиковалась сама идея стандартизции методов, подписанное главными гуру). Гради Буч (Grady Booch) пытался пойти более неформальным путем, но во время завтрака на OOPSLA 93 он обнаружил, что остальных гуру эта тема не очень-то интересует. Я помню встречу во время OOPSLA 93, когда гуру сказали, что несмотря на то, что это неплохая идея, никто не будет на нее работать.

Этот маленький мирок встряхнул Джим Румбах (Jim Rumbaugh), ведущий гуру в OMT, присоединившийся к Rational (в которой Гради Буч работает главным консультантом по науке). Они решили работать вдвоем и создать Unified Method. Как два ведущих специалиста по методологии, они могли бы придать Unified Method от Rational значительный вес.

Это событие вызвало панику среди методологов. В какой-то момент Rational заявила, что добъется стандартизации с помощью приемов Microsoft. Гради и Джим провозгласили, что война методов завершена и "мы победили". Методологи во всем мире стали создавать Анти-Буч Коалиции. Это было по-настоящему удивительное время.

Важнее было то, что в июне 1995-го OMG снова запустила SIG (группу особого интереса) по анализу и дизайну - проектированию ПО. В ранней ее инкарнации, она работала в своем маленьком уголке, и получала минимум внимания от управленцев OMG. Теперь OMG решила воспринять ее серьезно и Мэри Лумис (Mary Loomis) и Джим Оделл (Jim Odell) вошли в совет председателей. Очевидно, что OMG не хотела чтобы Rational установила свои стандарты без всякого влияния со стороны. SIG подготвила RFP (заявку на предложение) для стандартов: интерфейсы и моделирование вместе с нотацией.

К началу OOPSLA 1995 Rational была готова выдать свой первый документ по Unified Method (версию 0.8) на невероятно популярной бурной встрече, которая, кроме пения Джима Румбаха, была неплохим развлечением. Но Rational припрятала еще один козырь в своем рукаве -- покупку компании Ивара Якобсона (Objectory). С лучшими тремя методологами в своем составе, как они могут не выдать стандарт?

В 1996-ом Rational внедрила идеи Ивара Якобсона в Unified Method, изменив его название на Unified Modeling Language (UML). Они также стали более открытыми для других точек зрения, и получили серьезную поддержку от больших компаний, таких как Hewlett-Packard, Microsoft, Oracle, и Texas Instruments.

В начале 1997-го несколько заявок было подано в OMG Analysis and Design Task Force. Документ от Rational получил наибольшее внимание, но там также были заявки и от других организаций, наиболее заметной из которых была от IBM/ObjectTime. В этот момент весь процесс перешел в стадию обсуждения в прокуренных комнатах, в котором основным моментом были взаимные уступки, и выторговывание нужных каждому деталей. Важным результатом стало то, что все участники договорились насчет единого UML.

Не все методологи согласились с движением в сторону UML. Самым известным из диссидентов стал OPEN consortium, под руководством Дона Файрсмита (Don Firesmith), Брайана Хендерсона-Селлера (Brian Henderson-Sellers) и Яна Грэхама (Ian Graham). Они объявили, что UML слишком привязан к старым технологиям моделирования, которые не годятся для моделирования объектов и пердоставили свое решение: Открытый Язык Моделирования (OML).

Но UML начал доминировать. К 1997-у все участники OMG пришли к UML версии 1.1. Эта версия была формально принята OMG в конце 1997-го. Чтобы окончательно всех запутать, OMG взяла версию 1.1 от Rational и назвала ее OMG версия 1.0. Зачем нужно было так все запутывать, я не знаю. Сейчас рабочая группа вычищает спецификацию и движется к версии 1.2 (в обоих системах нумерации). В этой версии нет существенных отличий от 1.1.

TOC | Часть 2