Системный Анализ. Предметная область. Модели на 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.