Моделирование предметной области «Учет продаж» с помощью UML

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

Задачи теоретической части курсового проекта:

1. Получение представления о структурном подходе к проектированию ИС;
2. Рассмотреть экономическую сущность учета учета продаж в современных условиях;
3. Проведение сравнительного анализа используемых подходов;
4. Описание метода функционального моделирования;
5. Изучение способов и приемов построения сетевой модели.
6. Постановка задач автоматизации;
7. Проектирование информационной системы технологии управления работой магазина;
8. Изучить возможности программных средств реализации информационной системы (например, MS Access, Visual C++, Java, 1C: Предприятие и т.д.).

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

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

Объектом исследования является компьютерный магазин «Компьютерный мир».

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

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

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

Информационной базой написания работы выступают методические указания, учебные пособия, данные финансовой отчётности в магазине «Компьютерный магазин».

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Структурный подход к проектированию информационной системы

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

• принцип «разделяй и властвуй» - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
• принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

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

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

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».

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

Объектно-ориентированный подход к проектированию программного обеспечения

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

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

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

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

Для решения этой проблемы и были созданы объектно-ориентированные методы разработки ИС

В 1990 х годах словосочетание “объектно-ориентированный” в контексте информационных технологий стало синонимом слов “современность”, “высокое качество”, “ценность”.

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

ООП основан на представлении предметной области задачи в виде множества моделей для независимой от языка разработки программной системы на основе ее прагматики.

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

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

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

1.2 Особенности языка моделирования UML

Выделим следующие этапы проектирования ИС:

1. Исследование предметной области.
2. Разработка архитектуры системы.
3. Реализация проекта.
4. Внедрение системы.
5. Сопровождение системы.

Исследование предметной области предусматривает следующие шаги:

• спецификацию деятельности в предметной области;
• анализ деятельности в предметной области;
• структурно-логический анализ деятельности;
• анализ путей;
• анализ связности (прочности и сцепления) компонентов;
• анализ производительности;
• экономический анализ;

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

1. Спецификации требований к проектируемой системе.
2. Конструирование концептуальной модели предметной области.
3. Спецификации обработки данных в проектируемой системе.
4. Спецификации пользовательского интерфейса системы.
5. Спецификации деятельности в предметной области с учетом внедрения системы.

В последнее время для описания проектов широкое распространение получил UML (Unified Modeling Language) - уни- версальный язык моделирования. Графический способ ото- бражения объектов и связей (графическая нотация) является очень удобным языком для общения разработчиков между собой, а также общения разработчиков с заказчиками, со спе- циалистами прикладной области. UML является, фактически, стандартом для описания проек- тов, связанных с разработкой программного обеспечения. Из- ложенная в данном разделе нотация очень близка к нотации UML. Она упрощена, но достаточна для проектирования не- больших программных систем. При разработке проекта прикладной системы лучше всего использовать существующие средства автоматизации проек- тирования программного обеспечения (например, Rational Rose). Если производится проектирование небольшой систе- мы, которая выполняется силами только программистов, то, конечно, должен быть установлен разумный уровень детали- зации. Нет смысла использовать детализированные диаграм- мы там, где уже «видны коды».

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

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

Рисунок 1 - Жизненный цикл приложения

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

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

В описании UML используются три языковых уровня:

• Мета-метамодель, то есть описание языка, на котором описана метамодель.
• Метамодель, то есть описание языка, на котором описываются модели.
• Модель, то есть описание самой моделируемой предметной области.

Основная идея описания UML вполне традиционна и согласуется с общепринятой практикой: мета-метамодель — это описание используемого формализма; метамодель — это и есть собственно описание языка (элементов моделирования); там, где формализм не срабатывает, на помощь приходит естественный язык и все это сопровождается примерами фрагментов моделей.

1.3 Диаграммы языка UML

В UML используются следующие виды диаграмм:

• Диаграмма использования
• Диаграмма классов
• Диаграмма объектов
• Диаграмма состояний
• Диаграмма деятельности
• Диаграмма последовательности
• Диаграмма кооперации
• Диаграмма компонентов
• Диаграмма размещения

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

Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной на рис. 2.

Рисунок 2 - Иерархия типов диаграмм

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

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

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

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

Рисунок 3 - Нотация диаграммы использования (UML 2.0)

Диаграмма классов — основной способ описания структуры системы. Это не удивительно, поскольку UML сильно объектно-ориентированный язык, и классы являются основным (если не единственным) «строительным материалом» системы. На диаграмме классов применяются один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

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

Основные элементы нотации, применяемые на диаграмме классов, показаны на рис. 4.

Рисунок 4 - Нотация диаграммы классов

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

На диаграмме объектов применяют один основной тип сущностей: объекты (экземпляры классов), между которыми указываются конкретные связи (экземпляры ассоциаций).

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

Диаграмма деятельности — это, фактически, старая добрая блок-схема алгоритма, в которой модернизированы обозначения, а семантика согласована с современным объектно-ориентированным подходом, что позволило органично включить диаграммы деятельности в UML.

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

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

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

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс);
• зависимости между объектами и компонентами (объект входит в компонент).

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

Достоинства и недостатки объектно-ориентированного подхода

Рассмотрим достоинства объектно-ориентированного программирования.

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

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

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

4. ООП дает возможность создавать расширяемые системы. Компоненты могут быть добавлены на этапе исполнения программы.

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

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

7. Реализация работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.

8. Создание «каркаса». Независимые от приложения части предметной области могут быть реализованы в виде набора универсальных классов, или каркаса (framework).

9. Сокращается время на разработку.

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

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

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

Одако ООП имеет и недостатки.

1. Документирование классов — ресурсоёмкая задача.

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

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

3. Злоупотребление инкапсуляцией данных. Чем больше логики и данных скрыто в недрах класса, тем сложнее его расширять.

4. Неэффективность на этапе выполнения, в т.ч. инкапсуляция данных.

5. Неэффективность в смысле распределения памяти.

6. Излишняя универсальность.

ПРАКТИЧЕСКАЯ ЧАСТЬ

1.4 Спецификация требований к «Учёт продаж»

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

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

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

• Стратегический менеджмент, в том числе и стратегический маркетинг
• Управление товарами, в том числе и тактический маркетинг
• Управление магазинами
• Управление операциями (административный менеджмент).

Рисунок 5 - Функциональная организационная диаграмма

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

Рисунок 6 - Организационная структура технологии сырья и реализации готовой продукции ООО «Компьютерный мир»

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

Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors)

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

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

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

Данная диаграмма представляет собой совокупность актеров, вариантов использования и связей между ними. Каждый актер – это некая отдельная роль относительно конкретного варианта использования. Актерами выступают конкретные сотрудники, а также действующие должности. На диаграмме отображается поведение системы, то есть что система будет делать.

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

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

1.6 Диаграмма взаимодействия

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

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

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

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

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

Диаграмма последовательности действий Ввод заказа (рис.9) описывает алгоритм действий, при которых некоторый клиент заказывает продукцию и продавец осуществляет ввод заказа. Слева показан актер (работник магазина), инициирующий данный алгоритм. Работнику приходится взаимодействовать с тремя объектами, чтобы достигнуть своей цели, важнейшими из которых являются Выбор варианта заказа и Заказ, так как они влияют на ввод заказа.

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

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

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

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

Диаграмма сотрудничества

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграмма сотрудничества Ввод заказа (рис.11) моделирует последовательность действий при оформлении заказа сотрудником магазина.

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

Рисунок 11 - Диаграмма сотрудничества Подача заявления

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

2. Логическая модель информационной системы

Диаграмма FA-уровня должна содержать все, что содержит диаграмма КВ-уровня и, кроме того, все неключевые атрибуты.

Диаграмма выполнена в нотациях IDEF1X.

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

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

Все сущности на FA-диаграмме удовлетворяют по требованиям НФБК.

Диаграммы FA-уровня модели, выполненные в нотациях стандарта IDEF1X, представлена на рисунке 12.

Рисунок 12 - FA-уровень модели данных.

Глоссарий сущностей представлен в таблице 1.

Таблица 1. Глоссарий сущностей

Сущность	Описание
ДАННЫЕ ПОСТАВОК	Список поставок
ДАННЫЕ ПРОДАЖ	Список продаж
ДОЛЖНОСТИ	Список должностей
КАБИНЕТЫ	Список кабинетов
ПОКУПАТЕЛЬ	Список покупателей
ПОСТАВКИ	Каталог поставок
ПОСТАВЩИКИ	Каталог поставщиков
ПРОДАЖИ	Каталог продаж
ПРОДУКЦИЯ	Каталог продукции
СОТРУДНИКИ	Список сотрудников

Данная таблица сгенерирована мастером отчетов AllFusion ERwin Data Modeler 7.

Глоссарий описания связей представлен в таблице 2.

Таблица 2. Описание связей

Сущность	Отношение родительской сущности к дочерней правило связей	Отношение дочерней сущности к родительской правило связей
ДАННЫЕ ПОСТАВОК	A ДАННЫЕ ПОСТАВОК принадлежит zero, one or more ПОСТАВКИs.	A ПОСТАВКИимеет zero or one ДАННЫЕ ПОСТАВОК s.
ДАННЫЕ ПОСТАВОК	A ДАННЫЕ ПОСТАВОК принадлежит zero, one or more ПРОДУКЦ ИЯs.	A ПРОДУКЦИЯимеет zero or one ДАННЫЕ ПОСТАВОК s.
ДАННЫЕ ПРОДАЖ	A ДАННЫЕ ПРОДАЖ принадлежит к zero, one or more ПРОДУКЦИЯs.	A more ПРОДУКЦ ИЯ имеет zero or one ДАННЫЕ ПРОДАЖ s.
ДАННЫЕ ПРОДАЖ	A ДАННЫЕ ПРОДАЖ принадлежит к zero, one or more ПРОДАЖИ s.	A more ПРОДАЖИ имеет zero or one ДАННЫЕ ПРОДАЖ s.
ПРОДАЖИ	A ПРОДАЖИ принадлежит к zero, one or more ПОКУПАТЕЛЬ s.	A more ПОКУПАТЕЛЬ имеет zero or one ПРОДАЖИ s.
ПРОДАЖИ	A ПРОДАЖИ принадлежит к zero, one or more more СОТРУДНИКИ s.	A more СОТРУДНИКИ zero or one ПРОДАЖИ s.
ПОСТАВКИ	A ПОСТАВКИ принадлежит к zero, one or more more ПОСТАВЩИКИs.	A more ПОСТАВЩИКИ zero or ПОСТАВКИ s.
СОТРУДНИКИ	A СОТРУДНИКИ принадлежит к zero, one or more more КАБИНЕТЫ s.	A more КАБИНЕТЫ zero or СОТРУДНИКИ s.
СОТРУДНИКИ	A СОТРУДНИКИ принадлежит к zero, one or more more ДОЛЖНОСТИ s.	A more КАБИНЕТЫ zero or ДОЛЖНОСТИ s.

Сущности и их атрибуты представлены в таблице 3.

Таблица 3. Сущности и их атрибуты

Сущность	Атрибуты
ДАННЫЕ ПОСТАВОК	КОД ПОСТАВКИ
	ПРОДУКЦИЯ
	КОЛИЧЕСТВО
ДАННЫЕ ПРОДАЖ	КОД ПРОДАЖИ
	ПРОДУКЦИЯ
	КОЛИЧЕСТВО
ДОЛЖНОСТИ	КОД ДОЛЖНОСТИ
	ДОЛЖНОСТЬ
	ОКЛАД
КАБИНЕТЫ	КОД КАБИНЕТА
	РАБОЧИЙ ТЕЛЕФОН
ПОКУПАТЕЛЬ	КОД ПОКУПАТЕЛЯ
	ПОКУПАТЕЛЬ
	ТЕЛЕФОН
ПОСТАВКИ	КОД ПОСТАВКИ
	ДАТА ЗАКАЗА
	ДАТА ПОСТАВКИ
	СУММА ПОСТАВКИ
	ПОСТАВЩИКИ
ПОСТАВЩИКИ	КОД ПОСТАВЩИКА
	НАЗВАНИЕ ПОСТАВЩИКА
	ТЕЛЕФОН
ПРОДАЖИ	КОД ПРОДАЖИ
	ДАТА ПРОДАЖИ
	МЕНЕДЖЕР
	ОБЩАЯ СТОИМОСТЬ
	ПРЕМИЯ МЕНЕДЖЕРУ
	ПОКУПАТЕЛЬ
ПРОДУКЦИЯ	КОД ID
	МОДЕЛЬ
	ТЕХНИЧЕСКАЯ ХАРАКТЕРИСТИКА
	СТОИМОСТЬ ЗА ШТ
	ГАРАНТИЯ
	КОЛИЧЕСТВО
СОТРУДНИКИ	Код сотрудника
	ДАТА РОЖДЕНИЯ
	ТЕЛЕФОН
	АДРЕС
	КАБИНЕТ
	ДОЛЖНОСТЬ
	ФИО

Данная таблица сгенерирована мастером отчетов AllFusion ERwin Data Modeler 7 (ERwin).

Домен — допустимое потенциальное ограниченное подмножество значений данного типа.

Определения доменов представлены таблице 4.

Таблица 4. Сущности, атрибуты и домены

Сущность	Атрибуты	Домен
ДАННЫЕ ПОСТАВОК	КОД ПОСТАВКИ	Number
	ПРОДУКЦИЯ	String
	КОЛИЧЕСТВО	Number
ДАННЫЕ ПРОДАЖ	КОД ПРОДАЖИ	Number
	ПРОДУКЦИЯ	String
	КОЛИЧЕСТВО	Number
ДОЛЖНОСТИ	КОД ДОЛЖНОСТИ	Number
	ДОЛЖНОСТЬ	String
	ОКЛАД	Number
КАБИНЕТЫ	КОД КАБИНЕТА	Number
	РАБОЧИЙ ТЕЛЕФОН	String
ПОКУПАТЕЛЬ	КОД ПОКУПАТЕЛЯ	Number
	ПОКУПАТЕЛЬ	String
	ТЕЛЕФОН	String
ПОСТАВКИ	КОД ПОСТАВКИ	Number
	ДАТА ЗАКАЗА	Date/Time
	ДАТА ПОСТАВКИ	Date/Time
	СУММА ПОСТАВКИ	Number
	ПОСТАВЩИКИ	String
ПОСТАВЩИКИ	КОД ПОСТАВЩИКА	Number
	НАЗВАНИЕ ПОСТАВЩИКА	String
	ТЕЛЕФОН	String
ПРОДАЖИ	КОД ПРОДАЖИ	Number
	ДАТА ПРОДАЖИ	Date/Time
	МЕНЕДЖЕР	String
	ОБЩАЯ СТОИМОСТЬ	Number
	ПРЕМИЯ МЕНЕДЖЕРУ	Number
	ПОКУПАТЕЛЬ	String
ПРОДУКЦИЯ	КОД ID	Number
	МОДЕЛЬ	String
	ТЕХНИЧЕСКАЯ ХАРАКТЕРИСТИКА	String
	СТОИМОСТЬ ЗА ШТ	String
	ГАРАНТИЯ	String
	КОЛИЧЕСТВО	Number
СОТРУДНИКИ	КОД СОТРУДНИКА	String
	ДАТА РОЖДЕНИЯ	Date/Time
	ТЕЛЕФОН	String
	АДРЕС	String
	КАБИНЕТ	Number
	ДОЛЖНОСТЬ	String
	ФИО	String

Конечными пользователями БД являются сотрудники магазина.

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

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

2.1 Физическая модель информационной системы

В рамках разработки информационной системы автоматизации технологии управления работой компьютерного магазина необходимо произвести выбор СУБД исходя из следующих параметров:

- совместимость с существующей системной архитектурой информационной системы;

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

- нагрузка на СУБД в условиях ООО «Компьютерный магазин» - в среднем около 120 новых записей в день, одновременное подключение до 40 пользователей.

- возможность подключения к СУБД из большинства сред программирования без установки дополнительного программного обеспечения;

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

- оптимальность ценового критерия.

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

Наиболее оптимально заданным критериям удовлетворяет СУБД MS Access 2010.

Данная СУБД позволяет осуществлять совместный доступ пользователей. Лицензионное ограничение на число пользователей, предельный размер базы данных не повлияет на функционал автоматизированной системы ООО «Компьютерный мир» в силу небольшой наполняемости СУБД.

Согласно диаграмме физического уровня модели база данных создана схема в MS Access 2010.

Рисунок 13 - Физическая схема базы данных Магазин в MS Access 2010

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

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

Рисунок 14 - Диаграмма развёртывания

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

В результате всей работы была смоделирована информационная система «Учёт продаж». В ходе разработки созданы диаграммы, входящие в язык моделирования UML. Соответственно, изучены основы языка моделирования UML. Дано краткое описание для каждой разработанной диаграммы, рассмотрены базовые элементы графической нотации, необходимые для изображения различных элементов диаграмм.

Все диаграммы в данной курсовой работе разработаны с помощью Rational Rose, Bpwin, Microsoft Access.

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

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

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

Данный курсовой проект может быть использован при разработке (программировании) информационной системы «Учёт продаж».

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

1. Боггс У., Боггс М. UML и Rational Rose. – М.: Лори, 2000 – 582 с.
2. Буч Г., Рамбо Д., Джекобсон А., Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000 - 432с.
3. Грехем И. Объектно-ориентированные методы. Принципы и практика – М.: «Вильямс», 2004 – 880 с.
4. Федотова Д., Семенов Ю., Чижик К., «CASE-технологии. Практикум», 2005 г – 129 с.
5. Маклаков С.В., BPwin и ERwin: CASE-средства для разработки инофрмационных систем, 2002
6. Марка Д.А., МакГоуэн К., Методология структурного анализа и проек-тирования. – М.: «Мир», 1998 – 128 с.
7. Скодорова Л.К., Константинова Ю.С., Проектирование информационных систем, 2011 – 104 с.
8. Трофимов С.А., CASE-технологии: Практическая работа в Rational Rose. – 2-е изд. – М.: Бином-Пресс, 2002 – 288 с.
9. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – [Текст] / А.М. Ведеров. – М.: Финансы и статистика, 2006. – 544 с.
10. Максаков С.А. Достоинства и недостатки ООП: [Электронный документ]. – Режим доступа: http://www.maksakov-sa.ru/TehProgram/ObOrientProgr/DosNedOOP/index.html – Загл. с экрана.
11. Нотация и семантика языка UML: [Электронный документ]. – Режим доступа: http://www.intuit.ru/studies/courses/32/32/lecture/1000 – Загл. с экрана.
12. Объектно-ориентированный подход в программировании: [Электронный документ]. – Режим доступа: http://www.object.newmail.ru/obj1.html – Загл. с экрана.
13. Объектно-ориентированный подход к проектированию программного обеспечения: [Электронный документ]. – Режим доступа: http://www.scriru.com/14/27/75972817962.php – Загл. с экрана.
14. Рябышева И.В. Unified Modeling Language – Унифицированный Язык Моделирования: [Электронный документ]. – Режим доступа: http://www.ict.nsc.ru/ws/YM2004/8666/index.htm – Загл. с экрана.
15. Структурный подход к проектированию ИС: [Электронный документ]. – Режим доступа: http://citforum.ru/database/case/glava2_1.shtml – Загл. с экрана.
16. UML: [Электронный документ]. – Режим доступа: https://ru.wikipedia.org/wiki/UML – Загл. с экрана.
17. Unified Modeling Language – Унифицированный Язык Моделирования: [Электронный документ]. – Режим доступа: http://2programmer.ru/uml – Загл. с экрана.
18. Буч Г., Рамбо, Д., Джекобсон А., Язык UML Руководство пользователя: [Электронный документ]. – Режим доступа: http://dit.isuct.ru/ivt/books/CASE/case11/content.htm – Загл. с экрана.