Проектирование информационной системы турагентства

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

Диаграмма потоков данных нулевого уровня (контекстная диаграмма) проектируемой ИС представлена на рис.1.

 

Рис.1. ДПД нулевого уровня для ИС турагентства

 

Внешние сущности, используемые в проектируемой ИС туристического агентства:

1. Платёжная система. Является посредником между клиентом и организацией в процессе движения денежных средств. Передаёт в систему информацию о поступивших платежах.
2. Менеджер по продажам. Взаимодействует с клиентом, осуществляет оформление заказа и уведомление клиента о его статусе. Осуществляет составление готовых туров на основе списка услуг поставщиков.
3. Менеджер по закупкам. Контактирует с представителями поставщика, оформляет заказы на туры, доставку и т.д.
4. Клиент. Физическое или юридическое лицо, осуществляющее заказ услуг организации.
5. Бухгалтерия. Осуществляет финансовую деятельность организации. Контактирует с платёжной системой для мониторинга прихода/расхода. Меняет статус заказа. Собирает отчётность.
6. Туроператор. Туристская организация, занимающаяся комплектацией туров.
7. Авиаперевозчик. Организация поставщик транспортных услуг.
8. Консультант. Консультирует клиента организации по интересующим его вопросам.

 

 

 

2.2Детальное проектирование

 

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

В ДПД первого уровня также  описывают хранилища данных.

Хранилище данных позволяет  на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое. В случае, когда поток данных входит в хранилище или выходит из него и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

На рис.2. представлена диаграмма  потоков данных первого уровня для  проектируемой ИС.

Рис.2. ДПД первого уровня для ИС турагентства

 

В проектируемой ИС используется 3 хранилища данных:

1. База данных запросов
2. БД готовых заказов
3. БД услуг поставщиков

 

1)База данных запросов  клиентов представляет собой  хранилище различных вопросов, жалоб и пожеланий клиентов предприятия.

 

Процесс обработки  запросов

Наименование поля	Тип	Длина
Идентификатор	Число	5
Имя	Текст	20
Фамилия	Текст	20
E-mail	Текст	20
Тема	Текст	20
Сообщение	Текст	500

 

2) База данных готовых  заказов содержит заказы, обработанные  менеджером по продажам на основе заказов клиентов.

 

Составление тура

Наименование поля	Тип	Длина
Идентификатор тура	Число	5
Направление	Текст	50
Туроператор	Текст	20
Авиаперевозчик	Текст	20
Цена	Число	8
Интервал дат	Дата	30

 

Обработка готового заказа

Наименование поля	Тип	Длина
Идентификатор заказа	Число	5
Имя клиента	Текст	20
Фамилия клиента	Текст	20
Отчество клиента	Текст	20
Серия паспорта	Число	4
Номер паспорта	Число	6
Количество человек	Число	3
Идентификатор тура	Число	5
Длительность	Число	4
Дата начала	Дата	8
Страховка	Логическое	True/False
Стоимость	Число	7

 

Обработка оплаченных счетов

Наименование поля	Тип	Длина
Идентификатор заказа	Число	5
Имя клиента	Текст	20
Количество человек	Число	4
Стоимость	Число	7
Оплачено	Логическое	True/False

 

3) База данных услуг  поставщиков содержит услуги  туроператора и авиаперевозчика.

 

Обработка услуг  авиаперевозчика

Наименование поля	Тип	Длина
Идентификатор поставщика	Число	5
Название поставщика	Текст	20
Направление перелёта	Текст	50
Дата	Дата	20
Цена	Число	8

 

 

Обработка услуг  туроператора

Наименование поля	Тип	Длина
Идентификатор поставщика	Число	5
Название поставщика	Текст	20
Направление	Текст	50
Интервал дат	Дата	20
Цена	Число	8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

• Прототипирование

 

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

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

Прототипы ПО бывают следующих  видов:

1. Статические прототипы - это некие рисунки, схемы, т.е. те прототипы, внесение изменений в которые потребуют полной или значительной перерисовки предыдущего варианта. К статическим прототипам можно отнести наброски на бумаге, маркерной доске, рисунки в графических программах.
2. Динамические прототипы - Они позволяют использовать часть функциональности, которую в дальнейшем будет реализовывать данный интерфейс: это может быть переход по ссылкам, ввод данных в поля и более сложные вещи. Динамические прототипы могут создаваться как вручную (например, html файлы), так и с помощью специальных программ.
3. Комплексные прототипы - прототипы с использованием серверов и баз данных, максимально приближенные к разрабатываемой системе, позволяют моделировать сложную динамику поведения систем.

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

Беглое прототипирование (rapid prototyping): методология проектирования, которая быстро разрабатывает новый дизайн, оценивает его, затем выбрасывает прототип, и следующий дизайн разрабатывается уже с новым прототипом.

Повторное использование  прототипов (reusable prototyping): также известно как «эволюционирующие прототипы»; усилия на разработку прототипа не пропадают после его оценки, поскольку части прототипа (или он целиком) могут быть использованы для построения самого продукта.

Модульное прототипирование (modular prototyping): также известно как «инкрементное прототипирование»; новые части добавляются по мере продвижения по циклу разработки и проектирования;

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

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

Затем выполняется быстрое  проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.

Быстрое проектирование приводит к построению прототипа.

Прототип оценивается заказчиком и используется для уточнения требований к ПО.

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

Достоинство прототипирования:

• обеспечивает определение полных требований к ПО.

Недостатки прототипирования:

• заказчик может принять прототип за продукт;
• разработчик может принять прототип за продукт.

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