8.1.1. Использование silverrun-bpm
Для моделирования процессов предметной области целесообразно использовать CASE- средство SILVERRUN-BPM (Business Process Modeling).
Вначале необходимо сформулировать назначение разрабатываемого приложения БД. Цель должна быть сформулирована кратко без обширных пояснений и обоснования.
Затем должны быть определены основные функции приложения - что оно должно делать для достижения своей цели(своего назначения).
После этого необходимо проанализировать предметную область и проектирующие в ней процессы, предназначенные для реализации сформулированных функций приложения.
Рассмотрим следующий пример, с помощью которого будут рассмотрены основные фазы и этапы проектирования БД (для конкретного приложения).
Компания занимается реализацией комплектующих для персональных компьютеров. Назначение разрабатываемого приложения: помощь компании в заключении договоров с клиентами на покупку комплектующих. Название приложения DEALER.
Назначение приложения - система DEALER обслуживает процесс торговли.
Функции приложения:
система регистрирует и хранит сведения о покупателях;
система регистрирует и хранит полные сведения о комплектующих для ПК;
система генерирует договоры на продажу комплектующих.
8.1.2. Контекстная диаграмма
Анализ предметной области начинается с создания контекстной диаграммы с помощью CASE- средства SILVERRUN- BPM.
Основные элементы диаграмм CASE- средства SILVERRUN-BPM:
Внешние объекты
Процессы
Потоки информации
Накопители
На рис. 35 представлена контекстная диаграмма системы Dealer, содержащая внешние объекты «Менеджер» и «Покупатель», а также процесс «Торговля комплектующими», связанные между собой потоками.
Затем на основании контекстной диаграммы необходимо создать детализирующую диаграмму.
Рис.
35. Контекстная диаграмма системы Dealer
Детализирующая диаграмма
Детализирующая диаграмма представлена на рисунке 36.
Детализирующая диаграмма содержит накопители, внешние объекты, потоки данных.
Рис.
36. Детализирующая диаграмма системы
Dealer
Анализ информационных потоков показывает, что в модели должны быть три накопителя (рис.36):
накопитель CLIENT, в котором должны храниться сведения о покупателях
CLIENT NUM Идентификатор
CLIENT NAME Фамилия (название)
CLIENT ADDRESS Адрес
CLIENT DOLG Долг покупателя
накопитель COMPL для хранения информации об имеющихся комплектующих на складе
COMPL NUM Идентификатор
COMPL TYPE Тип
COMPL NAME Название
COMPL PARAM Параметры
COMPL PRICE Цена
COMPL QTY Количество на складе
накопитель DOGOV, в котором должна храниться информация о заключенных договорах с покупателями. При этом надо учитывать, что в каждом договоре должен быть указан перечень покупаемых комплектующих
DOGOV NUM Идентификатор договора
CLIENT NUM Идентификатор покупателя
DOGOV KIND Вид оплаты
DOGOV DATE Дата оплаты
DOGOV PROPL Предоплата (Сумма)
DOGOV SUM Сумма договора
CONTENT NUM Идентификатор перечня покупаемых комплектующих
COMPL NUM Идентификатор комплектующих
CONTENT QTY Количество покупаемых комплектующих
CONTENT SUM Себестоимость покупаемых комплектующих
Кроме того, с каждым накопителем необходимо связать структуру данных, которые будут в них храниться. На этом этапе следует определить все сущности и их атрибуты.
С накопителем CLIENT следует связать сущность CLIENT (табл. 23).
Таблица 23 Сущность CLIENT
CLIENT |
CLIENT NUM CLIENT NAME CLIENT ADDRESS CLIENT DOLG |
Кодированные имена атрибутов
CLNUM
CLNAME
CLADDRESS
CLDOLG
С накопителем COMPL необходимо связать сущность COMPL(табл. 23).
Таблица 23 Сущность COMPL
COMPL |
COMPL NUM COMPL TYPE COMPL NAME COMPL PARAM COMPL PRICE COMPL QTY |
Кодированные имена атрибутов
CMNUM
CMNAME
CMTYPE
CMPARAM
CMPRICE
СMQTY
С накопителем DOGOV следует связать две сущности – DOGOV и CONTENT (табл. 24), при этом сущность CONTENT необходимо сделать слабой, т. к. перечень приобретаемых комплектующих не может существовать без (наличия) договора. Поэтому в структуре данных DOGOV необходимо предусмотреть подструктуру CONTENT.
Таблица 24 Сущность DOGOV
После определения указанных выше объектов модели необходимо запустить на выполнение SILVERRUN-BPM и создать в нем концептуальную модель данных.