Разработка автоматизированного рабочего места менеджера по продаже бытовой техники в магазине

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

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

ФГБОУ ВО «Бурятская государственная сельскохозяйственная академия имени В.Р. Филиппова»

Кафедра «Информатика и информационные технологии в экономике»

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

На тему: «Разработка автоматизированного рабочего места менеджера по продаже бытовой техники в магазине»

Выполнил: студент 3 курса Ользонова М.Б.

Проверил: Садуев Н.Б.

Улан-Удэ 2015



Содержание

Введение

1. Теоретическая часть

1.1 Основные понятия проектирования информационных систем

1.2 Методология проектирования ИС

1.3 Моделирование бизнес-процессов средствами BPwin

2. Аналитическая часть

2.1 Анализ предметной области

2.2 Постановки задачи

3. Проектирование функциональных особенностей системы

3.1 Диаграмма прецедентов

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

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

3.4 Диаграмма коммуникаций

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

3.6 Диаграмма компонентов

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

4. Проектная часть

4.1 Разработка модели как должно быть

4.2 Описание проектируемых работ

Заключение

Список литературы



Введение

Что такое АРМ? Для каждой профессии существует множество особенностей построения автоматизированного рабочего места (АРМ), зависящих от выполняемых специалистом этой профессии функций. Но и создание автоматизированных вариантов рабочих мест для одних и тех же по профилю, но работающих в различных областях деятельности (или хотя бы в различных предприятиях одной сферы деятельности) специалистов несет в себе большое количество различий и особенностей из-за специфики учреждений, в которых работают эти люди. Автоматизация рабочего места представляет собой организацию места менеджер по продажам, оборудование средствами, необходимыми для автоматизации выполнения им определенных функций. Такими средствами, как правило, является ПК, дополняемый по мере необходимости другими вспомогательными электронными устройствами (печатающими устройствами, сканирующими устройствами, считывателями штрих - кодов, устройствами графики, средствами резервного копирования данных). Целью данной работы является разработка структуры АРМ менеджера.

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

Изучить особенности АРМ; Ознакомиться с требованиями, предъявляемыми к ним; Выполнить анализ предметной области; Выбрать программы и языки создания АРМ; Разработать структуру АРМ;·Определить принцип управления АРМ;·Определить внешний вид АРМ; Изучить элементы языка программирования Delphi 2010; Реализовать подключение БД средствами языка Delphi 2010.



1. Теоретическая часть

1.1 Основные понятия технологии проектирования информационных систем

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

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

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

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

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

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

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

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

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

• гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

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

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

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

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл- сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Проектирование информационных систем всегда начинается с определения цели проекта.

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

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

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

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

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

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

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

Этап проектирования завершается разработкой технического проекта ИС.

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

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

• обнаружение отказов модуля (жестких сбоев);

• соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

1.2 Методология проектирования ИС

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

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

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

Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

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

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

Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных _ систем SADT (Structured Analysisand Design Technique).

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги").На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение "Управление" (Control);

• левая сторона имеет значение "Вход" (Input);

• правая сторона имеет значение "Выход" (Output);

• нижняя сторона имеет значение "Механизм" (Mechanism).

Рисунок 1. Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (WorkElowDiagram).

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

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

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка 3peHHB(Viewpoint).

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

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

Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (ChildDiagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком - ChildBox). В свою очередь, функциональный блок -- предок называется родительским блоком по отношению к дочерней диаграмме (ParentBox), а диаграмма, к которой он принадлежит - родительской диаграммой (ParentDiagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0- модели.

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

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

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

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

1.3 Моделирование бизнес-процессов средствами BPwin

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silvemm (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес- процессов (IDEF3); диаграммы потоков данных (DFD).

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные -- в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

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

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

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

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

Модели AS-IS и ТО-BE. Обычно сначала строится модель существующей организации работы -- AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-BE (как будет) -- модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-BE, и только на основе модели ТО-BE строится модель данных, прототип и затем окончательный вариант ИС.



2. Аналитическая часть

2.1 Анализ предметной области

Информационная система «АИС магазин бытовой техники и электроники» разработана для магазина «INTEL». Предназначен для автоматизации процесса продаж и заказов и учета выполняемых операций.

Необходимость упростить и автоматизировать учет продаж.

Информационная система «АИС магазин бытовой техники и электроники» предназначена для:

• вести реестр клиентов(покупателей);

• осуществляют генерацию заказов;

• создавать отчеты различных категорий.

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

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

Должны присутствовать средства, обеспечивающие конфиденциальность информации и защиту от несанкционированного доступа (например, пароль);

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

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

В данной системе на контекстной диаграмме представлена работа AIS(«AMC магазин бытовой техники и электроники»). Входами являются данные о продаже, данные о заказе клиента, данные о поступлении товара, на выходе - отчет и заявка.

Рисунок 2. Контекстная диаграмма



Рисунок 3. Функциональная декомпозиция

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

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

1) Запись данных в реестр клиента. Механизм процесса - кассир, входом является данные о продаже, на выходе данные о проданной техники и данные ФИО клиента.

2) Создает заявку для поставщика. Механизм процесса - отдел заявок и претензий, входом является данные о заказе клиента. И данные о проданной техники, на выходе данные о составе заявки и сама заявка.

3) Создает различные формы отчетов. Механизм процесса - склад, входом является данные о составе заявки, данные о поступлении товара, данные ФИО клиента, выходом является отчет.

2.2 Постановки задачи

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

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



3. Проектирование функциональных особенностей системы

3.1 Диаграмма прецедентов

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

Use Смс Оидгят {Raqurawnti:;UK Сне Model}n §3] Component Architecture Diagram § Use Case Diagram |

Рисунок 4. Диаграмма прецедентов

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

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

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

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

_Component Architecture Diagram Use Case Diagram Щ CiassDiagraml

Рисунок 5 Диаграмма классов

На данной диаграмме представлено классы: клиент, продавец, реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, AIS, генератор заказов, поставщик и склад.

Каждому классу присвоен свой стереотип, характеризующий его функциональность. Граничные классы -клиент и поставщик, т.е. классы, расположенные на границе системы и всей окружающей среды. Управляющий класс-AIS, т.е. отвечает за координацию действий других классов. Классы-сущности - реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, генератор заказов, поставщик и склад.

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



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

Диаграмма взаимодействия, в которой основной акцент сделан на временном упорядочении сообщений. Данная диаграмма (см. рис. №5) иллюстрирует упорядоченный поток данных, которые передается в AIS, а она в свою очередь в отчеты. На диаграмме представлены классы: продавец, кассир, отдел заявок и претензий, склад, AIS, отчеты, которые входят в данное действие.

Рисунок 6. Диаграмма последовательности

3.4 Диаграмма коммуникаций

Диаграмма взаимодействий, в которой основной акцент сделан на структурной организации объектов, посылающих и получающих сообщения. Данная диаграмма (см. рис. №6) иллюстрирует упорядоченный поток данных необходимые для введения реестра клиента. В данном процессе участвуют: клиент, прайс, продавец, кассир, AIS, реестр клиента. Объекты прайс и продавец необходимы в данном описании, так как клиент не предоставит свои персональные данные кассиру и данные о покупке, пока не будут получены данные о техники и пока не будет выписана заявки.

Рисунок 7.Диаграмма коммуникаций

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

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

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

Рисунок 8.Диаграмма деятельности



3.6 Диаграмма компонентов

Диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними. Диаграмма представляется в виде графа с ребрами и вершинами.

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

На диаграмме компонентов находиться исполняемый компонент: «AIS. ехе» со стереотипом «executable».

Также присутствуют компоненты: «ПО реестр клиента», «ПО генерация заказов», со стереотипом «library» и компонент «ПО создание отчетов» со стереотипом «document». У компонентов иметься интерфейс. Через интерфейс взаимодействуют компоненты, с помощью связью зависимости. Запуск программы осуществляет AIS.exe, который взаимодействует с ПО реестр клиента, через связь зависимости, который в свою очередь взаимодействует с ПО генерация заказов и ПО создание отчетов, которые между собой тоже взаимодействуют, через связь зависимость.

Рисунок 9. Диаграмма деятельности

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

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

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

На диаграмме развертывания приставлен узел со стереотипов процессор: AIS и со стереотипов устройство: клиент, продавец, реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, генератор заказов, поставщик и склад.

Рисунок 10.Диаграмма развертывания



4. Проектная часть

4.1 Разработка модели как должно быть

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

Рисунок 11 .Контекстная диаграмма

4.2 Описание проектируемых работ

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

СУБД призвана обеспечить автоматизацию работы с контактными данными клиентов, упростить формирование списков клиентов

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

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



Заключение

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

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

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

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



Список литературы

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. Идоп. -- М.: Финансы и статистика, 2006. -- 544 с.

2. Ильина О.П. электронная книга иллюстрированный самоучитель «Информационные технологии бухгалтерского учета» 2001 г.

3. Иллюстрированный самоучитель по Acces 2002: электронный учебник, 2004 г.

4. Козлов В.А. Открытые информационные системы. - М.: Финансы и статистика, 2000.

5. Маклаков С.В., Создание информационных систем с ALLFusionModelingSuite. 2-е изд., испр. идополн. -М.: Издательство Диалог-МИФИ, 2007 - 400 с.

6. Попов В.И. Проектирование информационных систем: методические рекомендации для выполнения курсовых работ и расчетных заданий по дисциплине «Проектирование информационных систем» --Алт. гос. техн. ун-та, 2010. - 151 с.

7. Попов В.И. Диаграммы UML в VisualParadigm: методические рекомендации к лабораторным работам по дисциплине «Проектирование информационных систем» -- Алт. гос. техн. ун-та, 2009.- 151 с.

8. Тархов С.В., Рамбургер О.Л., Минасов Ш.М. Лабораторный практикум по дисциплине «Информатика».

9. Похилько А.Ф., Горбачев И.В. электронная книга иллюстрированный самоучитель «Case -технология моделирования процессов с использованием средств BPwin и Erwin.

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

...