Документирование результатов учебно-исследовательской работы с использованием языка UML

Министерство образования и науки Украины Севастопольский национальный технический университет Кафедра кибернетики и вычислительной техники ПОЯСНИТЕЛЬНАЯ ЗАПИСКА к курсовому проекту по дисциплине «Автоматизация проектирования сложных систем»

на тему: «Документирование результатов учебно-исследовательской работы с использованием языка UML»

Выполнил: ст. гр. М-52д Хлопотов А.И.

Проверили:

Воронин Д.Ю.

Мащенко Е.Н.

Севастополь

СОДЕРЖАНИЕ ВВЕДЕНИЕ

1. ПОСТАНОВКА ЗАДАЧИ

2. ОПИСАНИЕ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ, ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

3. ОПИСАНИЕ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ (ДИАГРАММЫ КОНЦЕПТУАЛЬНЫХ КЛАССОВ)

5. ОПИСАНИЕ ДИАГРАММ ВЗАИМОДЕЙСТВИЯ

4. ОПИСАНИЕ ДИАГРАММ КЛАССОВ ПРОЕКТИРОВАНИЯ

6. ОПИСАНИЕ ДИАГРАММ ВИДОВ ДЕЯТЕЛЬНОСТИ

7. ОПИСАНИЕ ДИАГРАММ СОСТОЯНИЙ ЗАКЛЮЧЕНИЕ БИБЛИОГРАФИЧЕСКИЙ СПИСОК ПРИЛОЖЕНИЕ А. ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

ПРИЛОЖЕНИЕ Б. ДИАГРАММА КОНЦЕПТУАЛЬНЫХ КЛАССОВ ПРИЛОЖЕНИЕ В. ДИАГРАММА ВЗАИМОДЕЙСТВИЯ ПРИЛОЖЕНИЕ Г. ДИАГРАММА КЛАССОВ ПРОЕКТИРОВАНИЯ

ПРИЛОЖЕНИЕ Д. ДИАГРАММА ВИДОВ ДЕЯТЕЛЬНОСТИ

ПРИЛОЖЕНИЕ Е. ДИАГРАММА СОСТОЯНИЙ ВВЕДЕНИЕ Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем. UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования.

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

UML — это язык визуализации, специфицирования, конструирования, а так же язык документирования. Как было сказано ранее язык UML предназначен прежде всего для разработки программных систем. Его использование особенно эффективно в следующих областях: информационные системы масштаба предприятия; банковские и финансовые услуги; телекоммуникации; транспорт; оборонная промышленность, авиация и космонавтика; розничная торговля; медицинская электроника; наука; распределенные Web-системы.

В данном курсовом мы рассмотрим язык UML на примере Web сервиса. На примерах диаграмм вариантов использования, концептуальных классов, классов проектирования, взаимодействия, видов деятельности и состояний.

1. ПОСТАНОВКА ЗАДАЧИ Основания и назначение разработки Основанием для разработки программного комплекса является задание на дипломное проектирование для студентов пятого курса.

Тема разработки: Интернет приложение (Web — сервис) позволяющий делать заказы онлайн и выполнять их обработку.

В рамках выполнения курсовой работы необходимо:

Определить варианты использования (описать на естественном языке и построить диаграммы вариантов использования);

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

Построить диаграмму взаимодействия;

Для выбранного алгоритма построить и описать диаграмму видов деятельности;

Построить и описать диаграмму состояний.

2. ОПИСАНИЕ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ, ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ Диаграмма вариантов использования (Use-Cases Diagram) — UML диаграмма, с помощью которой в графическом виде можно изобразить требования к разрабатываемой системе. Диаграмма вариантов использования — это исходная концептуальная модель проектируемой системы, она не описывает внутреннее устройство системы.

Вариант использования — результат моделирования, временные диаграммы и результат анализа.

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

Устанавливаются границы системы.

Выявляются актеры (actor).

Выявляются варианты использования (use case).

Определяются варианты использования;

Устанавливаются основные и альтернативные потоки событий (успешные и неуспешные сценарии поведения системы).

Проводится описание (специфицирование) вариантов использования в произвольной либо табличной форме.

Реализуется графическая нотация (диаграмма) вариантов использования.

Для разрабатываемого программного продукта диаграмма вариантов использования приведена в приложении А.

Описание вариантов использования для данной задачи Подразумевается, что изначально все виды актеров это User. После Log in определяется тип актера. За регистрацию в системе отвечает актер Admin, это означает, что только Admin имеет право создавать редактировать удалять и просматривать список пользователей. Несмотря на то что актеры Customer и Merchandiser ассоциируются с Manage orders только Сustomer может создавать заказы. В свою очередь Merchandiser может анализировать заказы. Supervisor это актер ответственный за добавление заказов поступивших на склад.

3. ОПИСАНИЕ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ (ДИАГРАММЫ КОНЦЕПТУАЛЬНЫХ КЛАССОВ)

Модель предметной области или концептуальная объектная модель (conceptual object model) — представление понятий, атрибутов и ассоциаций из предметной области, имеющих важное значение для решения задачи и выраженных в терминах реального мира.

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

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

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

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

Базовые отношения, изображаемые на диаграммах классов, следующие:

отношение ассоциации (association relationship);

отношение агрегации (aggregation relationship);

отношение композиции (composition relationship);

отношение обобщения (generalization relationship);

отношение зависимости (dependency relationship).

Для проектируемой системы диаграмма концептуальных классов приведена в приложении Б.

Описание концептуальных классов Описание основных классов:

User — хранит в себе информацию о пользователе, а также реализует методы для получения информации о пользователе;

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

Role — класс хранящий в себе виды ролей. При добавлении новых ролей придется добавить немного кода. Это дает гибкость нашей система;

Order — класс отображающий в себе общую информацию о заказе. Хранит в себе поля покупателя и ответственного за проверку заказа. Реализованы методы для получения данных всех полей данного класса;

Payment — класс хранящий в себе информацию о платеже (информация о кредитной карте). У каждого order может быть только 1 payment. Реализует все методы для взаимодействия order и payment, а также методы для получения всех полей;

OrderDetails — класс расширяющий класс order. Содержит в себе информацию о конкретном item и его свойства;

Items — класс содержащий в себе информацию о единице товара;

Price — расширяет класс Items. Включает в себя информацию о цене конкретного item для определенного Dimension;

Demension — расширяет класс Price и содержит в себе информацию о упаковки товара.

4. ОПИСАНИЕ ДИАГРАММ ВЗАИМОДЕЙСТВИЯ Диаграмма взаимодействия отражает потоки сообщений между объектами системы и вызовы методов — динамическое представление взаимосвязи объектов. Один из видов — диаграмма последовательности — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.

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

Диаграмма последовательности — схема, которая для определенного сценария варианта использования показывает:

генерируемые внешними исполнителями события;

их порядок;

события, генерируемые внутри системы.

Все системы рассматриваются как «черный ящик».

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

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

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

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

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

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

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

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

Существуют следующие типы сообщений:

синхронное сообщение — отправитель ожидает завершения выполнения операции получателем сообщения;

асинхронное сообщение — отправитель продолжает исполнение, не ожидая возврата от получателя;

возврат — получатель сообщения возвращает фокус управления отправителю сообщения. Могут не указываться на диаграмме;

создание объекта;

уничтожение объекта.

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

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

Используются следующие стереотипы сообщений:

«call» (вызвать) — сообщение, требующее вызова операции или процедуры принимающего объекта;

«return» (возвратить) — сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту;

«create» (создать) — сообщение, требующее создания другого объекта для выполнения определенных действий;

«destroy» (уничтожить) — сообщение с явным требованием уничтожить соответствующий объект;

«send» (послать) — обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается другим.

Для разрабатываемой системы диаграмма последовательностей приведена в приложении В. На диаграмме проиллюстрирована последовательность действий при работе с меню игры.

Инициатором, естественно, является пользователь запустивший приложение. Как результат он увидит окно игрового приложения. На экране монитора пользователь увидит главное меню игры и три пункта меню.

5. ОПИСАНИЕ ДИАГРАММ КЛАССОВ ПРОЕКТИРОВАНИЯ Классы проектирования — это классы, описания которых настолько полны, что они могут быть реализованы.

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

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

область решения — техническая и инструментальная база для реализации системы.

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

Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов:

«+» обозначает атрибут (операцию) с областью видимости типа общедоступный (public). Атрибут (операция) с этой областью видимости доступен или виден из любого другого класса;

«#» обозначает атрибут (операцию) с областью видимости типа защищенный (protected). Атрибут (операция) с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;

«-» обозначает атрибут (операцию) с областью видимости типа закрытый (private). Атрибут (операция) с этой областью видимости недоступен или невиден для всех классов без исключения.

Квантор видимости может быть опущен. В этом случае его отсутствие просто означает, что видимость атрибута (операции) не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как public или private. Вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private.

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

полнота и достаточность;

простота;

высокая внутренняя связность;

низкая связность с другими классами.

Для разрабатываемой системы диаграмма классов проектирования приведена в приложении Г.

6. ОПИСАНИЕ ДИАГРАММ ВИДОВ ДЕЯТЕЛЬНОСТИ интернет приложение диаграмма класс Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности (диаграммы видов деятельности). Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на этих диаграммах также присутствуют обозначения состояний и переходов. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние выполняется только при завершении этой операции.

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

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

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

Существуют три категории узлов:

узлы действия — представляют собой отдельные единицы работы, элементарные с точки зрения рассматриваемой деятельности;

узлы управления — управляют потоком деятельности;

объектные узлы — представляют объекты, используемые в деятельности.

Ребра представляют потоки деятельности. Существуют два типа ребер:

ребра потоков управления ;

ребра потоков объектов .

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

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

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

Для разрабатываемой системы диаграмма видов деятельности приведена в приложении Д.

7. ОПИСАНИЕ ДИАГРАММ СОСТОЯНИЙ Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия.

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

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

Понятие состояния (state) является фундаментальным в метамодели языка UML. Вся концепция динамической системы основывается на понятии состояния.

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

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

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

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

Простой переход (simple transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния объекта другим.

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

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

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

Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события-триггера и представляет собой некоторое булевское выражение. Из контекста диаграммы состояний должна явно следовать семантика этого выражения, а для записи выражения может использоваться синтаксис языка объектных ограничений.

Для разрабатываемого игрового приложения диаграмма состояний приведена в приложении Е.

ЗАКЛЮЧЕНИЕ

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

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

диаграмма концептуальных классов;

диаграмма классов проектирования;

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

диаграмма взаимодействий;

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

Построение перечисленных диаграмм выполнялось в приложении Software Ideas Modeler Standard, которое предоставляло инструментарий для построения диаграмм.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК Методические указания для выполнения курсовой работы по дисциплине «Автоматизация проектирования сложных систем» для студентов специальности «Компьютерные системы и сети» дневной формы обучения/ Сост.: Мащенко Е. Н., Нюнькина Ю.П.- Севастополь: Изд-во СевНТУ, 2010. — 48 с.

А.В. Леоненков. Нотация и семантика языка UML. Электронный курс. 2005 URL: http://www.intuit.ru/department/pl/umlbasics/

Фаулер М., Скотт К. UML. Основы. — Пер. с англ. — СПб; Символ-Плюс, 2002. — 192с., ил.

ПРИЛОЖЕНИЕ А. ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ ПРИЛОЖЕНИЕ Б. ДИАГРАММА КОНЦЕПТУАЛЬНЫХ КЛАССОВ ПРИЛОЖЕНИЕ В. ДИАГРАММА ВЗАИМОДЕЙСТВИЯ ПРИЛОЖЕНИЕ Г. ДИАГРАММА КЛАССОВ ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЕ Д. ДИАГРАММА ВИДОВ ДЕЯТЕЛЬНОСТИ ПРИЛОЖЕНИЕ Е. ДИАГРАММА СОСТОЯНИЙ