Документирование процесса разработки программного обеспечения с использованием UML

Документирование процесса разработки программного обеспечения с использованием UML

Министерство сельского хозяйства Российской Федерации

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«Московский государственный агроинженерный университет

имени В.П. Горячкина»

Кафедра вычислительной техники и прикладной математики

РАСЧЕТНАЯ РАБОТА

по дисциплине «Программная инженерия»

Документирование процесса разработки программного обеспечения с использованием UML

Пояснительная записка

МГАУ 080500.62.6013.159 ОО

МГАУ 080500.62.6013.158 ОО

МГАУ 080500.62.6013.160 ОО

МГАУ 080500.62.6013.143 ОО

Проверил: старший преп.

_____________С.С. Зимнов

Выполнили: студентки группы 23 БЭК

___________В.Д. Павловская

____________А.В. Тарасова

___________А.Д. Столярова

___________E.Н. Сорокина

Москва 2013г.

Содержание

Введение

Содержание работы:

Глава 1

.        Анализ предметной области проектирования

.        Нормативные документы, устанавливающие требования к процессу

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

Глава 2

.        Выбор метода разработки

.        Выбор и обоснование языка программирования

.        Описание языка программирования или среды разработки особенности, включающее наименование языка (среды), основные особенности и причины выбора

.        Описание СУБД и причины её выбора

.        Назначение Microsoft Visio

Глава 3

.        Разработка диаграммы классов, описывающей логическую модель системы

.        Разработка диаграммы состояний

.        Формирование диаграммы деятельности

.        Разработка диаграммы последовательности

Глава 4

.        Проектирование физической структуры программного средства. Разработка диаграммы компонентов

.        Разработка диаграммы развертывания

Заключение

Список литературы

Введение

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

Задачей расчетной работы является формирование у студентов навыков

применения:

− языка UML;

− правил формирования требований;

− принципов проектирования программных средств;

− стандартов по оформлению программных документов.

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

Глава 1

.Анализ предметной области проектирования

Таблица 1 - Входные, выходные и внутренние данные бизнес-процесса

.Нормативные документы, устанавливающие требования к процессу.

1) Закон РФ «О защите животных от жестокого обращения».

) Договора, касающиеся пребывания кур на птицефабрике.

) Европейская конвенция по защите домашних животных.

Таблица 2 - Заинтересованные лица.

Таблица 3 - Интересы заинтересованных лиц

Таблица 4 - Проблемы заказчика

Таблица 5 - Цели разработки ИС

Таблица 6 - Функциональные возможности

Форма ввода:

«Справочник работников»;

«Справочник кур»;

«Справочник заказчиков».

Отчетные формы:

Лицензии;

Заказы;

Договора;

Приказы;

Нормативно-правовые акты.

Вычислительные модули:

Расчет размера зарплат работников;

Определение количества заказов;

Затраты на содержание птицефабрики.

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

ВИ 01. Управлять пользователями

Роли:          администратор

Краткое описание: Администратор        создает роли и пользователей в системе

ВИ 02. Управлять правами пользователей

Роли:          администратор

Краткое описание: Администратор        устанавливает ограничения доступа пользователей в соответствии с их         ролями в системе.

ВИ 03. Войти в систему

Роли:          пользователь (работники птицефабрики, владельцы, заказчики, потребители, администратор)

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

ВИ 04. Управлять справочниками

Роли:          работники птицефабрики

ВИ 05. Получить         историческую информацию о работнике

Роли:          Работник, владелец.

Краткое     описание: По запросу владельца система предоставляет        историческую информацию о работнике. Работник может просматривать информацию о себе.

ВИ 06. Построить консолидированные отчёты

Роли:          Работник птицефабрики

Краткое описание: Работник птицефабрики задает необходимые входные параметры для построения для интересующих отчётов

ВИ 07. Оплатить продукцию

Роли:          Заказчик, потребитель, владелец.

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

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

Рисунок 1 - Диаграмма Вариантов         использования. Администрирование системы.

Рисунок 2 - Диаграмма Вариантов использования. Иерархия действующих лиц

Глава 2

.Выбор метода разработки

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

язык программирование диаграмма логический

2.Выбор и обоснование языка программирования

Язык UML предназначен для решения следующих задач:

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

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

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

.        Описание языка UML, включающее в себя семантический базис для понимания общих особенностей ООАП.

.        Развитие рынка объектных инструментальных средств.

.        Распространение объектных технологий и соответствующих понятий ООАП.

.        Интеграция новейших достижений практики ООАП.

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

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

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

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

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

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

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

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

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

3. Описание языка программирования или среды разработки особенности, включающее наименование языка (среды), основные особенности и причины выбора

В настоящее время разработаны средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы.

. Описание СУБД, содержащее наименование СУБД и причины её выбора

Система управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями.

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

Фреймворк UML дает разработчикам CASE необходимую информацию о метамодели, что позволяет генерировать схемы реляционных СУБД с учетом спецификаций языка описания данных (Data Definition Language - DDL). Как минимум, большинство этих CASE-средств генерируют ANSI DDL, а некоторые из них - DDL, предназначенные для определенных баз данных - таких как Oracle и SQL Server.

Поставщики ERD и средств моделирования объектов связаны между собой, как, например, Rational (производитель Rational Rose) и LogicWorks Inc. (ERWin). Например, бесплатно рапространяемый мост, доступный с Web-сайта Rational, позволяет генерировать схему СУБД непосредственно в ERWin. Это очень полезно, поскольку ERWin может генерировать DDL СУБД во многих различных языках, что, разумеется, расширяет диаграмму классов UML - источников схемы СУБД. Однако, если был выбран не ERWin, то можно воспользоваться средствами ERD, большинство которых предоставляют возможность обратной разработки. Можно использовать другой подход. С помощью объектных средств генерируется ANSI DDL, а затем эти файлы передаются средству ERD, и в дальнейшем они могут обрабатываться базой данных.

. Назначение Microsoft Visio

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

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

Здесь важно отметить, что библиотека подразумевает реализацию входящих в неё типов данных в некотором другом приложении (или других приложениях), а пользователь конструктора объектных моделей рассматривает те объекты, с которыми он работает, лишь как некоторые структурные описания классов, функциональное значение которых ему заранее известно. Таким образом, описание поведения объектов полностью исключено из модели, которая создается в конструкторе, и остается только их структурное описание. Это связано с тем - и это главная особенность конструктора, - что он ориентирован не на разработку новых приложений, а предназначен для построения объектной модели из всех возможных типов данных, которые уже описаны в библиотеке и ранее были реализованы в соответствующих приложениях, обеспечивающих объектное имитационное моделирование в конкретных предметных областях. Именно в этом проявляется существенное отличие разрабатываемого здесь интерфейса от различных систем объектно-ориентированного проектирования: последние ориентированы на разработку программных приложений с нуля, а предлагаемый инструмент предназначен для построения моделей на основе уже реализованных в различных приложениях библиотек объектов. Подобную технологию можно было бы назвать визуальным (объектным) моделированием, по аналогии с термином «визуальное программирование».

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

Глава 3

. Разработка диаграммы классов, описывающей логическую модель системы

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

Рисунок 3. Диаграмма классов

. Разработка диаграммы состояний

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

Рисунок 4. Диаграмма состояний

. Формирование диаграммы деятельности

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

Достоинством диаграммы деятельности является возможность развёртывания её в виде дорожек, т.е. с привязкой к исполнителям конкретных операций алгоритма. Диаграмма строится для отдельного класса, варианта использования, отдельной операции класса или целой подсистемы. На рис.5(ниже) представлена диаграмма деятельности под названием «Управление справочником администратора».

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

. Разработка диаграммы последовательности

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

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

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

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

Наша диаграмма последовательности описывает процесс добавления нового работника. В этом процессе участвуют такие объекты как: сотрудник отдела кадров (актер), отдел кадров (компонент), сотрудник отдела кадров (интерфейс) и работник (класс).

Сотрудник отдела кадров выполняет следующие действия (сообщения): open workerform (открыть рабочую форму), add workerform (добавить рабочую форму), close workerform (закрыть рабочую форму).

Отдел кадров выполняет следующие действия (сообщения): add worker (добавить работника), булева функция - Boolean и обратное сообщение - add worker (добавить работника), булева функция - Boolean.

Рисунок 6. Диаграмма последовательности

Глава 4

. Проектирование физической структуры программного средства.

Разработка диаграммы компонентов

Диаграмма компонентов описывает особенности физического представления системы и позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты (Администратор, Владелец, Работник, Заказчик, Браузер), интерфейсы (iАдминистратор,…,iWeb) и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей:

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

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

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

программного кода;

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

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

Рисунок 7. Диаграмма компонентов.

. Разработка диаграммы развертывания

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

Рисунок 8. Диаграмма развертывания

Заключение

В рамках выполненной работы на тему «Программная система птицефабрики»:

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

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

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

Список литературы

1.        Буч Г., Рамбо Д. Язык UML: руководство пользователя. - Москва, 2010. - 240 с.

2.      Фаулер М., Кендал С. UML: основы. - СПб. : Питер, 2008. - 186 с.

.        Методические указания к расчетной работе по дисциплине «Программная инженерия».

.        Зимнов С. Лекции по дисциплине «Программная инженерия».