новая папка 1 / 293613

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Оренбургский государственный университет»

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

О.Н. Яркова

ПРОЕКТИРОВАНИЕ ОБЪЕКТНООРИЕНТИРОВАННЫХ ПРОГРАММ СРЕДСТВАМИ StarUML (ДИАГРАММЫ ПРЕЦЕДЕНТОВ, КЛАССОВ)

Рекомендовано к изданию Редакционно-издательским советом федерального государственного бюджетного образовательного учреждения высшего профессионального образования «Оренбургский государственный университет» в качестве методических указаний для студентов, обучающихся по программам высшего профессионального образования по направлениям подготовки 080100.62 Экономика, профиль «Математические методы в экономике», 231300.62 Прикладная математика, Общий профиль, 080500.62 Бизнес-информатика, профиль «Архитектура предприятия»

Оренбург

2014

УДК 004.42(676.5) ББК 32.973-018.2я7 Я 74

Рецензент – кандидат технических наук Р.И. Хасанов

Яркова, О.Н.

Я74 Проектирование объектно-ориентированных программ средствами StarUML (диаграммы прецедентов, классов): методические указания / О.Н. Яркова; Оренбургский гос. ун-т. – Оренбург : ОГУ, 2014. – 28 с.

Методические указания содержат рекомендации к выполнению лабораторной и самостоятельной работы по дисциплине «Разработка и применение прикладного программного обеспечения». Методические указания предназначены студентам направлений 231300.62 Прикладная математика, 080500.62 Бизнес информатика, 080100.62 Экономика, а так же студентам других специальностей и направлений, изучающим дисциплину «Разработка и применение прикладного программного обеспечения» и родственные дисциплины.

УДК 004.42(676.5) ББК 32.973-018.2я7

Яркова О.Н., 2014

ОГУ, 2014

2

Содержание

3

Введение

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

StarUML является свободно распространяемым редактором, максимально соответствующим стандарту UML 1.4 и поддерживающим нотации языка UML 2.0.

Он служит достойной альтернативой дорогостоящему лицензионному пакету IBM

RationalRose.

1 Общие сведения о UML

Спецификация требований к разрабатываемому программному обеспечению

(Software requirements specification, SRS) включает модель требований (Requirements model) и модель прецедентов (Use case model, модель вариантов использования).

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

определяющие, какие функции должна выполнять автоматизированная система) и

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

Моделирование прецедентов – это другой, дополнительный, способ выявления и документирования требований. Модель прецедентов является основным источником объектов и классов. Это базовые исходные данные для моделирования классов. В этой модели выделяют четыре компонента:

- граница моделируемой системы или в нотации UML 2.х - контекст системы

(subject) – прямоугольник, очерчивающий прецеденты.

- действующие лица (actor, актеры, акторы, внешние роли) – роли,

выполняемые людьми или сущностями (другие системы или время),

использующими систему;

4

- варианты использования (прецеденты, спецификации функциональных возможностей системы) – то, что акторы могут делать с системой, функции,

выполняемые системой. Приемлемая норма – когда средней сложности приложение имеет от 20 до 50 прецедентов;

- отношения – значимые связи между акторами и прецедентами.

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

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

Она должна быть достаточно простой и понятной.

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

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

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

Для описания модели сложной системы в UML определены две группы диаграмм: структурные диаграммы и диаграммы поведения.

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

а) диаграмма классов (Class Diagram);

б) диаграмма объектов (Object Diagram);

5

в) диаграмма компонентов (Component Diagram);

г) диаграмма развертывания (Deployment Diagram).

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

а) диаграмма прецедентов или вариантов использования (Use Case Diagram);

б) диаграмма последовательности (Sequence Diagram);

в) диаграмма кооперации (Collaboration Diagram);

г) диаграмма состояний (Statechart Diagram);

д) диаграмма деятельности (Activity Diagram).

Это список основных диаграмм, применяемых в UML. Отметим, что некоторые инструментальные средства позволяют генерировать и другие виды.

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

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

(рисунок 1).

Рисунок 1 - Интегрированная модель сложной системы в нотации UML

6

2 Описание работы с пакетом StarUML

2.1 Общие сведения

StarUML поддерживает 11 типов диаграмм UML.

1. Диаграмма прецедентов или вариантов использования - Use Case

Diagram.

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

2. Диаграмма классов - Сlass Diagram.

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

3. Диаграмма сообщений (последовательностей) - Sequence Diagram.

Диаграмма последовательностей предназначена для визуализации взаимодействия составных частей системы. Она визуализирует множество взаимодействий (InteractionInstanceSet) между элементами множества инстанций

(CollaborationInstanceSet). Диаграммы последовательностей роли ориентированы на классификаторы-роли, а обычная диаграмма сообщений - на классификаторы-

инстанции.

4. Диаграмма сообщений (последовательностей) роли - Sequence Role

Diagram.

Диаграмма сообщений роли визуализирует взаимодействия с точки зрения ролей. Она визуализирует множество взаимных сообщений между классификаторами-ролями (Interaction) в рамках совместных действий

(Collaboration).

7

5. Диаграмма совместных действий (кооперации) - Collaboration Diagram.

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

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

на отображение инстанций.

6. Диаграмма совместных действий (кооперации) ролей - Collaboration

Role Diagram.

Диаграмма кооперации ролей визуализирует взаимодействия между ролями.

Она отображает модель взаимодействия классификаторов-ролей внутри кооперации.

Обычная диаграмма кооперации ориентирована на отображение инстанций,

диаграмма совместных действий ролей направлена на отображение классификаторов-ролей.

7. Диаграмма состояний (Statechart Diagram).

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

8. Диаграмма действий (Activity Diagram).

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

однако чаще всего она применяется к объектам подобным классам, пакетам и операциям.

9. Диаграмма компонентов (Component Diagram).

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

8

10. Диаграмма развертывания (Deployment Diagram).

На диаграмме развертывания изображают взаимодействие аппаратных

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

объектов.

11. Композиционная структурная диаграмма (Composite Structure

Diagram).

Композиционная структурная диаграмма отражает внутреннюю структуру объекта. Она показывает взаимодействие объекта с другими частями системы.

Создание новой диаграммы:

1. Запустите StarUML. После запуска система предложит вам выбрать тип создаваемого проекта (рисунок 2). Выберете «Empty Project» (пустой проект).

Рисунок 2 – Создание нового проекта

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

9