Проектирование ПО АИС в RationalRose

Содержание

 

 

Введение

 

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

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

Целью курсовой работы является проектирование автоматизированной системы учета движения товара на оптовом склада с использованием CASE - средства Rational Rose. Точнее это попытка применить знания на практике, научится использовать язык UML и программу Rational Rose.

Цель работы предопределила следующие её задачи:

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

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

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

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

 

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

 

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

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

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

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

Термин	Значение
Sklad (Склад)	Помещение (также их комплекс), предназначенное для хранения материальных ценностей и оказания складских услуг.
Gruzchiki (Грузчики)	Человеческий и машинный ресурс для выполнения простых рабочих операций: погрузки, выгрузки, перемещения, кантования, перекатывания и подъёма тяжелых (большой массы или размеров) грузов.
Postavschik (Поставщик)	Это любое юридическое (организация, предприятие, учреждение) или физическое лицо, поставляющие товары или услуги заказчикам.
Podrazdelenie (Производственное подразделение)	Это цех, участок, лаборатория, в которой изготавливается, проходит проверку продукция (работы, услуги), вырабатываются различные виды продукции.
TMC (Товарно-материальная ценность)	Это активы в виде: - запасов сырья, материалов, покупных полуфабрикатов и комплектующих изделий (деталей), топлива, тары и тарных материалов, запасных частей, прочих материалов.
Zav.skladom (Зав.складом)	Руководит работой склада по приему, хранению и отпуску товаров, по их размещению с учетом

 

Продолжение таблицы 1

	наиболее рационального использования складских площадей, облегчения и ускорения поиска необходимых товаров.
Oblaco (Облако)	Это совокупность IT-ресурсов, таких как вычислительные ресурсы (сервера), дисковое пространство (хранилища данных), сетевое оборудование, каналы связи, программное обеспечение (операционные системы, базы данных, прикладные приложения). Согласно концепции облачных технологий, из этих ресурсов выделяется часть под потребности конечного пользователя, причем выделение происходит моментально по запросу пользователя.
Otgruzka (Отгрузка)	Оформленный расчетными документами процесс передачи изготовленной продукции перевозчику или напрямую покупателю.
Sotrudniki sklada (Сотрудники склада)	Это абстрактная совокупность руководящего персонала склада.

 

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

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

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

Надежность:

1. работа программы без ошибок;
2. корректная работа программы 24 часа в неделю;
3. сопровождение программного обеспечения, техническая поддержка.

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

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

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

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

 Интерфейс:

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

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

 

 

 

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

 

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

 

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

 

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

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

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

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

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

 

 

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

 

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

1. поставщик;
2. зав.складом;
3. переупаковщик;
4. грузчики;
5. тмц;
6. отдел инвентаризации;
7. подразделение.

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

 

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

 

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

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

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

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

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

Рисунок 2 – диаграмма классов

 

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

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

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

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

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

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

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

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

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

4. «ТМЦ» (см.выше).
5. «Грузчики» (Перемещают ТМЦ, выполняют его отгрузку, частично формируют отчет).
6. «Отчет» (Содержит «Дату отгрузки», «Номер ТМЦ», «Кол-во штук», «Код подразделения»).
7. «Облако» (см.выше).

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

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