Размещено на http://allbest.ru

Размещено на http://allbest.ru

МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное Бюджетное образовательное учреждение высшего образования

«российский государственный аграрный университет -МСха имени К.А. Тимирязева»

Кафедра: «Вычислительная техника и прикладная математика»

КУРСОВОЙ ПРОЕКТ

По дисциплине: «Проектирование информационных систем в образовании»

На тему: «Проектирование информационных систем в микрофинансовой организации федерального уровня»

Выполнил студент 504 группы ГПФ:

Немцева Н.А.

Преподаватель: к.п.н., доцент Щедрина Е. В.

Москва, 2014



Оглавление

Введение

1. Предметная область: компания, занимающаяся микрофинансированием бизнеса

2. Case средства проектирования

3. Структурный подход

3.1 AllFusion Process Modeler BPWin

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

4. Объектно-ориентированный подход

4.1 EDraw Max 7.2

4.2 Организационная структура организации

4.3 Диаграмма иерархии пользователей

4.4 Диаграмма вариантов использования

4.5 Диаграмма последовательности

4.6 Диаграмма деятельности

4.7 Диаграмма классов

4.8 Диаграмма развертывания

5. Сравнение структурного и объектного подходов к проектированию информационных систем

Заключение

Список используемой литературы



Введение

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

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

· требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

· требуемую пропускную способность системы;

· требуемое время реакции системы на запрос;

· безотказную работу системы в требуемом режиме, иными словами -- готовность и доступность системы для обработки запросов пользователей;

· простоту эксплуатации и поддержки системы;

· необходимую безопасность.

В рамках курсовой работы, рассмотрены основные сведения об CASE средствах разработки и проектирования. Рассмотрены такие средства проектирования как AllFusion Process Modeler и Argo UML, их возможности для проектирования структурного, либо, объектно-ориентированного подходов.

В ходе выполнения работы разработанная ИС предоставлена как в структурном (IDEF) подходе, так и в объектном (UML), в последствии проведено сравнение этих двух подходов.



1. Предметная область: компания, занимающаяся микрофинансированием бизнеса

Микрофинансовая организация федерального уровня.

Основное направление деятельности компании - займы малому и среднему бизнесу. Главная миссия Компании - предоставить возможность любому предпринимателю, вне зависимости от размера и направления его бизнеса, получить доступ к быстрым финансовым ресурсам. Займы для ИП до 1 миллиона рублей предоставляются на срок до 24 месяцев. В отличие от банков, проводящих кредитование индивидуальных предпринимателей, срочный заем денег осуществляется всего за 1 день.

Для получения денег нужно заполнить заявку на получение займа или связаться с менеджером, который сам заполнит Вашу Заявку.

1. По электронной почте Вам отправляется анкета, которую нужно заполнить и распечатать.

2.Отсканированные копии документов (заполненную анкету и паспорт) Вы отправляете в нашу компанию по электронной почте.

3.Как только мы получим пакет документов, в течение 1 рабочего дня наш консультант свяжется с Вами и сообщит решение о предоставлении займа.

4.Финансовый менеджер компании выезжает для личного осмотра Вашего бизнеса.

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

По результатам своей деятельности микрофинансовая компания производит отчисления в налоговые органы и предоставляет отчетность в органы государственной статистики.



2. Case средства проектирования

CASE (англ. Computer-Aided Software Engineering) -- набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов.

Средства автоматизации разработки программ (CASE-средства) -- инструменты автоматизации процессов проектирования и разработки программного обеспечения для системного аналитика, разработчика ПО и программиста. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять как программные средства для поддержки процессов жизненного цикла ПО.[3]

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

В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.[5]

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

· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

· интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

· использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

· средства разработки приложений, включая языки 4GL и генераторы кодов;

· средства конфигурационного управления;

· средства документирования;

· средства тестирования;

· средства управления проектом;

· средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям:

· локальные средства, решающие небольшие автономные задачи (tools),

· набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit)

· полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

· применяемым методологиям и моделям систем и БД;

· степени интегрированностию с СУБД;

· доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

· средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

· средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

· средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

· средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

· средства конфигурационного управления (PVCS (Intersolv));

· средства тестирования (Quality Works (Segue Software));

· средства документирования (SoDA (Rational Software)).

На сегодняшний день рынок программного обеспечения СНГ располагает следующими наиболее развитыми CASE-средствами:

· Vantage Team Builder (Westmount I-CASE);

· Designer/2000;

· Silverrun;

· ERwin+BPwin;

· S-Designor;

· CASE.Аналитик.

· E-drowMax

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

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



3. Структурный подход

3.1 AllFusion Process Modeler BPWin

AllFusion Process Modeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов. Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса.

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

информационный микрофинансовый программный

Рисунок 1 - Интерфейс AllFusion Process Modeler 7

AllFusion Process Modeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. AllFusion Process Modeler 7 повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.[6]

AllFusion Process Modeler 7 (BPwin) эффективен в проектах, связанных с описанием действующих баз предприятий, реорганизацией бизнес-процессов, внедрением корпоративной информационной системы.

Продукт позволяет оптимизировать деятельность предприятия и проверить ее на соответствие стандартам ISO 9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции и повысить эффективность. В основу продукта заложены общепризнанные методологии моделирования, например, методология IDEF0 рекомендована к использованию Госстандартом РФ и является федеральным стандартом США.

Простота и наглядность моделей Process Modeler упрощает взаимопонимание между всеми участниками процессов. Распространенность самого AllFusion Process Modeler 7 позволяет вести согласование функциональных моделей с партнерами в электронном виде. Продукт AllFusion Process Modeler 7 (BPwin) создан компанией Computer Associates. AllFusion Process Modeler 7 наряду с ERwin Data Modeler (ранее: ERwin), Data Model Validator (ранее: ERwin Examiner),Model Manager (ранее: ModelMart) входит в состав пакета программных средств AllFusion Modeling Suite, комплексное использование которого обеспечивает все аспекты моделирования информационных систем.

Основные возможности системы:

· Поддержка различных технологий моделирования

· Анализ показателей затрат и производительности

· Интеграция процессов/данных

· Поддержка стандартных нотаций

· Экспорт объектов и свойств в другие модели

· Документирование информации в пределеах всей модели

· Масштабируемость отчетности без потери качества графиков

Кому нужен AllFusion Process Modeler 7 (BPwin): всем компаниям, желающим добиться оптимальности и эффективности собственного бизнеса или бизнеса заказчиков. Руководителям проектов, бизнес-аналитикам, системным аналитикам, руководителям, маркетологам, консультантам, менеджерам по качеству и др.

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

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

1. Прием звонков с обращениями от клиентов.

2. Прием заказов от клиентов.

3. Выполнение заказов.

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

· Оформление заказа.

· Обработка заказа.

· Составление отчета о заказе.

· Изготовление заказа.

· Доставка заказа клиенту.

В соответствии с данными о деятельности предприятия была составлена структурная схема с несколькими уровнями декомпозиции представленные в виде схем IDEF0, IDEF3 средствами средства проектирования ERWin. Функциональная схема А-0 представлена на рис. 2.



Рисунок 2 - Функциональная схема А-0

В виду деятельности компании на вход подаются:

· Звонки, обращения клиентов, прием заказов (Клиент звонит в ресторан, бронирует стол);

На выход процесса:

· Выполненный заказ (готовый заказ выданный клиенту официантом);

Механизмами воздействия являются:

· Персонал (официант, бухгалтер, шеф-повар и т.д).

· Система принятия заказов (заказ без участия официанта с помощью электронных устройств встроенных в каждый стол);

Управляющими факторами является:

· Документы регламентирующие работу( отчеты, нормативные акты, ГОСТ ,устав организации).



Проведем декомпозицию данного функционального блока А-0.

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

· Оформление заказа - в данном процессе осуществляется проработка системой заказа, и отправка его на изготовление;

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

· Доставка заказа клиенту -в данном процессе шеф-повар оповещает официанта о приготовленном заказе, второй в свою очередь приносит готовый заказ клиенту;

Так как механизмы управления и воздействия к каждому виду работ идентичны и описаны в пояснении к схеме А-0 (рис. 2) рассмотрим входы и выходы каждой из работ и добавленные механизмы управления, представленных в схеме А0 (рис. 3)

Рисунок 3 - Декомпозиция А0, Прием заказов ресторана



Оформление заказа:

Входом процесса являются: Звонки, обращения клиентов, прием заказов;

Выходом процесса является: Сформированный заказ клиента

Изготовление заказа

Входом процесса являются: Заказ клиента, ингредиенты

Выходом процесса является: Готовое блюдо

Механизм управления: Технология приготовления

Доставка заказа клиенту

Входом процесса являются: Готовое блюдо

Выходом процесса являются: Выполненный заказ

Механизм управления: Обслуживание клиента

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

· Оформление заказа А1 (рис. 4);

· Изготовление заказа А2 (рис. 5);

· Доставка заказа клиенту А3 (рис. 6);

В следствии декомпозиции процесса "Оформление заказа" получаем следующий список выполняемых работ:

· Поступление заказа в систему - в рамках данного процесса, клиент на электронном устройстве вбивает заказ в систему.

· Обработка заказа - в рамках данного процесса заказ поступивший от клиента обрабатывается системой.

· Составление отчета о заказе - в рамках данного процесса осуществляется составление отчета в системе.

· Подготовка заказа к выполнению - в рамках данного процесса осуществляется передача заказа официанты для исполнения.

Так как механизмы управления и воздействия к каждому виду работ идентичны и описаны в пояснении к схеме А-0 (рис. 2) и А0 (рис. 3) рассмотрим неописанные элементы схемы А1 (рис. 4)

Поступление заказа в систему

Выходом процесса является: заказ от клиента.

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

Выходом процесса является: обработанный заказ

Составление отчета о заказе

Выходом процесса является: готовый отчет

Подготовка заказа к выполнению

Выходом процесса является: заказ клиента

Рисунок 4- Декомпозиция А1, Оформление заказа



Рисунок 5 - Декомпозиция А2, Изготовление заказа

В следствии декомпозиции процесса "Изготовление заказа" получаем следующий список выполняемых работ:

· Получение заказа на кухне- в рамках данного процесса шеф-повар получает заказ от клиента

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

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

Так как в предыдущих схемах А-0, А0 были описаны внешние механизмы воздействия опишем оставшиеся элементы схемы А2.

Получение заказа на кухне

Выходом процесса является: полученный заказ

Проверка склада на наличие продуктов

Выходом процесса является: утвержденный заказ

Выполнение заказа

Выходом процесса являются: готовое блюдо

Оставшиеся процессы и их методы взаимодействия описаны ранее.

Рисунок 6 - Декомпозиция А3, Доставка заказа клиенту

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

· Оформление заказа- в рамках данного процесса блюдо украшается шеф-поваром и доводится до презентабельного вида;

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

· Доставка клиенту- в рамках данного процесса официант относит блюдо клиенту.

Так как в предыдущих схемах А-0, А0 были описаны внешние механизмы воздействия опишем оставшиеся элементы схемы А3 (рис. 6).

Оформление заказа

Выходом процесса является: заказ

Передача официанту

Выходом процесса является: заказ

Доставка клиенту

Выходом процесса является: выполненный заказ

Оставшиеся процессы и их методы взаимодействия описаны ранее.

Также для дополнения понимания процессов протекающих в предметной области в структурной схеме, было решено раскрыть процессы третьего уровня декомпозиции “А22.1 Проверка склада на наличие продуктов”, методом предоставление IDEF3 диаграмм:

· Проверка склада на наличие продуктов А22.1 (рис. 7);

Рисунок 7 - IDEF 3 А22.1 Проверка склада на наличие продуктов

Опишем блоки предоставленной IDEF3 диаграммы процесса "Проверка склада на наличие продуктов":

· Проверка наличия необходимых продуктов на складе - в рамках данного элемента осуществляется проверка персоналом наличие продуктов на складе.

· Элемент J2 "Synchronous OR" обозначает, что один или несколько следующих процессов запускаются одновременно

· Информирование шеф-повара о наличии необходимых продуктов.

· Информирование шеф-повара об отсутствии необходимых продуктов

· Элемент J3 "Synchronous OR" обозначает, что один или несколько следующих процессов запускаются одновременно

· Уведомление клиента об отсутствии продуктов

· Использование альтернативных продуктов

· Элемент J4 "Asynchronous OR" обозначает, что один или несколько предшествующих процессов должны быть завершены.

· Передача заказа на выполнение.

Стоимостной анализ представлен на рисунках ниже (рис. 9):

Рисунок 9 - Стоимостной анализ



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

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

Рисунок 12 - Диаграмма дерева узлов



4. Объектно-ориентированный подход

4.1 Приложение для объектного моделирования Argo UML

Средство UML моделирования. ArgoUML является открытым программным обеспечением и распространяется под лицензией EPL.

ArgoUML полностью написан на Java и для работы ему подходит любая операционная система с установленной Java 2 JRE или JDK версии 1.4 или выше.[4]

Функциональность ArgoUML включает в себя:

1. Поддержку спецификаций UML 1.3, 1.4, XMI 1.0, 1.1, 1.2

2. 9 видов диаграмм UML (диаграммы классов, состояний, кооперации, последовательности, деятельности, прецедентов, объектов, компонентов, развёртывания)

3. Поддержку OCL для классов

4. Генерацию исходного кода Java, C++, C# и PHP

5. Обратный инжиниринг из исходного кода и байткода Java

6. Автоматическую верификацию модели UML (design critics)

На рис. 13 представлен интерфейс данной программы. В рамках разработки информационной системы для ресторана, данное приложение было использовано для проектирование диаграмм, так как приложение обладает наиболее простым для этого интерфейсом.

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



Рисунок 13 - Интерфейс программы Argo UML

4.2 Организационная структура ресторана

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

В виду разделения организации на отделы "поддержка клиентов", "PR", "Бухгалтерия" и т.д. организационная схема будет выглядеть следующим образом (рис. 17)

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

«Директор»:

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

2. Изучает спрос потребителей на продукцию ресторана.

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

Рисунок 14 - Организационная структура ресторана

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

5.Представляет интересы ресторана и действует от его имени.

6.Предоставляет сведения, связанные с оказанием услуг

общественного питания, контролирующим органам.

«Системный администратор»:

1.Устанавливает на серверы и рабочие станции операционные системы и необходимое для работы программное обеспечение.

2.Осуществляет конфигурацию программного обеспечения на серверах и рабочих станциях.

3.Поддерживает в работоспособном состоянии программное обеспечение серверов и рабочих станций.

4.Регистрирует пользователей локальной сети и почтового сервера, назначает идентификаторы и пароли.

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

«Управляющий»:

1.Осуществляет организацию, планирование и координацию деятельности ресторана;

2. Обеспечивает прохождение работниками ресторана, связанными с производством, хранением и реализацией продуктов питания, медицинского обследования в сроки, устанавливаемые органом санитарного надзора;

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

4. Контролирует наличие документов, необходимых для бесперебойной деятельности ресторана.

«Менеджер по закупкам»:

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

2.Составляет заказы поставщикам, отслеживает выполнение этих заказов

3.Определяет виды товара, которыми необходимо дополнить ассортимент или вывести его из ассортимента, если они бесперспективны.

«Шеф-повар»: 1.Осуществляет руководство производственно-хозяйственной деятельностью подразделения предприятия общественного питания.

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

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

4.Организует учет, составление и своевременное представление отчетности о производственной деятельности, внедрение передовых приемов и методов труда.

«Официанты»:

1.Правильно и красиво сервировать стол

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

3.Подача заказа и уборка стола

4.Вежливое обращение к клиентам

«Повар»:

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

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

3.готовить блюда согласно утвержденным рецептам

«Уборщики»: 1.Уборка помещений, коридоров, лестниц. Удаление пыли с мебели, подметание и мойка вручную или с помощью машин и приспособлений стен, полов, лестниц, окон и т.д.

2.Сбор и транспортировка мусора и отходов в установленное место.

Расстановка урн для мусора, их очистка и дезинфицирование.

3.Соблюдение правил санитарии и гигиены в убираемых местах



4.3 Диаграмма иерархии пользователей

Зная о значимости и задачах каждого из отделов предприятия, можно разработать диаграмму иерархии пользователей для ИС в организации (рис. 18).

Рисунок 18 - Диаграмма иерархии пользователей

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

1. Клиент/Посетитель - актер, пытающийся получить доступ к системе;

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

2. Бухгалтер - актер предоставленный любому работнику связанному с бухгалтерским отделом.

3. Шеф-повар-

4. Менеджер - актер, предоставленный менеджерам, которые помогают клиентам на всех этапах сотрудничества с компанией;

5. Официант-

6. Администратор ИС - актер, предоставленный единичному пользователю, занимающемуся внедрением, разработкой и управлением построенной информационной системы.

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

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

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

4.4 Диаграмма вариантов использования

После разработки диаграммы иерархии пользователей, необходимо выделить вариант использование системы выделенным актерам, предоставленным на рис. 18.

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

Клиент/Посетитель (рис. 19):

· Вход под своей учетной записью - сотрудник (клиент) проходит авторизацию.

· Регистрация - клиент/посетитель вводит свои персональные данные (логин, пароль, ФИО, средства связи, электронная почта и т.д.), для последующей авторизации в системе.

· Просмотр меню - пользователь может просмотреть предложенное меню.

Рисунок 19 - Диаграмма вариантов использования для актера "гость"

Авторизованный пользователь (рис. 20):

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

· Регистрация в отдел - пользователь предоставляет информацию о своей должности, образовании, и предпочитаемом отделе в котором физически трудится.



Рисунок 20 - Диаграмма вариантов использования для актера "Авторизованный пользователеь"

Рисунок 21 - Диаграмма вариантов использования для актера "клиент"

Пользователь отдела (рис. 21):

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

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

· Просмотр отчетов и документации - пользователь получает доступ к рабочим отчетам, и присланным документам на подпись;

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

Рисунок 22 - Диаграмма вариантов использования для актера "инвестор"

Рисунок 23 - Диаграмма вариантов использования для актера "заемщик"

Инвестор (рис. 22)

· Доступ к специализированному инвестиционному ПО - пользователи получают доступ к ПО для инвесторов, с помощью которого они смогут управлять своими вложенными средствами.

Заёмщик (рис. 23)

· Заполнение и подпись договора - пользователи имеют возможность заполнить и подписать договор за займ.

· Погашение кредита - пользователь имеет возможность погасить свой займ через личный кабинет.

· Заполнение анкеты - пользователь имеет возможность скачать и заполнить анкету на займ.

Рисунок 24 - Диаграмма вариантов использования для актера "бухгалтер"

Так как деятельность, описанная на рис. 24 в основном понятна без полного описания, ниже приведены пункты, которые могут потребовать объяснения:

· Доступ к специализированному бухгалтерскому ПО - пользователь получает доступ к ПО упрощающим виды бухгалтерской деятельности (к примеру: 1С-бухгалтерия);

· Прием отчетов от отделов и подразделений - пользователь может просматривать и изымать информацию с отчетов, сгенерированных отделами как автоматически (данные продаж), так и начальниками отделов и подразделений;



Рисунок 25 - Диаграмма вариантов использования для актера "директор"

Директор (рис. 25):

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

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

Рисунок 26 - Диаграмма вариантов использования для актера "менеджер"

Менеджер (рис. 26):

· Составление договора- пользователь формирует договор на основании представленных клиентом данных.

· Прием анкет и документов - пользователь принимает пакет документов от клиентов и работает с ними.

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

Рисунок 27 - Диаграмма вариантов использования для актера "рекламщик"

Рекламщик (рис. 27):

· Продвижение ИС - пользователь продвигает ИС и продукты компании на сторонних ресурсов.

· Размещение рекламы на портале - пользователь размещает рекламу о продуктах в интерфейсе ИС.

Рисунок 28 - Диаграмма вариантов использования для актера "программист"



Рекламщик (рис. 28):

· Доступ к исходному коду портала - пользователь имеет доступ к исходному коду и возможность редактировать его.

· Разработка плагинов - пользователь имеет доступ к расширению ИС путем добавления новых плагинов для улучшения функционала.

· Улучшение безопасности портала - пользователь защищает систему от несанкционированного входа и взлома ИС.

· Создание ПО для портала - пользователь имеет возможность разрабатывать авторское ПО.

Рисунок 29 - Диаграмма вариантов использования для актера "администратор ИС"

Администратор ИС (рис. 29):

· Администрирование ИС - возможность менять настройки созданной информационной системы, расширять, изменять и т.д.;

· Добавление подразделений и отделов - возможность настраивать и добавлять дополнительные отделы и подразделения в случае расширение физической компании;

· Восстановление данных пользователей - возможность восстанавливать или обновлять данные пользователя.

4.5 Диаграмма последовательности

Диаграмма, на которой показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. [1]

Выберем наиболее важные процессы и построим диаграмму последовательности.

Построим диаграммы последовательности для процессов исполняемых актером "Заемщик"

Рисунок 30 - Диаграмма последовательности для заполнения анкеты

На рис. 30 представлено взаимодействия заёмщика с формой заполнения анкеты. В интерфейсе открывается анкета (идёт запрос к репозиторию на ссылку к файлу). Затем заполняется анкета и отправляется Менеджеру.

Вся информация заносится в БД, а файлы добавляются в репозиторий, ссылки на которые так же добавляются в БД. Затем клиента уведомляют, что анкета принята.

На рис. 31 представлено взаимодействие клиента с формой регистрации. Не авторизованный клиент открывает в интерфейсе форму регистрации, после чего отправляется запрос в базу данных на уникальность введенных данных. После успешной операции данные клиента добавляются в БД и завершается регистрация.

Рисунок 31 - Диаграмма последовательности для регистрации нового клиента

На рис. 32 представлено раскрытие процесса просмотра отчетов и документов. Клиент отправляет запрос на отчёт (документ) в интерфейсе, после чего проходит идентификация пользователя на доступ к документу в БД. После успешной операции идет запрос в репозиторий на ссылку к файлу. Затем клиент получает документ в интерфейсе.



Рисунок 32 - Диаграмма последовательности для просмотра отчетов и документов

4.6 Диаграмма деятельности

Это UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части.

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

На рис. 33 представлена диаграмма действия для авторизации и регистрации пользователя в системе, которые устанавливает условия количества некорректных вводов, и устанавливает взаимосвязь с администратором ИС в случае восстановления данных.

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



Рисунок 33 - Диаграмма деятельности для процесса авторизации и регистрации пользователя в системе

На рис. 34 представлена диаграмма деятельности для получения займа. Рассмотрен весь процесс получения займа и взаимодействия клиента и менеджера.

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



Рисунок 34 - диаграмма деятельности для процесса получения займа

4.7 Диаграмма классов

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

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

Рисунок 35 - диаграмма классов



4.8 Диаграмма развертывания

UML моделирует физическое развертывание артефактов на узлах. Например, чтобы описать веб-сайт диаграмма развертывания должна показывать, какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер приложения), какие программные компоненты («артефакты») работают на каждом узле и как различные части этого комплекса соединяются друг с другом. Используется технология Fast Ethernet 100BASE-TX (2 витые пары). Диаграмма развертывания для разрабатываемой ИС представлена на рис. 36.

Рисунок 36 - диаграмма развертывания



5. Сравнение структурного и объектного подходов к проектированию информационных систем

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

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

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

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

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

В представленной работе UML построение дает информацию о самой информационной системе, она позволяет с точностью определить роли (привилегии) в проектировании ИС. Подобная декомпозиция объектов позволяет в будущем, разработчику, всецело опираться на саму модель для проектирования самой системы. К примеру диаграмма классов, может лечь в основу построения объектов в ООП, что поможет разработчику упростить свою работу.

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

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

Так же, сейчас, на сертифицированных предприятиях получивших сертификаты качества в рамках стандартизации по ISO 9000, на предприятиях уже созданные структурные схемы процессов с необходимой декомпозицией, основываясь на которых построить объектную модель намного проще.



Заключение

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

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

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



Список используемой литературы

1. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. - М.: Конкорд, 1992.

2. Жоголев Е.А., МГУ, Технология программирования

3. Тимоти Бадд. Объектно-ориентированное программирование в действии. -- СПб.: «Питер», 1997. -- 464 с.

4. ArgoUML -- Википедия (режим доступа: 10.12.2014), URL: https://ru.wikipedia.org/wiki/ArgoUML

5. Структурный подход к проектированию ИС (режим доступа: 09.12.2014

6. AllFusion Process Modeler 7 (BPwin) - Программные продукты - Каталог ПО - Описания продуктов (режим доступа: 14.12.2014) - http://www.interface.ru/home.asp?artId=102

7. Крэг Ларман. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. -- 3-е изд. -- М.: Вильямс, 2006. -- 736 с.

8. Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. -- М.: Вильямс, 2005. -- 416 с.

9. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя = The Unified Modeling Language user guide. -- 2-е изд. -- М., СПб.: ДМК Пресс, Питер, 2004. -- 432 с.

10. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS / С. Орлов. -- 2-е изд.. -- СПб.: Питер, 2006. -- 736 с.

11. ERwin Data Modeler -- Википедия (режим доступа: 10.12.2014), URL: https://ru.wikipedia.org/wiki/ERwin_Data_Modeler

12. EDraw Max -- официальный сайт (режим доступа: 14.12.2014), URL: http://www.edrawsoft.com/

Размещено на Allbest.ru

...