Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 55
Текст из файла (страница 55)
12.12. Модель классов банкомата после очередных исправлений банке. Каждая карта авторизации идентифицирует один или несколько счетов, например один счет до востребования и один накопительный. Класс транзакций определен не достаточно универсально, чтобы можно было выполнять трансфер денег между счетами, потому что он связан только с одним счетом.
Вообще говоря, класс Тгапзасггоп (Транзакция) должен состоять из одного или нескольких обновлений отдельных счетов. Обновление — это одно действие (снятие наличных, размещение наличных, запрос баланса), выполняемое с одним счетом. Все обновления, относящиеся к одной транзакции, должны быть выполнены атомарно, как одна операция. Если хотя бы одно обновление не будет выполнено успешно, вся транзакция отменяется. Различие между классами Вала' (Банк) и ВапИСотригег (БанковскийКомпьютер), а также между Сопзогггит (Консорциум) и СепггагСотригег (Центральный- Компьютер) не влияет на аналитическую модель.
Тот факт, что взаимодействие осуществляется компьютерами, на самом деле является артефактом реализации. Мы превращаем Вап1гСотригег в Вап1г, а СепггагСотритег в Сопзогтгит. Класс Сизготег(Клиент) пока не появлялся в аналитической модели. Однако, если учесть возможные операции по открытию новых счетов, клиент может стать важным, поэтому пока мы оставим его в покое. На рис.
12.12 показана исправленная диаграмма классов, которая стала проще и яснее. 240 Глава 12 ° Анализ предметной области 12.2.11. Смещение уровня абстрагирования Ьоаа О..! Регеоп етр!оуеетуре l герон!лвсече! чгоягег Искоднан модель Усовершенствованная модель с лучшим абстрааированием Рис.
12.13. Смещение уровня абстрагирования Чтобы воспользоваться преимуществами абстрагирования, необходимо мыслить в категориях образцов. Разные образцы применяются на разных стадиях Пока что мы воспринимали описание задачи буквально. Мы считали существительные и глаголы в описании задачи прямыми аналогами классов и ассоциаций.
Такой подход удобен на начальном этапе анализа, но его не всегда оказывается достаточно. Иногда для решения задачи необходимо перейти на более высокий уровень абстрагирования. Этим следует заниматься в процессе построения модели, но мы добавили в описываемую последовательность моделирования отдельный этап, чтобы вы не пропустили процедуру абстрагирования.
Например, однажды мы столкнулись с приложением, разработчики которого создали отдельные классы 1лйтпг!иа!СолгпЬигот (Сотрудник), Бирегт/(вот (Контролер) и Мапаяег (Управляюший). Сотрудники отчитываются перед контролерами, а те — перед управляющими. Эта модель корректна, но она обладает некоторыми недостатками.
Три класса обладают слишком болыцим количеством общих черт; разница лишь в том, кто перед кем отчитывается. Например, они все характеризуются телефонными номерами и адресами. Общие черты можно было бы вынести в суперкласс, но от этого модель бы стала только сложнее.
Еше одна проблема возникла, когда мы поговорили с разработчиками, и они сказали, что хотят добавить еше один класс, перед которым будут отчитываться управляюшие. На рис. 12.13 показаны исходная и улучшенная модели. Итоговая модель стала более абстрактной. Вместо жесткого кодирования иерархии управления в модели, мы можем ввести его более гибко, при помощи ассоциации между руководителем и подчиненным. Человек, атрибут етр!оуееТуре которого имеет значение !лййг(иа!Солгг!Ьигог, является подчиненным и отчитывается перед другим человеком, у которого етр(оуееТуре - зиреллзог. Аналогичным образом, люди-контролеры отчитываются перед людьми-управляюшими. В усовершенствованной модели подчиненный не обязательно имеет руководителя, потому что иерархия подчинения должна быть конечной. Добавление уровня руководства не изменяет структуру модели; изменяются только конкретные данные.
12.2. Модель классов предметной области 241 разработки. Здесь нас интересуют аналитические образцы. Образец (раггегп) является квинтэссенцией знаний экспертов и дает проверенное решение общей задачи. Например, правая часть рис. 12.13 представляет собой образец моделирования иерархии управления. Везде, где мы сталкиваемся с потребностью описания иерархии управления, мы вспоминаем об этом образце и добавляем его в нашу модель. Использование проверенных образцов дает уверенность в правильности подхода и значительно повышает продуктивность.
Пример с банкоматом. Некоторые абстракции мы уже включили в модель банкомата на предыдущих этапах. Мы провели различие между классами Сазйсап( (БанковскаяКарта) и Сань'(иГЬопгаГ1оп (КартаАвторизации). Боле того, мы включили концепцию транзакций вместо того, чтобы перечислять все возможные виды взаимодействий. 12.2.12. Группировка классов в пакеты Последний этап моделирования — группировка классов в пакеты. Пакет (раскайе) — это группа элементов (классов, ассоциаций, обобщений и вложенных пакетов), характеризуюшихся обшей темой. Пакеты делают модель более удобной с точки зрения построения, печати и просмотра.
Более того, помещая определенные классы и ассоциации в пакет, вы делаете семантическое утверждение. Классы одного пакета связаны друг с другом сильнее, чем классы в разных пакетах. Нужно стараться ограничивать ассоциации рамками одного пакета. Некоторые классы можно повторять в разных пакетах. Чтобы распределить классы по пакетам, ищите точки сочленения (сш ро1пгз) — классы, являюшиеся единственным соединением двух частей людели, не имеюших между собой других связей. Такой класс образует мост между двумя пакетами. Например, в системе управления файлами класс Где (Файл) является точкой сочленения между структурой каталогов и содержимым файла. Старайтесь выбирать пакеты так, чтобы сокращать количество пересечений на диаграммах классов.
Приложив некоторые усилия, можно добиться того, что большинство диаграмм классов станут плоскими графами без пересекаюшихся линий. По возможности следует использовать пакеты из предыдущих проектов, однако не стоит «втискивать» их в модель. Повторное использование осуществляется проще всего, если часть предметной области совпадает с предыдущей задачей. Если новая задача похожа на предыдушую, но отличается от нее, вы можете расширить исходную модель, чтобы описать обе задачи. Судите сами, что лучше в каждом конкретном случае: строить модель заново или использовать предыдущую. Пример с банкоматом. Наша модель невелика и не требует деления на пакеты, но она может стать ядром для более детальной модели.
Потенциальные пакеты могут быть такими: ° кассиры: кассир, устройство ввода, касса, банкомат; ° счета: счет, банковская карта, карта авторизации, клиент, транзакция, обновление, кассовая транзакция, удаленная транзакция; ° банки: консорциум, банк. 242 Глава 12 ° Анализ предметной области В каждом пакете детализация может осуществляться независимо. Пакет «счета» может включать разнообразные транзакции, сведения о клиентах, выплаты процентов, штрафы.
Пакет «банки» может содержать сведения о филиалах, адреса банков и распределение затрат. 12.3. Модель состояний предметной области Некоторые объекты предметной области за время своей жизни сменяют несколько качественно различных состояний. В этих состояниях они могут иметь разные ограничения на значения атрибутов, разные ассоциации или кратности, выполнять разные операции или иметь разное поведение и т. д.
Часто бывает полезно построить диаграмму состояний для таких классов. Диаграмма состояний описывает различные состояния, в которых может находиться объект, свойства объекта и действуюшие на них ограничения, а также события, вызывающие переход объекта из одного состояния в другое. Большинство классов предметной области не требуют использования диаграмм состояний.
Для их описания достаточно списка операций. Модель состояний может помочь в понимании поведения тех классов, которые могут находиться в существенно разных состояниях. Сначала нужно выявить классы, которые могут находиться в разных состояниях, и записать состояния для каждого класса. Затем необходимо определить события, вызывающие переход каждого объекта из одного состояния в другое. Зная состояния и события, вы можете построить диаграмму состояний для каждого из объектов. Наконец, вы должны проверить полученные диаграммы на полноту и корректность. Модель состояний предметной области конструируется в несколько этапов; ° выявление классов, обладающих разнымитостояниями (раздел 12.3.1); ° выделение состояний (раздел 12.3.2); ° выделение событий (раздел 12.3.3); ° построение диаграмм состояний (раздел 12.3А); ° проверка диаграмм состояний (раздел 12.3.5). 12.3.1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
