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

• Введение
• 1. Описание проектируемой ПО АИС
• 2. Проектирование ПО АИС в Rational Rose
• 2.1 Диаграмма вариантов использования
• 2.2 Диаграммы логического представления
• 2.3 Диаграмма состояний и деятельности
• 2.4 Диаграммы физического представления
• 3. Генерация кода
• Заключение
• Список использованной литературы
• Введение
• Современные проекты информационных систем отличаются большой сложностью и стандартные технологии проектирования и программирования не могут быть использованы для них.
• В связи с этим актуальным становится использование CASE-средств, которые охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации.
• Целью курсовой работы является проектирование автоматизированной системы учета движения товара на оптовом склада с использованием CASE — средства Rational Rose. Точнее это попытка применить знания на практике, научится использовать язык UML и программу Rational Rose.
• Цель работы предопределила следующие её задачи:

1) описать АИС;

2) научиться проектировать на основе UML в Rational Rose;

3) создать диаграммы АИС учета движения товара на оптовом складе в Rational Rose;

4) сгенерировать код на основе готовых UML диаграмм.

1. Описание проектируемой ПО АИС

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

Облако — это выделенные вычислительные мощности в виде сервера в сети интернет, для хранения базы данных и обработки информации.

Составим глоссарий для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы.

Таблица 1 — Глоссарий

Изучив предметную область и желания заказчика выделяем основные её требования и спецификации к разрабатываемому программному обеспечению:

1) возможность ведения учета товарно-материальных ценностей;

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

3) возможность добавления в код дополнительных модулей с целью улучшения качества работы программного обеспечения, его обновления и расширения возможностей;

4) поддержка совместной, синхронной работы нескольких клиентов программного обеспечения.

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

Надежность:

1) работа программы без ошибок;

2) корректная работа программы 24 часа в неделю;

3) сопровождение программного обеспечения, техническая поддержка.

Производительность:

1) система не должна быть требовательна к аппаратным возможностям ЭВМ.

2) система должна быть кроссплатформенной (т.е. работать на нескольких видах операционных систем).

Безопасность:

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

2) исключить возможность редактирование или изменения кода программного обеспечения не предусмотренными лицами.

Интерфейс:

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

И так, были определены основные требования и спецификации, и описаны стоящие перед разработчиками задачи. Приступим к проектированию программного обеспечения в популярном CASE — инструменте Rational Rose.

2. Проектирование ПО АИС в Rational Rose

Rational Rose — средство моделирования объектно-ориентированных информационных систем, базирующееся на языке моделирования UML. Rose способна решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

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

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

1) действующих лиц;

2) варианты использования;

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

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

На диаграмме изображены следующие действующие лица (актеры):

1) поставщик;

2) зав. складом;

Рисунок 1 — диаграмма вариантов использования

3) переупаковщик;

4) грузчики;

5) тмц;

6) отдел инвентаризации;

7) подразделение.

Диаграмма показывает процесс работы склада и передвижение «ТМЦ» (товарно-материальных ценностей). Весь процесс описывается следующим образом: Актер «Поставщик» поставляет товарно-материальную ценность актеру «Зав.складом», «Подразделение» отправляет заказ на товарно-материальную ценность актеру «Зав.складом», он поставляет товарно-материальную ценность на склад («ТМЦ» принимает «Зав.складом»), «Зав.складом» отправляет товарно-материальную ценность на переупаковку актёру «Переупаковщик», но только в том случае если «Переупаковщик» получит «заявку на переупаковку», в противном случае «Зав.складом» отправляет заявку на размещения товарно-материальной ценности «Грузчикам 1-го отдела» которые, в свою очередь, непосредственно размещают товарно-материальную ценность. Далее товарно-материальную ценность перемещают в зону отгрузки, там ее принимают «Грузчики 2-го отдела», и если «Зав.складом» отправляет им заявку от подразделения (заказчика), они привозят и отгружают товар «Подраздлению». Так же «Отдел инвентаризации» может провести инвентаризацию товарно-материальной ценности, но только в том случае если получит соответствующую заявку.

2.2 Диаграммы логического представления

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

Логическое представление содержит:

1) диаграмму классов (рисунок 2);

2) диаграммы последовательности и кооперации (рисунок 3, рисунок 4);

3) диаграммы состояний и деятельности (рисунок 5, рисунок 6).

На этой диаграмме показано взаимодействие классов, как и куда происходит перемещение ТМЦ и его учет.

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

1) «Подразделение» (подразделение выполняет функцию клиента который заказывает у склада необходимое количество ТМЦ с помощью класса «АИС» (собственно «АИС» — это и есть олицетворение нашей разрабатываемой системы).

В него были включены следующие атрибуты: «Код подразделения» (для того чтобы сотрудники склада ориентировались кому и куда отправлять ТМЦ), «номер ТМЦ» (это номер ТМЦ которое требуется заказать у сотрудников склада) и собственно «Телефон» (номер для обратной связи).

Рисунок 2 — диаграмма классов Так же добавлена одна операция: «Делает заказ» — это говорит о том, что данный класс совершает действие/операцию т. е. делает заказ на «ТМЦ» у «Сотрудников класса» через класс «АИС».

2) «АИС» (этот класс характеризует разрабатываемое программное обеспечение, описывает операции которые он совершает и его атрибуты, фактически он посредник между «Подразделением» и «Сотрудниками склада»).

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

3) «Сотрудники склада» (этот класс является промежуточным звеном между «Подразделением» и «Грузчиками», они анализируют информацию, отправляют отчет «Подразделению» и информацию о движение ТМЦ, а так же дают указания грузчикам).

Включает атрибуты: «Код подразделения», «Телефон подразделения», «Номер ТМЦ», «Дата отгрузки» (для грамотного введения отчетности и документооборота), «Отчет» (отчет формируется для узаконивания и подтверждения того что определенная операция или сделка была проведена определенного числа и подписана обоими сторонами). Так же в состав «Сотрудников склада» был включен, из соображений удобства, класс «ТМЦ» (он содержит атрибут «Номер ТМЦ», «Кол-во штук» и «Код подразделения»). Операцию которую совершает «Сотрудник склада» это «Отправления заявки на отгрузку».

4) «ТМЦ» (см.выше).

5) «Грузчики» (Перемещают ТМЦ, выполняют его отгрузку, частично формируют отчет).

6) «Отчет» (Содержит «Дату отгрузки», «Номер ТМЦ», «Кол-во штук», «Код подразделения»).

7) «Облако» (см.выше).

Переходим к диаграмме последовательности (рисунок 3) и кооперации (рисунок 4).

Диаграмма последовательности (sequence diagram) — разновидность диаграммы взаимодействия, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени — вдоль оси Y.

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

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

Рисунок 3 — диаграмма последовательности Рисунок 4 — диаграмма кооперации

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

2.3 Диаграмма состояний и деятельности

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

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

Рисунок 5 — диаграмма состояний

На диаграмме наглядно показано изменение состояния всей системы, до её конечного состояния.

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

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

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

Рисунок 6 — диаграмма деятельности

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

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

2.4 Диаграммы физического представления

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы.

Полный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов (рисунок 7) и диаграмму развертывания (рисунок 8).

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

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

1) визуализации общей структуры исходного кода программной системы;

2) спецификации исполняемого варианта программной системы;

3) обеспечения многократного использования отдельных фрагментов программного кода;

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

Рисунок 7 — диаграмма компонентов На диаграмме наглядно представлена каким образом система будет функционировать, какие компоненты реализуют классы, и с чем взаимодействуют, а так же физическое представления ЭВМ (PC) на котором будет функционировать система. Компонент «MainSOFT.exe» реализует основной класс из диаграммы классов «AIS».

Диаграмма развертывания — это вид диаграмм предназначеный для анализа аппаратной части системы, то есть «железа», а не программ.

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

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

При разработке диаграммы развертывания преследуют следующие цели:

1) определить распределение компонентов системы по ее физическим узлам;

2) показать физические связи между всеми узлами реализации системы на этапе ее исполнения;

3) выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

Рисунок 8 — диаграмма развертывания Спроектированная диаграмма говорит о том, что программное обеспечение устанавливает на компьютеры подразделения и на компьютеры склада, а связь с «Облаком"(где хранится БД) и связь между подразделением и складом осущестляется по Локальной/Глобальной сети.

автоматизированный информационный код программа

3. Генерация кода

Генерация кода происходит на основе диаграммы компонентов. Спроектированы все не обходимые данные, классы и диаграммы, осуществляться генерация кода будет на языке ANSI C++.

Си++ (англ. C++) — компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования.

Разработка языка началась в 1979 году. Целью создания C++ было дополнение C возможностями, удобными для масштабной разработки программного обеспечения, с сохранением гибкости, скорости и портабельности C. Вместе с тем создатели C++ стремились сохранить совместимость с C: синтаксис первого основан на синтаксисе последнего, и большинство программ на C будут работать и как C++. Изначально новый язык назывался «C с классами», но затем имя было изменено на C++ - это должно было подчеркнуть, как его происхождение от C, так и его превосходство над последним.

Были сгенерированы компоненты реализации таких классов как:

1) «AIS» (рисунок 9, рисунок 10)

2) «Sotrudniki sklada» (рисунок 11)

3) «GUI» (рисунок 12)

4) «TMC» (рисунок 13)

Рисунок 9 — файл сгенерированного кода AIS. cpp

Рисунок 10 — файл сгенерированного кода AIS. h

Рисунок 11 — файл сгенерированного кода Sotrudniki sklada. h

Рисунок 12 — файл сгенерированного кода GUI. h

Рисунок 13 — файл сгенерированного кода TMC. h

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

Заключение

Согласно теме курсовой работы «Проектирование автоматизированной информационной системы по учет движения товара на оптовом складе», были разработаны следующие диаграммы на языке UML:

1) диаграмма вариантов использования;

2) диаграмма классов;

3) диаграмма последовательности;

4) диаграмма кооперации;

5) диаграмма состояний;

6) диаграмма деятельности;

7) диаграмма компонентов;

8) диаграмма развертывания.

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

• 1. Богс, М.У. UML и Rational Rose/ М. У. Богс. — М.: Лори, 2001. — 411с.
• 2. Буч, Г. Язык UML Руководство пользователя/ Г. Буч, Д. Рамбо, А. Джекобсон. — СПб.: ДМК Пресс, 2004. — 525с.
• 3. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование/ Т. Кватрани. — М.: ДМК Пресс, 2001. — 295с.

1. Ларман К. Применение UML и шаблонов проектирования/ К. Ларман. -М.: Вильямс, 2002. — 340с.

• 4. Леоненков А. В. Самоучитель UML/ А. В. Леоненков. -СПб.: BHV-СПб, 200. — 632с.
• 5. Мацяшек Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML/ Л. А. Мацяшек. -М.: Вильямс, 2002. — 250с.
• 7. Портал магистров Донецкого национального технического университета, раздел — о языке UML