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

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

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

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

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

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

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

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

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

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

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

     

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

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

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

      Визуальное  моделирование в 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. Диаграмма последовательности для варианта

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

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