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

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

Наблюдение пациента: модель спецификации

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

Тип Показателя

0..1

Измерение

значение: Количество

Показатель

диапазон: КоличественныйДиапазон

0..1

Наблюдение

Пациент

Рис. 11.4. Модель наблюдения пациента уровня спецификации

Модель наблюдения пациента представлена здесь с точки зрения спецификации. На ней указаны скорее интерфейсы классов, чем сами классы. Можно было бы поддерживать эту концептуальную модель и далее, но более вероятно, что начиная с этого момента, я буду работать только с моделью спецификации. Я не стараюсь поддерживать слишком много моделей. Мое личное правило состоит в следующем: если я не могу поддерживать модель посредством внесения в нее необходимых обновлений, то она отправляется в корзину. (Я знаю, что я к тому же ленив!)

Теперь рассмотрим поведение, ассоциированное с нашей моделью наблюдения пациента (рис. 11.5).

Тип Показателя

0..1

Измерение

значение:Количество

Показатель

диапазон: КоличественныйДиапазон

0..1

Наблюдение

моментВремени

Пациент

последнееЗначение (Тип Показателя): Количество показатель (Тип Показателя): Показатель

Рис. 11.5. Операции модели наблюдения пациента

Первый сценарий запрашивает последние данные о сердечном ритме пациента. В связи с этим возникает первый вопрос: кто должен нести ответственность за выполнение этого запроса? Естественным ответом представляется Пациент. Пациент должен просмотреть все свои наблюдения, выбрать из них измерения с Типом Показателя сердечный ритм и найти среди них самое последнее значение. Чтобы сделать это, необходимо добавить в Измерение момент времени. Поскольку аналогичные рассуждения могут быть применены и к другим наблюдениям, я также добавлю момент времени и в Наблюдение.

Пациент имеет такую же ответственность по отношению к Показателю: Найти последнюю Категорию Наблюдения, которая обладает Показателем для данного Типа Показателя.

На рис. 11.5 показаны те операции, которые были мною добавлены к классу Пациент, чтобы отразить в модели все сказанное выше.

Переход к кодированию

Теперь мы можем обратиться к рассмотрению фрагментов программного кода, реализующего те идеи, которые обсуждались в предыдущих разделах. Я начну с Типа Показателя (Phenomenon Туре) и Показателя (Phenomenon), поскольку они довольно тесно взаимосвязаны.

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

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

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

Таким образом, между данными объектами существует некоторая кооперация. Она может быть хорошо представлена с помощью диаграммы последовательности (рис. 11.6).

Должны ли вы строить все эти диаграммы?

Вовсе нет. Многое зависит от ваших способностей к визуализации моделей и от того, насколько легко вам работать с выбранным языком программирования. Что касается языка Smalltalk, то зачастую писать код так же легко, как и разрабатывать диаграммы. Если же программа разрабатывается на языке С-Н-, то диаграммы приносят больше пользы.

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

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

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