Файл: Основы проектирования программ. Этапы создания программного обеспечения (Создание начальной диаграммы прецедентов).pdf

В настоящее время экономика в России предполагает, что фирмы и организации вынуждены постоянно эволюционировать, чтобы не остаться за бортом прогресса и бизнеса. Насыщение абсолютно всех рынков товарами в такой мере, что компаниям приходится буквально биться за покупателей, приводит к пониманию исключительной роли совершенствования организации коммерческой деятельности предприятий. Продукция или услуга, произведенная фирмой, должна быть оптимальным образом продана: то есть, с учетом всех предпочтений и пожеланий клиентов, и с получением наибольшей выгоды. Поэтому главная задача любого предпринимателя – идеальным образом совместить желания клиентов и собственные возможности. Именно поэтому система логистического обеспечения является центральной в организации коммерческой деятельности на предприятии.

Целью данного курсового проекта является разработка технического проекта информационной системы транспортной логистики фирмы ООО "AZ", которая позволит организовать на более качественном уровне хранение, учет, нахождение и отображение запрашиваемой информации.

Среди основных требований, которые предъявляются к системе можно выделить

удобный интерфейс;
простоту управления данными;
просмотр данных на различных этапах формирования результата;
просмотр и печать выходной информации.

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

Приложение должно обеспечивать заполнение справочников сотрудников, машин, топлива, путевых листов.

В программе необходимо обеспечить следующие виды поиска:

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

Выходная информация, формируемая в результате работы программы, должна быть представлена в следующих формах:

отчёт по расходу топлива - выводится полная информация о расходах бензина за определённый месяц
отчёт по пробегам - выводится информация о количестве отработанных дней и средний пробег за конкретный месяц

ГЛАВА 1. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1. Описание существующих процессов

На начальных этапах создания ИС необходимо понять как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Модель должна быть адекватна предметной области. Для моделирования бизнес процессов предприятия воспользуемся IDEF0 технологией и будем при этом использовать в качестве инcтрументального средства BpWin.

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

Компания “AZ” в настоящее время является эксклюзивным дистрибьютором продукции компании GP Batteries, «премьер-дистрибьютором» светотехнической продукции компании General Electric, дистрибьютором продукции компании Duracell и владельцем торговой марки СТАРТ. ООО "AZ" обеспечивает собственные перевозки грузов автомобильным транспортном. Фирма обладает собственным автомобильным транспортом, а так же необходимой обслуживающей инфраструктурой и персоналом. Контекстная диаграмма деятельности транспортной службы предприятия приведена на рис.1.

Основными входными потоками в системе транспортной логистики предприятия являются:

- поток заявок на доставку и перевозку грузов;

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

- поток фактической информации о пробеге и состоянии транспортных средств предприятия;

- поток учетных данных сотрудников компании и транспортных средств компании.

Рис.1. Контекстная диаграмма

В качестве выходных поток необходимо указать следующие

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

- поток отчетов о движении транспорта и выполненных заявках, сформированный по полученной заявке;

- поток учетных данных о движении транспортных средств и расходах топлива.

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

- заместитель директора компании по логистике;

- начальник отдела логистики;

- логистик предприятия;

- бухгалтер предприятия.

В своей деятельности пользователи системы руководствуются должностными инструкциями и законами Российской Федерации.

Детализация контекстной диаграмме представлена на рис.2.

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

- регистрация и обработка заявок на доставку грузов;

- регистрация заявок и формирование отчетов о движении транспортных средств и выполнении заявок;

- регистрация и обработка потока учетных данных и фактического пробега.

Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. Работы нижнего уровня те же, что и работы верхнего уровня, но в более детальном изложении.

Рис.2. Деятельность компании

Рис.3. Декомпозиция работы регистрация и обработка заявок на доставку грузов

Рис.4. Декомпозиция работы регистрация заявок и формирование отчетов о движении транспортных средств и выполнении заявок

Рис.5. Декомпозиция работы регистрация и обработка потока учетных данных и фактического пробега

Диаграмма дерева узлов показывает иерархию работ модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Это обзорная диаграмма, показывающая структуру всей модели. Обычно вершина соответствует контекстному блоку.

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

Рис.6. Диаграмма дерева узлов

1.2. Определение функционального назначения системы

Пользователи системы

Пользователи системы по имеющимся у них обязанностям, делятся на следующие категории:

- заместитель директора компании по логистике;

- начальник отдела логистики;

- логистик предприятия;

- бухгалтер предприятия.

ГЛАВА 2 ПРАКТИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

2.1 Создание начальной диаграммы прецедентов

Диаграммы прецедентов использования (use case) описывают функциональность ИС, видимую пользователями системы. Имеет высокий уровень абстракции и позволяет определить функциональные требования к системе. Т.е. поведение системы с точки зрения пользователя.

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

На основе изучения бизнес процессов предприятия были созданы следующие диаграммы

Рис.7. Диаграмма прецедентов использования для всех категорий пользователей

Уточним диаграммы прецедентов для каждой категории пользователей.

Рис.8. Диаграмма прецедентов для управления движением транспортных средств (логистик компании)

Рис.9. Диаграмма прецедентов для подсистемы формирования отчетов (Начальник отдела логистики)

Диаграммы прецедентов или вариантов использования являются необходимым средством на стадии формирования требований у программному обеспечению. Каждый вариант использования – это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.

2.2. Создание диаграмм активности

Диаграммы прецедентов не показывают динамику системы. Для отражения порядка выполнения различных прецедентов создадим диаграммы активности.

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

Рис.10. Диаграмма активности обработки заявок на доставку грузов

Рис.11. Диаграмма активности обработки заказов на выдачу информационных отчетов

На основе анализа диаграмм прецедентов были выделены следующие объекты :

В результате анализа предметной области была спроектирована база данных, содержащая следующие таблицы:

Машины (Код, Марка, Шифр, Государственный №, Код бензина, Код перевозки, Расход_норма, Тариф)
Топливо (Код бензина, Марка бензина)
Перевозки (Код перевозки, Наименование перевозки )
Путевые листы (Номер путевого листа, КодКлиента, Код, Табельный №, Дата выезда, Время выезда, Дата возврата, Время возврата, Спидометр (выезд), Спидометр (возврат), Получено_талоны, Получено_кредит, Остаток_выезд, Остаток_возврат)
Клиенты (Код клиента, Название )
Сотрудники (Табельный №, Фамилия, Имя, Отчество)

Схема связи таблиц приведена на рисунке 1.

ГЛАВА 3. ПРОЕКТИРОВАНИЕ ИС

3.1. Проектирование базы данных

Проектирование БД начинается с построения логической модели. Различают 3 подуровня логического уровня модели данных, отличающиеся по глубине представления информации о данных:

диаграмма сущность-связь (Entity Relationship Diagram (ERD);
модель данных, основанная на ключах (Key Based model (KB);
полная атрибутивная модель (Fully Attributed model (FA).

Диаграмма сущность-связь включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС.

Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области

Рис.12. Диаграмма сущность - связь

Полная атрибутивная модель - наиболее детальное представление структуры данных и включает все сущности, атрибуты и связи.

Ниже приводится полная атрибутивная модель

Рис.13. Полная атрибутивная модель

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

Физическая модель данных приведена ниже.

Рис.14. Физическая модель

Физическая модель представляет реляционную базу данных в 4-й нормальной форме, так как она соответствует требованиям 3-й нормальной формы и в ней отсутствуют многозначные связи, или связи многие ко многим.

3.2. Диаграммы состояний

Диаграммы состояний определяют все возможные состояния, в которых может находится конкретный объект, а также процесс смены состояний объекта в результате наступления некоторого события.