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

Моделирование предметной области «Учет товаров» с помощью UML (Основы проектирования ИС и учет товаров)

Содержание:

ВВЕДЕНИЕ

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

Язык UML необходим для описания программной системы на этапе проектирования и анализа.

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

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

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

1.ОСНОВЫ ПРОЕКТИРОВАНИЯ ИС И УЧЕТА ТОВАРОВ

1.1.Анализ технического задания

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

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

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

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

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

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

1.2.Общие понятия проектирования ИС

В основе проектирования ИС лежит моделирование предметной области.

Предметная область – это мысленно ограниченная область реальной действительности , подлежащая описанию или моделированию и исследованию.

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

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

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

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

Начало разработки диаграмм функционального моделирования относится к середине 1960-х годов, когда Дуглас Т. Росс предложил специальную технику моделирования, получившую название SADT (Structured Analysis & Design Technique). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями. Такая чисто функциональная ориентация является принципиальной. Функции системы анализируются независимо от объектов, которыми они оперируют. Для этой цели строятся специальные модели, которые позволяют в наглядной форме представить последовательность определенных действий. Исходными строительными блоками любой модели IDEF0 процесса являются деятельность и стрелки. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Модель рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. [5, c. 126]

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

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

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

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой.

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

Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. [1, c. 168]

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

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

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

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

Разработка модели с применением ERwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Также ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Разработка модели данных в ERwin представляется в виде сущностей, которые точно определяют хранящуюся в них информацию.

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

Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. [2, с. 86] Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого

различного целевого назначения. В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. [4, c. 79]

В UML языке, в качестве самостоятельных представлений используются следующие диаграммы: диаграмма вариантов использования; диаграмма классов; диаграмма состояний; диаграмма деятельности; диаграмма последовательности; диаграмма кооперации; диаграмма компонентов; диаграмма развертывания. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. Методологии, технологии и инструментальные средства проектирования составляют основу проекта любой ИС. [7, c. 83]

1.3.Экономическая сущность учета товаров и реализации продукции

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

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

Учет реализации товаров в оптовой торговле осуществляется по мере отгрузки товаров и предъявления покупателям расчетных документов. Основной единицей информации в системе является документ. Основные операции в системе подразделяются на товарные и расчетно-денежные операции. В процессе коммерциализации экономики особую значимость приобретает такая важная форма реализации товаров как, розничная торговля. [6, c. 143]

Розничная торговля - это завершающая форма продажи товаров конечному потребителю в небольших объемах через магазины, павильоны, лотки, палатки и другие пункты сети розничной торговли. Коммерческая работа по продажи в розничных торговых предприятиях в отличии от оптовых предприятий имеет свои особенности. Розничные торговые предприятия реализуют товары непосредственно населению, то есть физическим лицам, применяя свои, специфические способы и методы розничной продажи, окончательно завершают обращение от изготовителя продукции. [9, c. 281]

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

Также в розничной торговле особое внимание уделено формированию ассортимента на розничном торговом предприятии. Понятие ассортимент товара включает в себя совокупность их видов, разновидностей и сортов, объединенных или сочетающихся по определенному признаку. Формирование ассортимента – это процесс подбора групп, видов и разновидностей товаров в соответствии со спросом населения с целью его полного удовлетворения. Правильный выбор ассортиментной политики предприятия служит своего рода гарантией, что выгодные возможности не будут упущены. [3, c. 368]

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

1.4.Постановка задачи и основные особенности учета товаров

В магазине для товара фиксируется место хранения (склад), количество товара и его поставщик.

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

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

Выяснив особенности данной системы, теперь можно приступить к ее проектированию.

2.ПРОЕКТИРОВАНИЕ СИСТЕМЫ УЧЕТА ТОВАРОВ

2.1. Разработка модели данных с применением BPwin

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

BPwin имеет достаточно простой и понятный интерфейс пользователя, дающий возможность создавать сложные модели при минимальных усилиях. BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0), описание бизнес-процессов (IDEF3), диаграммы потоков данных (DFD), каждая из которых решает свои специфические задачи. В BPwin также возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD.

Модель в BPwin рассматривается как совокупность работ, каждая из

которых оперирует с некоторым набором данных.

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

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

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

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

Управляющая информация «Правила» входит в блок «Учёт товаров в бакалейной лавке» сверху (информация, управляющая действиями работы). Входная информация - это «Данные о поставщике», «Данные о товаре», «Данные о свободной позиции», показана с левой стороны блока, а результат показан с правой стороны, им является «Справочная информация», «Оплаченный заказ», «Проданный товар» и «Списанный товар». Механизмы «Пользователь» и «Информационная система», осуществляющие операцию, представляются

стрелками, входящими в блок «Учёт товаров в бакалейной лавке» снизу. Данная диаграмма приведена на рисунке 1.

Рис.1 Контекстная диаграмма «Учёт товаров в бакалейной лавке»

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

Далее блок «Учёт товаров в магазине» декомпозируется и создаётся диаграмма декомпозиции IDEF0. Блок «Учёт товаров в магазине», который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков («Работа с поставщиком товара», «Приём товара от поставщика», «Реализация товара»), то есть система разбивается на подсистемы (диаграммы декомпозиции). Управляющая информация, входная информация, механизмы и результат на декомпозированной диаграмме остаются неизменными, продолжают выполнять свои функции для каждого блока. Диаграмма декомпозиции «Учёт товаров в магазине» показана на рисунке 2.

Рис.2 Диаграмма декомпозиции контекстной диаграммы «Учёт товаров в бакалейной лавке»

Также дополнительно декомпозируются блоки «Работа с поставщиком товара», «Приём товара от поставщика» и «Реализация товара». Декомпозиция блока «Работа с поставщиком товара» представлена на рисунке 3. Данная диаграмма представлена в IDEF0. И она показывает последовательность работы пользователя системы с конкретным поставщиком.

Рис.3 Диаграмма декомпозиции блока «Работа с поставщиком товара»

Декомпозиция блока «Приём товара от поставщика» представлена также в IDEF0. Данная декомпозиция показывает осуществление приёма товара и оплаты услуг поставщика. Диаграмма декомпозиции представлена на рисунке 4.

Рис.4 Диаграмма декомпозиции блока «Приём товара от поставщика»

Диаграмма декомпозиции блока «Реализация товара» показана на рисунке 5. Она представлена в IDEF0 и в IDEF3. В IDEF0 декомпозирован весь блок «Реализация товара». В результате декомпозиции получаем следующие блоки: «Определение товара на позицию», «Хранение товара», «Продажа товара» «Формирование справочной информации». Декомпозиция осуществляется в IDEF0, так как данная декомпозиция представляет собой совокупность упорядоченных и взаимосвязанных диаграмм. Входная информация, управляющая информация, механизмы и результат на декомпозированной диаграмме остаются прежними и продолжают выполнять свои функции.

Рис.5 Диаграмма декомпозиции блока «Реализация товара»

Блок «Хранение товара» декомпозирован дополнительно и декомпозиция осуществлена в IDEF3. (рисунок 6)

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

Рис.6 Диаграмма декомпозиции блока «Хранение товара»

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

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

Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок.

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

На диаграмму декомпозиции «Хранение товара» необходимо поместить перекрестки Exclusive OR для случаев

слияния и разветвления стрелок. Перекресток Exclusive OR в случае разветвления стрелок означает, что запускается только один следующий процесс, а в случае слияния – только один предшествующий процесс должен быть завершен.

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

2.2. Разработка модели данных с применением ERwin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграммы состояний представлены на рисунках 14, 15.

Рис.14. Диаграмма состояний для варианта использования «Заказ и хранение товара»

Рис.15. Диаграмма состояний для варианта использования «Продажа товара»

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

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

В процессе проектирования системы «Учёт товаров в бакалейной лавке» средствами Rational Rose были созданы такие типы диаграмм как: диаграмма вариантов использования, диаграмма классов, диаграмма коопераций, диаграмма последовательностей, диаграмма состояний и диаграмма деятельности.

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

ЗАКЛЮЧЕНИЕ

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

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

Одним из достоинств Rational Rose является возможность использования диаграмм на языке UML. В данной работе приведены основные диаграммы, которые дают полное явное представление о функционировании проектируемой системы «Учёт товаров в бакалейной лавке», а также возможные варианты развития системы в зависимости от воздействия внешних факторов.

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

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

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

ЛИТЕРАТУРА

1. Вендеров, А. М. Проектирование программного обеспечения экономических информационных систем / А. М. Вендеров. - М. : Финансы и статистика, 2002.

2. Кватрани, Т. Rational Rose 2000 и UML. Визуальное моделирование / Т. Кватрани. - М. : ДМК Пресс, 2001. - 176 с.

3. Ломакин, В. К. Мировая экономика: Учебник для вузов/ В. К. Ломакин. — М: ЮНИТИ, 2000.

4. Мацяшек, А. П. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML / А. П. Мацяшек, А. Н. Лешек. – М. : Издательский дом «Вильямс», 2002. – 432 с.

5. Проектирование информационных систем: курс лекций / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина. - М. : Интернет-Ун-т Информ технологий, 2005. - 304 с.

6. Титова, Н. Е. История экономических учений: курс лекций / Н. Е. Титова. — М.: Гуманит. изд. центр ВЛАДОС, 2007.

7. Трофимов, С. А. CASE-технологии: практическая работа в Rational Rose / С. А. Трофимов. - М. : Бином-Пресс, 2002.

8. Федотова, Д. Э. CASE-технологии: Практикум /Д. Э. Федотова, Ю. Д. Семенов, К. Н. Чижик. - М. : Горячая линия-Телеком, 2005.

9. Шишкин, А. Ф. Экономическая теория: Учебное пособие для ву-2-е изд.: В 2 кн. Кн. 1 / А. Ф. Шишкин. - М.: Гуманит, изд. зов. центр ВЛАДОС, 2006. - 656 с.