Файл: Моделирование предметной области «Учет товаров на складе магазина» с помощью UML.pdf
Добавлен: 17.05.2023
Просмотров: 447
Скачиваний: 6
СОДЕРЖАНИЕ
1. Описание предметной области. Постановка задачи.
1.1. Описание предметной области. Постановка цели.
1.2. Предлагаемые мероприятия по улучшению технологии решения задачи.
2. Подготовка требований и построение моделей.
2.1. Выбор средства для моделирования предметной области решаемой задачи.
При закреплении по адресу хранения данных о товаре запись может вестись по следующим реквизитам: наименование товара, количество.
При изменении данных о товаре могут измениться следующие реквизиты: количество, расположение (адрес хранения).
При удалении записи о товаре удаляются данные, о том, что по данному адресу находится данный товар и ставится отметка, что адрес свободен.
Подсистема Отпуск ТМЦ выполняет следующие операции:
Получение заявки на товары;
Поиск в БД товаров, согласно заявке, проверка наличия по остаткам;
Составление расходной накладной;
Изменение данных об остатках товаров, проведение накладной;
Отбор товаров согласно накладной Отпуск товаров согласно накладной.
При получении заявки на товары регистрируются реквизиты: наименование товара, количество товара, код товара, дополнительная информация.
При поиске в БД могут указываться реквизиты: наименование товара, количество товара, код товара, дополнительная информация
При составлении расходной накладной в нее вносятся следующие реквизиты: дата документа, контрагенты (поставщик, получатель), код товара, наименование товара, количество товара, цена товара, дополнительная информация.
При изменении данных об остатках товара могут измениться следующие реквизиты: количество товара, адреса хранения, дополнительная информация. Вводятся данные о накладной, согласно которой изменяются остатки товара.
Отбор и отпуск товаров производится вручную, в системе ставится отметка о завершении данных операций (в накладной).
Подсистема Изменение свойств товара выполняет следующие операции:
Получение распоряжения об изменении свойств товаров;
Поиск товаров в БД;
Изменение данных о товаре;
При получении распоряжения об изменении свойств товаров регистрируются реквизиты: наименование товара, код товара, количество, цена, дополнительная информация.
При поиске товаров в БД могут указываться реквизиты: наименование товара, код товара, дополнительная информация.
При изменении данных о товаре могут измениться следующие реквизиты: наименование товара, код товара, количество, цена, сведения о комплектности, дополнительная информация.
Подсистема Проведение инвентаризаций выполняет следующие операции:
Формирование остатков ТМЦ на начало инвентаризации;
Формирование сводной инвентаризационной описи, введение фактических остатков товаров;
Формирование сличительной ведомости;
Получение результатов инвентаризации.
При формировании остатков ТМЦ на начало инвентаризации регистрируются следующие реквизиты: дата проведения инвентаризации, номер приказа об инвентаризации.
При формировании сводной инвентаризационной описи указываются следующие реквизиты: дата проведения, состав инвентаризационной комиссии, наименование товара, код товара, цена, количество (проставляются фактические остатки).
При формировании сличительной ведомости сверяются фактическое количество товаров с остатками в БД. На основании этого выявляются расхождения в количестве и сумме по каждому наименованию товаров.
При получении результатов инвентаризации формируется документ, в котором указывается: дата начала и дата окончания инвентаризации, состав инвентаризационной комиссии, окончательные результаты инвентаризации.
2. Подготовка требований и построение моделей.
2.1. Выбор средства для моделирования предметной области решаемой задачи.
Выбор средства для моделирования предметной области решаемой задачи. Задачей курсового проекта является разработка объектно-ориентированной модели информационной подсистемы для учета движения товаров на складе фирмы с использованием языка UML.
В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose 2000 Enterprise v6.5.
Выводы
В результате проектирования должна быть получена объектно-ориентированная модель информационной подсистемы для учета движения товаров на складе. Модель будет включать в себя:
- диаграмму вариантов использования;
- диаграмму последовательности;
- диаграмму сотрудничества;
- диаграмму классов;
- диаграмму состояний;
- диаграмму компонентов;
- диаграмму размещения;
2.2. Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию.
Создание диаграммы прецедентов.
Диаграммой прецедентов, или использования (use case diagram) называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения и ассоциации) между ними.
Она позволяет выделить внешние системы, контактирующие с системой, основные процессы и их взаимосвязь. Диаграммы прецедентов дают возможность выделить функциональную структуру системы, не вдаваясь в детали ее реализации. Кроме того, производится предварительное выделение объектов системы и их классификация. На основании построенной модели составляется план разработки системы.
Элементы диаграммы:
- вариант использования - это логическое описание определенной части деятельности системы. Он не представляет собой четкую конструкцию, которую можно напрямую реализовать в программном коде. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером.
- актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности. Актеры используются для моделирования внешних по отношению к проектируемой системе сущностей, которые взаимодействуют с системой и используют ее в качестве отдельных пользователей.
- отношения ассоциации устанавливают, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования.
Рисунок 1 - Диаграмма прецедентов
Между вариантами использования и действующими лицами используется вязь коммуникации (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» - карта складского учета.
После создания объектов и сообщений между ними было выполнено соотнесение объектов с классами, а сообщений с операциями. Все названия объектов и сообщений совпадают с названиями классов и операций соответственно.
Выводы
1. На диаграмме последовательности «get_tovar» (принять товар), размещены пять объектов и девять сообщений между ними.
2. Каждый объект был соотнесен с классом, а сообщение с операцией.
Создание диаграммы сотрудничества
Вторым видом диаграммы взаимодействия является кооперативная диаграмма (collaboration diagram).
Подобно диаграммам последовательности, кооперативные диаграммы отображают поток событий через конкретный сценарий варианта использования. Кооперативные диаграммы заостряют внимание на взаимосвязях вообще, то есть на них отражается наличие сообщений от клиентов к серверам.
Диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Ведь объекты, в отличие от созданных на этапе проектирования классов, создаются и уничтожаются на всем протяжении работы программы. И в каждый момент имеется конкретная группа объектов, с которыми осуществляется работа.
При создании диаграммы сотрудничества располагают участвующие во взаимодействии объекты в виде вершин графа. Связи между этими объектами, отраженные на диаграмме последовательности, дополняются сообщениями, которые объекты принимают и посылают. Это дает аналитику ясное визуальное преставление о потоке управления в контексте структурной организации кооперирующихся объектов.
Согласно созданной выше диаграмме «get_tovar» (принять товар), была создана диаграмма сотрудничества (рисунок 3).
Рисунок 3 - Диаграмма сотрудничества для варианта использования «get_tovar» (принять товар)
На диаграмме расположены объекты:
- «sklad» ;
- «Add/Select Tovar Form»;
- «Add/Select Postav Form»;
- «Card Sklad_Uchet»;
- «DataBase».
Назначение данных объектов аналогично соответствующим объектам диаграммы последовательности.
Выводы
Была создана диаграмма сотрудничества «get_tovar» (принять товар), на которой представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее разобраться в последовательности событий.
Создание диаграммы классов
Диаграммы классов (class diagram) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (сlasses) и интерфейсов (interfaces). На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами Данный тип диаграмм противоположен по содержанию диаграмме сотрудничества, на которой отображаются объекты системы.
Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй - его атрибуты. В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом).
Обычно для описания системы создают несколько диаграмм классов. На одних показывают некоторое подмножество классов и отношения между классами подмножества. На других отображают то же подмножество, но вместе с атрибутами и операциями классов. Третьи соответствуют только пакетам классов и отношениям между ними. По умолчанию существует одна диаграмма классов, называемая Главной (Main), на которой показывают пакеты классов модели (рисунок 4).