Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Введение 3
1. Описание проектируемой ПО АИС 4
2. Проектирование ПО АИС в Rational Rose 7
2.1.Диаграмма вариантов использования 7
2.2.Диаграммы логического представления 9
2.3.Диаграмма состояний и деятельности 13
2.4.Диаграммы физического представления 16
3. Генерация кода 19
Заключение 24
Список использованной литературы 25
Современные проекты информационных систем отличаются большой сложностью и стандартные технологии проектирования и программирования не могут быть использованы для них.
В связи с этим актуальным становится использование CASE-средств, которые охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации.
Целью курсовой работы является проектирование автоматизированной системы учета движения товара на оптовом склада с использованием CASE - средства Rational Rose. Точнее это попытка применить знания на практике, научится использовать язык UML и программу Rational Rose.
Цель работы предопределила следующие её задачи:
Суть разрабатываемого программного обеспечения в том, что для подразделения(заказчика) и склада (поставщика) создается одно клиентское программное обеспечение и размещается на компьютере склада и на компьютере подразделения. С использованием сети интернет или локально вычислительной сети устанавливается связь с облаком и между двумя клиентами, тем самым осуществляются заказы товарно-материальных ценностей подразделением у склада, и ведётся его учет.
Облако – это выделенные вычислительные мощности в виде сервера в сети интернет, для хранения базы данных и обработки информации.
Составим глоссарий для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы.
Таблица 1 – Глоссарий
|
Термин |
Значение |
|
Sklad (Склад) |
Помещение (также их комплекс), предназначенное для хранения материальных ценностей и оказания складских услуг. |
|
Gruzchiki (Грузчики) |
Человеческий и машинный ресурс для выполнения простых рабочих операций: погрузки, выгрузки, перемещения, кантования, перекатывания и подъёма тяжелых (большой массы или размеров) грузов. |
|
Postavschik (Поставщик) |
Это любое юридическое (организация, предприятие, учреждение) или физическое лицо, поставляющие товары или услуги заказчикам. |
|
Podrazdelenie (Производственное подразделение) |
Это цех, участок, лаборатория, в которой изготавливается, проходит проверку продукция (работы, услуги), вырабатываются различные виды продукции. |
|
TMC (Товарно-материальная ценность) |
Это активы в виде: - запасов сырья, материалов, покупных полуфабрикатов и комплектующих изделий (деталей), топлива, тары и тарных материалов, запасных частей, прочих материалов. |
|
Zav.skladom (Зав.складом) |
Руководит работой склада по приему, хранению и отпуску товаров, по их размещению с учетом |
Продолжение таблицы 1
|
наиболее рационального использования складских площадей, облегчения и ускорения поиска необходимых товаров. |
|
|
Oblaco (Облако) |
Это совокупность IT-ресурсов, таких как вычислительные ресурсы (сервера), дисковое пространство (хранилища данных), сетевое оборудование, каналы связи, программное обеспечение (операционные системы, базы данных, прикладные приложения). Согласно концепции облачных технологий, из этих ресурсов выделяется часть под потребности конечного пользователя, причем выделение происходит моментально по запросу пользователя. |
|
Otgruzka (Отгрузка) |
Оформленный расчетными документами процесс передачи изготовленной продукции перевозчику или напрямую покупателю. |
|
Sotrudniki sklada (Сотрудники склада) |
Это абстрактная совокупность руководящего персонала склада. |
Изучив предметную область и желания заказчика выделяем основные её требования и спецификации к разрабатываемому программному обеспечению:
Так же определим некоторые дополнительные спецификации. Дополнительные спецификации определяют нефункциональные требования к системе, такие, как надежность, удобство использования, производительность, сопровождаемость, а также ряд функциональных требований, являющихся общими для нескольких вариантов использования.
Надежность:
Производительность:
Безопасность:
Интерфейс:
И так, были определены основные требования и спецификации, и описаны стоящие перед разработчиками задачи. Приступим к проектированию программного обеспечения в популярном CASE – инструменте Rational Rose.
Rational Rose – средство моделирования объектно-ориентированных информационных систем, базирующееся на языке моделирования UML. Rose способна решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.
В первую очередь следует построить диаграмму вариантов использования. Представление вариантов использования содержит всех действующих лиц, все варианты использования и их диаграммы для конкретной системы. Представление вариантов использования содержит:
На основе результатов изучения предметной области для информационной системы «учет движения товара на оптовом складе» была построена диаграмма вариантов использования (рисунок 1). Название всех диаграмм, их объектов, вариантов использования, классов написаны на латинице во избежание некорректной работы программы и во избежание ошибок.
Рисунок 1 – диаграмма вариантов использования
На диаграмме изображены следующие действующие лица (актеры):
Диаграмма показывает процесс работы склада и передвижение «ТМЦ» (товарно-материальных ценностей). Весь процесс описывается следующим образом: Актер «Поставщик» поставляет товарно-материальную ценность актеру «Зав.складом», «Подразделение» отправляет заказ на товарно-материальную ценность актеру «Зав.складом», он поставляет товарно-материальную ценность на склад («ТМЦ» принимает «Зав.складом»), «Зав.складом» отправляет товарно-материальную ценность на переупаковку актёру «Переупаковщик», но только в том случае если «Переупаковщик» получит «заявку на переупаковку», в противном случае «Зав.складом» отправляет заявку на размещения товарно-материальной ценности «Грузчикам 1-го отдела» которые, в свою очередь, непосредственно размещают товарно-материальную ценность. Далее товарно-материальную ценность перемещают в зону отгрузки, там ее принимают «Грузчики 2-го отдела», и если «Зав.складом» отправляет им заявку от подразделения (заказчика), они привозят и отгружают товар «Подраздлению». Так же «Отдел инвентаризации» может провести инвентаризацию товарно-материальной ценности, но только в том случае если получит соответствующую заявку.
После проектирования диаграммы вариантов использования нужно спроектировать диаграммы логического представления проектируемой системы. Логическое представление показывает, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает взаимодействие этих частей. Логическое представление включает конкретные классы, диаграммы классов и диаграммы состояний. С их помощью конструируется детальный проект создаваемой системы.
Логическое представление содержит:
Рисунок 2 – диаграмма классов
На этой диаграмме показано взаимодействие классов, как и куда происходит перемещение ТМЦ и его учет.
Для лучшей наглядности были созданы следующие классы:
В него были включены следующие атрибуты: «Код подразделения» (для того чтобы сотрудники склада ориентировались кому и куда отправлять ТМЦ), «номер ТМЦ» (это номер ТМЦ которое требуется заказать у сотрудников склада) и собственно «Телефон» (номер для обратной связи).
Так же добавлена одна операция: «Делает заказ» – это говорит о том, что данный класс совершает действие/операцию т.е. делает заказ на «ТМЦ» у «Сотрудников класса» через класс «АИС».
«АИС» хранит информацию об отчетах, товарно-материальных ценностях, совершенных сделках, сохраняет сообщения, синхронизирует информацию, делает расчеты. Часть этих функций, в основном по хранению, берет на себя «Облако» – оно хранит базу данных и всю сопутствующую информацию, и, по запросу программного обеспечения выдает ее.
Включает атрибуты: «Код подразделения», «Телефон подразделения», «Номер ТМЦ», «Дата отгрузки» (для грамотного введения отчетности и документооборота), «Отчет» (отчет формируется для узаконивания и подтверждения того что определенная операция или сделка была проведена определенного числа и подписана обоими сторонами). Так же в состав «Сотрудников склада» был включен, из соображений удобства, класс «ТМЦ» (он содержит атрибут «Номер ТМЦ», «Кол-во штук» и «Код подразделения»). Операцию которую совершает «Сотрудник склада» это «Отправления заявки на отгрузку».
Переходим к диаграмме последовательности (рисунок 3) и кооперации (рисунок 4).
Диаграмма последовательности (sequence diagram) – разновидность диаграммы взаимодействия, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени – вдоль оси Y.
Линия жизни объекта – вертикальная линия, отражающая существование объекта во времени. Фокус управления изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие.
Рисунок 3 – диаграмма последовательности
Диаграмма кооперации так же является разновидностью диаграммы взаимодействия, и в контексте языка UML описывает динамический аспект взаимодействия объектов при реализации отдельных вариантов использования. Проще говоря это диаграмма последовательности только в другом представлении.
Рисунок 4 – диаграмма кооперации
Этими диаграммами показывается последовательность выполнения тех или иных операций, событий, классов а так же продолжительность их деятельности по времени.
Каждый объект системы, обладающий определенным поведением, может находится в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: диаграмма состояний (рисунок 5) и диаграмма деятельности (рисунок 6).
Диаграмма состояний предназначена для отображения состояний объектов системы, имеющих сложную модель поведения.
Рисунок 5 – диаграмма состояний
На диаграмме наглядно показано изменение состояния всей системы, до её конечного состояния.
Диаграмма деятельности – это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.
Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.
Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на этих диаграммах также присутствуют обозначения состояний и переходов. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние выполняется только при завершении этой операции.
Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения.
Рисунок 6 – диаграмма деятельности
В этой диаграмме не описывается система в целом а описывается один класс «Подразделение» для лучшего понятия его функций, и адаптации разрабатываемой системы для стабильного взаимодействия с этим классом.
Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы.
Полный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов (рисунок 7) и диаграмму развертывания (рисунок 8).
Диаграмма компонентов, в отличие от ранее спроектированных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
Рисунок 7 – диаграмма компонентов
На диаграмме наглядно представлена каким образом система будет функционировать, какие компоненты реализуют классы, и с чем взаимодействуют, а так же физическое представления ЭВМ (PC) на котором будет функционировать система. Компонент «MainSOFT.exe» реализует основной класс из диаграммы классов «AIS».
Диаграмма развертывания – это вид диаграмм предназначеный для анализа аппаратной части системы, то есть "железа", а не программ.
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.
Диаграмма развертывания (рисунок 8) содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации.
При разработке диаграммы развертывания преследуют следующие цели:
Рисунок 8 – диаграмма развертывания
Спроектированная диаграмма говорит о том, что программное обеспечение устанавливает на компьютеры подразделения и на компьютеры склада, а связь с «Облаком»(где хранится БД) и связь между подразделением и складом осущестляется по Локальной/Глобальной сети.
Генерация кода происходит на основе диаграммы компонентов. Спроектированы все не обходимые данные, классы и диаграммы, осуществляться генерация кода будет на языке ANSI C++.
Си++ (англ. C++) – компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования.
Разработка языка началась в 1979 году. Целью создания C++ было дополнение C возможностями, удобными для масштабной разработки программного обеспечения, с сохранением гибкости, скорости и портабельности C. Вместе с тем создатели C++ стремились сохранить совместимость с C: синтаксис первого основан на синтаксисе последнего, и большинство программ на C будут работать и как C++. Изначально новый язык назывался “C с классами”, но затем имя было изменено на C++ – это должно было подчеркнуть, как его происхождение от C, так и его превосходство над последним.
Были сгенерированы компоненты реализации таких классов как:
Рисунок 9 – файл сгенерированного кода AIS.cpp
Рисунок 10 – файл сгенерированного кода AIS.h
Рисунок 11 – файл сгенерированного кода Sotrudniki sklada.h
Рисунок 12 – файл сгенерированного кода GUI.h
Рисунок 13 – файл сгенерированного кода TMC.h
На основе этих сгенерированных кодов разработчик может дополнять, редактировать, совершенстовать код, добавлять новые элементы классы и т.д.
Согласно теме курсовой работы «Проектирование автоматизированной информационной системы по учет движения товара на оптовом складе», были разработаны следующие диаграммы на языке UML:
В итоге был сгенерирован код разрабатываемой программы, отвечающий основным требованиям темы. Созданная программа в данном варианте представляет код, который требует дальнейшей отладки и совершенствования. Также в ходе выполнения курсовой работы были применены на практике знания, полученные в процессе изучения курса, а так же отработаны практические навыки создания автоматизированной информационной системы (АИС) в 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. Режим доступа: http://www.masters.donntu.edu.ua.