Файл: Моделирование предметной области «Учет товаров» с помощью UML (Характеристика предметной области).pdf

ВВЕДЕНИЕ

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

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

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

1. Характеристика предметной области

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

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

Основные функции выполняют заведующий складом и кладовщик. Заведующий складом проводит ревизии и составление документ-оборота за период. Кладовщик осуществляет инвентаризацию и прием/выдачу товара.

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

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

Для Моделирования информационной подсистемы учета движения товаров на складе был выбран язык UML (Unified Modeling Language).

---

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

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

В качестве среды разработки информационной подсистемы был использован программный продукт Online Diagrame Editor.

2. Моделирование предметной области учет товара на складе с использованием языка UML

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

• диаграмму вариантов использования (диаграмма прецедентов);
• диаграмму последовательности;
• кооперативная диаграмма;
• диаграмма классов и диаграмма пакетов;
• диаграмму состояний:
• диаграмму компонентов;
• диаграмму размещения;

1)       Диаграмма вариантов использования (диаграмма прецедентов) по решаемой задаче.

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

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

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

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

---

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

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

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

В качестве актеров на диаграмме (рисунок 1.1) используются объекты:

• «warehouse_manager» (заведующий складом), который управляет вариантами использования:
• «monthly_turnover» (оборот за месяц);
• «audit» (ревизия);
• «storekeeper» (кладовщик), управляющий следующими вариантами использования:
• «get_product» (принять товар);
• «send_product» (отправить товар);
• «inventory» (инвентаризация).

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

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

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

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

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

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

---

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

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

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

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

• «storekeeper» (кладовщик) – действующее лицо;
• «Add/Select prouct – содержит форму ввода или выбора товара;
• «Add/Select delivery from» – содержит форму ввода или выбора поставщика товара;
• «Card warehouse accounting» – форма карты складского учета, которая создается после ввода всех данных и является итоговым документом;

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

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

• «Open» – открыть форму;
• «Cancel» – отмена действия;
• «Query to DataBase» – запрос к базе данных на выбор товара;
• «Answer from DataBase» - наименование товара;
• «Query to DataBase on generation warehouse accounting card» - запрос к базе данных на выбор поставщика и генерацию карты складского учета;
• «Generate» - карта складского учета.

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

3)       Кооперативная диаграмма

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

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

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

---

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

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

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

• «storekeeper»;
• «Add/Select product»;
• «Add/Select delivery form»;
• «Card warehouse accounting»;
• «DataBase».

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

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

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

4)       Диаграмма классов и диаграмма пакетов.

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

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

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

---