Московский Государственный Технический Университет им. Н. Э. Баумана
Кафедра “Программного обеспечения ЭВМ и информационные технологии”
Лабораторная работа №2
По курсу “Технология программирования”
Моделирование информационных систем с использованием
CASE
средств
Методические указания по выполнению лабораторной работы
Подготовила: Романова Т.Н.
доц. кафедры ИУ-7, к.ф.-м. н.
.
Москва 2011 г.
Содержание
Содержание…………………………………………………………………………………………2
Постановка задачи………………………………………………………………………………….3
Краткие теоретические сведения………………………………………………………………….4
Список литературы………………………………………………………………………………..30
Цель работы
- знакомство с унифицированным языком моделирования (UML), знакомство с пакетом визуального моделирования Rational Rose в соответствии с методологией Rational
Unified Process и приобретение навыков разработки технического задания в соответствии
с требованиями ЕСПД и навыков моделирования конкретной информационной системы
в CASE системе Rational Rose 2000.
Постановка задачи
Выбрать предметную область, для которой необходимо разработать информационную систему (ИС
). Это может быть будущая дипломная работа или небольшая подсистема крупной ИС, в разработке которой Вы принимаете участие.
2. Разработать техническое задание (ТЗ
) на информационную систему, которую будете моделировать в лабораторной работе №2 в соответствии со стандартами (Единой системой программной документации).
В
CASE системе спроектировать выбранную ИС:
Поведение разрабатываемой системы, то есть функциональность, обеспечиваемую системой, (функциональную модель) описать с помощью диаграмм прецедентов (
use
case
diagrams
).
Основным средством для представления статической модели
ИС является
диаграмма классов
. Выделить в проектируемой информационной системе объекты и классы. Описать отношения в диаграммах классов (ассоциацию, обобщение, зависимость, агрегацию, композицию, реализацию).
Построить динамическую модель
ИС с помощью диаграмм схем состояний
, и диаграмм последовательности действий
.
Диаграммы компонентов
применить для проектирования физической структуры ИС. Эти диаграммы показывают, как выглядит программное обеспечение на физическом уровне, т. е. из каких частей состоит и как эти части связаны между
собой. Промоделировать размещение компонентов.
Средствами CASE системы сгенерировать код ИС.
Представить отчет о выполнении лабораторной работы №2 по схеме.
· Титульный лист.
· Введение, описание предметной области, необходимость создания ИС.
· Техническое задание по ЕСПД.
· Распечатки всех построенных в CASE системе диаграмм.
· Описание атрибутов и спецификаций.
· Выводы о достоинствах и недостатках CASE системы для моделирования выбранного класса задач.
· Список использованной литературы.
Краткие теоретические сведения.
АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ.
Собственно разработка любого программного обеспечения начинается с анализа требований к будущему программному продукту. В результате анализа получают спецификации разрабатываемого программного обеспечения, выполняют декомпозицию и содержательную постановку решаемых задач, уточняют их взаимодействия и их эксплуатационные ограничения. В целом в процессе определения спецификаций строят общую модель предметной области как некоторой части реального мира, с которой будет тем или иным способом взаимодействовать разрабатываемое программное обеспечение, и конкретизирует его основные функции.
Спецификации программного обеспечения при структурном подходе
Cпецификации представляют собой полное
и точное
описание функций и ограничений разрабатываемого программного обеспечения. При этом одна часть спецификаций (функциональные
) описывает функции разрабатываемого программного обеспечения, а другая часть (эксплуатационные
) определяет требования к техническим средствам надежности информационной безопасности и т. д.
Определение отражает главные требования к спецификациям. Применительно к функциональным спецификациям подразумевается, что:
● требование полноты
означает, что спецификации должны содержать всю существенную информацию, где ничего важного не было бы упущено и отсутствует несущественная информация, например детали реализации, чтобы не препятствовать разработчику в выборе наиболее эффективных решений;
● требование точности
означает, что спецификации должны однозначно восприниматься как заказчиком так и разработчиком;
Последнее требование выполнить достаточно сложно в силу того, что естественный язык для описания спецификаций не подходит: даже подробные спецификации на естественном языке не обеспечивают необходимой точности. Точные спецификации можно определить, только разработав некоторую формальную модель
разрабатываемого программного обеспечения.
Формальные модели, используемые на этапе определения спецификаций можно разделить на две группы: модели, зависящие от подхода к разработке
(структурного или объектно-ориентированного), и модели, не зависящие
от него. Так диаграммы переходов состояний, которые демонстрируют особенности поведения разрабатываемого программного обеспечения при получении тех или иных сигналов извне, и математические модели предметной области используют при любом подходе к разработке.
В рамках структурного подхода на этапе анализа и определения спецификаций используют три типа моделей: ориентированные на функции, ориентированные на данные и ориентированные на потоки данных. Каждую модель целесообразно использовать для своего специфического класса программных разработок.
На рис.1 показана классификация моделей разрабатываемого программного обеспечения, используемых на этапе определения спецификаций.
Рис. 1.
Классификация моделей разрабатываемого программного обеспечения, используемых на этапе определения спецификаций
Следует иметь в виду, что все функциональные спецификации описывают одни и те же характеристики разрабатываемого программного обеспечения: перечень функций и состав обрабатываемых данных. Они различаются только системой приоритетов (акцентов), которая используется разработчиком в процессе анализа требований и определения спецификаций. Диаграммы переходов состояний определяют основные аспекты поведения программного обеспечения во времени, диаграммы потоков данных - направление и структуры потоков данных, а концептуальные диаграммы классов - отношение между основными понятиями предметной области.
Поскольку разные модели описывают проектируемое программное обеспечение с разных сторон, рекомендуется использовать сразу несколько моделей и сопровождать их текстами, словарями, описаниями и т. п., которые поясняют соответствующие диаграммы.
Так методологии структурного анализа и проектирования,
основанные на моделировании потоков данных, обычно используют комплексное представление программного обеспечения в виде совокупности моделей:
● диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;
● диаграмм “сущность-связь” (ERD - Enity Relationhship Diagrams), описывающих базы данных разрабатываемой системы;
● диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;
● спецификаций процессов;
● словаря терминов.
Взаимосвязь элементов такой обобщенной модели показана на рис.2
Рис.2.
Элементы полной спецификации методологий структурного анализа и проектирования программного обеспечения основанных на потоках данных
Спецификации процессов
. Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси-Шнейдермана. Поскольку описание процесса должно быть кратким и понятным, как разработчику, так и заказчику, для их спецификации чаще всего используют псевдокоды.
Словарь терминов
представляет собой краткое описание основных понятий используемых при составлении спецификаций. Он должен включать определение основных понятий предметной области, описание структур элементов данных их типов и форматов, а также всех сокращений и условных обозначений. Он предназначен для повышения степени понимания предметной области и исключения риска возникновения разногласий при обсуждении моделей между заказчиками и разработчиками.
Обычно описание термина в словаре выполняют по следующей схеме:
● термин;
● категория (понятие предметной области элемент данных условное обозначение и т. д.);
● краткое описание.
В качестве примера приведем описание одного из терминов системы решения комбинаторно-оптимизационных задач:
Термин . . . . . . . . . Алгоритм
Категория . . . . . . . Понятие предметной области
Описание . . . . . . . В настоящем проекте используется для обозначения обобщенного понятия “реализация процедуры решения конкретной задачи выбранным методом”
Кроме указанных моделей в состав полной спецификации при любом подходе могут входить математические модели описания объектов предметной области, которые позволяют уточнить основные соотношения анализируемых величин и накладываемые на них ограничения.
Диаграммы переходов состояний
Диаграмма переходов состояний
является графической формой предоставления конечного автомата
- математической абстракции используемой для моделирования детерминированного поведения технических объектов или объектов реального мира.
На этапе анализа требований и определения спецификаций диаграмма переходов состояний демонстрирует поведение
разрабатываемой программной системы при получении управляющих воздействий. Под управляющими воздействиями
или сигналами в данном случае понимают управляющую информацию получаемую системой извне. Например, управляющими воздействиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной системе. Получив такое управляющее воздействие, разрабатываемая система должна выполнить определенные действия и или остаться в том же состоянии, или перейти в другое состояние взаимодействия с внешней средой.
Для построения диаграммы переходов состояний необходимо в соответствии с теорией конечных автоматов определить: основные состояния, управляющие воздействия (или условия перехода), выполняемые действия и возможные варианты переходов из одного состояния в другое. Условные обозначения, используемые при построении диаграмм переходов состояний на рис.3.
Рис.3.
Условные обозначения диаграмм переходов состояний:
а
- терминальное состояние; б
- промежуточное состояние; в - переход
Если программная система в процессе функционирования активно не взаимодействует с окружающей средой (пользователем или датчиком), например, использует примитивный интерфейс и выполняет некоторые вычисления по заданным исходным данным, то диаграмма переходов состояний
обычно интереса не представляет. В этом случае она демонстрирует только последовательно выполняемые переходы: из исходного состояния в состояние ввода данных, затем после выполнения вычислений - в состояние вывода и, наконец, в состояние завершения работы (рис. 4).
Рис. 4.
Диаграмма переходов состояний программного обеспечения, активно не взаимодействующего с окружающей средой
Для активного программного обеспечения с развитым пользовательским интерфейсом основные управляющие воздействия - команды пользователя, для программного обеспечения реального времени - сигналы от датчиков и/или оператора производственного процесса. Общим для этих типов программного обеспечения является наличие состояния ожидания, когда программное обеспечение приостанавливает работу до получения очередного управляющего воздействия. Для интерактивного программного обеспечения наиболее характерно получение команд различных типов (рис.5), а если это еще и программное обеспечение реального времени - однотипных сигналов (либо от многих датчиков, либо требующих продолжительной обработки).
В отличие от интерактивных систем для систем реального времени обычно установлено более жесткое ограничение на время обработки полученного сигнала программного обеспечения. Такое ограничение часто требует выполнения дополнительных исследований поведения системы во времени, например, с использованием систем Петри или марковских процессов.
К программному обеспечению, требующему уточнения особенностей посредством построения диаграммы переходов состояний, относится и программное обеспечение, ориентированное на работу в сети. При этом отдельно строят модели поведения сервера и клиента, представляя сообщения, передаваемые между ними в виде управляющих воздействий.
Пример.
Рассмотрим диаграмму переходов состояний для программного построения графиков функций одной переменной. Программа относится к классу интерактивных, соответственно на этапе анализа и определения спецификаций целесообразно уточнить поведение программы на уровне интерфейса с пользователем (наличие простого интерфейса желательно оговорить в техническом задании). Один из возможных вариантов диаграммы переходов состояний программы представлен на рис.6.
Полученную диаграмму переходов состояний следует согласовать с за-казчиком программного обеспечения.
Поиск классов и объектов
Объект (
objekt)
- это некая сущность реального мира или концептуальная сущность. Объект может быть чем-то конкретным, например, грузовик или мой компьютер, или концептуальным, как, например, химический процесс, банковская операция, торговый заказ, кредитная история или ставка прибыли.
Объектом называется концепция, абстракция или вещь с четко определенными границами и значением для системы. Каждый объект в системе имеет три характеристики: состояние, поведение и индивидуальность.
Состояние, поведение и индивидуальность
Состоянием (
state)
объекта называется одно из условий, в которых он может находиться.
Состояние системы обычно меняется во времени и определяется набором свойств, называемых атрибутами(
attribute)
, значений свойств и отношений между объектами. Например, объект учебный курс (CourseOffering) в системе регистрации учебных курсов может находиться в одном из двух состояний: открыт для записи или закрыт для записи. Если количество студентов, зарегистрированных на курс, меньше десяти, запись на курс продолжается. После регистрации десятого студента она прекращается.
Поведение (
behavior)
определяет, как объект реагирует на запросы других объектов и что может делать сам объект. Поведение реализуется с помощью набора операций
(operation) для объекта. В системе регистрации курсов объект учебный курс может иметь операции добавить студента или удалить студента.
Индивидуальность (
identity)
означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта. Например: Алгебра 101, секция 1 и Алгебра 101, секция 2 – два объекта в системе регистрации курсов. Хотя они оба являются учебными курсами, каждый из которых уникален.
В языке UML объект изображается в виде прямоугольников, а его имя пишется с подчеркиванием (см. рис.1).
| Алгебра 101, Раздел 1
|
Рис. 1. Нотация языка
UML для объекта
Что такое класс
Класс (
class)
– это описание группы объектов с общими свойствами.
Каждый объект является экземпляром конкретного класса и не может быть экземпляром нескольких классов. Например, класс учебный курс (Course Offering) может определяться следующими характеристиками:
Атрибуты – место занятий, время занятий;
Операции – получить место занятий, получить время занятий, добавить студента на курс.
Алгебра 101, секция 1 и Алгебра 101, секция 2 – это объекты, принадлежащие классу учебный курс. Каждый объект имеет значения атрибутов и доступ к операциям, определенным классом учебный курс.
«Хороший» класс представляет одну и только одну абстракцию, то есть должен отражать одну основную сущность. Например, класс, способный хранить информацию о студентах и данные о курсах, которые студент посещает в течение нескольких лет, не является «хорошим» классом, потому что не представляет одну сущность. Такой класс необходимо разделить на два связанных класса: студент и история студента.
Название классов выбираются в соответствии с понятиями предметной области. Имя должно быть существительным в единственном числе, наиболее точно характеризующим предмет. В качестве имени класса можно использовать акроним
, если он имеет одинаковое значение для всех предоставляемых сущностей. При использовании акронима в описании класса желательно указать полное название.
Иногда трудно отличить объект от класса. Почему, например, Алгебра 101, секция 1- объект, а не класс? Что отличает его от объекта Алгебра 101, секция 2? Ответы на эти вопросы субъективны. Изучив эти объекты, можно заключить, что у них одинаковая структура и поведение. Они лишь являются разными учебными предметами семестра. Кроме того, в системе регистрации курсов можно обнаружить множество схожих сущностей с одинаковой структурой и поведением:
Музыка 101, секция 1;История 101,секция 1; История 101,секция 2 и т.п.
Значит, допустимо создание единого класса учебный курс (CourseOffering).
В языке UML классы изображаются в виде разделенных прямоугольников. В верхней секции указывается имя класса, средняя секция содержит его структуру - атрибуты, а нижняя описывает его поведение- операции. Класс показан на рис.2.
| Учебный курс |
| Место занятий |
| Добавить студента |
Рис. 2.Нотация языка
UML
Рис. 3. Класс, созданный в окне браузера
для классов
Порядок создания классов в программе
Rational
Rose:
Щелкните правой кнопкой мыши по разделу Logical
View
(Логическое представление) в окне браузера.
В появившемся контекстно-зависимом меню выберите команду New
→ Class
(Создать → Класс). В список браузера будет добавлен новый класс с именем New
Class.
3. Введите нужное имя класса.
Класс в окне браузера показан на рис.3.
Стереотипы и классы
Мы уже говорили о стереотипах отношений на диаграмме функций. Классы тоже могут иметь стереотипы. Как и ранее, стереотип используется для создания нового типа элемента моделирования, в данном случае для создания нового типа элемента моделирования, в данном случае для создания новых типов классов. Некоторые основные стереотипы класса- это сущность, граничный элемент, элемент управления, сервисный элемент и исключение.
Стереотип класса указывает под его именем и заключается в двойные треугольные скобки. Если требуется, стереотип можно отобразить графическим значком или выделить цветом. В программе Rational Rose есть изображения для стереотипов Rational Unifield Process – управляющего элемента, сущности и граничного элемента. Эти стереотипы, а также пример класса со стереотипом исключение
показаны на рис. 4.
Рис. 4. Классы со стереотипами
Обнаружение классов
Рецептов для поиска классов не существует. Как сказал Грейди Буч: «Это действительно трудно!» Rational Unifield Process содержит средства, помогающие обнаружить в системе классы типа управляющий элемент, граничный элемент, сущность. Эти три стереотипа соответствуют концепции «модель-представление-управление» и позволяют аналитику отделить друг от друга представление, предметную область и управление в системе.
По причине того, что процесс анализа и проектирования является интерактивным, список классов со временем изменится. Начальный набор классов, скорее всего, будет отличаться от итогового. Поэтому для описания начального набора классов, обнаруженных в системе, часто используется термин «класс-кандидат».
Классы-сущности
Класс-сущность (
entity
class)
используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы. Такие классы обычно не зависят от окружения, то есть они нечувствительны к взаимодействию окружающей среды с системой. Следовательно, они не зависят от приложения и могут использоваться в различных приложениях.
Первый шаг - изучить обязанности, описанные в потоке событий для выявления прецедентов (что система должна делать). Классы – сущности это обычно те классы, которые требуются системе для выполнения определенных обязанностей. Использование существительных для описания обязанностей может стать хорошим началом. Исходный список нужно профильтровать, так как он будет содержать слова, не относящиеся к предметной области, языковые выражения, избыточные слова и существительные, описывающие структуру класса.
Классы – сущности обычно определяются на стадии проработки. Их часто называют классами предметной области, потому что они представляют собой абстракции предметов реального мира.
Граничные классы
Граничные классы (
boundary
class)
обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы предоставляют интерфейс для пользователя или другой системы (то есть актера). Они составляют внешне зависимую часть системы для моделирования интерфейсов системы.
Для обнаружения граничных классов изучают пары классов актер/сценарий. Такие классы, определенные на фазе проработки, обычно являются классами верхнего уровня. Например, вы можете смоделировать окно, но не моделировать его диалоговые элементы и кнопки. В этом случае вы опишете требования пользовательского интерфейса, но не реализуете его.
Требования к пользовательскому интерфейсу порой недостаточно ясны. Обычно используются термины «дружественный» и «гибкий». Но дружественный интерфейс разными людьми трактуется по-разному. Здесь могут пригодиться прототипы. Пользователь может посмотреть и почувствовать систему, чтобы реально оценить, что значит «дружественный». И то, что это значит, затем представляется как структура и поведение граничного класса. На этапе проектирования такие классы совершенствуются и реализуются пи создании пользовательского интерфейса.
Граничные классы также используются для обеспечения связи с другими системами. На этапе проектирования эти классы совершенствуются и выносятся на обсуждение вопросов реализации протоколов взаимодействия.
Управляющие классы
Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение. Управляющие классы можно представить как классы, «исполняющие» прецедент и определяющие его динамику. Они обычно зависят от приложения.
На ранней стадии проработки управляющие классы добавляются для каждой пары актер/прецедент. Такие классы определяют поток событий в прецедентах.
Вопрос использования управляющих классов очень субъективный. Многие авторы утверждают, что их применение приводит к отделению данных от поведения. Это может случиться, если управляющие классы выбраны неаккуратно. Если управляющий класс реализует что-то большее, чем последовательное действие, то он делает слишком много. Например: в системе регистрации учебных курсов студент выбирает курс, и если курс доступен, студента на него записывают.
Кто должен знать, как прикрепить студента,- управляющий класс или класс, представляющий курс занятий? Правильный ответ – класс, представляющий курс занятий. Управляющий класс знает лишь, когда студент должен быть прикреплен. «Плохой» управляющий класс знает не только когда, но и как прикрепить студента.
Управляющий класс для каждой пары актер/прецедент создается на начальном этапе. При дальнейшем анализе и проектировании управляющие классы могут исключаться, разделяться и объединяться.
Этапы создания стереотипов для классов в программе Rational Rose:
1. Щелкните правой кнопкой мыши по имени класса в списке браузера.
2. В появившемся контекстно – зависимом меню выберете команду Open Specification (Открыть параметры).
3. Щелкните по вкладке General(Общие).
4. В открывающемся списке Stereotype (Стереотип) выберете нужный стереотип. Чтобы создать новый стереотип, введите его имя в поле открывающегося списка Stereotype.
5. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно настройки параметров класса.
Рис.5 Установка стереотипа класса Студент
Документирование классов
После того, как класс создан, информацию о нем необходимо отразить в документации. Документация предназначена для описания назначения класса, а не его структуры. Например, класс студент может быть описан следующим образом:
Информация, необходимая для регистрации студента и оплаты обучения. Студент- это человек, обучающийся в университете.
А вот пример неправильного описания:
Имя, адрес и телефон студента.
Оно раскрывает только структуру класса, которую можно увидеть, посмотрев на список атрибутов, и не поясняет, для чего нужен данный класс.
Трудности при выборе имени и описании класса могут свидетельствовать о том, что это недостаточно хорошая абстракция. В следующем списке перечислены возможные варианты:
Можно определить имя и дать краткое, четкое описание- хороший класс-кандидат;
Можно определить имя и выбрать описание, похожее на описание другого класса,-объединить классы;
Можно определить имя, но потребуется целая книга, чтобы описать назначение класса, - разделить
Нельзя определить имя и дать описание - требуется дополнительный анализ для выделения правильных абстракций.
Чтобы описать классы в программе Rational Rose:
Выберете класс в списке браузера.
Установите курсор в окне описания и введите описание класса.
Описание класса представлено на рис.6.
Рис.6. Описание классов.
Пакеты
Если в системе существует много классов, управлять ими достаточно легко. Многие системы состоят из большого количества классов, поэтому необходимы пакеты.
Пакет(
package)
в логическом представлении модели- это набор классов и других связанных пакетов. Путем объединения классов в пакеты мы можем получить представление модели на более высоком уровне. Изучая содержимое пакета, мы, наоборот, получаем более детальное представление.
Каждый пакет содержит интерфейс, реализуемый набором его общедоступных классов
(public classes), то есть тех, с которыми могут общаться классы из других пакетов. Остальные классы пакета- это классы реализации
(implementation classes), которые не взаимодействуют с классами в других пакетах.
В сложной системе для облегчения восприятия пакеты могут быть
созданы на этапе проработки. В более простой системе классы,
выделенные на этапе анализа, могут быть сгруппированы в
один пакет, представляющий саму систему.
В ходе дальнейшего анализа и проектирования пакеты нужны для группировки классов, используемых в системной
архитектуре.
В языке UML пакеты изображаются в виде папок (см. рис. 7).
Рис. 7. Нотация UML для пакетов.
Чтобы создать пакеты в программе Rational Rose:
Щелкните правой кнопкой мыши по разделу Logical→
View
(Логическое представление) в окне браузера.
В появившемся контекстно-зависимом меню выберете команду New→
Pack
age( Создать→
Пакет).
Введите нужное имя пакета.
Пакет, созданный в списке браузера, показан на рис. 8. После создания пакета в него можно поместить необходимые классы.
Последовательность перемещения классов в пакет в программе Rational Rose:
В списке браузера выделите нужный класс, щелкнув по нему мышью.
Удерживая кнопку мыши нажатой, перетащите класс в пакет.
Повторите те же действия для других классов, которые требуется переместить.
Перемещенные классы показаны на рис.9.
Рис.8. Пакет, созданный в списке Рис.9. Перемещенные классы
браузера
Объекты и классы в системе регистрации курсов
Рассмотрим сценарий добавление учебного курса (Add a Course Offering to Teach) , который является внутренним потоком для прецедента выбор предметов для преподавания (Select Course to Teach). Данный сценарий позволяет преподавателю выбрать учебный курс для конкретного семестра.
Хотя мы рассматриваем этот процесс пошагово, на практике большинство шагов могут быть выполнены одновременно.
Выбор граничных классов
Рассматриваемый прецедент взаимодействует только с актером преподаватель. Действие, выполняемое указанным сценарием,- это только одна из возможностей, обеспечиваемых прецедентом (он также определяет, что преподаватель может изменять, удалять, просматривать и печатать курсы). Это означает, что в системе должен быть механизм, позволяющий преподавателю выбирать желаемое действие. Для обеспечения потребностей преподавателя создается специальный класс – параметры курса преподавателя (Professor Course Options). Дополнительно мы можем указать класс, который служит для добавления новых курсов, доступных преподавателю, - добавление учебного курса (Add a Course Offering).
Выбор классов-сущностей
Данный сценарий состоит из предметов, учебных курсов и назначения преподавателей. Мы можем выделить три класса-сущности: предмет (Course), учебный курс (Course Offering) и преподаватель (Professor).
Выбор управляющих классов
Добавим один управляющий класс с целью
обработки потока событий для прецедента
– менеджер курсов преподавателя
(Professor Course Manager).
Выбранные классы (с установленными
стереотипами сущность, управляющий
элемент или граничный элемент)
могут быть добавлены к модели (см. рис. 10).
Так как актер преподаватель уже
существует, при создании класса преподаватель
программа Rational Rose предупредит, что Рис.10. Классы для сценария
одно и то же имя используется в разных разделах. Добавление учебного курса
Создание пакетов
Следующий шаг – объединить классы в пакеты. На данном этапе выделим шесть
классов: предмет, учебный курс, преподаватель, параметры курса,
добавление учебного курса, менеджер курсов преподавателя.
Таким образом, мы можем создать следующие пакеты: Интерфейсы (Interfaces),
Объекты университета (Univercity Artifacts) и сведения о людях (PeopleInfo).
Затем классы помещаются в соответствующие пакеты (см. рис.11) .
Рис. 11. Пакеты в браузере.
Диаграммы классов
По мере того, как новые классы добавляются в систему, их текстовое представление становится неудобным. Диаграммы классов
(class diagrams) помогают графически представить некоторые или все классы в модели. Главная диаграмма классов в логическом представлении модели обычно отображает пакеты системы. Каждый пакет также имеет свою диаграмму классов, которая обычно содержит общедоступные классы пакета. Другие диаграммы создаются по необходимости.
Типичные примеры использования диаграмм классов:
Просмотр всех классов реализации в пакете;
Просмотр структуры и поведения одного или нескольких классов;
Просмотр иерархии наследования классов.
Программа Rational Rose автоматически создает главную диаграмму классов в логическом представлении модели.
Чтобы добавить пакеты к главной диаграмме классов,
сделайте следующее:
Дважды щелкните по пункту списка Main
diagram
(Главная диаграмма) в браузере, чтобы открыть диаграмму.
Выберете нужный пакет в списке, щелкнув по нему мышкой.
Перетащите пакет на диаграмму.
Аналогичным образом перетащите на диаграмму другие пакеты.
Главная диаграмма классов для системы регистрации показана на рис.12.
Этапы создания главной диаграммы классов пакета в программе Rational Rose:
Дважды щелкните по изображению пакета на диаграмме классов.
Пакет откроется, и появится главная диаграмма классов.
Выберете нужный класс в списке браузера и перетащите его на диаграмму с помощью мыши. Для отображения стереотипа класса на диаграмме можно воспользоваться командой меню Format→
Stereotype
display
(Формат→
Показать стереотип).
Рис.12. Главная диаграмма классов
Главная диаграмма классов для пакета Объекты университета изображена на рис. 13. Заметьте, что класс учебный курс (Course Offering) на ней отсутствует. Это класс реализации в пакете, и мы решили не показывать его на главной диаграмме. По мере добавления пакетов и классов в модель могут быть созданы дополнительные диаграммы.
Рис. 13.Главная диаграмма классов пакета « Объекта университета»
Настройка видимости классов по умолчанию:
1. Выберете команду меню Tools →
Options
(Сервис →
Параметры).
2. Щелкните по вкладке Diagram
(Диаграмма).
3. Установите флажок Slow
Visibility
(Показать видимость) для отображения по умолчанию всех классов.
Установка видимости для выбранного класса:
1. Щелкните правой кнопкой мыши по одному из классов на диаграмме.
2.
В появившемся контекстно-зависимом меню выберете команду Options →
Slow
Visibility
(Параметры →
Показать видимость).
Диаграмма классов, отражающая видимость пакетов, показана на рис.14.
Рис. 14. Диаграмма классов, отображающая видимость пакетов.
Резюме
Объекты
– это компьютерное представление сущностей (предметов реального мира или понятий, придуманных человеком). Объект- это концепция, абстракция или вещь с четко определенными границами и значением для системы. Каждый объект в системе имеет три характеристики: состояние, поведение и индивидуальность. Состояние объекта – одно из условий, в которых он может находиться. Поведение характеризует объект и показывает, как он реагирует на запросы других объектов. Индивидуальность означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта.
Класс
- это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами (ассоциативными и агрегационными) и семантикой.
После того, как класс создан, его необходимо описать в документации. Документация предназначена для описания назначения класса, а не его структуры.
Стереотипы
обеспечивают возможность создания новых типов элементов моделирования и должны основываться на элементах, входящих в метамодель языка UML. На этапе анализа выделяют три основных стереотипа для классов: класс-сущность, граничный класс и управляющий класс. Эти стереотипы используются для определения классов в разрабатываемой системе.
Пакет
в логическом представлении модели – это набор классов и других связанных пакетов. Путем объединения классов в пакеты мы можем получить представление модели на более высоком уровне. Изучая содержимое пакета, мы получаем более детальное представление.
Диаграммы классов помогают графически изобразить некоторые или все классы системы. Диаграммы классов можно создать и в представлении модели прецедента. Они обычно прикрепляются к прецеденту и содержат представления классов, участвующих в их выполнении.
Изучение взаимодействия объектов.
Реализация прецедентов
Диаграмма прецедентов представляет внешний вид системы. Выполнение прецедентов отображается с помощью потока событий. Сценарии используются для описания того, как реализуются прецеденты, взаимодействия между группами объектов.
Сценарии
(scenario) – это элемент прецедента. Он представляет собой одиночный проход по потоку событий для прецедентов. Сценарии помогают выделить объекты, классы и взаимодействия объектов, необходимые для исполнения единичного действия, определенного прецедентом. Сценарии описывают порядок того, как обязанности, возложенные на прецеденты, распределяются среди объектов и классов в системе. Сценарии говорят на языке конечных пользователей и экспертов и поэтому являются средством выражения их пожеланий по необходимому поведению системы для разработчиков.
Каждый прецедент- это сплетение первичных (нормальный поток для прецедента) и вторичных сценариев (логика ЧТО-ЕСЛИ в прецеденте). Это значит, что существует множество сценариев для системы - первичные и вторичные сценарии для всех прецедентов. На этапе анализа уже можно сказать, что определение первичного сценария для каждого выбранного прецедента будет достаточным.
Когда вы обнаружите, что каждый новый сценарий повторяет большинство шагов из предыдущего, то вы добились цели. Данная фаза анализа должна завершаться по мере того, как разработчики продумают приблизительно 80% первичных сценариев и выборочно коснутся вторичных. Если проработать больше сценариев, результаты анализа, вероятно, окажутся хуже; если меньше - не будет достаточного понимания поведения системы, чтобы правильно оценить риски.
По методологии Rational Unified Process реализации прецедентов (use case realizations) отражаются в логическом представлении модели.
Обратимся к концепции стереотипов, чтобы показать,
что прецеденты, созданные в логическом представлении,
являются реализациями прецедентов из представления
use case. Другими словами, прецеденты в логическом
представлении имеют те же имена, что и в
представлении use case, а также, стереотип,
указывающий на реализацию. В языке UML
реализация прецедентов изображается в виде
пунктирного овала (см. рис.15). Логическое Рис. 15. Нотация UML
представление прецедентов обычно отображается для реализации
на диаграмме прецедентов (или наборе диаграмм). Прецедента.
Создание диаграммы прецедентов в логическом представлении модели в программе Rational Rose состоит из следующих шагов:
1. Щелкните правой кнопкой мыши по папке Logical
View
( Логическое представление) в окне браузера.
2. В появившемся контекстно-зависимом меню выберете команду New→
Use
Case
(Создать →
Прецедент). В раздел логического представления модели будет добавлена новая диаграмма прецедентов с названием New
Diagram
.
3. Введите для новой диаграммы название Realizations.
Окно браузера с диаграммой прецедентов Realizations
показано на рис.16.
Последовательность создания реализаций
прецедентов в программе Rational Rose:
1. Дважды щелкните по диаграмме прецедентов
Realizations
в списке браузера, чтобы открыть
диаграмму.
2. Щелкните по кнопке Use
Case (
Прецедент)
на панели инструментов.
3. Щелкните по диаграмме прецедентов.
В диаграмму и список браузера будет добавлен
новый прецедент.
4. Дважды щелкните по изображению
прецедента. На экране появится диалоговое окно Рис.16. Реализация прецедентов
Use Case Specification
(Параметры прецедента).
5. Введите название прецедента (такое же, как у модели) в поле ввода Name (Имя). Заметьте, что вы должны указать название в диалоговом окне параметров прецедента или в браузере, чтобы сообщить программе Rational Rose об использовании другого пространства имен (namespase). Если вы введете название прецедента непосредственно на диаграмме, программа Rational Rose будет считать, что это этот же прецедент, что и в представлении Use Case.
6.
В открывающемся списке Stereotype
(Стереотип) выберете стереотип Use
Case
realization.
7. Щелкните по кнопке OK
, чтобы закрыть диалоговое окно.
Диаграмма прецедентов Realizations показана на рис.17.
Связь между прецедентами в логическом и Use Case-представлении отражается путем добавления прецедентов из представления Use Case на диаграмму Realizations
и соединения с их реализациями посредством однонаправленной ассоциативной связи с соответствующим стереотипом. (В языке UML используется стереотипные зависимости, но они пока не поддерживаются программой Rational Rose.)
Рис. 17. Диаграмма реализаций прецедентов.
Документирование сценариев
Поток событий для прецедента описывается словами, тогда как сценарии отображаются с помощью диаграмм взаимосвязи (interaction diagrams). Существует два типа диаграмм взаимодействий (collaboration diagrams). Каждая диаграмма является графическим представлением сценария.
Диаграммы последовательности действий
Диаграммы последовательности действий (
seguence diagram) отображает взаимодействие объектов, упорядоченное по времени. На ней показаны объекты и классы, используемые в сценарии, и последовательность сообщений, которыми обмениваются объекты, для выполнения сценария. Диаграммы последовательности действий обычно соответствуют реализациям прецедентов в логическом представлении системы.
В языке UML объект на диаграмме последовательности действий выглядит как прямоугольник, содержащий подчеркнутое название объекта. Название может состоять только из имени объекта, из имени объекта и его класса или только имени класса (анонимный объект). Эти три вида наименований объекта показаны на рис. 18.
Рис. 18. Наименование объектов на диаграмме
последовательности действий.
Названия объектов могут быть конкретными (например, Алгебра 101, раздел 1) или общими (например, учебный курс). Часто анонимные объекты используются для представления любого объекта данного класса.
Каждый объект также имеет свою временную линию (timeline), изображаемую пунктиром под объектом. Сообщения, передаваемые между объектами, указываются стрелками, направленными от клиента(отправителя сообщения) к поставщику (получателю сообщения).
На рис.19 представлена нотация языка UML для объектов и сообщений на диаграмме последовательности действий.
Для создания диаграммы последовательности действий в программе
Rational
Rose:
1. Щелкните правой кнопкой мыши по папке Logical
View
(Логическое представление) в окне браузера.
2. В появившемся контекстно-зависимом меню выберете команду New
→
Seguence
Diagram
(Создать→
Диаграмма последовательности действий).
3. Введите ее имя.
Рис. 19. Нотация языка UML для объектов и сообщений на диаграмме
последовательности действий.
Окно браузера с диаграммой последовательности действий показано на рис.20. Чтобы создать объекты и сообщения на диаграмме последовательности действий в программе
Rational Rose:
1. Дважды щелкните по диаграмме последовательности действий в списке браузера, чтобы открыть диаграмму.
2. Выберете из списка актера, щелкнув по нему мышью.
3. Перетащите актера на диаграмму последовательности действий.
4. Щелкните по кнопке Object
(Объект) на панели инструментов.
5. Щелкните по диаграмме последовательности действий, чтобы добавить новый объект.
6. Введите имя объекта.
Рис.20. Окно браузера с диаграммой последовательности действий
7. Повторите предыдущие шаги для каждого объекта и актера в сценарии.
8. Щелкните по кнопке Object
Message
(Сообщение) на панели инструментов.
9. Щелкните по актеру или объекту-отправителю сообщения и проведите стрелку сообщения к актеру или объекту-получателю.
10. Введите название сообщения.
11. повторите шаги с седьмого по девятый для каждого сообщения в сценарии.
Диаграмма последовательности действий для сценария создание учебного предмета(Create a Course) изображена на рис.21.
Рис. 21. Диаграмма последовательности действий.
Присваивание объектов соответствующим классам на диаграмме последовательности действий в программе
Rational
Rose предусматривает выполнение следующих шагов:
1. В списке браузера выберете класс, щелкнув по нему мышью.
2. Перетащите класс на объект на диаграмме последовательности действий. Программа Rational Rose автоматически добавит имя класса с предшествующим знаком двоеточия к названию объекта. Если у объекта нет имени, название примет вид: имя класса. Если у стереотипа данного класса есть значок, то он будет использован для изображения объекта на диаграмме.
Диаграммы последовательности действий
и граничные классы
Граничные классы добавляются на диаграмму последовательности действий для того, чтобы показать взаимодействие с пользователем или другой системой. На стадии анализа назначение граничных классов на диаграмме заключается в описании требований к интерфейсу, но не в описании реализации интерфейса.
Реальные сообщения, поступающие от актера граничному классу, и информация об их последовательности зависят от структуры приложения и определяются на стадии проектирования. Они могут изменяться, по мере того как в систему добавляется информация о способах реализации.
Сложность и диаграммы последовательности действий
Возникает вопрос: «Насколько сложной может быть диаграмма последовательности действий?». Ответ такой: «Постарайтесь сделать её простой!». Прелесть этой диаграммы в её простоте - можно легко понять и увидеть объекты, взаимодействия объектов, сообщения между ними и функциональность, задаваемую сценарием.
Следующий вопрос выглядит так: «Что делать с условной логикой?» ( с логикой ЕСЛИ-ТО-ИНАЧЕ, которая существует в реальном мире). Ответ на него также субъективен. Если логика проста и требует небольшого количества сообщений, то обычно добавляют ее к одной диаграмме и используют примечания для указания выбора, который нужно сделать. С другой стороны, если логика ЕСЛИ-ТО-ИНАЧЕ требует сложных сообщений, обычно рисуют отдельные диаграммы: одну для случая ЕСЛИ, одну для ТО и одну для ИНАЧЕ.
Это делается для сохранения простоты диаграмм. Если нужно, их можно связать друг с другом. Это позволит пользователем перемещаться по набору.
Для связывания диаграмм в программе
Rational
Rose
нужно выполнить следующие действия:
1. Щелкните по кнопке Note
(Сноска) на панели инструментов.
2. Щелкните по диаграмме, чтобы поместить на нее сноску.
3. Выберете в списке браузера диаграмму, которую нужно связать с текущей, и перетащите ее на сноску.
4. Для перехода на связанную диаграмму необходимо дважды щелкнуть по сноске.
Диаграммы взаимодействий
Диаграммы взаимодействий
(collaboration diagram) – это альтернативный способ отображения сценариев. Такой тип диаграммы показывает взаимодействие объектов, организованное вокруг них, и их связи друг с другом. Диаграмма взаимодействий содержит:
Объекты, изображаемые в виде прямоугольников;
Связи между объектами, изображаемые в виде линий;
Сообщения в виде текста и стрелки, направленной от клиента к поставщику.
Нотация языка UML для объектов, связей и сообщений на диаграмме взаимодействий показана на рис.22. Последовательность создания диаграмм взаимодействия из диаграмм последовательности действий в программе Rational Rose :
Дважды щелкните по диаграмме последовательности действий в списке браузера, чтобы открыть диаграмму.
Выберете диаграмму меню Brows →
Create
collaboration
diagram
( Просмотр →
Создать диаграмму взаимодействий) или нажмите клавишу F5
.
Расположите объекты и сообщения на диаграмме нужным образом.
Рис. 22. Нотация UML для объектов, связей и сообщений
на диаграмме взаимодействий.
Диаграмма взаимодействий показана на рис.23. Можно сначала создать диаграмму взаимодействий. В этом случае диаграмма последовательности действий (Seguence diagram) может
быть получена из нее.
Рис. 23. Диаграмма взаимодействий.
Зачем нужны две разные диаграммы
Диаграмма последовательности действий используется для просмотра сценария во временном порядке: что происходит сначала, что происходит затем. Поэтому они очень полезны на стадии анализа. Диаграмма взаимодействий представляет общую картину сценария, так как взаимодействия на ней организованы между связанными друг с другом объектами. Такой тип диаграмм чаще используется на этапе проектирования, когда планируется реализация отношений.
Диаграмма последовательности действий
для системы регистрации курсов
Продолжим анализ сценария добавление учебного курса (Add a Course Offering). Диаграмма показана на рис.24. Диаграммы классов могут быть также прикреплены к реализациям прецедентов. Они содержат представления классов, участвующих в выполнении прецедентов (participating classes).
Рис. 24. Диаграмма последовательности действий для сценария добавление учебного курса
Последовательность создания представления участвующих классов
в программе
Rational
Rose:
Щелкните правой кнопкой мыши по реализации прецедента в окне браузера.
В появившемся контекстно-зависимом меню выберете команду New
Class Diagram(Создать Диаграмма классов).Введите имя новой диаграммы.
Дважды щелкните по правой диаграмме в списке браузера, чтобы открыть ее.
Выберете класс в логическом представлении модели и перетащите его на диаграмму с помощью мыши.
Аналогичным образом поместите на диаграмму другие нужные классы.
Участвующие классы для прецедентов выбор для обучения показаны на рис.25.
Рис. 25. Схема классов, участвующих в прецеденте.
Резюме
Диаграмма прецедентов представляет внешний вид системы. Выполнение прецедентов отображается с помощью потока событий. Сценарии используются для описания того, как прецеденты реализуются в виде взаимодействия между группами объектов. Сценарий – это экземпляр прецедента. Он представляет собой одиночный проход по потоку событий для прецедента. Таким образом, каждый прецедент- это сплетение сценариев. Они помогают выделить объекты, классы и взаимодействия объектов, необходимые для исполнения единичного действия, определенного прецедентом.
Поток событий для прецедентов обычно описывается словами, тогда как сценарии -диаграмма связи. Существует два типа диаграмм взаимосвязи-диаграммы последовательности действий и диаграммы взаимодействий. Каждая диаграмма-это графическое представление сценария.
Диаграмма последовательности действий отображает взаимодействие объектов, упорядоченное во времени. Диаграмма взаимодействий - это альтернативный способ отображения сценариев. Этот тип диаграмм показывает взаимодействие объектов, организованное вокруг самих объектов, и их связи друг с другом.
Список литературы
Иванова Г.С. Технология программирования. – М: Изд-во МГТУ им.Н.Э.Баумана, 2002.
Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование. – М: ДМК, 2001.
Орлов С.А. Технологии разработки программного обеспечения. Разработка сложных программных систем. Учебное пособие. 2-е изд. – СПб.: Питер, 2003.