Формальные модели предметной области

1) ДПД

2) ER-модель

 

Описание, постановка задачи и разработка бизнес-правил.

Фирма «ЮГ-АВТО» занимается прокатом легковых автомобилей.

 

Процесс проката осуществляется следующим образом. Клиент производит заказ на прокат желаемого автомобиля, пользуясь каталогом легковых автомобилей, предоставляемым фирмой. Представитель фирмы проверяет доступность данного легкового автомобиля в указанные в заявке сроки, выписывает счёт на выбранную модель автомобиля и отправляет данные о клиенте для проверки в милицию. После оплаты по соответствующему счёту фирма «ЮГ-АВТО» подтверждает запрос о прокате автомобиля и обязуется предоставить автомобиль клиенту в указанные сроки.

При анализе бизнес-процесса фирмы полезно ответить на 6 вопросов: ЧТО, КАК, ГДЕ, КТО, КОГДА и ПОЧЕМУ.

 

При ответе на первый вопрос: «ЧТО лежит в основе бизнеса данной фирмы?», как правило, выявляются наиболее важные для данного бизнеса или производственного процесса компоненты. А именно:

· сотрудники;

· клиенты;

· каталог;

· автомобили;

· заказы;

· милиция.

При ответе на второй вопрос: «КАК это делается?» позволяют получить список основных бизнес-процессов, происходящих в фирме. А это следующие:

• составление каталога;
• рассылка каталога;
• анализ рынка;
• прокат;
• оформление счетов и накладных;
• управление работой персонала;
• реклама;
• решение бухгалтерских задач;
• взаимодействие с органами правопорядка.

 

Вопрос «ГДЕ происходят данные процессы?» больше относятся к проблемам телекоммуникаций и организации совместной работы персонала. Ведь в случае, например, большого объёма операций, которые выполняются вне территории фирмы торговыми агентами, придётся учитывать проблемы синхронизации данных. При наличии филиалов весьма непростой проблемой является оптимальный выбор системы распределения данных. Можно централизовать всю обработку данных, и филиалы будут выполнять свои операции, пользуясь возможностями телекоммуникаций. Работа с данными в этом случае упрощается, но каково будет удивление клиента, когда вы ему сообщите, что не можете ему сдать в прокат приглянувшуюся машину, так как оборвалась связь с центральным офисом. Поэтому в данной системе допустим, что все операции выполняются в пределах одного здания, а организация совместного использования данных основана на возможностях локальной сети и сервера БД.

 

Ответ на вопрос: «КТО выполняет эти процессы?» даст организационная структура фирмы. Упрощённая организационная структура фирмы «ЮГ-АВТО» представлена на рисунке:

 

 

Важно получить и ответ на вопрос: «КОГДА выполняется то или иное действие?».

Это прояснит периодичность осуществляемых бизнес-процессов и позволит правильно расставить акценты в будущей прикладной программе. В данной фирме это:

• обновление каталога- раз в год и внесение поправок в экстренных случаях;
• подведение итогов прокатов – ежемесячно;
• годовой отчёт – ежегодно к 20 февраля.

 

Последний вопрос: «ПОЧЕМУ эти действия выполняются?» позволяет определить мотивацию производственной деятельности фирмы. Бизнес- задачи фирмы «ЮГ-АВТО» определим так:

• достижение наилучшего соотношения «затраты – удобство» для клиентов;
• обеспечение условий для успешной деятельности персонала;
• получение приемлемой прибыли;
• повышение доходов при автоматизации обработки данных.

ОПИСАНИЕ ЗАДАЧИ.

Наименование задачи:

Автоматизация управления работой дилера по прокату легковых автомобилей

 

Цель работы дилера:

Прокат легковых автомобилей на заказ по каталогу.

Функции дилера:

• Заключение договоров на поставку автомобилей;
• Ведение каталога автомобилей, предлагаемых в прокат;
• Приём заказов у клиентов на прокат автомобилей;
• Работа с клиентами: реклама автомобилей, подготовка сведений о автомобилях, взятых в прокат, анализ прокатов, ведение справочника клиентов;
• Отправка сведений о клиентах в правоохранительные органы;
• Ведение расчётов за автомобили, сданные в прокат;
• Учёт валютного курса.

Бизнес – правила:

• Сведенья о клиентах хранятся 5 лет с момента последнего заказа;
• При отказе от поставленного автомобиля с клиента удерживается 9% суммы оплаты по счёту, данная величина должна регулироваться;
• просрочка предоставления автомобиля клиенту оплачивается фирмой «ЮГ-АВТО» из расчёта 0,2% в день от стоимости проката, данная величина может регулироваться;
• При сдаче автомобиля клиентом после указанных сроков с клиента удерживается штраф: 110% от суммы за прокат за день в день.
• При пропаже автомобиля и неявки клиента на клиента возбуждается уголовное дело по факту угона.
• вся ответственность за автомобиль во время его использования возлагается нВ клиента. И в случае аварии по вине клиента ремонт делается за счёт клиента.

Требования к программе:

Программа должна работать под управлением операционных систем MS Windows 95, MS Windows 98, MS Windows NT, MS Windows 2000, MS Windows XP.

Перечень вводимой информации:

адрес

дата

водительские права

запрос

количество

имя

марка машины

номер

номер и серия паспорта

номер кредитки

отчество

состояние

цвет

цена

фамилия

 

Перечень печатных отчётов:

· номенклатура предлагаемых к прокату автомобилей;

· список клиентов;

· анализ прокатов;

· список заказов;

· счёт на прокат.

Требования к оснащению офиса фирмы компьютерной теникой:

ПЭВМ со следующими характеристиками:

- процессор не ниже Pentium II 500МГц;

- объем ОЗУ не менее 128 Мб;

- НГМД 3,5 (1,44 Мб);

- НЖМД не менее 8 Гб;

- графический адаптер не хуже SVGA 8 Мб;

- монитор не хуже SVGA 0.26, 15 дюймов;

- сетевая плата, совместимая с Ethernet;

- манипулятор типа “мышь”;

- струйный или лазерный принтер формата А4.

Пользователи банков данных.

Как любой программно-организационно-технический комплекс, Банк Данных существует во времени и в пространстве. Он имеет определённые стадии своего развития:

1. Проектирование
2. Реализация
3. Эксплуатация
4. Модернизация и развитие
5. Полная реорганизация

На каждом этапе своего существования с банком данных связаны разные категории пользователей.

Основные категории пользователей и их роль в функционировании банка данных:

§ Конечные пользователи. Это основная категория пользователей, в интересах которых и создаётся банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи, обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты фирмы, рассматривающие каталог автомобилей, которые доступны для проката, с обобщённым или подробным описанием того или иного автомобиля. Регулярными пользователями могут быть сотрудники фирмы, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении их должностных обязанностей. Например, менеджер имеет в своём распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать поступление новых автомобилей для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств.

§ Администраторы банка данных. Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации.

§ Разработчики и администраторы приложений. Это группа пользователей, которая функционирует во время проектирования, создания и реорганизации банка данных. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединённых в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из базы данных, которая требуется для конкретного приложения.

Наиболее сложные обязанности возложены на группу администратора БД. В составе группы администратора БД должны быть:

o системные аналитики;

o проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;

o проектировщики технологических процессов обработки данных;

o системные и прикладные программисты;

o операторы и специалисты по техническому обслуживании..

Модель данных.

Общие положения

Ядром любой базы данных является модель данных. Модель данных представляет

собой множество структур данных, ограничений целостности и операций

манипулирования данными. С помощью модели данных могут быть представлены

объекты предметной области и взаимосвязи между ними.

Модель данных — совокупность структур данных и операций их обработки.

СУБД основывается на использовании иерархической, сетевой или реляционной

модели, на комбинации этих моделей или на некотором их подмножестве [I].

Рассмотрим три основных типа моделей данных: иерархическую, сетевую и

реляционную.

 

Иерархическая модель данных

 

Иерархическая структура представляет совокупность элементов, связанных

между собой по определенным правилам. Объекты, связанные иерархическими

отношениями, образуют ориентированный граф (перевернутое дерево).

К основным понятиям иерархической структуры относятся: уровень, элемент

(узел), связь. Узел — это совокупность атрибутов данных, описывающих

некоторый объект. На схеме иерархического дерева узлы представляются

вершинами графа. Каждый узел на более низком уровне связан только с одним

узлом, находящимся на более высоком уровне. Иерархическое дерево имеет

только одну вершину (корень дерева), не подчиненную никакой другой вершине

и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные)

узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в

базе данных определяется числом корневых записей.

К каждой записи базы данных существует только один (иерархический) путь

от корневой записи.

 

Сетевая модель данных

В сетевой структуре при тех же основных понятиях (уровень, узел, связь)

каждый элемент может быть связан с любым другим элементом.

 

 

Реляционная модель данных

 

Понятие реляционный (англ. relation — отношение) связано с разработками

известного американского специалиста в области систем баз данных Е. Кодда.

Эти модели характеризуются простотой структуры данных, удобным для

пользователя табличным представлением и возможностью использования

формального аппарата алгебры отношений и реляционного исчисления для

обработки данных.

Реляционная модель ориентирована на организацию данных в виде двумерных

таблиц. Каждая реляционная таблица представляет собой двумерный массив и

обладает следующими свойствами:

. каждый элемент таблицы — один элемент данных;

. все столбцы в таблице однородные, т.е. все элементы в столбце имеют

одинаковый тип (числовой, символьный и т.д.) и длину;

. каждый столбец имеет уникальное имя;

. одинаковые строки в таблице отсутствуют;

. порядок следования строк и столбцов может быть произвольным.

Отношения представлены в виде таблиц, строки которых соответствуют кортежам

или записям, а столбцы — атрибутам отношений, доменам, полям.

Поле, каждое значение которого однозначно определяет соответствующую

запись, называется простым ключом (ключевым полем). Если записи однозначно

определяются значениями нескольких полей, то такая таблица базы данных

имеет составной ключ.

Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы

ввести в состав ключа второй таблицы (возможно совпадение ключей); в

противном случае нужно ввести в структуру первой таблицы внешний ключ —

ключ второй таблицы.

 

Процесс проектирования.

Построение ДПД:

В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно. Источники
информации (внешние сущности) порождают информационные потоки (потоки данных),
переносящие информацию к подсистемам или процессам. Те в свою очередь
преобразуют информацию и порождают новые потоки, которые переносят информацию к
другим процессам или подсистемам, накопителям данных или внешним сущностям -
потребителям информации. Построение иерархии диаграмм потоков
данных Первым шагом при построении иерархии ДПД является построение
контекстных диаграмм. Обычно при проектировании относительно простых ИС строится
единственная контекстная диаграмма со звездообразной топологией, в центре
которой находится так называемый главный процесс, соединенный с приемниками и
источниками информации, посредством которых с системой взаимодействуют
пользователи и другие внешние системы. Если же для сложной системы
ограничиться единственной контекстной диаграммой, то она будет содержать слишком
большое количество источников и приемников информации, которые трудно
расположить на листе бумаги нормального формата, и кроме того, единственный
главный процесс не раскрывает структуры распределенной системы. Признаками
сложности (в смысле контекста) могут быть: распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.

 

Прокат автомобилей [1]
Сбор заявок [1.1]
Прием заявок [1.1.1]
Анализ заявок [1.1.2]
Сохранение заявок [1.1.3]
Сбор сведений о клиенте [1.2]
Прием информации о клиенте [1.2.1]
Анализ информации о клиенте [1.2.2]
Сохранение информации о клиенте [1.2.3]
Сбор сведений о наличии авто [1.3]
Запись сведений о наличии ВС [1.3.3]
Анализ сведений о наличии авто [1.3.2]
Прием сведений о наличии авто [1.3.1]
Запрос инфо [1.4]
проверка информации о клиенте [1.5]
подготовка сведений о клиенте [1.5.1]
проверка сведений о клиенте [1.5.2]
сохранение данных [1.5.3]
Передача машины клиенту [1.7]
приём машины [1.7.1]
Прием сведений [1.7.2]
Подготовка данных для передачи и передача [1.7.3]
регистрация машины на данного клиента [1.6]
Оформление заказа [1.6.3]
Подбор авто [1.6.1]
регистрация машины на клиента [1.6.2]

 

 

А) 1 уровень

 

В) 2 уровень

С) 3 уровень

1) Сбор заявок

2) Сбор сведений о клиенте

3) Сбор сведений о наличии авто

4) Проверка информации о клиенте

5) Регистрация автомобиля на данного клиента

6) Передача автомобиля клиенту