Читальный зал -->  Диаграммы параллельных состояний 

1 [ 2 ] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Бучу из компании Rational Software с намерением объединить их методы.

Следующий год прошел в невольном удивлении.

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

К конференции OOPSLA95 Гради и Джим подготовили первое общедоступное описание своего объединенного метода в форме документации на Унифицированный метод (Unified Method) версии 0.8. Однако более важным оказалось их сообщение о приобретении фирмой Rational Software компании Objectory и о том, что Айвар Джекобсон присоединится к команде разработчиков Унифицированного метода. Фирма Rational устроила презентацию подготовленной версии 0.8, которая была воспринята с большим вниманием. Встреча прошла достаточно весело, ее не смогло испортить даже пение Джима Рамбо.

Гради, Джим и Айвар, ползившие широкую известность как трое друзей , в течение 1996 года продолжали работу над своим методом, но уже под новым названием: Унифицированный язык моделирования (UML). Однако другие главные действующие лица из сообщества разработчиков объектных методов не были расположены к тому, чтобы последнее слово осталось за UML.

Для стандартизации этих методов в рамках консорциума OMG была сформирована инициативная группа. Эта попытка решить данную проблему оказалась гораздо более серьезной, чем предыдущие усилия OMG в области этих методов. Председателем группы была выбрана Мэри Лумис (Магу Loomis), а затем в работу в качестве сопредседателя включился Джим Оделл, став фактическим лидером этой деятельности. Оделл дал ясно понять, что не желает поддерживать стандарт, предлагаемый компанией Rational, и готов предложить в качестве стандарта свой собственный метод.

В январе 1997 года различные организации представили на рассмотрение свои предложения по стандартизации методов, что способствовало обмену информацией между различными моделями. Эти предложения касались в основном метамодели и необязательной нотации. Среди этих предложений была и документация на язык UML версии 1.0, подготовленная компанией Rational.

После этого последовал короткий, но трудный период времени, в течение которого были объединены различные предложения. В результате консорциум OMG выдвинул в качестве официального стандарта OMG версию 1.1 языка UML. В последутощем инициативная группа по пересмотру (RTF) языка UML, возглавляемая Крисом Кобрином (Cris Ко-bryn), внесла в язык несколько существенных дополнений. В то время как версия 1.2 мало отличалась от своей предшественницы, версия 1.3,

ставшая обш;едоступной в начале 1999 года, подверглась серьезным изменениям. Весной 1999 года эксперты из инициативной группы RTF завершили свою работу, а версия 1.3 стала очередной официальной версией языка UML.

Нотации и метамодели

Язык UML, в своем нынешнем состоянии, определяет нотацию и мета-модель.

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

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

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

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

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

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

кой полезностью. Один из способов заключается в определении некоторой метамодели: диаграммы (как правило, диаграммы классов), определяющей нотацию.

На рис. 1.1 изображена небольшая часть метамодели языка UML, которая показывает отношение между ассоциациями и обобщением. (Этот фрагмент приведен с единственной целью - дать лишь общее представление о том, что такое метамодель. Я даже не буду пытаться давать здесь какие-либо дополнительные пояснения.)

Структурное свойство			Свойство поведения

0..1

{упорядочено}

Параметр

Рис. 1.1. Фрагмент метамодели языка UML

Насколько велико влияние метамодели на того, кто использует соответствующую нотацию при моделировании? Как минимум, она помогает определить, что такое правильно построенная модель, то есть модель, являющаяся синтаксически правильной. Кроме того, пользователь, обладающий высокой квалификацией в области методов, должен понимать данную метамодель. Однако большинству пользователей методов вовсе не нужно столь глубокое понимание метамодели для практического применения нотации языка UML.

Именно поэтому изложение материала в книге не является формальным; я следую по пути традиционных методов и апеллирую к вашей интуиции. При желании получить более строгое изложение обратитесь к справочному руководству или официальной документации.

Насколько глубоко вам придется погрузиться в изучение данного языка моделирования? Это зависит от цели, с которой вы его используете. Если вы располагаете CASE-средством, которое генерирует код, то для получения эффективного кода необходимо хорошо понимать механизм интерпретации языка моделирования этим CASE-средством. Ее-

1 [ 2 ] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку.



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.