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

Сущность «Пользователь» содержит информацию о пользователе системой и имеет идентифицирующую связь с приходной накладной. Атрибутами у сущности «Пользователь» будут «Фамилия», «Имя» и «Отчество». Атрибутом первичного ключа будет являться «Код пользователя».

Сущность «Товар» содержит всю необходимую информацию о товаре и формируется атрибутами – «Наименование товара», «Единицы измерения», «Вид товара», «Количество товара», «Срок годности» и «Количество свободного места для товара». Атрибутом первичного ключа является «Код товара». Данная сущность содержит в себе полную информацию о товаре.

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

Сущность «Продажа» содержит информацию о расходе товара, то есть о продаже товара. Данная сущность содержит атрибуты – «Дата продажи», «Количество проданного товара», «Цена товара» и «Код товара».

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

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

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

Связь между сущностями «Пользователь» и «Приходная накладная» будет являться неидентифицирующей и следовательно первичный ключ («Код пользователя») сущности «Пользователь» будет являться атрибутом сущности «Приходная накладная».

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

Рис. 7. Модель базы данных в ERwin

2.3. Разработка модели «Учёт товаров в бакалейной лавке» в среде Rational Rose

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

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

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

последовательности взаимодействий. Физическая модель задается компонентной диаграммой (component diagram), которая описывает распределение реализации классов по модулям, и диаграммой поставки (deployment diagram).

Основными элементами диаграммы вариантов использования являются

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

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

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

Таким образом, учитывая все возможные внешние события, добавим на диаграмму следующие варианты использования: «Заказ и хранение товара», «Идентификация заказа», «Отмена заказа», «Продажа товара», «Идентификация покупки», «Отказ в продаже», «Формирование справочной информации» и «Доступ к базе данных». Основными вариантами использования являются «Заказ и хранение товара» и «Продажа товара», которые далее будут рассмотрены более подробно.

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

Рис. 8. Диаграмма вариантов использования

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

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

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

В нашем случае на диаграмму следует нанести такие классы: «Поставщик», «Приём товара», «Товар», «Транзакт лавки», «Продажа товара».

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

Зададим для классов значения атрибутов и операции (процессы, реализуемые классом), добавим ассоциации. Все атрибуты будут иметь квантор видимости public. Для класса «Транзакт лавки» квантор видимости private. Диаграмма классов приведена на рисунке 9.

Рис.9. Диаграмма классов

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

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

Создадим диаграммы коопераций для основных вариантов использования: процесса «Заказ

и хранение товара» и «Продажа товара». На начальном этапе изобразим все объекты и связи между ними на диаграммах кооперации. В последующем необходимо на диаграмму кооперации нанести все сообщения, указав их порядок и семантические особенности. Диаграммы кооперации для вариантов использования показаны на рисунках 10, 11.

Рис.10. Диаграмма кооперации для варианта

использования «Заказ и хранение товара»

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

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

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

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

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

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

Рис.12. Диаграмма последовательности для варианта

использования «Заказ и хранение товара»

Данная диаграмма демонстрирует линию жизни объекта класса «Поставщик» символом уничтожения (крестик). То есть «Поставщик» поставляет товар и уходит из рассмотрения и дальнейшая деятельность осуществляется без его участия.

Рис. 13. Диаграмма последовательности для варианта

использования «Продажа товара»

Данная диаграмма показывает линию жизни объекта класса «Транзакт лавки» символом уничтожения (крестик). То есть «Транзакт лавки» на определённом шаге уходит из рассмотрения и дальнейшая деятельность осуществляется без его участия.

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

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

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

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