Модель idef0 бизнес процесса оптовая фирма

Проблематика

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

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

В связи с этим я решил описать, то есть создать некую почти универсальную модель. Я к ней шёл уже, наверное, лет десять.Конечно, я не занимался ее разработкой все это время. Но уже  десять лет назад у меня были первые, скажем так, черновики такой модели.

Почему функции, а не процессы?

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

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

Как  читать модель

Модель нужно читать слева направо, сверху вниз. То есть сначала мы читаем название функции, потом, что в нее входит, что вводится, что выводится. И так шаг за шагом каждую модель. Затем, если мы хотим понять, что нам необходимо, чтобы эта функция работала, мы смотрим на стрелки, которые идут снизу вверх. Это механизмы, которые необходимы: программное обеспечение, сотрудники и так далее. 

Что делать, если  за несколько функций отвечает один человек

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

Механизмы — виртуальное понятие. То есть у вас может быть один человек, который выполняет несколько разных функций. Например, в каких-то случаях может отсутствовать руководитель или, например, оператор ЭВМ. В вашем случае продажник может сам заниматься созданием заявки в учетной системе, создавать и печатать документы, и он же несет ответственность за то, что происходит с этими заявками дальше. 

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

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

А есть ли такая модель для  производственной организации? 

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

Можно ли сделать программное обеспечение на основе этой модели?

Да, можно. Я уже создавал ERP-систему для одной из организаций, которая построена по этому принципу. То есть я сначала описывал модель в IDEF0, а потом уже – — процессы в BPMN и, соответственно, автоматизировал, т.е. разработал программное обеспечение.

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

Как я давал названия

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

Модель

Диаграмм A-0

Диграмма A0

Привлечь покупателя

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

Продать товар

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

Закупить товар

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

Сохранить товар

После того, как поставщик нам товар этот отгрузил, мы должны его принять от поставщика. То есть «сохранить товар» — это функция, которая принимает на входе товар и выдаёт его получателю.

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

Доставить товар

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

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

Пример описания предметной области.

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

Для
директора должны формироваться следующие
отчеты:

1. Отчет
   по продажам;

2. Отчет
   по поставщикам;

3. Отчет
   продавцам;

4. Отчет
   по распределению товара по магазинам.

Отчет
по продажам для директора должен в
наглядной форме показывать какие модели
самые продаваемые. Каким-то образом
формировать рейтинг моделей. Например,
так:

1. количество
   проданных сумок в день – по моделям;

2. количество
   проданных сумок за неделю – по моделям.

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

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

Рейтинг
поставщика может определяться следующим
образом:

1. по
   умолчанию 1;

2. за
   каждую проведенную сделку +1;

3. за
   срыв сделки -2;

4. за
   просроченную -1;

5. за
   продаваемость товара +1;

6. директор
   может повысить или понизить рейтинг.

Отчет
по продавцам – показывает количество
проданных сумок в месяц и тоже самое в
денежном эквиваленте.

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

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

1. по
   поставщикам;

2. общий
   список товаров, с возможностью заносить
   информацию о поступившем товаре.

Для
продавцов:

1. список
   товаров по магазину, с возможностью
   заносить информацию о проданном товаре;

2. возможность
   посмотреть на какую сумму сделаны
   продажи этим продавцом на текущую дату.

Построение idef0 модели.

Шаг
1. Построение
модели начинается с определения границ
системы, цели и точки зрения модели.

Необходимо
определить границы системы для модели
«Информационная система для сети
магазинов по продажам сумок». Для
этого:

1. Составляется
   список всех объектов, которые имеют
   отношение к системе.

2. Составляется
   список всех функций, имеющих отношение
   к системе.

Список
объектов:

1. характеристики
   сумок

2. информация
   о магазинах

3. информация
   о поставщиках

4. информация
   о заказах

5. информация
   о сотрудниках

6. рейтинг
   поставщика

7. рейтинг
   модели

8. рейтинг
   продавца

9. премии

10. цены

11. спрос

Список
функций:

1. Записать
   заказ сумок

2. Проследить
   выполнение заказа сумок

3. Распределить
   сумки по магазинам

4. Записать
   информацию о продаже сумок

5. Выявить
   самые продаваемые модели

6. Узнать
   рейтинг поставщиков

7. Узнать
   рейтинг продавцов

8. Определить
   размер премии по результатам продаж

9. Корректировать
   цены

10. Подсчитать
    прибыль

Шаг
2. Теперь
определяем цель и точку зрения системы.
То есть нужно сформулировать цель модели
«Информационная система для сети
магазинов по продажам сумок» и
определить, с чьей точки зрения будет
описана работа этой системы.

Для
этого:

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

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

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

Список
вопросов:

1. Как
   увеличить прибыль фирмы?

2. 2.
   Как выбрать нужный товар для заказов?

3. 3.
   Как выбрать надежного поставщика?

4. 4.
   Как правильно распределить товар по
   магазинам?

5. 5.
   Как поощрять персонал?

6. 6.
   Как увеличить продажи?

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

Точка
зрения:

1. директор
   компании

2. продавцы

3. отдел
   закупок

4. клиент

5. независимый
   консультант

6. друг

Точка
зрения:
директор компании

Рис.
4. Контекстная диаграмма IDEF0 модели

Шаг
4. Построение
диаграммы А0

Рис.
5. Диаграмма второго уровня детализации
(А0).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Содержание:

Введение

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

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

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

Объект исследования – склад торгового предприятия.

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

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

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

I. Теоретическая часть

Глава 1. Анализ предметной области

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

Рисунок 1 — Схема информационных потоков предприятия

Рассмотрим информационные потоки предприятия (рис.1). Заказчик (юридическое лицо) делает заявку у менеджера (сбрасывает по факсу или договаривается по телефону) на нужную ему продукцию.

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

Оформленная заявка поступает в отдел снабжения, где все заявки сортируются в зависимости от товара, от сроков поставки и т.д. и определяется примерная дата поступления товара на склад. Менеджер, имея эти данные, уточняет сроки доставки товара с клиентом [2, с.124].

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

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

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

Модель в IDEF0 строится на основе организационной структуры. В этом случае иерархия объектов в модели должна соответствовать иерархии структурных подразделений предприятия [3, с.89].

Организационная структура типового торгового предприятия показана на рис. 2.

Рисунок 2 – Организационная структура торгового предприятия

Поскольку, в рамках данной курсовой работы мы рассматриваем единичный бизнес-процесс «Управление складом», функциональную диаграмму построим для персонала склада. Контекстная диаграмма бизнес-процесса «Управление складом» в нотации IDEF0 [4, с.34] показана на рис. 3.

Рисунок 3 – Контекстная диаграмма IDEF0

Диаграмма декомпозиции контекстной диаграммы бизнес-процесса «Управление складом» в нотации IDEF0 показана на рис. 4.

Рисунок 4 — Диаграмма декомпозиции контекстной диаграммы IDEF0

Как видно из рис. 4, бизнес-процесс «Управления складом» делится на три основных подпроцесса:

1. Пием товара.
2. Хранение товара.
3. Отгрузка и возврат товара.

Входными данными бизнес-процесса «Управление складом» являются:

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

Выходными данными бизнес-процесса «Управление складом» являются:

• информация о выданном товаре;
• информация о списанном товаре;
• отчетная документация.

Для построения модели предметной области в UML, выделим Акторов системы. Актор — это роль, которую выполняет пользователь или другая система, при взаимодействии с проектируемой системой. Каждый актор имеет уникальное имя.

Акторами проектируемой модели являются:

1. Менеджер.

2. Бухгалтер.

3. Сотрудник склада.

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

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

Глава 2. Построение диаграммы вариантов использования

Диаграмма вариантов использования применяется для получения самого общего представления о функциональности системы. Она дает представление о том, как Актор (активный субъект системы) взаимодействует с другими субъектами, или же внешними системами [5, с.132].

Общая диаграмма вариантов использования показана на рис. 5.

Рисунок 5 – Обща я диаграмма вариантов использования

Описание общей диаграммы.

1. Расход товара.

Менеджер проверяет наличие товара на складе. Если товар есть в достаточном количестве, оформляет счет на оплату товара.

Бухгалтер, после поступления оплаченного счета, оформляет расходную накладную и передает ее менеджеру.

Менеджер, на основании накладной формирует заказ.

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

2. Приход товара.

Менеджер проверяет наличие товара и по результатам проверки формирует заказ.

Бухгалтер проплачивает счет поставщика и оформляет приходную накладную.

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

Рассмотрим диаграммы вариантов использования для каждого Актора системы.

На рис. 6 показана диаграмма вариантов использования для Актора Менеджер.

Рисунок 6 – Диаграмма вариантов использования Менеджера

Описание диаграммы вариантов использования Менеджера.

1. Приход товара.

Менеджер проверяет наличие товара, в случае. Если товар отсутствует, или его мало, менеджер оформляет заказ на поставку и передает бухгалтеру счет поставщика на оплату.

2. Расход товара.

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

На рис. 7 показана диаграмма вариантов использования для Актора Бухгалтер.

Рисунок 7 — Диаграмма вариантов использования Бухгалтера

Описание диаграммы вариантов использования Бухгалтера.

1. Приход товара.

После получения от Менеджера счета на оплату товара поставщику, Бухгалтер оплачивает счет и оформляет приходную накладную при получении товара от поставщика.

2. Расход товара.

Бухгалтер формирует расходную накладную после оплаты счета на товар клиентом.

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

Рисунок 8 — Диаграмма вариантов использования Сотрудника склада

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

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

Глава 3. Построение диаграммы последовательностей и диаграммы сотрудничества

Диаграмма последовательностей отображает действия Актора в той последовательности, в которой он их выполняет [5, с.138].

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

Построим диаграмму последовательности и диаграмму сотрудничества Актора Менеджер для основных прецедентов.

Диаграмма последовательности Менеджера для прецедента «Проверяет наличие товара» показана на рис. 9.

Рисунок 9 — Диаграмма последовательности Менеджера для прецедента «Проверяет наличие товара»

Диаграмма сотрудничества Менеджера для прецедента «Проверяет наличие товара» показана на рис. 10.

Рисунок 10 — Диаграмма сотрудничества Менеджера для прецедента «Проверяет наличие товара»

Диаграмма последовательности Менеджера для прецедента «Формирует счет на оплату» показана на рис. 11.

Рисунок 11 — Диаграмма последовательности Менеджера для прецедента «Формирует счет на оплату»

Диаграмма сотрудничества Менеджера для прецедента «Формирует счет на оплату» показана на рис. 12.

Рисунок 12 — Диаграмма сотрудничества Менеджера для прецедента «Формирует счет на оплату»

Диаграмма последовательности Менеджера для прецедента «Формирует заказ на выдачу» показана на рис. 13.

Рисунок 13 — Диаграмма последовательности Менеджера для прецедента «Формирует заказ на выдачу»

Диаграмма сотрудничества Менеджера для прецедента «Формирует заказ на выдачу» показана на рис. 14.

Рисунок 14 — Диаграмма сотрудничества Менеджера для прецедента «Формирует заказ на выдачу»

Диаграмма последовательности Менеджера для прецедента «Формирует заказ поставщику» показана на рис. 15.

Рисунок 15 — Диаграмма последовательности Менеджера для прецедента «Формирует заказ поставщику»

Диаграмма сотрудничества Менеджера для прецедента «Формирует заказ поставщику» показана на рис. 16.

Рисунок 16 — Диаграмма сотрудничества Менеджера для прецедента «Формирует заказ поставщику»

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

Диаграмма последовательности Бухгалтера для прецедента «Оформляет приходную накладную» показана на рис. 17.

Рисунок 17 — Диаграмма последовательности Бухгалтера для прецедента «Оформляет приходную накладную»

Диаграмма сотрудничества Бухгалтера для прецедента «Оформляет приходную накладную» показана на рис. 18.

Рисунок 18 — Диаграмма сотрудничества Бухгалтера для прецедента «Оформляет приходную накладную»

Диаграмма последовательности Бухгалтера для прецедента «Формирует расходную накладную» показана на рис. 19.

Рисунок 19 — Диаграмма последовательности Бухгалтера для прецедента «Формирует расходную накладную»

Диаграмма сотрудничества Бухгалтера для прецедента «Формирует расходную накладную» показана на рис. 20.

Рисунок 20 — Диаграмма сотрудничества Бухгалтера для прецедента «Формирует расходную накладную»

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

Диаграмма последовательности Сотрудника склада для прецедента «Проводит инвентаризацию» показана на рис. 21.

Рисунок 21 — Диаграмма последовательности Сотрудника склада для прецедента «Проводит инвентаризацию»

Диаграмма сотрудничества Сотрудник склада для прецедента «Проводит инвентаризацию» показана на рис. 22.

Рисунок 22 — Диаграмма сотрудничества Сотрудник склада для прецедента «Проводит инвентаризацию»

Диаграмма последовательности Сотрудника склада для прецедента «Получает товар» показана на рис. 23.

Рисунок 23 — Диаграмма последовательности Сотрудника склада для прецедента «Получает товар»

Диаграмма сотрудничества Сотрудник склада для прецедента «Получает товар» показана на рис. 24.

Рисунок 24 — Диаграмма сотрудничества Сотрудник склада для прецедента «Получает товар»

Глава 4. Построение диаграммы классов

Диаграмма классов системы определяет типы классов системы и связи между ними. Классы представляют сущности предметной области (на этапе анализа) или элементы программной системы (на этапе проектирования и реализации) [5, с.155].

Основными элементами проектируемой системы являются классы, а также связи между ними. Классы характеризуются «атрибутами» и «операциями».

Диаграмма классов проектируемой системы «Складской учет» показана на рис. 25.

Рисунок 25 – Диаграмма классов

Основной сущностью в системе будет являться товар. Как известно из задания на проектирование, товар хранится на складе. Но понятия товара как некоего описания и товара, лежащего непосредственно на складе, отличаются друг от друга. Товар, лежащий на складе, кроме того, что связан со складом отношением композиции (агрегация не совсем подходит, поскольку в данной системе товар является товаром, пока он не покинет склад), ещё характеризуется количеством. Аналогично следует рассуждать и при рассмотрении отношения Товара и Заказа, Товара и Накладной. В связи с тем, что Заказ и Накладная, в сущности, являются документами и имеют сходные атрибуты, они были объединены с помощью общего класса-предка Документ.

Заключение

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

1. Выполнен анализ предметной области, выделены наиболее значимые ее составляющие.
2. Установлен характер связей между составляющими.
3. На основании полученных данных построена диаграмма классов.

Построенная диаграмма классов отображает найденные сущности системы «Управление складом» и связи между ними.

Библиография

1. Рунов А. В. Социальная информатика: Учеб. пособие. – М.: МГСУ, 2009. — 303 с.
2. Михеева Е. В. Информационные технологии в профессиональной деятельности: Учеб. пособие. – М.: Проспект, 2010. — 448 с.
3. Давид Марка, Клемент МакГоуэн. Методология структурного анализа и проектирования. Пер. с англ. – М.: Мета Технология, 1993. — 240 с.
4. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем. IDEF-технологии: Учебник-практикум. — М.: Финансы и статистика, 2006. — 188 с.
5. Кендалл С., Мартин Ф. UML. Основы. – 2. изд. — СПб.: Символ, 2002. — 185 с