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

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

честве стандарта версию 1.1. В конце 1997 года версия была одобрена консорциумом OMG. Однако при невыясненных обстоятельствах консорциум OMG назвал этот стандарт языка UML версией 1.0. Таким образом, в то время существовали две версии языка UML: версия 1.0 консорциума OMG и версия 1.1 компании Rational, которые не следует путать с версией 1.0 компании Rational. На практике же все разработчики называли этот стандарт версией 1.1.

Версия 1.1 языка UML имеет несколько незначительных отличий от версии 1.0.

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

Более значительные изменения коснулись версии 1.3, которые заметно уточнили терминологию в отношении вариантов использования и диаграмм деятельности. Позже в 1999 году были опубликованы две книги трех друзей : Руководство пользователя [6] и Справочник пользователя [37], которые отразили изменения в версии 1.3 до публикации официальных документов по этой версии языка UML, что привело к некоторым недоразумениям.

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

Изменения в первом издании книги

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

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

ная группа RTF решила не изменять номер версии языка UML, поэтому она так и осталась версией 1.3.

Далее в этом приложении внимание сосредоточено на двух основных отличиях в языке UML, имевших место при изменениях версий с 1.0 на1.1ис1.2на1.3. Мне бы не хотелось обсуждать в деталях все произошедшие изменения, поэтому остановлюсь лишь на тех из них, которые каким-то образом затрагивают материал книги UML в кратком изложении или относятся к важным свойствам языка UML, рассмотренным в первом издании.

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

Я также воспользуюсь представленной возможностью отметить те или иные важные ошибки или погрешности предыдущих вариантов книги. Спасибо читателям, которые сообщили о них.

Отличия версий 1.0 и 1.1 языка UML Тип и класс реализации

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

Эти обстоятельства нашли отражение в языке UML, поскольку теперь утверждается, что все классы на диаграмме классов могут быть определены либо как типы, либо как классы реализации.

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

Можно установить, что для отдельной диаграммы все классы обладают некоторым особым стереотипом. Это может произойти в том случае, когда диаграмма отражает отдельную точку зрения. При этом точка зрения реализации предполагает использование классов реали-

зации, а концептуальная точка зрения и точка зрения спецификации предполагают использование типов.

Если некоторый класс реализации реализует один или несколько типов, то это может быть показано с помощью отношения реализации.

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

Для класса реализации может быть использована только единственная статическая классификация, однако для типов можно использовать множественную и динамическую классификацию. (Я думаю, что причиной этого является то обстоятельство, что основные объектно-ориентированные языки поддерживают единственную статическую классификацию. Если в один прекрасный день вы будете пользоваться языком, который поддерживает множественную или динамическую классификацию, то это ограничение может быть снято.)

Ограничения полного и неполного обобщения

в предыдущих выпусках UML в кратком изложении было отмечено, что ограничение {полный} ({complete}) для некоторого обобщения устанавливает, что все экземпляры супертипа должны быть также экземпляром некоторого подтипа в данном разбиении. Вместо этого в языке UML версии 1.1 определено ограничение {полный}, которое указывает лишь на то, что соответствующее разбиение отражает все подтипы. А это совсем не то же самое. Мною было обнаружено множество несоответствий в интерпретации этого ограничения, поэтому вам следует обратить на это внимание.

Если вы хотите, чтобы все экземпляры супертипа были экземпляром одного из подтипов, то во избежание недоразумений логично использовать другое ограничение. Лично я использую в этом случае {обязательно} ({mandatory}).

Композиция

Использование композиции в языке UML версии 1.0 означает, что эта связь неизменна (или постоянна) по крайней мере для однозначных компонентов. Это ограничение больше не является частью определения композиции.

Неизменность и постоянство

Язык UML определяет ограничение {постоянный} ({frozen}) для указания неизменяемости ролей ассоциации. Как определено в настоящее время, это ограничение не может быть применено к атрибутам или

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 
Продажа и изготовление мебели.

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