Проектирование и разработка модуля «Учет работы ресторана » средствами 1С: предприятие 8.2

 

Негосударственное образовательное учреждение

Высшего профессионального  образования

«Русско-Британский Институт Управления»

(НОУВПО РБИУ)

Высшая школа менеджмента

Кафедра математики и информатики

 

 

КУРСОВАЯ РАБОТА

«Проектирование И РАЗРАБОТКА МОДУЛЯ «Учет работы РЕСТОРАНА» СРЕДСТВАМИ 1С: ПРЕДПРИЯТИЕ 8.2»

по дисциплине «Профессиональное  программирование бизнес-приложений»  Специальность 080800.62 Прикладная информатика

 

 

 

Руководитель проекта:

К.п.н., доцент кафедры математики и информатики

Ивинская Надежда Леонидовна

Выполнил:

Студент группы ПИ-413

Мирошников Артём Юрьевич

 

 

 

Челябинск 2012 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ 3

1. МЕТОДЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ……..5

2. Проектирование информационной системы «учет РАБОТЫ ресторана»………………………………………………………...18

2.1 Анализ программных продуктов…………………………………………...18

2.2 Описание IDEF0 диаграммы………………………………………………21

2.3 Описание  DFD диаграммы……………………………………………….25

2.4. Описание IDEF3 диаграммы……………………………………………..27

3.  ПРОЕКТИРОВНИЕ И РАЗРАБОТКА МОДУЛЯ……………………….28

3.1  Проектирование предметной области……………………………………28

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

3.3  Проектирование объектов конфигурации и их описание……………...37

ЗАКЛЮЧЕНИЕ………………………………………………………………...38

БИБЛИОГРАФИЧЕСКИЙ СПИСОК…………………………………….…..39

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ВВЕДЕНИЕ

Для грамотного предоставления определенной услуги или производства высококачественного продукта, управляющие крупных компаний зачастую используют совокупность взаимосвязанных задач или мероприятий, называемых бизнес – процессами. Для большей наглядности бизнес – процессы моделируют в соответствии с различными методологиями моделирования. Такими методологиями являются IDEF0, IDEF3 и DFD.

Графическая нотация IDEF0 позволяет формализовывать и описывать бизнес – процессы. Важной особенностью методологии моделирования IDEF0 является соподчиненность объектов и логическое отношение между работами.

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

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

Для функционального моделирования  моделей данных используют программные  продукты в области реализации средств  CASE – технологий. Нередко эту роль выполняет программный продукт CA AllFusion Process Modeler (ранее BPwin). Он занимает одно из лидирующих мест в своем сегменте рынка.

Цель курсовой работы:

Формализация и описание бизнес – процесса «Кредитование» с использованием методологии функционального  моделирования и графической  нотации IDEF0, диаграмм потоков данных DFD и стандарта документирования процессов IDEF3, посредством программного продукта Computer Associates AllFusion Process Modeler r7.3.

Задачи разработчика:

1. Анализ программных продуктов;
2. Изучение методов и средств проектирования бизнес – процессов и информационных систем;
3. Изучение порядка бизнес – процесса «Кредитование»;
4. Функциональное моделирование контекстной диаграммы и диаграмм декомпозиций бизнес – процесса «Кредитование»;
5. Проектирование информационной системы с использованием диаграмм потоков данных (DFD);
6. Использование методологии моделирования и стандарта документирования процессов IDEF3.

 

1. МЕТОДЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Бизнес-процесс - это логичный, последовательный, взаимосвязанный  набор мероприятий, который потребляет ресурсы, создаёт ценность и выдаёт результат. В международном стандарте ISO 9000:2000 принят термин "процесс", однако в настоящее время эти  термины можно считать синонимами.

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

Описание бизнес-процессов  проводится с целью их дальнейшего  анализа и реорганизации. Целью  реорганизации может быть внедрение  информационной системы, сокращение затрат, повышение качества обслуживания клиентов, создание должностных и рабочих  инструкций и т.п., а детальное  описание процессов само по себе не представляет ценности. Реинжиниринг бизнес-процессов (англ. Business process reengineering) - это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимальной эффективности производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Бизнес-инжиниринг состоит из моделирования бизнес-процессов (разработка модели "как есть", её анализ, разработка модели "как надо") и разработки и реализации плана перехода к состоянию "как надо".

Основу многих современных  методологий моделирования бизнес-процессов  составили методология SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam - это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

• Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов - стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.
• Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.
• Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.
• Прочие методологии.  [1].

Метод функционального моделирования  IDEF(Function Modeling) – совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой – либо предметной области. Функциональная модель объекта отображает производимые им действия и связи между ними.

В соответствии с этим методом  бизнес – модель должна выглядеть  следующим образом:

1. Верхний уровень модели должен отражать только контекст системы, то есть её взаимодействие с внешним миром.
2. На втором уровне модели должны находиться все основные виды деятельности предприятия, другими словами тематически сгруппированные бизнес – процессы предприятия и их взаимосвязь.
3. Дальнейшая детализация бизнес – процессов осуществляется посредством бизнес – функций, то есть совокупностей операций, сгруппированных по определенным признакам.
4. Описание элементарной бизнес – операций осуществляется с помощью задания алгоритма ее выполнения.

Принципы ограничения  сложности IDEF0-диаграмм

Обычно IDEF0-модели несут в  себе сложную и концентрированную  информацию, и для того, чтобы  ограничить их перегруженность и  сделать удобочитаемыми, в соответствующем  стандарте приняты соответствующие  ограничения сложности[2]:

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

 

Типы связей между функциональными  блоками в модели IDEF0

Различают связи 7 типов:

1. Тип случайной связности: наименее желательный – Случайная связность возникает, когда конкретная связь между модулями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на IDEF0-дугах в одной диаграмме имеют малую связь друг с другом.
2. Тип логической связности – Логическое увязывание происходит тогда, когда данные и функции собираются вместе благодаря тому, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается. Временная связь представляет функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно;
3. Тип временной связности – Связанные по времени элементы возникают благодаря тому, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
4. Тип процедурной связности – Процедурно-связанные элементы появляются сгруппированными вместе благодаря тому, что они выполняются в течение одной и той же части цикла или процесса. Общий элемент процесса может быть итерационным или ветвью, зависящей от принятого решения, или линейной последовательностью этапов.
5. Тип коммуникационной связности – Диаграммы демонстрируют коммуникационные связи, когда блоки группируются благодаря тому, что они используют одни и те же входные данные и/или производят одни и те же выходные данные. Это первый тип связи, обсуждаемый далее, который представляет предпочтительный уровень связи для IDEF0. Важным доводом является то, что ни один из уровней связности, обсуждавшихся выше, не привязан достаточно тесно к конкретной проблеме. Коммуникационная связность является самым нижним уровнем, на котором мы встречаем связи между функционирующими элементами, являющимися по своей сути проблемно-зависимыми.
6. Тип последовательной связности – На диаграммах, имеющих последовательные связи, выход из одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости. Следовательно, это высокая степень связности.
7. Тип функциональной связности - Диаграмма отражает полную функциональную связность, когда все элементы функции влияют на выполнение одной единственной функции или результата. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности.

Основные блоки для диаграмм IDEF0 приведены в Таблице 1:

Таблица 1

Основные «строительные  блоки» для диаграмм IDEF0

№	Наименование	Описание элемента IDEF0 диаграммы	Графическое представление
1	Модуль поведения (UOB)	Объект служит для описания функций (процедур, работ), выполняемых  подразделениями/сотрудниками предприятия.
2	Стрелка слева	Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции.
3	Стрелка справа	Стрелка описывает исходящие  документы, информацию, материальные ресурсы, являющиеся результатом выполнения функции.
4	Стрелка сверху	Стрелка описывает управляющее  воздействия, например распоряжение, нормативный  документ и т.д. В нотации IDEF0 каждая процедура должна обязательно иметь  не менее одной стрелки сверху, отражающей управляющее воздействие.
5	Стрелка снизу	Стрелка снизу описывает  т.н. механизмы, т.е. ресурсы, необходимые  для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.
6	Стрелка вниз	Стрелка вниз изображает связь между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.

 

Метод моделирования потоков  данных DFD. 

DFD (Data Flow Diagramming) - это стандарт моделирования, в котором система представляется в виде сети работ, соединенных между собой объектами, взаимодействующими с результатами данных работ. Сфера применения DFD находится в области моделирования информационных потоков организации. В этой нотации моделируется не последовательность работ, а именно потоки информации (данных) между работами и объектами, которые используют, хранят или "рождают" эти данные.

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