Системный Анализ. Предметная область. Модели на UML. Михаил Кумсков
Читать онлайн книгу.классов «Блюдо» преобразуется по паттерну «Объект – список» – сравните с рис. 1.10
Паттерн «Объединение картотек»
Если на диаграмме классов встречаются ассоциации с такой множественностью, как:
• «один» к «одному» («1» – «1»),
• «один» к «ноль..одному» («1» – «0..1»),
• «ноль..один» к «ноль..одному» («0..1» – «0..1»), то соответствующие картотеки можно рассматривать как «кандидаты на объединение». В нашем примере такая связь есть на диаграмме «Заказ» между классом «Заказом» и классом «Оплатой заказа». Если мы объединяем эти картотеки, то:
• объединяются атрибуты картотек;
• новый класс (картотека) приобретает состояния.
Для диаграммы классов «Заказ» получаем следующую преобразованную диаграмму классов уже без связи с «Оплатой заказа» (рис. 1.17).
Рис. 1.17. Диаграмма классов «Заказ» после применения паттерна «Объединение картотек». У «заказа» появился новый атрибут «Дата-Время-Оплаты»
Состояния объединенной картотеки «Заказ» опишем UML-диаграммой «Машина состояний» (рис. 1.18).
Рис. 1.18. Диаграмма «Машина состояний UML для класса „Заказ“ после объединения с картотекой „Оплата заказа“»
Итоги раздела 1
Был рассмотрен пошаговый процесс построения модели предметной области в виде набора диаграмм классов в визуальной нотации UML. Были рассмотрены паттерны выявления бизнес-событий «Брак», «Инвентаризация» и «Прайс-лист».
После построения диаграмм классов было показано, как и когда применяются паттерны преобразования модели – паттерны «Объект – список» и «Объединение картотек».
Предлагается применить описанный выше процесс к другим задачам, постановка которых приведена в приложении 1: «Театральные кассы», «Автоматизация поликлиники», «Таксопарк», «Мастерские автообслуживания», «Информационные материалы», «Документы муниципалитета», «Риелторская контора», «Расчет зарплаты», «Регистрация студентов на курсы».
Раздел 2
Требования к системе
В этом разделе будет показано, как формировать функциональные требования к ИС, опираясь на модель предметной области. Изложение будет построено на основе понятия сценария использования, которое является базовым в методологии разработки программного обеспечения IBM RUP (IBM Rational Unified Process)6. В свое время это была одна из ведущих методологий, и если процессы разработки в организации ставились на основе RUP, то это обеспечивало прозрачность и управляемость проекта, т. е. позволяло создавать ИС в соответствии с требованиями заказчика на момент сдачи системы.
RUP определяет роли, задачи, артефакты и 9 процессов, применение которых помогает сделать разработку программного обеспечения предсказуемой. IBM RUP – это оформленная в виде web-сайта электронная энциклопедия «правильной» (Framework) разработки, которая описывает основные процессы создания ИС:
1. Моделирование бизнес процессов.
2. Управление требованиями.
3. Анализ и проектирование.
4. Реализация.
5.
6
Крачтен Ф. Введение в Rational Unified Process.: пер. с англ. М.: Вильямс, 2002. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: пер. с англ. СПб: Питер, 2002.