Разработка автоматизированного рабочего места менеджера по продаже бытовой техники в магазине
Ознакомление с основными понятиями проектирования информационных систем. Обоснование выбора программы и языков создания автоматизированного рабочего места. Определение цели начального создания информационных систем. Анализ роли интерфейсных дуг.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 27.04.2019 |
Размер файла | 1,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на 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
...Подобные документы
Общие принципы построения информационных систем и их реализации на языке программирования Паскаль. Разработка программного обеспечения для создания автоматизированного рабочего места "Склад" для ООО "Комторг". Основные требования к ресурсам компьютера.
дипломная работа [1,2 M], добавлен 13.01.2016Определение общих требований к организации автоматизированного рабочего места. Создание модели автоматизированного рабочего места менеджера фирмы "Информстиль". Разработка базы данных и описание алгоритма программы по учету продаж вычислительной техники.
дипломная работа [2,9 M], добавлен 03.07.2015Разработка и реализация автоматизированного рабочего места для менеджера по продажам компьютерной техники. Требования к функциональным характеристика программного изделия. Стадии и этапы разработки. Эксплуатационная документация, руководство оператора.
курсовая работа [686,9 K], добавлен 19.05.2014Понятие информации, информационных технологий и их виды. Анализ основных положений по автоматизации рабочего места оператора автотранспортного предприятия. Разработка модели автоматизированного рабочего места начальника отдела. Применение модели АРМ.
дипломная работа [4,0 M], добавлен 18.09.2010Обоснование необходимости и основные цели использования вычислительной техники для решения задачи. Используемые классификаторы и системы кодирования. Программное обеспечение разработки автоматизированного рабочего места. Описание программных модулей.
дипломная работа [3,9 M], добавлен 11.08.2015Особенности создания автоматизированного рабочего места (АРМ). Разработка модулей электронных учебников и конспектов. Внедрение электронного документооборота. Схема основных образовательных процессов. Экономическое обоснование эффективности проекта.
дипломная работа [1,6 M], добавлен 03.11.2014Принципы создания автоматизированного рабочего места. Задачи финансового отдела предприятия, распределение функций по рабочим местам. Состав, характеристика, обоснование выбора системного и прикладного программного обеспечения, технических средств.
контрольная работа [16,8 K], добавлен 15.01.2009Задачи, функция и структура выбранной организации. Выявление и оценка информационных потоков. Разработка автоматизированного рабочего места сотрудника с использованием Microsoft Access. Описание концептуальной и логической моделей объекта, тестирование.
дипломная работа [7,8 M], добавлен 21.01.2012Разработка автоматизированного рабочего места в виде Web-приложения "Платные образовательные услуги" для отделения дополнительного образования строительного техникума. Технология создания макета. Разработка программного кода, функции интерфейса.
дипломная работа [1,8 M], добавлен 10.06.2013Сфера применения автоматизированного рабочего места менеджера системы Клиент-Банк, выполнение финансовых операций и перевод денежных средств между счетами клиента, использование сертифицированных программных средств, их высокая производительность.
курсовая работа [1,1 M], добавлен 28.08.2012Технологический процесс сбора, передачи, обработки и выдачи информации. Назначение программного продукта. Анализ экономических показателей внедрения автоматизированного рабочего места кассира-операциониста. Организация рабочего места оператора ЭВМ.
дипломная работа [2,6 M], добавлен 08.12.2014Проектирование автоматизированного рабочего места менеджера по закупкам нефтепродуктов сети АЗС. Анализ информационных потребностей менеджера, информационных потоков и бизнес-процессов. Пути совершенствования информационной системы учета нефтепродуктов.
дипломная работа [3,0 M], добавлен 16.03.2012Цели и задачи автоматизированной системы. Разработка автоматизированного рабочего места в виде мобильного приложения "Учета финансов" для отделения дополнительного образования. Экономический расчет разработки автоматизированного рабочего места.
дипломная работа [1,7 M], добавлен 06.06.2023Состав, содержание и документирование работ на стадиях создания систем автоматизированного проектирования. Стандарты создания технологического оборудования, тактико-техническое задание и технико-экономическое обоснование комплекса средств автоматизации.
курсовая работа [26,9 K], добавлен 22.11.2009Анализ тенденций развития информационных технологий. Назначение и цели применения систем автоматизированного проектирования на основе системного подхода. Методы обеспечения автоматизации выполнения проектных работ на примере ЗАО "ПКП "Теплый дом".
курсовая работа [210,0 K], добавлен 11.09.2010Описание модели организации. Определение уровня зрелости процессов управления. Использование итерационной методологии проектирования информационных систем. Внедрение информационной системы. Повышение производительности труда секретаря судебного заседания.
дипломная работа [1,2 M], добавлен 25.02.2016Схема автоматизации магазина и бизнес-процессов администратора отдела продаж автомагазина "Москвич". Снижение трудоемкости подбора автозапчастей. Формирование сведений о запросах. Функционирование автоматизированного рабочего места администратора.
курсовая работа [730,1 K], добавлен 21.06.2013История развития информационных технологий. Компьютерные сети и средства, аппаратное обеспечение связи. Принципы организации автоматизированного рабочего места. Классификация программ в бухгалтерском учете. Особенности российского рынка деловых программ.
курс лекций [284,1 K], добавлен 12.12.2012Создание автоматизированного рабочего места подготовки управляющих программ для станков с ЧПУ. Технологическая сущность и формализация алгоритма задачи; техническое и программное обеспечение АРМ. Организация оптимальных условий труда программиста; смета.
дипломная работа [2,4 M], добавлен 22.05.2013Анализ информационных систем деятельности культурно-оздоровительных центров. Создание автоматизированного рабочего места специалиста по работе с клиентами санатория. Построение модели предметной области, описание полей таблиц; верификация программы.
дипломная работа [1,8 M], добавлен 16.09.2016