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

Содержание:

Введение

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

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

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

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

Объектом исследования является отдел «Склад магазина».

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

Целью курсовой работы является смоделировать предметную область «Учет товаров на складе магазина» с помощью UML.

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

1) сбор и анализ предметной области по учету товаров;

2) построить диаграмму вариантов использования;

3) построить диаграмму деятельности;

4) построить диаграмму последовательности;

5) построить диаграмму состояний;

6) построить диаграмму классов.

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

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

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

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

- повышение скорости обработки товарных потоков для организации ускоренного сбыта;

- минимизация потерь;

- снижение издержек;

- организация эффективного управления всеми бизнес-процессами.

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

• Приемка товара по количеству и качеству, размещение товара на складе;
• Отпуск товара со склада;
• Изменение свойств товара;
• Инвентаризация товаро-материальных ценностей.

UML (Unified Modeling Language) - это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования объектно-ориентированных систем. UML призван поддерживать процесс моделирования программных средств на основе объектно-ориентированного подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла программных средств, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.

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

По запросу Object Management Group (OMG) - организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных объектно-ориентированных методов - Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики. UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development -- MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML - это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process.

Словарь UML

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

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

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

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

· Ассоциация - это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе - с одной стороны, или для нахождения всех заказов в которых есть данный товар, - с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование - отношение вида «целое» - «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.

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

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

Диаграммы. В UML предусмотрены следующие диаграммы:

· Диаграммы, описывающие поведение системы:

· Диаграммы состояний (State diagrams),

· Диаграммы деятельностей (Activity diagrams),

· Диаграммы объектов (Object diagrams),

· Диаграммы последовательностей (Sequence diagrams),

· Диаграммы взаимодействия (Collaboration diagrams);

· Диаграммы, описывающие физическую реализацию системы:

· Диаграммы компонент (Component diagrams);

· Диаграммы развертывания (Deployment diagrams).

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

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

Система состоит из подсистем:

• Приемка ТМЦ;
• Размещение ТМЦ на складе;
• Отпуск ТМЦ;
• Изменение свойств товара;
• Проведение инвентаризаций;

Подсистема Приемка ТМЦ выполняет следующие операции:

• Ввод нового товара;
• Поиск товара;
• Сортировка товара;
• Изменение данных о товаре;
• Составление акта о расхождении.

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

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

Сортировка товаров может вестись по следующим реквизитам: наименование товара, группа товара.

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

Подсистема Размещение ТМЦ на складе выполняет следующие операции:

• Поиск свободного адреса для размещения товара;
• Закрепление по адресу хранения данных о размещенном товаре;
• Изменение данных о товаре (количество, расположение);
• Удаление записи о товаре, освобождение адреса.

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

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

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

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

Подсистема Отпуск ТМЦ выполняет следующие операции:

Получение заявки на товары;

Поиск в БД товаров, согласно заявке, проверка наличия по остаткам;

Составление расходной накладной;

Изменение данных об остатках товаров, проведение накладной;

Отбор товаров согласно накладной Отпуск товаров согласно накладной.

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

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

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

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

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

Подсистема Изменение свойств товара выполняет следующие операции:

Получение распоряжения об изменении свойств товаров;

Поиск товаров в БД;

Изменение данных о товаре;

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

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

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

Подсистема Проведение инвентаризаций выполняет следующие операции:

Формирование остатков ТМЦ на начало инвентаризации;

Формирование сводной инвентаризационной описи, введение фактических остатков товаров;

Формирование сличительной ведомости;

Получение результатов инвентаризации.

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

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

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

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

2. Подготовка требований и построение моделей.

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

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

В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose 2000 Enterprise v6.5.

Выводы

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

- диаграмму вариантов использования;

- диаграмму последовательности;

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

- диаграмму классов;

- диаграмму состояний;

- диаграмму компонентов;

- диаграмму размещения;

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

Создание диаграммы прецедентов.

Диаграммой прецедентов, или использования (use case diagram) называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения и ассоциации) между ними.

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

Элементы диаграммы:

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

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

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

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

Между вариантами использования и действующими лицами используется вязь коммуникации (communication). Направление стрелки позволяет понять, кто инициирует коммуникацию.

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

Создание диаграммы последовательности

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

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

В данной модели для создания диаграммы последовательности был использован вариант использования «get_tovar» (принять товар), взятый из предыдущей диаграммы прецедентов (рисунок 2).

Рисунок 2 - Диаграмма последовательности «get_tovar» (принять товар)

На данную диаграмму помещены следующие объекты:

- «klad» (кладовщик) - действующее лицо;

- «Add/Select Tovar Form» - содержит форму ввода или выбора товара;

- «Add/Select Postav Form» - содержит форму ввода или выбора поставщика товара;

- «Card Sklad_Uchet» - форма карты складского учета, которая создается после ввода всех данных и является итоговым документом;

- «DataBase» - содержит информацию о поставщиках и товарах, на основании информации этого объекта формируется карта складского учета

Сообщения между объектами на диаграмме:

- «Open» - открыть форму;

- «Cancel» - отмена действия;

- «Query to DataBase» - запрос к базе данных на выбор товара;

- «Answer from DataBase» - наименование товара;

- «Query to DataBase on generation Sklad_Uchet card» - запрос к базе данных на выбор поставщика и генерацию карты складского учета;

- «Generate» - карта складского учета.

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

Выводы

1. На диаграмме последовательности «get_tovar» (принять товар), размещены пять объектов и девять сообщений между ними.

2. Каждый объект был соотнесен с классом, а сообщение с операцией.

Создание диаграммы сотрудничества

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

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

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

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

Согласно созданной выше диаграмме «get_tovar» (принять товар), была создана диаграмма сотрудничества (рисунок 3).

Рисунок 3 - Диаграмма сотрудничества для варианта использования «get_tovar» (принять товар)

На диаграмме расположены объекты:

- «sklad» ;

- «Add/Select Tovar Form»;

- «Add/Select Postav Form»;

- «Card Sklad_Uchet»;

- «DataBase».

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

Выводы

Была создана диаграмма сотрудничества «get_tovar» (принять товар), на которой представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее разобраться в последовательности событий.

Создание диаграммы классов

Диаграммы классов (class diagram) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (сlasses) и интерфейсов (interfaces). На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами Данный тип диаграмм противоположен по содержанию диаграмме сотрудничества, на которой отображаются объекты системы.

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

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

Рисунок 4 - Главная диаграмма классов информационной подсистемы

Внутри каждого пакета также имеется «главная диаграмма», включающая в себя все классы этого пакета (рисунок 5, 6).

Рисунок 5 - Диаграмма классов «form»

Рисунок 6 - Диаграмма классов «DataBase»

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

Рисунок 7 - Диаграмма классов «get_tovar» (принять товар)

Выводы

1. На диаграмме классов «get_tovar» (принять товар) были представлены все классы и взаимосвязи между ними.

2. Указанная множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Так же были добавлены атрибуты и методы в некоторые классы.

Создание диаграммы состояний для классов

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

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

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

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

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

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

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

В данном курсовом проекте диаграмма состояний создается для варианта использования «get_tovar» (принять товар). Она представлена на рисунке 8.

Рисунок 8 - Диаграмма состояний для варианта использования «get_tovar» (принять товар)

Выводы

На диаграмме состояний расположены следующие состояния:

- начальное состояние «Start»;

- конечное «exit» состояние;

- «Initialization» (инициализация);

- «SomeStop» (выполнение приостановлено);

- «Cancel» (отменен);

- «Get» (выполнен).

Для каждого из состояний созданы следующие действия:

- «StoreDate» (сохранить дату) на входе для состояния «Initialization» (инициализация);

- «Info Tovar» (собрать информацию о товаре и поставщиках);

- «Add» (добавить к набору товаров);

- «StoreData» (сохранить дату отмены) на выходе;

- «Card Ucheta» (карта учета) - на выходе формируется складская карта учета.

Создание диаграммы компонентов

Диаграммы компонентов (component diagram) предназначены для распределения классов и объектов по компонентам при физическом проектировании системы. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Часто данный тип диаграмм называют диаграммами модулей.

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

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

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

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

На рисунке 9 показаны компоненты пакета «Form». Они содержат классы пакета «Form» логического представления системы.

Рисунок 9 - Диаграмма компонентов пакета «Form»

На рисунке 10 показаны компоненты пакета «DataBase». Они содержат классы пакета «DataBase» логического представления системы.

Рисунок 10 - Диаграмма компонентов пакета «DataBase»

Общая диаграмма компонентов для рассматриваемого варианта использования «get_tovar» (принять товар) на рисунке 11.

Рисунок 11- Диаграмма компонентов для варианта использования «get_tovar» (принять товар)

Выводы

1. Так как система разрабатывается на языке C++, то у каждого класса имеется свой собственный заголовочный файл и файл с расширением *.cpp.

2. Для каждого класса была создана спецификация пакета и тело пакета. Они соединены с помощью связей dependency.

Создание диаграммы размещения

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

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

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

Построенная диаграмма размещения показана на рисунке 12.

Рисунок 12 - Диаграмма размещения

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

Выводы

1. На созданной диаграмме размещения расположены процессоры «Server» и «Client»,а также устройство «Printer».

2. Между этими элементами проведены следующие связи:

- От «Server» к «Client»;

- От «Client» к «Printer».

3. Кроме этого, созданы процессы «Get_tovarServerE» на процессоре «Server» и « Get_tovarClientEXE» на процессоре «Client».

Заключение

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

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

Диаграмма активности;

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

Диаграмма состояний.

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

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

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

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

Диаграмма активности;

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

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

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

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

Снижение объема бумажной документации;

Снижение затрат на хранение бумажной документации;

Снижение числа необходимых работников;

Облегчение доступа и поиска необходимой информации;

Повышение скорости обработки товарных потоков для организации ускоренного сбыта;

Минимизация потерь;

Снижение издержек;

Организация эффективного управления всеми бизнес-процессами.

Увеличение скорости принятия управленческих решений;

Увеличение правильности управленческих решений;

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

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

1.  Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2012.- 432 с., ил.

2. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2009.- 581 с., ил.

3. Вендров А.М. «CASE-технологии. Современные методы и средства проектирования информационных систем», cтатья c сайта www.citforum.ru

4. Маклаков С.В. Bpwin и Erwin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ, 2015 — 256 с.

5. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом «Вильямс», 2001. - 496 с., ил.

6. Уэнди Боггс, Майкл Боггс. UML и Rational Rose. Лори, 2014 — 510 с.

7. www.interface.ru/rational/rosemain.htm