М. Фаулер, К. Скотт - UML Основы (1114905), страница 32
Текст из файла (страница 32)
11.7. Посмотрим, каким образом данная диаграмма акцентирует внимание на интерфейсе, а не на реализации. Роль от Типа Показателя к Показателю моделируется как некая квалифицированная роль, поскольку это главный интерфейс класса Тип Показателя. Аналогично показана связь Наблюдения с Типом Показателя, поскольку и здесь существует интерфейс, хотя имеется только одно измерение с прямым указателем на Показатель. Глядя на эту диаграмму, мы можем сделать вывод, что единственное различие между классами Измерение и Наблюдение заключается в том, 165 Переход к кодированию Рис, 11.7.Другая модель спецификации наблюдения пациенпга что Измерение обладает количеством. Класс Измерение можно совсем удалить из модели спецификации, предположив, что любое наблюдение обладает количеством (которое может иметь неопределенное значение пи)1).
Мы могли бы все же оставить отдельный класс Измерение с полями величина и тип показателя, но при этом никто за пределами данного пакета не будет знать о существовании данного класса. Чтобы обеспечить создание соответствующего класса, нам может понадобиться добавить методы образца «Фабрика» (Гас1огу) 1Гамма и др., 1995 [20)) либо в класс Наблюдение, либо в класс Пациент. Я оставлю это дополнение в качестве упражнения для читателей и перейду к автоматическому связыванию Показателя с Измерением. Этот общий процесс изображен на рис. 11.7. 166 Глава 11. Язык 0МЕ и программирование Сначала необходимо добавить метод вызова в конструктор класса Измерение. С1азз Веазогеввп1 роЫ1с Неавсгевепг (Осапг11у авоспг, РПеповвпопТуре РЬеповепопТурв, Ра11епг ра11впп Оагв впепсозегчез) 1п111а11ге (ра11епг, впвпсозегчеа); авоспг = авоопг; рЬеповепопТуре рЬеповепопТурв; рЬеповепоп са1сс1агвРЬеповепопрог( авоспг); Далее эта задача делегируется классу Тип Показателя.
С1азз Веазсгевепг роЫ1с РЬеповепоп са1со1агвРЬеповепопрог(соап11(у агц) ( гегогп рпеповепопТуре.рпеповепоп1пс1оз1пц(агц); ) Далее по очереди запрашивается каждый показатель. С)азз РпеповепопТуре рсЫ1с РЬеповепоп рпеповвпоп1пс1оа1пц (Осап11гу агц) ( Епсвегаг1оп е = рЬеповапа(); вП11в (е.
ПазйогеЕ)евепгз() ) ( РЬеповепоп васЬ = (Рпеповепоп) е.пехгЕ1евепг(); 17 (еасЬ.1пс1освз(агц)) гегогп вась; ): гегсгп пс11; ) С1азз РПеповепоп роЫ1с Ьоо1еап 1пс1сзез (Осап111у агц) ( гегсгп ( гапце == пс)1 7 Га1зе: гапце.1пс1осез (агц)); ) Данный код достаточно явно следует из диаграммы последовательности. На практике я обычно пользуюсь диаграммой последовательности, чтобы только приближенно представить взаимодействие, а затем по мере кодирования вношу в него необходимые изменения. Если взаимодействие имеет существенное значение, я поддерживаю диаграмму последовательности в активном состоянии как часть моей документации.
Если же я сочту, что диаграмма последовательности не вносит никакой дополнительной ясности в программный код, то сдам ее в архив. Этот небольшой пример показывает, как использовать языка ПМ) в совокупности с языком программирования, однако при этом он дает и общее представление о процессе. Нет необходимости черезчур формально подходить к выполнению проекта и пытаться использовать аб- Переход к кодированию 167 солютно все возможности языка УМ1..
Вполне достаточно пользоваться только теми из них, которые представляются вам полезными. Схематическое представление проекта с помощью диаграммы классов и диаграммы взаимодействия помогает привести мысли в порядок и существенно облегчает процесс кодирования. Я рассматриваю эти схемы в качестве первых прототипов. В дальнейшем эти диаграммы вовсе не обязательно поддерживать, однако может оказаться, что они будут облегчать понимание программного кода вам самим и другим разработчикам, Нет необходимости использовать какое-то изысканное и дорогостоящее САЯЕ-средство.
Обычной доски и несложного графического редактора на компьютере может оказаться вполне достаточно. Конечно, существуют полезные САЯЕ-средства, и если вы участвуете в крупномасштабном проекте, то следует рассмотреть возможность применения какого-либо из них. Если вы решите использовать какое-либо САЯЕ-средство, сравните его возможности с простым графическим редактором и текстовым процессором.
(Просто поразительно, как много можно сделать с помощью таких средств, как Ч1в1о и Чх ого.) Если средство обладает возможностью генерации кода, то следует с большим вниманием присмотреться к тому, каким образом оно это делает. Возможность генерации кода САЯЕ- средством привносит крайне специфическую интерпретацию диаграмм, которая может повлиять на их смысл и ваш способ построения. Дополнительную информацию по данному примеру можно найти на моем сайте.
В приведенной там версии примера более детально рассмотрены вопросы взаимосвязи данной модели с пользовательским интерфейсом. Средство Назначение Показывает поведение вместе со структурой управлеяия. Может изображать множество объектов в иескольких вариантах использования, множество объектов в единственном варианте использования или реализацию метода. Предоставляет возможность определять параллельные процессы. Диаграмма деятельности Показывает статическую структуру понятий, типов и классов. Понятия отражают представление пользователей о реальном мире; типы отражают иитерфейсы компонентов ярограммяого обеспечения; классы отражают реализацию компонентов программно го обеспечеиия.
Диаграмма Нлассов СКС-карточки Помогают выделить сущность назначения класса. Полезяое средство при поиске ответа яа вопрос: как реа-лизовывать вариант использования. Следует примеиять при возникновении проблем с деталями реализации, а также при изучении объектного подходак проектированию. Диаграмма развертываиия Показывает физическое размещение компонентов ка узлах аппаратуры. Средства и их использование 169 Приложение А. Средства и их использование Средство Назначение Обеспечивает строгое определение назначения опера- ции и допустимого состояния класса.
Кодирует дан- ное определение в классе с целью расширения воз- можностей отладки. Проектирование по контракту Показывает кооперацию нескольких объектов в рам- ках одного варианта использования. Диаграмма взаямодействия Показывает группы классов и зависимости между ними. Диаграмма пакетов Образцы Являются полезным средством для анализа, проек- тирования н кодирования. Представляют собой хо- рошие примеры для обучения.
Могут служить на- чальной точкой для проектирования. Помогает вносить изменения в работающую про- грамму с целью улучшения ее структуры. Следует применять при необходимости тщательного проек- тирования программного кода. Реорганизация Показывает особенности поведения единственного объекта в нескольких вариантах использования. Диаграмма состояний Вариант непользования Облекает пользовательские требования в законченную форму.
Планирование фазы построения осуществляется с учетом реализации на каждой итерации нескольких вариантов использования. Является основой для тестирования системы. Отличия версий языка 0М~ Когда вышло в свет первое издание этой книги, язык ПМЬ имел еще версию 1.0. С ее появлением многие элементы языка ПМВ обрели устоявшуюся терминологию, а консорциум ОМО приобрел официальное признание.
С тех пор версия языка ПМБ пересматривалась несколько раз. В этом приложении описываются все существенные изменения языка ПМ1 с момента появления версии 1.0, что позволит учесть их, если вы пользуетесь первым изданием. Эволюция языка ПМ1 потребовала обновления книги, и второе издание содержит материал, отражающий ситуацию на момент его написания. Эволюция языка 0ЬИ. Первой общедоступной версией языка ПМ1 был Унифицированный метод версии 0.8, который был представлен на конференции ООРВ1 А, состоявшейся в октябре 1995 года.
Унифицированный метод был разработан Г. Бучем и Д. Рамбо 1к этому моменту А. Джекобсон еще не был сотрудником компании Ва$1опа1). В 1996 году компания ВаФ1опа1 выпустила версии 0.9 и 0.91, в работе над которыми принимал участие Джекобсон.
После выхода этой последней версии название метода изменилось на 11М1,. В январе 1997 года компания Ва$1опа1 представила на рассмотрение инициативной группы анализа и проектирования из ОМО версию 1.0 языка 11МБ. В последующем компания Ва$1опа! объединила эту версию ПМБ с другими методами и в сентябре 1997 года предложила в ка- Отличия версий языка 11Мс честве стандарта версию 1.1.
В конце 1997 года версия была одобрена консорциумом ОМС. Однако при невыясненных обстоятельствах консорциум ОМС назвал этот стандарт языка УМ1 версией 1.0. Таким образом, в то время существовали две версии языка УМЕ: версия 1.0 консорциума ОМС и версия 1.1 компании Ва11опа1, которые не следует путать с версией 1.0 компании Ва11опа1.
На практике же все разработчики называли этот стандарт версией 1.1. Версия 1.1 языка УМ). имеет несколько незначительных отличий от версии 1.0. В ходе работы над версией 1.1 ПМВ в рамках консорциума ОМС была образована инициативная группа по пересмотру языка (Веч1во1п Тав1с апогее, ВТГ), которую возглавил Крис Кобрин. Задача группы состояла в устранении неточностей языка ПМЕ. В июле 1998 внутри консорциума ОМС была выпущена версия 1.2. Появление последней считается внутренним делом ОМС, поскольку официальным стандартом УМ1 оставалась версия 1.1. Поэтому версию 1.2 можно считать бета-версией языка ПМ1.. Однако в действительности эти изменения едва заметны, поскольку были опубликованы только изменения в стандарте языка ПМ1' фиксированные типы, грамматические ошибки и т.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
