Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

Глава 1. Аналитическая часть.

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

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

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

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

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

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

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

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

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

− оперативный доступ к имеющимся данным;

− ввод, хранение, изменение и удаление информации о товарах, поставщиках и клиентах;

− ввод, хранение, изменение и удаление информации о приходе и расходе товаров;

− фильтрация информации;

− сортировка информации по убыванию и возрастанию;

− поиск информации; − формирование отчетов.

Информационная система будет выполнять все функции, необходимые для ведения учета товаров на складе.

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

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

− список товаров;

− список категорий товаров;

− список единиц измерения товаров;

− список клиентов;

− список поставщиков;

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

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска информации о товарах;

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска категорий товаров;

− создание форм для ввода, редактирования и удаления информации о единицах измерения товаров;

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска информации о покупателях;

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска информации о приходе товаров;

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска сведений о поставщиках;

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

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска данных о клиентах;

− создание форм для ввода, редактирования и удаления, фильтрации, сортировки и поиска информации о расходе товаров;

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

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

Глава 2. Проектная часть

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

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

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

Унифицированный язык моделирования UML (Unified Modeling Language) - это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-oriented Software Engineering) Ивар Якобсон.

Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

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

- обеспечить независимость от конкретных языков программирования и процессов разработки;

- обеспечить формальную основу для понимания этого языка моделирования;

(язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Между вариантами использования и действующими лицами используется вязь коммуникации (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» - карта складского учета.

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

Выводы

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

начальное состояние «Start»;
конечное «exit» состояние;
«Initialization» (инициализация);
«SomeStop» (выполнение приостановлено);
«Cancel» (отменен);
«Get» (выполнен).

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

«StoreDate» (сохранить дату) на входе для состояния «Initialization» (инициализация);
«Info Tovar» (собрать информацию о товаре и поставщиках);
«Add» (добавить к набору товаров);
«StoreData» (сохранить дату отмены) на выходе;
«Card Ucheta» (карта учета) – на выходе формируется складская карта учета.

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

Так как система разрабатывается на языке C++, то у каждого класса имеется свой собственный заголовочный файл и файл с расширением *.cpp.
Для каждого класса была создана спецификация пакета и тело пакета. Они соединены с помощью связей dependency.
Создание диаграммы размещения

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

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

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

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

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

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

Выводы

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

От «Server» к «Client»;
От «Client» к «Printer».

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ЛИТЕРАТУРЫ

Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. – М.: ДМК, 2000.- 432 с., ил.
Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. – М.: Издательство «Лори», 2000.- 581 с., ил.
Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. – СПб.: Питер, 2002.- 432 с., ил.
Ларман К. применение UML и шаблонов проектирования: Пер. с англ. – М.: Издательский дом «Вильямс», 2001. – 496 с., ил.
Леоненков А. Самоучитель UML.– СПб.: БХВ–Петербург, 2001