В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 13
Текст из файла (страница 13)
Основные используемые виды моделей следующие.• Модель вариантов использования (Use-Case Model).Эта модель определяет требования к ПО — то, что система должна делать — в виде наборавариантов использования. Каждый вариант использования задает сценарий взаимодействиясистемы с действующими лицами (actors) или ролями, дающий в итоге значимый для нихрезультат. Действующими лицами могут быть не только люди, но и другие системы,взаимодействующие с рассматриваемой. Вариант использования определяет основной ходсобытий, развивающийся в нормальной ситуации, а также может включать несколькоальтернативных сценариев, которые начинают работать только при специфическихусловиях.38Запросызаинтересованных лицКонцепцияСписок рисковБизнес планСловарьПлан разработкиПОПланразвертыванияМодель вариантовиспользованияОписаниеархитектуры ПОДополнительныетребованияМодельпроектированияМодель анализаПлантестированияМодельреализацииПроцессразработкиРисунок 11.
Основные артефакты проекта по RUP и потоки данных между ними.Модель вариантов использования служит основой для проектирования и оценки готовностисистемы к внедрению.Примером варианта использования может служить сценарий действий клиента Интернетмагазина по отношению к сайту этого магазина, в результате которых клиент заказываеттовар, например, книги. Такой вариант использования можно назвать «Заказ товара». Еслинас интересует сайт магазина только как программная система, результатом можно считатьто, что запись о сделанном заказе занесена в базу данных, а оператору заказов отправленоэлектронное письмо, содержащее всю информацию, которая необходима для того, чтобыможно было сформировать заказ.
В нее входит контактная информация покупателя,идентификатор заказа и, например, список заказанных книг с их ISBN, их количество длякаждого наименования и номера партий для удобства их поиска на складе. При этомвыполнение остальной части варианта использования — это дело других составляющихсистемы под названием «Интернет-магазин». Эта работа может включать звонок илиписьмо клиенту и подтверждение, что именно он сделал заказ, вопрос об удобных для негоформе, времени и адресе доставки и форме оплаты, формирование заказа, передача его длядоставки курьеру, доставка и подтверждение получения заказа и оплаты.
В нашем примередействующими лицами являются клиент, делающий заказ, и оператор заказов.Альтернативные сценарии в рамках данного варианта могут выполняться, если, например,заказанного пользователем товара нет на складе или сам пользователь находится на плохомсчету в магазине из-за неоплаченных прежних заказов, или, наоборот, он являетсяпривилегированным клиентом или представителем крупной организации.39Заказ товараКлиентОператорзаказовРисунок 12. Пример варианта использования и действующих лиц.•Модель анализа (Analysis Model).Она включает основные классы, необходимые для реализации выделенных вариантовиспользования, а также возможные связи между классами.
Выделяемые классыразбиваются на три разновидности — интерфейсные, управляющие и классы данных. Этиклассы представляют собой набор сущностей, в терминах которых работа системы должнапредставляться пользователям. Они являются понятиями, с помощью которых достаточноудобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь вдетали.Интерфейсные классы (boundary classes) соответствуют устройствам или способамобмена данными между системой и ее окружением, в том числе пользователями.
Классыданных (entity classes) соответствуют наборам данных, описывающих некоторыеоднотипные сущности внутри системы. Эти сущности являются абстракциямипредставлений пользователей о данных, с которыми работает система. Управляющиеклассы (control classes) соответствуют алгоритмам, реализующим какие-то значимыепреобразования данных в системе и управляющим обменом данными с ее окружением врамках вариантов использования.В нашем примере с Интернет-магазином можно было бы выделить следующие классы вмодели анализа: интерфейсный класс, предоставляющий информацию о товаре ивозможность сделать заказ; интерфейсный класс, представляющий сообщение оператору;управляющий класс, обрабатывающий введенную пользователем информацию ипреобразующий ее в данные о заказе и сообщение оператору; класс данных о заказе.Соответствующая модель приведена на Рис.
13.Каждый класс может играть несколько ролей в реализации одного или несколькихвариантов использования. Каждая роль определяет его обязанности и свойства, тожеявляющиеся частью модели анализа.В рамках других подходов модель анализа часто называется концептуальной модельюсистемы. Она состоит из набора классов, совместно реализующих все вариантыиспользования и служащих основой для понимания работы системы и объяснения ееправил всем заинтересованным лицам.КлиентИнтерфейсзаказа товараОбработчикзаказаИнтерфейс сообщенийОператороператорузаказовДанные заказаРисунок 13. Пример модели анализа для одного варианта использования.•Модель проектирования (Design Model).Модель проектирования является детализацией и специализацией модели анализа. Онатакже состоит из классов, но более четко определенных, с более точным и детальнымраспределением обязанностей, чем классы модели анализа.
Классы модели проектированиядолжны быть специализированы для конкретной используемой платформы. Каждая такая40•••платформа может включать операционные системы всех вовлеченных машин;используемые языки программирования; интерфейсы и классы конкретных компонентныхсред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использованиясистем управления базами данных, СУБД, например, Oracle или MS SQL Server;используемые библиотеки разработки пользовательского интерфейса, такие как swing илиswt в Java, MFC или gtk; интерфейсы взаимодействующих систем и пр.В нашем примере, прежде всего, необходимо детализировать классы, уточнить ихфункциональность. Скажем, для того, чтобы клиенту было удобнее делать заказ, нужнопредоставить ему список имеющихся товаров, какие-то способы навигации и поиска в этомсписке, а также детальную информацию о товаре. Это значит, что интерфейс заказа товарареализуется в виде набора классов, представляющих, например, различные страницы сайтамагазина.
Точно так же данные заказа должны быть детализированы в виде несколькихтаблиц в СУБД, включающих, как правило, данные самого заказа (дату, ссылку на данныеклиента, строки с количеством отдельных товаров и ссылками на товары), данные товаров,клиента и пр. Кроме того, для реляционной СУБД понадобятся классы-посредники междуее таблицами и объектной структурой остальной программы. Обработчик заказа можетбыть реализован в виде набора объектов нескольких классов, например, с выделеннымотдельно набором часто изменяемых политик (скидки на определенные категории товарови определенным категориям клиентов, сезонные скидки, рекламные комплекты и пр.) иболее постоянным общим алгоритм обработки.Далее, приняв, например, решение реализовывать систему с помощью технологий J2EE или.NET, мы тем самым определяем дополнительные ограничения на структуру классов, да ина само их количество.
О правилах построения ПО на основе этих технологийрассказывается в следующих лекциях.Модель реализации (Implementation Model).Под моделью реализации в рамках RUP и UML понимают набор компонентоврезультирующей системы и связей между ними. Под компонентом здесь имеется в видукомпонент сборки — минимальный по размерам кусок кода системы, который можетучаствовать или не участвовать в определенной ее конфигурации, единица сборки иконфигурационного управления. Связи между компонентами представляют собойзависимости между ними. Если компонент зависит от другого компонента, он не можетбыть поставлен отдельно от него.Часто компоненты представляют собой отдельные файлы с исходным кодом. Далее мыпознакомимся с компонентами J2EE, состоящими из нескольких файлов.Модель развертывания (Deployment Model).Модель развертывания представляет собой набор узлов системы, являющихся физическиотдельными устройствами, которые способны обрабатывать информацию — серверами,рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними,образованными различного рода сетевыми соединениями.