2.4 Анализ требований к программным и информационным компонентам системы
Рассмотрев предполагаемую архитектуру разрабатываемой информационной системы, кратко проанализируем способы реализации данной архитектуры на базе имеющегося аппаратного и программного обеспечения. Как было сказано ранее, сама система будет размещена на одном ПК, которому будет присвоен статус сервера. Подсистемы можно будет выполнить в виде отдельных программных модулей с прикрепленными объектами данных (базами данных, электронными архивами и т.д.). В процессе работы между подсистемами необходима связь для работы друг с другом.
Другим важным аспектом является организация удобного и наглядного интерфейса. Это требование может быть выполнено с использованием форм языков программирования 1с конфигуратор. В этом случае при подключении к системе пользователь аутентифицируется и подключится к главной форме, которая позволяет ему запустить разрешенные подсистемы.
После запуска требуемой подсистемы, появляется ее форма с необходимыми элементами управления. Также можно организовать переход по формам типа «возврат в предыдущее меню». Управление формами будет осуществляться с применением кнопок и привязанными к ним командами, что также не вызовет особых затруднений.
2.5 Предложения по оргштатной структуре для поддержки системы
Разрабатываемая информационная система представляет собой малый программно-аппаратный комплекс, размещенный в одном автосервисе, в одной комнате. В связи с этим можно весь процесс обслуживания и поддержки системы, возложить на ее администратора, т.к. объем работ по настройке и текущей профилактике системы очень мал. А весь объём работы с регистрированием клиентов и заполнения заказов возложить на Работника автосервиса.
2.6 Ограничения в процессе разработки
В процессе проектирования рассматриваемой информационной системы необходимо учитывать следующие ограничения:
- вся информация, хранящаяся в информационной системе, должна быть защищена от доступа к ней в обход информационной системы
- общий объем памяти, занимаемый системой вместе с заполненными базами данных, не должен превышать 5Гб.
2.7 Потоки данных в системе
Построение потоков данных в информационной системе желательно начинать с создания и описания прецедентов. В самом общем случае прецедент – это некое законное действие выполненное системой, которое могло быть вызвано влиянием внешних пользователей (актеров), либо внутренними процессами. Прецедент является составным элементом, т.е. он обычно состоит из ряда элементарных действий. Даже если информационная система небольшая по объему, список прецедентов может быть достаточно большим. Для нашей информационной системы был составлен следующий список прецедентов:
- регистрация клиента;
- сохранение клиента в базе;
- выбор клиентом нужных ему работ;
- подсчёт общей суммы за выполненные работы;
- вывод чека;
Рассмотрим подробно прецедент регистрация клиента.
1. Главное действующее лицо – Работник автосервиса.
2. Действующие лица и их интересы:
Работник автосервиса – быстро, точно и качественно принять заявку, заинтересован в получении процента с количества принятых заявок.
Клиент – быстро сдать автомобиль в ремонт.
Работник (авто-слесарь) – быстро определить неполадку, заинтересован в получении процента с количества выполненных заявок.
Внешняя бухгалтерская программа – заинтересована в объемах продаж и отчислений.
3. Предусловия (начальные условия)
Данные должны быть заполнены
4. Постусловия (результаты)
Данные о заявке сохранены. Сведения отправлены.
5. Основной успешный сценарий:
а) клиент приходит в автосервис, обращается к Работнику автосервиса;
б) Работник автосервиса регистрирует клиента;
в) клиент выбирает из прайс-листа нужную ему услугу;
г) система выводит общую стоимость выбранных работ;
д) Работник оформляет заявку на ремонт, сохраняет, система передает информацию, печатает квитанцию;
е) клиент получает квитанцию, покидает автосервис.
Альтернативные сценарии:
невозможно сразу определить неполадку:
в) клиент не знает что у него сломалось в автомобиле ;
г) Работник оформляет заявку на диагностику, сохраняет, печатает квитанцию;
д) клиент получает квитанцию, покидает автосервис.
2) клиента не устраивает цена ремонта:
г) клиент отказывается от ремонта и покидает офис.
3) выход из заявки:
Для более наглядного представления прецедентов информационной системы можно воспользоваться диаграммами UML, которые позволяют достаточно четко представить прецеденты системы без использования громоздких описаний. Полученная диаграмма прецедентов показана на рисунке 2
Рисунок 2 – Диаграмма прецедентов
Как было описано выше, на данной диаграмме присутствуют два актера: менеджер и елиент .
Посмотрим диаграммы потоков данных(DFD), которые позволяют проследить:
- какие данные поступают в систему;
- какие данные она выдает во внешнюю информационную среду;
- какие процессы обработки данных происходят в системе.
Важным преимуществом DFD диаграмм является возможность их декомпозиции, т.е. разбиения на более мелкие составляющие с целью более глубокой детализации процессов обработки данных, происходящих в системе.
Рассмотрим контекстную DFD-диаграмму, где наша информационная система представлена в виде единого блока с входными и выходными данными (рисунок 3).
Рисунок 3 – Контекстная DFD-диаграмма информационной системы
Как видно из приведенной выше диаграммы, между внешними объектами системы и самой системой организованы потоки данных, цели которых составляют сущность работы системы. Для данной диаграммы можно выполнить декомпозицию.
Далее рассмотрим декомпозицию блока «регистрацию клиента» (рисунок 4). Приведенная на нем DFD-диаграмма демонстрирует процессы, происходящие внутри этого блока.
Рисунок 4 – Декомпозиция блока «регистрации клиентов»
Приведенная на рисунке 4 DFD-диаграмма демонстрирует процессы обработки данных при регистрацию клиентов. Для наглядности прецедента, описанного нами, рассмотрим также декомпозицию блока «оформление заказа» (рисунок 5).
Рисунок 6 – Декомпозиция блока «оформление заказа»