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

Содержание:

Введение

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

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

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

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

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

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

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

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

• 1. Сбор и анализ предметной области по учету товаров;
  2. построить диаграмму вариантов использования;
  3. построить диаграмму деятельности;
  4. построить диаграмму последовательности;
  5. построить диаграмму состояний;
  6. построить диаграмму классов.

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

1.1 Описание организации

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

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

Основные задачи начальника склада:

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

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

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

Рисунок 1 – Схема деятельности начальника склада

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

Рисунок 2 – Документация, с которой работает начальник склада

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

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

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

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

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

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

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

Таблица 1 – Перечни и источники используемых документов

№ п/п	Перечень документов	Источники документов
1	Приходные накладные	Поставщики
2	Журнал учета приходных накладных	Начальник склада
3	Карточка складского учета материалов	Начальник склада
4	Журнал учета расходных накладных	Начальник склада
5	Расходные накладные (требование)	Начальник склада

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

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

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

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

Основные недостатки в ведении складского учета:

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

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

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

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

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

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

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

• 1. Прием и учет товаров:
  • приход товаров, прием товаров (проверка соответствия количества и качества товаров);
  • занесение товаров в карточку складского учета материалов и занесение приходной накладной в журнал прихода товаров;
  • занесение карточки складского учета материалов в картотеку;
  1. Расход товаров:
  • на склад поступает требование от главного инженера, на основании которого проверяется лимитно-заборная ведомость и наличие товаров на складе;
  • при соответствии количества необходимого товаров и соблюдении норм лимитно-заборной ведомости происходит списание товаров с карточки складского учета материалов и выписка расходной накладной, которая регистрируется в журнале расхода товаров.

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

Ведение учета с использованием ЭВМ позволит:

1. Упорядочить процесс учета и ведения деятельности.
2. Быстро и оперативно находить нужную информацию.
3. Представлять информацию в оптимально удобном виде.
4. Рационально хранить информацию.
5. Оперативно составлять аналитические отчеты.

1.2 Цель работы

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

1. Учет движения товаров:
   • прием товаров на склад;
   • выдача товаров со склада.
2. Анализ движения товаров:
   • обработка данных учета – формирование отчетов.

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

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

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

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

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

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

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

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

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

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

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

Номер	Название	Входная информация	Выходная информация	Дата реализации	Автор	Описание
1	Прием и учет товаров	Приходная накладная	Журнал учета товаров	11.02.15
2	Хранение товаров	Журнал учета товаров	Карточка складского учета	11.02.15
3	Расход товаров	Расходные накладные	Журнал учета расходных накладных по товарам	11.02.15
4	Формирование отчетности	Приходные, расходные накладные	Журнал учета книжного фонда	11.02.15

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

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:

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

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

Результат выполнения этапов по созданию диаграммы состояний представлен на рисунке 9.

Рисунок 9 – Диаграмма состояний

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

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

В этом разделе будет разработана диаграмма последовательности, которая представлена в соответствии с рисунком 10.

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

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

• «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» - карта складского учета.

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

3. Анализ бизнес-процессов, проведение реинжиниринга БП

3.1 Анализ моделей. Проведение реинжиниринга бизнес-процессов

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

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

Входная информация.

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

• • № приходной накладной;
  • Наименование поставщика;
  • Дата;
  • Вид ТМЦ;
  • Количество;
  • Цена.

Нормативно-справочная информация.

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

Выходная информация.

Все отчеты формируются автоматически посредством запросов к БД.

Отчет об остатках ТМЦ на складе. Данный документ содержит перечень видов ТМЦ, размещенных на складе, с указанием их количества.

Отчет о динамике расходования ТМЦ. В нем отражается динамика изменения объемов расходования по группам ТМЦ за выбранный период.

Товарный отчет. В этом отчете отражается информация относительно прихода, расхода и остатков ТМЦ на складе.

Отчет о списании ТМЦ. Данный документ содержит перечень и количество списанных ТМЦ на определенном складе за выбранный период.

Акт списания. В нем отражается перечень и количество списанных ТМЦ. [2].

3.2 Формирование предложений по улучшению БП

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

• поступление новых товаров;
• расход товаров;
• движение товаров.

3.3 Корректировка модели БП

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

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

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

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

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

На основе представленных выводов спроектируем модели бизнес-процессов, которые представлены в соответствии с рисунками 11, 12.

Рисунок 11 – Диаграмма «Учет товаров на складе магазина»

Рисунок 12 – Декомпозиция диаграммы

3.4 Генерация программного кода на основе построенных моделей

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, unit2, Grids, DBGrids, ComCtrls, StdCtrls, DBCtrls, Menus, myword,

ExtCtrls;

type

TForm1 = class(TForm)

Pagecontrol1: TPageControl;

ts2: TTabSheet;

ts4: TTabSheet;

ts5: TTabSheet;

ts6: TTabSheet;

ts7: TTabSheet;

dbgrd2: TDBGrid;

dbgrd4: TDBGrid;

dbgrd5: TDBGrid;

dbgrd6: TDBGrid;

dbgrd7: TDBGrid;

dbgrd8: TDBGrid;

button2: TButton;

button3: TButton;

button4: TButton;

button6: TButton;

button7: TButton;

button5: TButton;

button8: TButton;

button9: TButton;

button10: TButton;

label3: TLabel;

button11: TButton;

button12: TButton;

button13: TButton;

Button1: TButton;

Button14: TButton;

Button15: TButton;

button20: TButton;

button21: TButton;

button22: TButton;

mm1: TMainMenu;

mniN1: TMenuItem;

mniN2: TMenuItem;

mniN3: TMenuItem;

mniN4: TMenuItem;

N1: TMenuItem;

N2: TMenuItem;

N4: TMenuItem;

mniCjhnbhjdrf1: TMenuItem;

mniN5: TMenuItem;

mniN6: TMenuItem;

mniN7: TMenuItem;

mniN8: TMenuItem;

mniN9: TMenuItem;

mniN10: TMenuItem;

mniN11: TMenuItem;

mniN12: TMenuItem;

dbgrd9: TDBGrid;

lbl1: TLabel;

N5: TMenuItem;

dblkcbbts8: TDBLookupComboBox;

ts1: TTabSheet;

button23: TButton;

button24: TButton;

button25: TButton;

dbgrd1: TDBGrid;

N6: TMenuItem;

N7: TMenuItem;

Label1: TLabel;

Label4: TLabel;

Label5: TLabel;

Button19: TButton;

edit3: TEdit;

N8: TMenuItem;

N9: TMenuItem;

Label7: TLabel;

Label6: TLabel;

Label9: TLabel;

DBLookupComboBox3: TDBLookupComboBox;

Edit1: TEdit;

Button26: TButton;

DBLookupComboBox4: TDBLookupComboBox;

Button27: TButton;

Button28: TButton;

Label2: TLabel;

Label10: TLabel;

Label11: TLabel;

Button29: TButton;

N10: TMenuItem;

ts3: TTabSheet;

Label12: TLabel;

dbgrd3: TDBGrid;

Button16: TButton;

Button17: TButton;

Button18: TButton;

Button30: TButton;

Label16: TLabel;

Label17: TLabel;

Label18: TLabel;

cbb1: TComboBox;

cbb2: TComboBox;

Button31: TButton;

N11: TMenuItem;

N12: TMenuItem;

N13: TMenuItem;

Button32: TButton;

Button33: TButton;

DBLookupComboBox1: TDBLookupComboBox;

Label13: TLabel;

DBLookupComboBox5: TDBLookupComboBox;

Label14: TLabel;

Button34: TButton;

N14: TMenuItem;

N15: TMenuItem;

Label15: TLabel;

dblkcbb1: TDBLookupComboBox;

label19: TLabel;

label20: TLabel;

dblkcbb2: TDBLookupComboBox;

button36: TButton;

mniN16: TMenuItem;

mniN17: TMenuItem;

label21: TLabel;

label22: TLabel;

cbb3: TComboBox;

button37: TButton;

label23: TLabel;

label24: TLabel;

label25: TLabel;

dblkcbb3: TDBLookupComboBox;

dblkcbb4: TDBLookupComboBox;

button38: TButton;

button39: TButton;

mniN18: TMenuItem;

mniN19: TMenuItem;

procedure button9Click(Sender: TObject);

procedure button11Click(Sender: TObject);

procedure button3Click(Sender: TObject);

procedure button4Click(Sender: TObject);

procedure button8Click(Sender: TObject);

procedure button7Click(Sender: TObject);

procedure button10Click(Sender: TObject);

procedure ts6ContextPopup(Sender: TObject; MousePos: TPoint;

var Handled: Boolean);

procedure button6Click(Sender: TObject);

procedure button2Click(Sender: TObject);

procedure button13Click(Sender: TObject);

procedure button5Click(Sender: TObject);

procedure button12Click(Sender: TObject);

procedure ts7ContextPopup(Sender: TObject; MousePos: TPoint;

var Handled: Boolean);

procedure Button15Click(Sender: TObject);

procedure Button14Click(Sender: TObject);

procedure Button16Click(Sender: TObject);

procedure Button17Click(Sender: TObject);

procedure Button18Click(Sender: TObject);

procedure Button1Click(Sender: TObject);

procedure button20Click(Sender: TObject);

procedure button21Click(Sender: TObject);

procedure button22Click(Sender: TObject);

procedure button23Click(Sender: TObject);

procedure button24Click(Sender: TObject);

procedure button25Click(Sender: TObject);

procedure mniN2Click(Sender: TObject);

procedure mniN3Click(Sender: TObject);

procedure mniN4Click(Sender: TObject);

procedure N1Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure N5Click(Sender: TObject);

procedure mniN14Click(Sender: TObject);

procedure N8Click(Sender: TObject);

procedure Button19Click(Sender: TObject);

procedure N9Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure DBLookupComboBox3Click(Sender: TObject);

procedure Edit1Change(Sender: TObject);

procedure Button28Click(Sender: TObject);

procedure Button29Click(Sender: TObject);

procedure N10Click(Sender: TObject);

procedure Button26Click(Sender: TObject);

procedure Button27Click(Sender: TObject);

procedure Button31Click(Sender: TObject);

procedure N11Click(Sender: TObject);

procedure N12Click(Sender: TObject);

procedure N13Click(Sender: TObject);

procedure Button32Click(Sender: TObject);

procedure Button33Click(Sender: TObject);

procedure Button30Click(Sender: TObject);

procedure Button34Click(Sender: TObject);

procedure N14Click(Sender: TObject);

procedure N15Click(Sender: TObject);

procedure button36Click(Sender: TObject);

procedure mniN16Click(Sender: TObject);

procedure button37Click(Sender: TObject);

procedure button38Click(Sender: TObject);

procedure button39Click(Sender: TObject);

procedure mniN18Click(Sender: TObject);

procedure mniN19Click(Sender: TObject);

procedure mniN17Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

Заключение

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

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

Для решения данной задачи было использовано CASE – средство RationalRose.

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

1. Диаграмма вариантов использования
2. Диаграмма последовательности
3. Кооперативная диаграмма
4. Диаграмма классов
5. Диаграмма состояний

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

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

1. http://www.interface.ru/rational/rosemain.htm
2. А.М. Вендров “CASE-технологии. Современные методы и средства проектирования информационных систем”, cтатья c сайта http://www.citforum.ru
3. Маклаков С.В. Bpwin и Erwin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ, 2000 – 256 с.
4. Уэнди Боггс, Майкл Боггс. UML и Rational Rose. Лори, 2004 – 510 с.

Сокращения

БП – Бизнес-процесс

КП – Курсовой проект

UML – Unified Modeling Language