Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 62
Текст из файла (страница 62)
Обобщение можно применять и к действующим лицам. Например, адзгинистратора можно считать олералтором, обладающим дополнительными привилегиями. 1пвег1 сагб гешгп саго [ипгеабаЫе] [геабаЫе] [Ьаб Ьапк собе ог Ьаб ассоип!] ]со!оп!Оп!сабопв боттп] [саго ОК] [сост!поп!Саг]опв боагп] [ассоип1 !гасо а1еб] [дооб ассоипт] [соптптип]сеаопв 60ттп] гециев1 раввигогб ]сопипип]сабопв бовгп] [гпи1бр]е раввигогб га!1игев] ]солист развагогб] Меер сап1 Рис. 1З.Б. Диаграмма деятельности дпя проверки карты Пример с банкоматом.
На рис. [3.6 показаны варианты использования, структурироваиные с применением отношения включения. Консорциум Клиент Банк Рис. 13.6. Структурирование вариантов использования 13.2. Модель классов приложения 269 13.1.10. Проверка по модели классов предметной области На этом этапе модель предметной области и модель приложения должны быть уже хорошо согласованы друг с другом.
Действующие лица, варианты использования и сценарии основаны на классах и концепциях модели предметной области. Вспомните, что одним из этапов построения этой модели является проверка маршрутов. На практике эта проверка — первый шаг к выделению вариантов использования. Сверьте друг с другом модель приложения и модель предметной области, чтобы убедиться в их согласованности.
Изучите сценарии и проверьте, что в модели предметной области имеются все необходимые данные. Убедитесь, что эта модель содержит все параметры событий. 13.2. Модель классов приложения Классы приложения описывают само приложение, а не объекты реального мира, с которыми оно работает. Большинство классов приложения связаны с компьютерами и определяют восприятие приложения пользователями. Модель классов приложения строится в несколько этапов.
1. Указать интерфейсы пользователя (раздел 13.2.1). 2. Определить граничные классы (раздел 13.2.2). 3. Определить управляющие объекты (раздел 13.2.3). 4. Проверить модель классов по модели взаимодействия (раздел 13.2А). 13.2.1. Определение интерфейсов пользователя Большинство взаимодействий можно разделить на две части: логика приложения и пользовательский интерфейс. Пользовательским интерфейсом (цэег иагег1асе) называется объект или группа объектов, предоставляющих пользователю системы единую точку доступа к объектам предметной области, командам и параметрам приложения.
В процессе анализа внимание уделяется прежде всего потокам информации и управления, а не формату представления. Одна и та же программная логика может принимать входные данные из командной строки, считывать из файла, интерпретировать как щелчки мышью, нажатия на сенсорные панели и кнопки, так и поступающие удаленные сигналы, при условии, что внешний интерфейс аккуратно отделен от внутренней части приложения. На этапе анализа пользовательский интерфейс рассматривается достаточно грубо. Не следует беспокоиться о том, каким конкретно образом будет введена определенная порция данных.
Вместо этого нужно попытаться определить команды, которые пользователь должен иметь возможность выполнять. Командой (сошшапс() называется крупномасштабный запрос некоторой услуги системы. Например, командами могут быть «забронировать билеты» и «найти поисковую строку в базе данных». Формат ввода информации и их запуска на выполнение 270 Глава 13 ° Анализ приложения изменить относительно несложно, поэтому, в первую очередь, следует выработать сами команды. Тем не менее вполне допустимо предварительно набросать интерфейсы, чтобы с их помощью визуализировать работу приложения и проверить, не было ли пропущено что-нибудь важное.
Можно даже сделать имитацию интерфейса, чтобы пользователи могли попробовать поработать с ним и оценить его. Логику приложения можно имитировать фиктивными процедурами. Отделение логики от пользовательского интерфейса дает вам возможность оценить ощущения от работы с этим интерфейсом, пока приложение все еше находится в стадии разработки. Пример с банкоматом. На рис. 13.7 показан возможный вид интерфейса банкомата. Точные детали на этом этапе несущественны. Самое важное — это информация, которой пользователи обмениваются с системой. Иногда пример интерфейса помогает визуализировать работу приложения.
Рис. 13.7. Формат интерфейса банкомата 13.2.2. Определение пограничных классов Система должна быть способна работать с информацией, принимаемой из внешних источников, но ее внутренняя структура не должна зависеть от этих источников. Часто оказывается полезно определить пограничные классы, которые будут изолировать внутреннюю часть системы от внешнего мира. Пограничным называется класс, который является посредником во взаимодействии системы с внешним источником.
Такой класс должен уметь принимать данные в формате одного или нескольких внешних источников и преобразовывать их к формату, с которым работает внутренняя часть системы. Пример с банкоматом. Полезно будет определить пограничные классы СазлСатйВоилпагу (Границакарты) и АссоилгВоилгуагу (Границасчета), которые скроют взаимодействие банкомата с консорциумом. Этот интерфейс позволит сделать приложение более гибким и упростит его расширение для работы с несколькими консорциумами.
13.2. Модель классов приложения 271 13.2.3. Определение управляющих объектов Управляющий обьеюп (сопгго11ег) — это активный объект, осуществляющий управление внутри приложения. Ои принимает сигналы из внешнего мира и от объектов системы, реагирует на иих, вызывает операции на объектах системы и передает сигналы во внешний мир. Управляющий объект — это воплощение поведения в форме объекта. С поведением в такой форме проще работать и его проще изменять, чем простой код. В основе многих приложений лежат управляющие объекты, упорядочивающие поведение этих приложений. Проектирование управляющего объекта сводится, по большей части, к разработке диаграммы состояний этого объекта. В модели классов приложения существование управляющих объектов тоже необходимо отразить, вместе с информацией, которую оии обрабатывают, и ассоциациями, которые связывают их с другими объектами системы.
Пример с банкоматом. Из сценариев, показанных на рис. 13.2, следует, что банкомат имеет два главных управляющих цикла. Внешний цикл проверяет клиентов и счета. Внутренний цикл обслуживает транзакции. Каждый из этих циклов наиболее естественно воплотить в управляющем объекте. 13.2Я. Проверка по модели взаимодействия Построив модель классов приложения, вернитесь к вариантам использования и подумайте о том, как оии могут осуществляться этим приложением. Например, если пользователь передает приложению команды, параметры команды должны передаваться каким-либо объектом пользовательского интерфейса.
Запрос иа саму команду должен исходить из какого-либо управляющего объекта. При наличии корректных моделей классов предметной области и приложения вы должны быть способны имитировать варианты использования при помощи классов. Тут нужно мыслить в терминах прослеживания маршрутов, о чем рассказывалось в главе 3. Ручное моделирование помогает убедиться в том, что все составляющие находятся иа своих местах. Пример с банкоматом. На рис. 13.8 показана предварительная модель классов приложения и классы предметной области, с которыми она взаимодействует. Интерфейсов всего два: один для пользователей, другой — для консорциума.
Эти классы в модели приложения представлены заглушками, потому что пока еще ие ясно, каким образом они должны быть реализованы. Обратите внимание, что пограничные классы делают структуру данных более плоской и объединяют информацию, полученную из разных классов предметной области. Для простоты количество пограничных классов и их отношений следует по возможности уменьшать.
Класс ТгаихаспопСопггоает (Управляюшийобьекттраизакций) обрабатывает запросы по счетам и собственно транзакции. Класс 5езиопСолггойег (УправляюшийобъектСеаисов) управляет классами АТМзеззюп (СеаисБаикомата), каждый из которых обслуживает клиента. Каждый объект А ТМзезяоп может иметь, а может и ие иметь корректных СпзлСаЫ (БанковскаяКарта) и Ассоилг (Счет). Класс уеяюлСопггоаег имеет атрибут жагиз (состояние), который может принимать 272 Глава 13 ° Анализ приложения Сопволдогпгп1еггвсв пвег1п!еггесе РгоЫегпТурв Соп1го11егРгоЫет в1аг10а!еТипе Мор0в!еТипе асииеСаг Севновп! 0..1 О..! АТМвевв1оп аввв1опСоп1гоавг 0..1 О..! в!ал0е!ет1ипе * и!е!ии Ассов п! вс!1иеАссоип! Рис.
13.8. Модель классов приложения 13.3. Модель состояний приложения Модель состояний приложения описывает состояния классов приложения и, таким образом, дополняет модель состояний предметной области. Классы приложения с большей вероятностью продемонстрируют изменение своего состояния, то есть наблюдать их поведение важнее чем поведение классов предметной области. Сначала нужно выделить классы приложения, обладающие несколькими состояниями, и с помощью модели взаимодействия определить события, которые влияют на эти состояния. Затем нужно упорядочить допустимые последовательности событий для каждого из классов на диаграмме состояний. После этого нужно проверить различные диаграммы состояний и убедиться, что одинаковые события на них действительно соответствуют друг другу.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
