Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Учет продаж» с помощью UML ( Выбор средства для моделирования предметной области решаемой задачи)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Идея состоит в том, что абстрактный граф модели, состоящий из множества разнотипных сущностей и отношений, не подлежит конструированию или изучению в целом. Каждый раз для визуализации, изменения или иных манипуляций из этого общего графа вычленяются только сущности и отношения, релевантные для определенного аспекта моделируемой системы, а все остальные игнорируются. Такой вид с определенной точки зрения, можно сказать, проекцию модели, мы называем представлением (view). Можно сказать, что представление ‒ это средство логического структурирования модели. В настоящее время процесс автоматизации затронули не только производственную, техническую и технологическую сферы деятельности человечества, но и информационное пространство; в частности издательства, библиотеки, музеи, информационные центры. Уже сложно представить жизнь общества без таких понятий как интернет, средства телекоммуникации и т.д. Автоматизация больше всего затронула информационную сферу, так как именно информация нуждалась и нуждается в быстром поиске, отборе и хранении, а так же в обеспечении доступа к ней.

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

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

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

Объектом изучения предметной области является реализация операций процесса, а предметом – «Учет продаж».

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

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

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

Таблица 1 Основные задачи процесса

Код задачи	Наименование задачи	Назначение задачи	Входная информация	Выходная информация	Исполнитель
01	Поиск и привлечение покупателей	Расширение круга покупателей	Результаты мониторинга рынка, отчеты по продажам	Отчеты о потоке покупателей	Отдел по маркетингу
02	Подготовка товаров к продаже	Гарантия наличия необходимого товара	Перечень товаров, описание товаров, прайс-лист	Перечень и описание подготовленных товаров	Отдел по продажам
03	Осуществление продажи	Формальное оформление отношений с покупателем	Перечень товаров, описание товаров, прайс-лист	Чек об оплате, перечень и описание товаров с изменениями	Отдел по продажам
04	Учет продаж	Учет продаж	Перечень осуществленных продаж	Отчеты о продажах, отчеты о покупателях, отчеты о сотрудниках	Отдел по продажам

Схема связей задач бизнес-процесса приведена на Рисунке 1.

Рисунок 1. Взаимосвязь задач бизнес-процесса

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

Для названной задачи источник информации – отдел по продажам, он же является и исполнителем задачи.

Входной информацией выступают такие документы, как перечень товаров, описание товаров и прайс-лист.

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

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

Основной задачей являются - «Продажи», в ней выделяется следующее содержание:

Чек или счет об оплате
Перечень товаров
Прайс-лист
Описание товаров

В качестве внешнего окружения задачи выступают следующие факторы и документы:

Результаты мониторинга рынка (позволяют определить товары, актуальные для продажи)
Отчеты о потоке покупателей (позволяют определить товары, актуальные для продажи той или иной категории покупателей)
Отчеты о продажах, покупателях, сотрудниках (позволяют определить дальнейшие направления развития)

Внутреннее и внешнее содержание задачи «Осуществление продажи» проиллюстрировано на Рисунке 2.

Рисунок 2. Содержание задачи «Определение перечня и стоимости билетов на определенную дату»

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

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

Предлагаемые мероприятия по улучшению технологии решения задачи

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

Отчеты о потоке покупателей;
Перечень товаров;
Прайс-лист;
Описание товаров;
Мониторинг рынка.

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

Таблица 2. Отчеты о потоке покупателей

Отдел по маркетингу

БД

Подготовка отчета

Отчет

Регистрация отчета в базе данных

Таблица 3. Перечень товаров

Отдел по продажам

БД

Подготовка перечня

Перечень

Перечень товаров

Регистрация перечня в базе данных

Таблица 4. Прайс-лист

Покупатель

Отдел по продажам

БД

Подготовка прайс-листа

Прайс-лист

Ознакомление с прайс-листом

Таблица 5. Описание товаров

Отдел по продажам

БД

Подготовка описания

План продаж

Фиксация описания в базе данных

Таблица 6. Мониторинг рынка

	Отдел по маркетингу	Отдел по продажам	БД
Осуществление мониторинга рынка	Мониторинг Мониторинг Мониторинг Мониторинг Мониторинг
Ознакомление с произведенным мониторингом
Формирование соответствующих цен на товар
Продажа соответствующих товаров

Трудозатраты, количество документов и количество их обновлений представлено в Таблице 7.

Таблица 7. Характеристика документов

Код документа	Наименование	Кол-во сотрудников	Кол-во документов, шт	Кол-во обновлений в месяц	Кол-во обновлений в год
01	Отчеты о потоке покупателей	2	2	1	12
02	Перечень товаров	1-3	2	28-31	336-372
03	Прайс-лист	2	2	4	24
04	Описание товаров	1-3	2	28-31	336-372
05	Мониторинг рынка	4	2	1	12

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

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

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

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

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

Результатная информация для данной системы – отчеты, прайс-лист, список товаров с их описанием.

Характеристика результатных документов приведена в Таблице 13.

Таблица 13. Характеристика результатных документов

Наименование	Источник формирования	Частота формир/мес	Структура документа	Способ доставки
Отчет о покупателях, сотрудниках, товарах	Мониторинг рынка, Список товаров	2	Оригинальная	Вывод формы на экран
Прайс-лист	Мониторинг рынка	28-31	Стандартная	Вывод формы на экран
Список товаров с описанием	Чеки, мониторинг рынка	28-31	Оригинальная	Вывод формы на экран

Обоснование проектных решений по информационному обеспечению

Основными являются следующие документы задачи:

Отчеты о потоке покупателей;
Перечень товара;
Прайс-лист;
Описание товаров;
Мониторинг рынка.

Возможность или невозможность применения унифицированных форм рассмотрена в Таблице 8.

Таблица 8. Обоснование формы документа

Код документа	Наименование	Унифицированная форма	Оригинальное проектирование
01	Отчеты о потоке покупателей		+
02	Перечень товаров	+
03	Прайс-лист	+
04	Описание товаров	+
05	Мониторинг рынка		+

Технология проектирования ИС – совокупность методов и средств проектирования ИС, а также организации и управления, внедрения и модернизации проекта. ИС.

Организация проектирования ИС предполагает использование определенной совокупности методов проектирования.

Методы проектирования принято классифицировать по различным признакам:

По степени автоматизации разработки проектных решений:
Ручное (традиционное) проектирование
Методы автоматизированного проектирования
По степени типизации проектных решений
Методы оригинального (индивидуального) проектирования
Методы типового проектирования
По степени адаптивности проектных решений
Методы реконструкции – адаптация проектных решений выполняется путем изменения соответствующих компонентов готовой системы.
Методы параметризации – изменение проектных решений в соответствии с новыми параметрами объекта проектирования
Методы реструктуризации – изменение проектных решений в связи с изменением модели ПО.

Проектирование ИС предполагает использование различных средств проектирования как на традиционных так и на машинных носителях, в их числе:

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

Сочетание различных методов и средств проектирования обуславливает выделение 2-х классов технологии проектирования:

Каноническое проектирование – соответствующее определенному канону, правилу.
Индустриальное проектирование
Автоматизированная технология проектирования
Типовая технология проектирования
Типовая параметрически-ориентированная технология
Типовая модельно-оринтированная технология.

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

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

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

Классификация − это система распределения объектов (предметов, явлений, процессов, понятий) по классам в соответствии с определенным признаком.

При моделировании и проектировании данного программного продукта применяются классификаторы, отображенные в Таблице 9.

Таблица 9. используемые классификаторы

Наименование кодируемого объекта	Рабочее наименование	Кол-во знаков кода	Система кодирования	Вид классификатора
IDтовара	IDт	4	Порядковая	Локальный
IDпокупателя	IDп	4	Порядковая	Локальный
IDсотрудника	IDс	4	Порядковая	Локальный
IDчека	IDч	4	Порядковая	Локальный

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

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

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

Этапы внешней машинной информационной базы: разделенный фонд данных, централизованный фонд данных, организация БД.

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

Основные подходы к построению внутри машинной ИБ:

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

Виды массивов: входные (первичные), основные (базовые), рабочие (промежуточные), выходные (результатные).

Массив данных – конструкция данных, компоненты которой идентичны по своим характеристикам.

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

Файл – идентифицированная совокупность экземпляров полностью описанного в конкретной программе.

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

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

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

2.1 Выбор средства для моделирования предметной области решаемой задачи

В основе проектирования ИС должно лежать моделирование предметной области.

Предметная область - это мысленно ограниченная область реальной действительности, подлежащая описанию или моделированию и исследованию.

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

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

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

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

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

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

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

При компьютерном моделировании сложных систем c успехом используются объектно- ориентированные языки. Владение объектно-ориентированным языком программирования (например, Java) и доступ к обширной библиотеке ресурсов составляют необходимое, но не достаточное условие для создания объектной системы. Очень важную роль в процессе ее разработки играют анализ и проектирование системы с точки зрения объектной методологии. Аббревиатура UML означает Unified Modeling Language (унифицированный язык моделирования). Этот язык представляет собой систему обозначений, которая базируется на диаграммах и предназначается для моделирования систем на основе объектно-ориентированного подхода.

Основная идея объектно-ориентированного анализа и проектирования (object-oriented analysis and design) состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий или сущностей). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. Например, в случае библиотечной информационной системы среди понятий должны присутствовать Book(книга), Library (библиотека) и Patron(клиент). В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. Например, в библиотечной системе программный объект Воok может содержать атрибут title (название) и метод print (печатать) И наконец, в процессе конструирования (construction) или объектно-ориентированно программирования (object-oriented programming) обеспечивается реализация разработанных компонентов, таких как класс Book на языке C++, Java. Smalltalk или Visual Basic.

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

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

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

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

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

1. Планирование — планирование, определение требований, создание прототипов и т.д.

2. Построение — конструирование системы.

3. Развертывание — ввод системы в действие. Итеративный процесс разработки

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

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

2.2 Информационная модель и ее описание

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

Справочник товаров;
Справочник покупателей;
Справочник сотрудников;
Справочник покупок.

Информационная модель изображена на рисунке 3.

Безымянный.png

Рисунок 3. Информационная модель

Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

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

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

Рассмотрим диаграмму прецедентов «Магазин компьютерной техники». На Рисунке 3 приведена диаграмма прецедентов для рассматриваемого примера.

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

В этом примере можно выделить следующие субъекты и соответствующие им прецеденты:

Директор – запрашивает работнику о состояния магазина (прецедент «Запрос о состоянии магазина») и работник передаёт эти отчеты в одном отчете ( прецедент «Отчет о состоянии магазина») .

Продавец - работает с клиентами: продает товар (прецедент «Продажа товара»); проявляет инициативу к клиенту (прецедент «Запрос клиента»); отвечает на вопросы клиента (прецедент «Проверка наличия товара»); отвечает за прием товара (прецедент «Склад»).

Поставщик - заинтересован в реализации прецедента («Склад»), как выдача товара, но не является основным или вспомогательным исполнителем.

Клиент - вынуждает продавца инициировать один из прецедентов..

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

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

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

Объекты – это обычно именованные или анонимные экземпляры (instances) классов, однако они могут также представлять экземпляры других элементов (things), таких как кооперации, компоненты и узлы. Диаграммы последовательности используются для иллюстрации динамического представления (view) системы.

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

Рисунок 5. Диаграмма последовательности «Учет продаж»

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

Рисунок 6. Диаграмма состояний процесса «Учет продаж»

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

Основными элементами диаграмм деятельности являются:
•овалы, изображающие действия объекта;
• линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И"};
• ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");
• стрелки — отражают последовательность действий, могут иметь метки условий.
На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы.

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

Рисунок 7. Диаграмма деятельности «Учет продаж»

Класс (class) - категория вещей, которые имеют общие атрибуты и операции.

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

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

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

На данной диаграмме (см. рис. №4) представлено 11 классов: клиент, продавец, реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, AIS, генератор заказов, поставщик и склад.
Каждому классу присвоен свой стереотип, характеризующий его функциональность. Граничные классы – клиент и поставщик, т.е. классы, расположенные на границе системы и всей окружающей среды. Управляющий класс-AIS, т.е. отвечает за координацию действий других классов. Классы-сущности – реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, генератор заказов, поставщик и склад.
Для каждого класса определены свои связи, атрибуты и операции с указанием типов. Все связи диаграммы – это связи зависимости.

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

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

ЗАКЛЮЧЕНИЕ

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

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

Таким образом была выполнена поставленная цель – смоделирована реализация операций процесса «Учет продаж». Разработанная информационная система отвечает всем требованиям, предъявленным в рассмотренном исследовании.

СПИСОК ЛИТЕРАТУРЫ

Бекаревич Ю.Б., Пушкина Н.В. MS ACCESS 2000 за 30 занятий. - СПб.: БХВ - Петербург, 2001.
Боровиков В.В. MS ACCESS 2002. программирование и разработка баз данных и приложений. - СОЛОН-Р, 2002.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - М.: Финансы и статистика, 2002.
Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2004
Диго С.М. Базы данных: проектирование и использование. - М.: Финансы и статистика, 2005.
Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Баумана, 2003.
Информатика. Базовый курс.2-е издание / Под ред. С.В. Симоновича. - СПб.: Питер, 2008. - 640 с.: ил.
Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб: Питер, 2001.
Литвинская О.С. Проектирование базы данных в среде Microsoft Access. - Пенза: Издательство Пенз. гос. технол. акад., 2004.
Матюшкин-Герке А. Учебно-прикладные задачи в курсе информатики. Информатика и образование, №3-4, 5-6, 2007.
Орлов С.А. Технология разработки программного обеспечения: Учебник. - СПб.: Питер, 2002.
Робинсон С. MicrosoftAccess 2000 учебный курс. - СПб.: Питер, 2000.