2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006).pdf), страница 4

Тем не менее многие пользователи испытывализатруднения при выборе языка моделирования, который полностьюотвечал бы их потребностям, что послужило причиной так называемой «войны методов». В результате появилось новое поколение методов, среди которых особое значение приобрели метод Буча, OOSE(ObjectFOriented Software Engineering), разработанный Якобсоном,и OMT (Object Modeling Technique), разработанный Рамбо. Крометого, следует упомянуть методы Fusion, ShlaerFMellor и CoadFYourdon.Каждый из этих методов можно было считать целостным и законченным, хотя любой из них имел не только сильные, но и слабые стороны.Выразительные возможности метода Буча были особенно важны наэтапах проектирования и конструирования системы.

OOSE был великолепно приспособлен для анализа и формулирования требований,а также для высокоуровневого проектирования. OMT оказался особенно полезным для анализа и разработки информационных систем.Критическая масса новых идей начала накапливаться к середине1990Fх годов, когда Гради Буч (компания Rational Software Corporation), Джеймс Рамбо (General Electric), Ивар Якобсон (Objectory)и другие предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в областиобъектноFориентированных методов.

Являясь основными авторамиметодов Буча, OOSE и OMT, мы попытались создать новый, унифицированный язык моделирования и руководствовались при этомтремя соображениями. ВоFпервых, все три метода независимо от желания разработчиков уже развивались во встречном направлении.Разумно было продолжить это движение вместе, а не по отдельности,что помогло бы в будущем устранить нежелательные различия и, какследствие, неудобства для пользователей. ВоFвторых, унифицировавКраткая история UML15методы, проще было привнести стабильность на рынок инструментовобъектноFориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточитьсяна более продуктивной деятельности. Наконец, следовало полагать,что подобное сотрудничество приведет к усовершенствованию всехтрех методов и обеспечит решение задач, для которых любой из них,взятый в отдельности, был не слишком пригоден.Начав унификацию, мы поставили перед собой три главныецели:1.

Моделировать системы целиком, от концепции до исполняемыхкомпонентов, с помощью объектноFориентированных методов;2. Решить проблему масштабируемости, которая присуща сложным, критически важным системам;3. Создать язык моделирования, который может использоваться не только людьми, но и компьютерами.Создание языка для объектноFориентированного анализа и проектирования не слишком отличается от разработки языка программирования. ВоFпервых, требовалось ограничить задачу.

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

Внесение слишком большого числа изменений могло быоттолкнуть уже имеющихся пользователей, а авторы, сопротивляясьразвитию языка, потеряли бы возможность привлекать новых пользователей и делать язык более простым и удобным для применения. Создавая UML, мы старались найти оптимальное решение этих проблем.Официальное создание UML началось в октябре 1994 года, когда Рамбо перешел в компанию Rational Software, где работал Буч.

Первоначальной целью было объединение методов Буча и OMT. Перваяпробная версия 0.8 Унифицированного метода (Unified Method), какего тогда называли, появилась в октябре 1995 года. Приблизительнов то же время в компанию Rational перешел Якобсон, и проект UMLбыл расширен с целью включить в него OOSE. В результате наших совместных усилий в июне 1996 года вышла версия 0.9 языка UML. Напротяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области создания программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса.16ВведениеВ результате был создан консорциум UML, в который вошлиорганизации, изъявившие желание предоставить ресурсы для работы, направленной на создание полной спецификации UML.

Версия1.0 языка появилась в результате совместных усилий компанийDigital Equipment Corporation, HewlettFPackard, IFLogix, Intellicorp,IBM, ICON Computing, MCI Systemhousе, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 годаон был предоставлен в качестве проекта стандартного языка моделирования консорциуму OMG (Object Management Group).Между январем и июлем 1997 года консорциум UML расширился –в него вошли почти все компании, откликнувшиеся на призыв OMG,а именно: Andersen Consulting, Ericsson, Object Time Limited, PlatinumTechnology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координироватьработу с другими группами, занимающимися стандартизацией, подруководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйхолта (Ed Eykholt) из Rational была организованарабочая группа.

Пересмотренная версия UML (1.1) была представлена на рассмотрение OMG в июле 1997 года. В сентябре версия былаутверждена на заседаниях группы по анализу и проектированиюи Комитета по архитектуре OMG, а 14 ноября 1997 года была утверждена в качестве стандарта всеми участниками консорциума OMG.В течение нескольких лет специальная рабочая группа OMG(OMG Revision Task Force) поддерживала продвижение проектаUML.

Были созданы версии 1.3, 1.4 и 1.5. За 2000–2003 годы новая,расширенная группа участников проекта создала модернизированную версию UML 2.0. Эта версия рассматривалась в течение годарабочей группой Finalization Task Force (FTF) во главе с БрэномСэликом (Bran Selic) из IBM, а в начале 2005 года члены OMG утвердили официальную версию UML 2.0. UML 2.0 – это последний релиз UML, который включает в себя большое количество дополнительных возможностей. Много изменений было сделано благодаряопыту использования предыдущих версий. Текущую спецификациюUML вы найдете на WebFсайте OMG www.omg.org.UML – это результат работы множества специалистов и осмысления опыта их предыдущих разработок. Подсчитать источники,которые использовались при подготовке этого проекта, было быогромным научным трудом.

Но сложнее всего было бы установитьвсе предшествующие наработки, в большей или меньшей степениоказавшие влияние на UML. С учетом всех научных исследованийи рабочей практики можно сказать, что UML – это верхушка «айсберга», который вобрал в себя весь предыдущий опыт.Часть IВведение в процессмоделированияГлава 1. Зачем мы моделируемГлава 2. Введение в UMLГлава 3. Здравствуй, мир!Значение моделированияГлава 1. Зачем мы моделируемВ этой главе:Значение моделированияЧетыре принципа моделированияНаиболее важные модели программных системОбъектноориентированное моделированиеКомпания, занимающаяся производством программного обеспечения, может преуспевать только в том случае, если выпускаемаяею продукция отличается высоким качеством и разработана в соответствии с запросами пользователей.

Фирма, которая способнавыпускать такую продукцию своевременно и регулярно, при максимально полном и эффективном использовании всех имеющихся человеческих и материальных ресурсов будет стабильно процветать.Из сказанного следует, что основным продуктом такой компанииявляется первоклассное программное обеспечение, удовлетворяющее повседневные нужды пользователей. Все остальное – прекрасные документы, встречи на высшем уровне, великолепные лозунгии даже Пулитцеровская премия за идеальные строки исходногокода – вторично по сравнению с этой основной задачей.К сожалению, во многих организациях путают понятия «вторичный» и «несущественный».

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

Чтобы справиться с поставленной задачей, принимая во внимание затраты на жизненный цикл системы, необходимо, чтобыпроцесс разработки приложения был тщательно продуман и мог19быть адаптирован к изменяющимся потребностям вашего бизнесаи технологии.Центральным элементом деятельности, ведущей к созданию первоклассного программного обеспечения, является моделирование.Модели позволяют нам наглядно продемонстрировать желаемуюструктуру и поведение системы.