V Международная студенческая научная конференция Студенческий научный форум - 2013

В статье кратко изложен результаты курсового проекта по дисциплине «Проектирование ИС» (МТУСИ, ФИ, 4 курс, научн.рук. проф.Воронова Л.И.) связанного с разработкой модели TO-BE для ИС ООО «Ресторан «Элиста»

Ресторанный бизнес - важный субъект рыночной инфраструктуры, поэтому разработка ИС для предприятий малого бизнеса является актуальной задачей.

Целью курсовой работы являлось проектирование ИС ООО «Ресторан «Элиста» с дальнейшей интеграцией с разработанной для компании базой данных. Стадии и этапы создания ИС должны соответствовать ГОСТ 34.601-90.

Основной задачей ИС является удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. При формировании требований к ИС производится обследование объекта и обоснование необходимости создания ИС. Также разрабатываются концепции ИС, техническое задание и документация. Информационная модель проектируется в двух видах «как есть» и «как должно быть». В работе курсовой работе проведён системный анализ предметной области, краткий обзор информационных систем, изложены основные принципы проектирования информационных систем, моделирование моделей «как есть» и «как должно быть», разработана инфологическая модель предметной области и осуществлен переход к реляционной модели базы данных, разработан пакет сопровождающих моделирование документов. Программная реализация выходит за рамки данного проекта.[1]

Проектирование информационной системы для ООО «Ресторан«Элиста»

Разработка модели TO-BE

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

Руководствуясь этими знаниями разработаем модель "TO-BE", используя процессный подход с помощью средства BPWin.[2]

1. Создание модели в стандарте IDEF0

IDEF0 - Function Modeling - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow).

Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило - наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны : — стрелка входа приходит всегда в левую кромку активности, — стрелка управления — в верхнюю кромку, — стрелка механизма — нижняя кромка, — стрелка выхода — правая кромка.

Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку. [3][4]

Разработаем диаграммы в методологии моделирования IDEF0. Контекстная диаграмма (рис.1.) содержит общее описание системы. Компания получает заявку клиента, и сотрудники, руководствуясь правилами, выполняет заказ.

Рис. 1 Контекстная диаграмма Рис. 2 Диаграмма декомпозиции

«Деятельность компании» IDEF0 «Деятельность компании» IDEF0

Создадим диаграмму декомпозиции диаграммы «Деятельность компании» в методологии IDEF0 (рис.2). В компании ведется деятельность основная и деятельность поддерживающая. Основная деятельность работает с заявками клиентов, поддерживающая деятельность работает с заявками сотрудников основного штаба, получая от них заявку, устраняет проблему, например, с техническим обеспечением.

Поступление заказа может быть двух видов: заказ на банкет и простой заказ (в режиме повседневной работы). При заказе на банкет заключается договор об оплате, происходит организация банкета и полная отчетность о банкете. При простом заказе происходит обслуживание клиента и ежедневная отчетность. Создадим диаграмму декомпозиции Деятельность основная» в методологии IDEF0(рис.3).

Рис. 3 Диаграмма декомпозиции «Деятельность основная» IDEF0.

2. Создание модели в стандарте DFD

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML.

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

Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием). Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.[3][4]

При заказе банкета происходит проверка: свободен ли ресторан в запрашиваемую клиентом дату и вместит ли он необходимое количество человек. Если она прошла успешно, происходит внесение заказа. Вносится информация о клиенте, дата банкета и количество человек. На выходе мы получаем информацию о банкете и договор об оплате. Здесь целесообразно использовать стандарт DFD.

На основании выходных данных с Внесения заказа (рис.4) формируется Договор об оплате(рис.5). Он состоит из суммы к оплате, процента предоплаты, даты предоплаты и контактной информации о клиенте.

Рис. 4 Диаграмма декомпозиции Рис. 5 Диаграмма декомпозиции «Договор

«Заказ банкета» DFD об оплате» DFD

Организация банкета происходит следующим образом: сначала согласуются все детали с клиентом, затем зал оформляется для банкета и закрывается для других посетителей. Также производится расчет и закупка необходимых продуктов и напитков и приготовление блюд. С началом банкета происходит обслуживание гостей и после банкета уборка зала. Здесь снова используем стандарт IDEF0 (рис.6).

Рис. 6 Диаграмма декомпозиции «Организация банкета» IDEF0.

3. Создание модели в стандарте IDEF3.

IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. Система описывается как упорядоченная последовательность событий с одновременным описанием объектов, имеющих отношение к моделируемому процессу.

IDEF3 состоит из двух методов: Process Flow Description (PFD) — Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса; Object State Transition Description (OSTD) — описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Основу методологии IDEF3 составляет графический язык описания процессов. Модель в нотации IDEF3 может содержать два типа диаграмм: диаграмму Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) и диаграмму Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN). [3][4]

Рис. 7 Диаграмма декомпозиции «Согласование с клиентом»IDEF3.

При согласовании заказа на банкет с клиентом необходимо выяснить дату банкета, количество человек. Клиент также должен выбрать из меню блюда для банкета. Он может потребовать особенного оформления зала или еще какие-либо дополнительные требования. После того, как все согласовано, заключается договор об оплате. Используем при этом стандарт IDEF3(рис.7).

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

Рис. 8 Диаграмма декомпозиции «Работа в повседневном режиме» IDEF0.

При поступлении клиента его необходимо встретить, проводить до столика и дать время сделать заказ, принять заказ и передать его на приготовление(рис.9).

Рис. 9 Диаграмма декомпозиции «Обслуживание клиента»IDEF3.

Для приготовления заказа в повседневном режиме необходимо заранее рассчитать и закупить нужное количество продуктов и напитков для меню, сделать заготовки блюд, если это возможно. И непосредственно при получении заказа на кухню или бармену приготовить его. Отразим это на диаграмме декомпозиции в стандарте IDEF0(рис.10).

Рис. 10 Диаграмма декомпозиции «Приготовление заказа» IDEF0.

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

Рис. 11 Диаграмма декомпозиции «Расчет клиента»IDEF3.

В основную деятельность компании входит сбор документов о банкетах и документов о ежедневной работе. Для документов о банкетах берется информация о банкете из внесения заказа. На основе этих документов строится БД банкетов. А на основе ежедневной отчетности стоится БД заказов, так же в документы ежедневной работы входит информация из БД сотрудников и состояний меню (рис.12).

Рис. 12 Диаграмма декомпозиции «Сбор документов» DFD.

Перейдем к проектированию поддерживающей деятельности. Сотрудники обеспечивающего штаба получают заявки от сотрудников основного штаба и устраняют проблемы. Для декомпозиции воспользуемся стандартом IDEF0 (рис.13), а на рис 14 приведен список полученных диаграмм.

Рис. 13 Диаграмма декомпозиции Рис. 14. Список диаграмм

«Деятельность поддерживающая»

Таким образом, для при проектировании ИС разработана модель "TO-BE" с помощью средств BPWin. При разработке в BPWin диаграммы были построены согласно всем трем стандартам(IDEF0, IDEF3, DFD) и были продекомпозированы до четвертого уровня. В результате получено 7 диаграмм декомпозиций в стандарте IDEF0, 3 в стандарте IDEF3 и 3 в стандарте DFD.

Список источников и литературы.

1. Курс лекций по дисциплине «Проектирование Информационных Систем».

2. Федотова Д., Семенов Ю., Чижик К., «CASE-технологии. Практикум», 2005 г

3. Сайт «Википедия» http://ru.wikipedia.org.

4. Описание продукта AllFusion Process Modeler7 (BPwin), сайт «Internet and software company» http://www.interface.ru

5. Вендров А.М. «CASE-технологии: Современные методы и средства проектирования информационных систем», 1998.

Код для цитирования: Скопировать