Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению. С помощью UML можно разработать детальный план создаваемой системы, отображающий не только ее концептуальные элементы, такие как системные функции и бизнес-процессы, но и конкретные особенности реализации, в том числе классы, написанные на специальных языках программирования, схемы баз данных и программные компоненты многократного использования.
Эта книга научит вас эффективной работе с UML.
Прочитав эту книгу, вы:
Предлагаемое вашему вниманию руководство пользователя рассказывает о разнообразных свойствах UML, однако не претендует на всеохватность. Возместить этот недостаток призвано другое издание - "Справочник по языку UML" ("The Unified Modeling Language Reference Manual". Rumbaugh, Jacobson, Booch, Addison-Wesley, 1999).
Авторы настоящего руководства описывают важнейшие аспекты процесса разработки с использованием UML. Читателям, которых эта тема интересует более подробно, следует обратиться к изданию "The Unified Software Development Process" (Jacobson, Booch, Rumbaugh, Addison-Wesley, 1999).
В книге содержится множество рекомендаций и советов по использованию UML для решения часто возникающих задач моделирования, но она не учит моделированию как таковому. Подобный подход принят в руководствах по большинству языков программирования, разъясняющих, как применять язык, но не обучающих собственно программированию.
Язык UML представляет интерес для любого специалиста, участвующего в процессе разработки, установки и поддержки программного обеспечения. Данное руководство пользователя в первую очередь предназначено для разработчиков, создающих модели UML. Тем не менее его полезно будет прочитать всем, кто должен анализировать эти модели, а также осваивать, создавать, тестировать или выпускать в свет программные системы. Хотя под такое описание подходит практически любой сотрудник организации, занимающейся программным обеспечением, эта книга особенно пригодится аналитикам и конечным пользователям, которые специфицируют требуемую структуру и поведение системы, архитекторам, которые проектируют системы в соответствии с этими требованиями, разработчикам, преобразующим проект в исполняемый код, сотрудникам отдела технического контроля, проверяющим и подтверждающим соответствие структуры и поведения системы заданным спецификациям, библиотекарям, которые создают каталоги компонентов, а также руководителям группы разработки и проекта в целом, которые борются с хаосом, осуществляют общее руководство, определяют направление работ и распределяют необходимые ресурсы.
Данная книга рассчитана на читателей, которые имеют хотя бы общее представление об объектно-ориентированных концепциях. Опыт работы с конкретными объектно-ориентированными языками и методиками не требуется, хотя и желателен.
Тем, кто только начинает осваивать язык UML, лучше всего читать эту книгу подряд. Особое внимание рекомендуется уделить второй главе, в которой излагается концептуальная модель языка. Изложение в каждой главе опирается на материал предыдущей, что делает книгу удобной для последовательного чтения.
Опытные разработчики, желающие найти решение конкретных проблем, возникающих при моделировании, могут читать это руководство в любой последовательности. Советуем обратить внимание на типичные приемы моделирования, представленные в каждой главе.
Руководство пользователя содержит семь основных разделов.
Кроме этого, книга включает в себя три приложения: обзор применяемой в языке UML нотации, список стандартных элементов UML и обзор Рационального Унифицированного Процесса (Rational Unified Process). Приводится глоссарий наиболее распространенных терминов.
Каждая глава посвящена рассмотрению какой-то одной черты UML и, как правило, состоит из следующих четырех разделов:
В третьем разделе каждой главы содержатся примеры решения проблем, часто возникающих при моделировании.
Объектно-ориентированные языки моделирования появились в период с середины 70-х до конца 80-х годов, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектно-ориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию. С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее многие пользователи испытывали затруднения при выборе языка моделирования, который бы полностью соответствовал их потребностям, что послужило причиной так называемой "войны методов". В результате этих войн появилось новое поколение методов, среди которых особое значение приобрели языки Booch, созданный Грейди Бучем (Grady Booch), OOSE (Object-Oriented Software Engineering), разработанный Айваром Джекобсоном (Ivar Jacobson) и ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо (James Rumbaugh). Кроме того, следует упомянуть языки Fusion, Шлаера-Меллора (Shlaer-Mellor) и Коада-Йордона (Coad-Yourdon). Каждый из этих методов можно считать вполне целостным и законченным, хотя любой из них имеет не только сильные, но и слабые стороны. Выразительные возможности метода Буча особенно важны на этапах проектирования и конструирования модели. OOSE великолепно приспособлен для анализа и формулирования требований, а также для высокоуровневого проектирования. ОМТ-2 оказался особенно полезным для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных.
Критическая масса новых идей начала формироваться к середине 90-х годов, когда Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ, партнеры попытались создать новый, унифицированный язык моделирования и руководствовались при этом тремя соображениями. Во-первых, все три метода, независимо от желания разработчиков, уже развивались во встречном направлении. Разумно было продолжать эту эволюцию вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей. Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточиться на более продуктивной деятельности. Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден.
Начав унификацию, авторы поставили перед собой три главные цели:
Изобретение языка для объектно-ориентированного анализа и проектирования не слишком отличается от разработки языка программирования. Во-первых, требовалось ограничить задачу. Следует ли включать в язык возможность спецификации требований? Должен ли язык позволять визуальное программирование? Во-вторых, было необходимо найти точку равновесия между выразительной мощью и простотой. Слишком простой язык ограничил бы круг решаемых с его помощью задач, а слишком сложный мог ошеломить неискушенного разработчика. Кроме того, при объединении существующих методов приходилось учитывать наличие уже разработанных с их помощью продуктов. Внесение слишком большого числа изменений могло бы оттолкнуть уже имевшихся пользователей, а сопротивляясь развитию языка, авторы потеряли бы возможность привлекать новых пользователей и делать язык более простым и удобным для применения. Создавая UML, разработчики старались найти оптимальное решение этих проблем.
Официально создание UML началось в октябре 1994 года, когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и ОМТ. Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области конструирования программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был основан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полного определения UML.
Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, OMG) на конкурс по созданию стандартного языка моделирования.
Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG, а именно: Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйкхолта (Ed Eykholt) из Rational была организована семантическая группа. Пересмотренная версия UML (1.1) была снова представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях Группы по анализу и проектированию и Комитета по архитектуре OMG, a 14 ноября 1997 года принята в качестве стандарта на общем собрании всех членов OMG.
Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 - UML 1.3. Данное руководство пользователя описывает именно эту версию языка.
Грейди Буч, Айвар Джекобсон и Джеймс Рамбо начали работы по созданию UML и являются авторами первоначального проекта, но окончательная версия языка сформировалась в результате объединенных усилий группы разработчиков. Хотя у каждого из них были свои собственные идеи, заботы и интересы, результат только выиграл от разнообразия опыта и точек зрения участников.
Ядро команды UML составили:
Крис Кобрин заслуживает особой благодарности за руководство технической командой UML в ходе создания версий этого языка 1.1, 1.2 и 1.3.
Разработка UML всегда была открытым процессом, и в рамках Группы пользователей по объектным технологиям (OTUG - Object Technology User Group) авторы получили тысячи сообщений по электронной почте со всего мира. Невозможно поименно перечислить всех корреспондентов, но создатели языка благодарят каждого из них за комментарии и предложения. Все письма были прочитаны, и нет сомнения, что UML стал лучше и богаче благодаря такой широкой международной поддержке.
Самую свежую информацию, касающуюся UML, включая его формальную спецификацию, можно найти в Internet на сайтах http://www.rational.com и http:// www.omg.org. С результатами работы Группы по усовершенствованию можно ознакомиться по адресу http://uml.shl.com.
В Internet существует несколько форумов, где обсуждаются различные вопросы, связанные с UML. Это группы новостей comp.software-eng и comp.object, а также списки рассылки otug@rational.com и uml-rtf@omg.org.
Грейди БучДля облегчения работы с текстом в книге приняты следующие соглашения:
Примечание: Текст примечания содержит не относящиеся непосредственно к теме изложения комментарии и общие рекомендации.
Диаграммы и примеры, приведенные в книге, оставлены без перевода в том случае, если они иллюстрируют структурные, а не содержательные аспекты UML.
Издательство "ДМК" заинтересовано в получении ваших отзывов об этой книге. Напишите нам, какие еще книги по программированию вы хотели бы прочитать. Свои отклики и пожелания присылайте на наш Web-сайт http://www.dmk.ru.
Релятивисты и позитивисты утверждают, что "мысленный эксперимент" весьма полезный интрумент для проверки теорий (также возникающих в нашем уме) на непротиворечивость. В этом они обманывают людей, так как любая проверка может осуществляться только независимым от объекта проверки источником. Сам заявитель гипотезы не может быть проверкой своего же заявления, так как причина самого этого заявления есть отсутствие видимых для заявителя противоречий в заявлении.
Это мы видим на примере СТО и ОТО, превратившихся в своеобразный вид религии, управляющей наукой и общественным мнением. Никакое количество фактов, противоречащих им, не может преодолеть формулу Эйнштейна: "Если факт не соответствует теории - измените факт" (В другом варианте " - Факт не соответствует теории? - Тем хуже для факта").
Максимально, на что может претендовать "мысленный эксперимент" - это только на внутреннюю непротиворечивость гипотезы в рамках собственной, часто отнюдь не истинной логики заявителя. Соответсвие практике это не проверяет. Настоящая проверка может состояться только в действительном физическом эксперименте.
Эксперимент на то и эксперимент, что он есть не изощрение мысли, а проверка мысли. Непротиворечивая внутри себя мысль не может сама себя проверить. Это доказано Куртом Гёделем.
Понятие "мысленный эксперимент" придумано специально спекулянтами - релятивистами для шулерской подмены реальной проверки мысли на практике (эксперимента) своим "честным словом". Подробнее читайте в FAQ по эфирной физике.
|
![]() |