Файл: Моделирование предметной области «Учет товаров» с помощью UML (Построение моделей бизнес-процессов, описывающих основную деятельность предприятия).pdf

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

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

2.1 Подготовка требований к модели бизнес-процессов

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

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

Для построения адекватной и корректной модели бизнес-процесса, которая успешно прослужит компании длительное время, следует придерживаться нескольких базовых принципов:

1. Корректность синтаксиса. Синтаксис модели должен соответствовать выбранному языку моделирования. Большинство инструментов моделирования бизнес-процессов снабжены функциями проверки синтаксиса.

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

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

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

Таблица 1 – Требования к бизнес-процессам

В результате были определены основные бизнес-процессы.

2.2 Выделение основных и вспомогательных бизнес-процессов

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

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

2.3 Обоснование необходимости построения всех типов диаграмм в UML

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

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

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

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

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

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

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

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

2.4 Построение моделей бизнес-процессов, описывающих основную деятельность предприятия

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

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

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

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

• «zav_sklad» (заведующий складом), который управляет вариантами использования:
• «oborot_mes» (оборот за месяц);
• «reviziya» (ревизия);
• «klad» (кладовщик), управляющий следующими вариантами использования:
• «get_tovar» (принять товар);
• «send_tovar» (отправить товар);
• «inventar» (инвентаризация).

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

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

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

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

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

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

По умолчанию существует одна диаграмма классов, называемая Главной (Main), на которой показывают пакеты классов модели, представленной в соответствии с рисунком 4.

Рисунок 4 – Главная диаграмма Классов системы учета товаров на складе магазина

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

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

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

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

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

В результате созданы несколько диаграмм классов, на которых также показаны классы и пакеты системы.

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

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

Диаграмма деятельности представлена в соответствии с рисунком 8.

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

• «sklad»;
• «Add/Select Tovar Form»;
• «Add/Select Postav Form»;
• «Card Sklad_Uchet»;
• «DataBase».

Рисунок 8 – Диаграмма деятельности

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

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

Объекты характеризуются поведением и состоянием, в котором находятся. Например, человек может быть новорожденным, младенцем, ребенком, подростком или взрослым. Другими словами, объекты что-то делают и что-то "знают". Диаграммы состояний применяются для того, чтобы объяснить, каким образом работают сложные объекты. Несмотря на то что смысл понятия "состояние" интуитивно понятен, все же приведем его определение в таком виде, в каком его дают классики и Zicom Mentor: