Слайд 1Технология объектно-ориентированного моделирования
Черняховская Л.Р.
Кафедра технической кибернетики
УГАТУ - 2006
Слайд 2 ЦЕЛЬ КУРСА
Формирование знаний о принципах методологии объектно – ориентированного анализа
и проектирования программных систем
Слайд 3 ЗАДАЧИ КУРСА
усвоение знаний по принципам методологии объектно – ориентированного анализа
и проектирования, построения и использования моделей программных систем;
формирование умений применения
универсального языка моделирования и программных продуктов Rational;
отработка навыков использования инструментальных средств Rational.
Слайд 4Преимущества использования объектно-ориентированного подхода
Кодирование составляет небольшую часть разработки программного обеспечения
Оценка
временных затрат, в %
35% Спецификация, разработка
20% Кодирование, отладка
30% Тестирование, корректировка, фиксация
15% Оформление документации, поддержка
Объектно-ориентированный подход облегчает другие составляющие разработки программных систем
Слайд 5 Основная идея объектного подхода
состоит в том, чтобы
заключить данные и связанные с ними процедуры в некие структуры
- объекты, объединенные механизмом наследования. Такие структуры инкапсулируют данные и функции, моделирующие поведение соответствующих компонентов
Слайд 6 Объект - это абстракция множества предметов реального мира, обладающих одинаковыми
характеристиками и законами поведения. Объект представляет собой типичный неопределенный элемент
такого множества.
Экземпляр объекта - это конкретный определенный элемент множества.
Слайд 7 Класс - это множество предметов реального мира, связанных общностью структуры
и поведением.
Элемент класса - это конкретный элемент данного множества.
Таким образом, объект - это типичный представитель класса, а термины "экземпляр объекта" и "элемент класса" равнозначны.
Слайд 8Важнейшие понятия объектного подхода
Инкапсуляция;
Наследование;
Полиморфизм.
Слайд 9Инкапсуляция -
сокрытие данных и методов в качестве собственных ресурсов объекта
Слайд 10Полиморфизм -
способность объекта принадлежать более чем одному типу. Существуют и
другие виды полиморфизма, такие как перегрузка и параметрический полиморфизм. С
помощью перегрузки имена, обозначающие названия методов, могут быть использованы для указания различающихся реализаций.
Слайд 11Наследование
Наследование означает построение новых классов на основе существующих с возможностью
добавления или переопределения данных и методов.
Слайд 12 Методология объектно-ориентированного анализа и проектирования реализуется с использованием унифицированного языка
моделирования Unified Modeling Language (UML)
Слайд 13 Унифицированный язык моделирования UML –это язык визуального моделирования для решения
задач общего характера, который используется при определении, визуализации, конструировании и
документировании артефактов программной системы
Слайд 14Основы UML
Разработка языка UML есть результат усилий по консолидации и
унификации многих объектно- ориентированных методов моделирования и обозначений артефактов программных
систем
Основные разработчики: Г. Буч, А. Якобсон, Дж. Рамбо [1]
Object Management Group – www.omg.org
Слайд 15 Объектно-ориентированная модель предметной области
представляет собой совокупность диаграмм, описывающих с
использованием языка UML различные аспекты структуры и поведения программной системы.
Слайд 16Визуальное моделирование
В процессе разработки производится объектно-ориентированная модель проекта, на которой
базируется вся работа
Модель использует UML как общую систему обозначений
Визуальное моделирование
Описывает
поведение и
структуру системы
Поддерживает
согласованность описания
Облегчает взаимопонимание
Слайд 17UML
UML (Unified Modeling Language)
- язык графического моделирования для описания объектно-ориентированного
программного обеспечения. Разрабатывается с 1994
Объединяет средства представления трех ведущих объектно-ориентированных
методов:
OMT (James Rumbaugh)
OOSE (Ivar Jacobson)
Booch (Grady Booch)
Является промышленным стандартом
Обладает многими полезными свойствами и большой коллекцией изобразительных средств
Отображает множество видов
Содержит множество диаграмм
Слайд 18Мотивация применения UML
Увеличиваются объемы и сложность программных систем
Трудно анализировать
Необходимо документировать
разработку программных систем
Ясно
Сжато
Точно
UML является графической моделью программной системы с адекватным
математическим основанием
Обеспечивает простое, но точное описание программной системы
Является CASE (Computer-aided software engineering) – средством разработки программной системы
Имеются средства для генерации и анализа UML - моделей
Слайд 19Визуальное моделирование
Модель проекта представляет собой совокупность подмоделей структуры и поведения
Каждая
подмодель представлена
набором диаграмм
Подмодели согласованы между собой
Слайд 20Контроль качества
Проблемы обходятся на два-три порядка дороже, если они возникают
и устраняются после развертывания программного обеспечения.
Для достижения целей в рамках
установленных ресурсов
необходимы
контроль и
управление
качеством.
Слайд 21Контроль качества
Концепции Rational Software Ink. предполагают объективно осуществляемое управление качеством
Оценка
качества всех действий и их участников выполняется с использованием объективных
измерений и критериев
Испытание (тестирование) качества производится на всех итерациях жизненного цикла
Слайд 23Типы диаграмм
Диаграммы требований к системе
Структурные диаграммы – сфокусированы на статических
аспектах программных систем : диаграммы классов, объектов, компонентов и размещения
Диаграммы
, описывающие динамику поведения систем: диаграммы кооперации, состояний и деятельности
Слайд 24Методология Rational Unified Process
Rational Unified Process (RUP)- это процесс
разработки программного обеспечения. Его цель состоит в том, чтобы гарантировать
высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков.
Слайд 25Обзор Rational Unified Process
Процесс
- это частично упорядоченный набор шагов, которые
нужно проделать для достижения цели.
При разработке программной системы цель состоит
в формировании или расширении существующего программного изделия.
Слайд 26Обзор Rational Unified Process
Цель:
гарантировать получение высококачественной программной системы, отвечающей потребностям
заказчиков, в пределах предсказуемого
временного графика и бюджета, используя
лучший опыт,
обобщенный в концепциях Rational Software Inc.
инструментальную поддержку средствами Rational Suite
Слайд 28Rational Unified Process:
Структура жизненного цикла
Жизненный цикл приложения
разбивается на циклы,
каждый из которых работает над новым поколением изделия.
Каждый цикл развития
состоит
из четырех последовательных стадий.
Стадии завершаются главными вехами.
Слайд 29Rational Unified Process:
Структура жизненного цикла
Первый цикл выполнения этих стадий
- начальный цикл.
Последующие циклы развития
- эволюционные циклы.
Каждый эволюционный цикл проходит
те же четыре стадии.
Слайд 30Rational Unified Process.
Структура жизненного цикла
Итерации
Каждая стадия может быть разбита
на итерации.
Итерация - цикл, приводящий к выпуску изделия (внутренней или
внешней версии) или подмножества конечного продукта, возрастающего от итерации к итерации до законченной системы.
Слайд 31Структура процесса
Деловое моделирование
Требования
Анализ и проектирование
Выполнение
Испытание
Развертывание
Управление конфигурацией и изменением
Руководство проектом
Среда
Слайд 34Поток работ делового моделирования
Слайд 35Управление требованиями
Управление требованиями включает:
установление и поддержание соглашений
между заказчиком и
исполнителем об изменяющихся требованиях к системе
отслеживание изменений и
оценка их
влияния на процесс и уже реализованные решения
обнаружение, организацию и
документирование начальных требований
Слайд 36Управление требованиями
Определения:
Экземпляр прецедента - последовательность действий, выполняемых системой; она имеет
наблюдаемый результат, ценный для конкретного субъекта
Прецедент - набор экземпляров прецедента
Действие
- процедура, выполняемая по сигналу субъекта. Действие атомарно. Оно выполняется полностью, или не выполняется вовсе
Субъект - роль, которую пользователь играет относительно системы
Главные требования пользователя (что должна делать система) выражаются прецедентами.
Слайд 37Управление требованиями
Через требования, прецеденты управляют технологическими маршрутами разработки системы от
делового моделирования до испытаний.
Слайд 38Диаграммы UML
I. Диаграмма требований
Слайд 39Стереотипы UML
на диаграмме требований
На диаграмме элемент Use Case изображается в
виде эллипса. Линии соединяют актеров с элементами Use Case, в
которых они участвуют
Слайд 40
Идентификация акторов
Для идентификации акторов системы могут быть заданы следующие вопросы:
Кто
заинтересован в конкретном требовании ?
Кто в организации будет использовать
систему ?
Кто извлечет пользу от системы ?
Кто будет пользоваться информационной поддержкой системы?
Нуждается ли система во внешних ресурсах ?
Взаимодействует ли система с другими системами ?
Слайд 41Идентификация прецедентов (Use Cases)
Для идентификации прецедентов могут быть заданы следующие
вопросы:
Каковы задачи каждого актора ?
Будет ли актор создавать, хранить,
изменять, удалять или читать определенную информацию?
Будет ли актор информировать систему о внезапных, внешних изменениях?
Нуждается ли актор в информации о конкретных событиях, происходящих в системе?
Какие прецеденты будут поддерживаться и обслуживаться в системе?
Все ли функциональные требования будут выполняться посредством выделенных прецедентов?
Слайд 42Диаграмма Use Case помогает определить требования пользователя
Данная диаграмма - это
представление работы системы с точки зрения акторов (actors), то есть
объектов, выполняющих в системе определенные функции
Элемент Use Case - это согласованный блок функциональности, которую представляет система, подсистема или класс
RUP предполагает "управляемый прецедентами подход“, в соответствии с которым определенный для системы прецедент является основанием для всего процесса разработки
Назначение диаграммы Use Case
Слайд 43Разработка требований в
Rational RequisitePro
Помогает собирать программные требования, документировать их, располагать
по приоритетам, отслеживать выполнение и управлять изменениями.
Слайд 44Пример модели требований в Requisite Professional
Rational RequisitPro обеспечивает возможность формирования
терминологии предметной области составления словаря (Glossary)
Слайд 45Диаграммы UML
II. Диаграмма классов
Слайд 46Диаграммы классов (class diagrams) описывают статическую структуру классов.
Диаграммы могут
описывать основные понятия предметной области на концептуальном уровне
На детальном
уровне ( уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов.
Диаграмма классов на UML
Слайд 48Атрибуты и операции класса
Атрибут - это значение, характеризующее объект в
его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса
счет); имя, возраст, вес (атрибуты объектов класса человек) и т.д.
Операция - это функция (или преобразование), которую можно применять к объектам данного класса. Примеры операций: проверить, снять, поместить (для объектов класса счет), открыть_на_чтение, читать, закрыть (для объектов класса файл) и т.п.
Слайд 50Если система содержит большое количество классов, они могут быть объединены
в пакеты, представляющие архитектуру системы
Слайд 52Отношения между классами (пиктограммы)
Ассоциация
Постоянное, структурное отношение, “has a”
Непрерывная линия со
стрелкой (в случае направленности ассоциации)
Зависимость
Временное отношение, “uses a”
Пунктирная линия со
стрелкой
Обобщение
Наследование, “is a”
Непрерывная линия со стрелкой (треугольной)
Использование
Пунктирная линия со стрелкой (треугольной)
OR
Слайд 53Идентификация и представление сообщений
Когда мы говорим: объект A связан
отношением с объектом B,
мы должны ответить на следующие вопросы:
Каков
тип отношения?
Какие роли в отношении играют объекты A и B ?
Как определить мощность отношений (multiplicity) ?
Могут ли несколько объектов, принадлежащих одному классу, взаимодействовать друг с другом?
На языке UML мы можем представить отношения так, чтобы ответить на поставленные вопросы.
Слайд 54Отношения
Имена отношений
Агрегация в основном не именуется, так как она читается
с использованием слов «имеет» или «содержит».
Ассоциация может быть именована. Обычно
мы используем имя отношения, указывающее его значение, например «учить» (см. рис.).
Имена ролей: Имя роли в ассоциации обозначается на конце линии в ассоциации между классами.
Association Name Role Name
Слайд 55Индикатор мощности отношения (multiplicity indicator) : Мощность отношений (multiplicity) указывается
для классов и определяет допустимое количество объектов, участвующих в отношении
с каждой стороны. Часто используемые значения мощности:
1 Exactly one 0..* Zero or more
1..* One or more 0..1 Zero or one
Рекурсивное отношение (reflexive relationships) : Объекты, принадлежащие к одному классу, могут взаимодействовать друг с другом.
Multiplicity Indicator Reflexive Relationship
Отношения
Слайд 56Наследование или обобщение
Наследование или обобщение определяет отношение между классами, когда
структура и/или поведение одного класса распространяется на другой (или другие)
классы. Подклассы наследуют атрибуты и операции от одного или более суперклассов.
Слайд 57Разработка диаграмм классов (пример)
Слайд 58
Диаграммы
Ш. Для описания динамики используются диаграммы поведения (behavior diagrams),
которые подразделяются на:
диаграммы состояний (statechart diagrams),
диаграммы активностей (activity
diagrams) и
диаграммы взаимодействия (interaction diagrams), состоящие из:
диаграмм последовательности (sequence diagrams)
диаграмм взаимодействий (collaboration diagrams)
Слайд 59Диаграмма последовательности действий (sequence diagram)
Диаграмма последовательности действий отображает взаимодействие объектов,
упорядоченное по времени. На ней показаны объекты и классы, используемые
в сценарии, и последовательность сообщений, которыми обмениваются объекты, для выполнения сценария.
Слайд 60На диаграмме последовательности взаимодействие изображается в виде двухмерной схемы (в
формате графа). По вертикали проходит временная ось, где течение времени
происходит сверху вниз. По горизонтали указываются роли классификатора, которые представляют отдельные объекты взаимодействия.
Диаграммы взаимодействия объектов
(Sequence and Collaboration Diagrams)
Слайд 61Диаграмма последовательности
Объект
Сообщение
Активация
Диаграмма последовательности действий отображает взаимодействие объектов, упорядоченное по времени.
Слайд 62Диаграмма взаимодействия (Collaboration diagram)
С помощью диаграммы последовательности и диаграммы взаимодействия
мы можем описать динамику поведения системы как кооперацию между объектами
системы.
Слайд 63Диаграмма состояний
(State Chart diagram)
Формализм машины конечных состояний (FSM, Final
State Machine) представляет собой следующий кортеж:
FSM = (Q,Σ,Ψ,σ,q0),
Q – множество
символов, представляющих состояние,
Σ - множество входных символов,
Ψ - множество выходных символов,
σ - функция перехода (трансформация состояния, transition):
Q×Σ→Q×Ψ,
q0∈Q –начальное состояние.
Слайд 64FSM может быть представлена в виде ориентированного графа состояний и
переходов из одного состояния в другое. Вершины графа представляют собой
состояния моделей, в дуги – переходы. Каждая дуга маркирована парой «условие - действие», где первое представляет условие перехода, а второе – результат.
Диаграмма состояний
(продолжение)
Слайд 65Основные элементы и пиктограммы диаграммы состояний
Слайд 66Состояние – это некоторое положение в жизни объекта, при котором
он удовлетворяет определенному условию, выполняет некоторое действие или ожидает события.
Диаграмма состояний включает все сообщения, которые объект получает и отправляет. Переходы между состояниями представляют собой смену исходного состояния последующим (которое может быть тем же, что и исходное). Переход может сопровождаться определенным действием.
Анализ поведения объекта на диаграмме состояний
Слайд 67 Действия, сопровождающие переходы в определенное состояние, можно рассматривать как входные
действия (entry action) для этого состояния. И наоборот, действия, сопровождающие
переходы из данного состояния, являются для него выходными (exit action). Поведение, возникающее внутри состояния, называется деятельностью (activity).
Анализ поведения объекта на диаграмме состояний
Слайд 68Диаграмма состояний класса «Учебный курс»
Слайд 69button1&2Pressed
Диаграмма состояний
Состояние
Начало
Конец
Переход
Событие
Слайд 70Программные средства, реализующие нотацию Unified Modeling Language
Rational Unified Process
– гипертекстовая база знаний;
Rational Rose – CASE средство объектного
моделирования;
SoDA - инструмент автоматизации документооборота моделирования;
Requisite PRO – инструмент управления требованиями;
ClearQuest - средство управления запросами на изменение .
Слайд 71Общая платформа группы
ClearQuest
RequisitePro
Rational Rose
Главная БД
БД
пользователей
Коллективная
БД
Документы
БД
пользователя
Rational Test
БД
Rational Test
БД
RequisitePro
Rational SoDA
Документы
Word
Репозиторий.
Правила синхронизации
Слайд 72Поддержка потоков работ средствами Rational Suite
Слайд 73Инструменты для аналитиков.
Rational Rose (Modeler Edition)
Обеспечивает возможность визуального моделирования архитектуры
и компонентов c использованием соответствующего промышленным стандартам Унифицированного языка моделирования
(UML).
Слайд 74Инструменты для разработчиков.
Rational Rose (Modeler Edition)
Обеспечивает возможность визуального моделирования
архитектуры и компонентов
Автоматически создает каркас кода для Java, C++, XML
и др. языков
Автоматически поддерживает взаимодействие между Requisite Professional и SoDa
Слайд 75Общая платформа группы.
Rational SoDA
Автоматически генерирует документы, извлекая информацию из файлов,
которые производятся при разработке проекта, включая исходный код и модели,
произведенные инструментами Rational.
Форматирует информацию согласно предопределенным шаблонам.
Слайд 76Графический интерфейс пользователя Rational Rose
Слайд 77Генерация программного кода Java на основе UML-модели
Базовые конструкции языка Java
Java-программа
представляет собой один или несколько классов.
Начало класса отмечается служебным словом
class, за которым следует имя класса. Все, что содержится в классе, записывается в фигурных скобках и составляет тело класса (class body)
Все действия производятся с помощью методов обработки информации (method).
Метод возвращает (returns) только одно значение, тип которого указывается перед именем метода
После имени метода в скобках перечисляются аргументы, или параметры метода. Тело метода записывается в фигурных скобках.
Слайд 78Пример Java программы
Class Helloworld{
Public static void main {String [] args
{
Systemout.println (“Hello, XXI Century World”);
}
}
Слайд 79От UML диаграммы классов ↔ к Java коду
Различное представление одинаковой
информации:
Имя, состояние, поведение класса
Отношения между классами
Обеспечение возможности перенести одно на
другое
UML ⇒ Java
Генерация кода, основанного на UML-модели
Java ⇒ UML
Создание UML-модели для документирования разрабатываемого кода
Слайд 80Java → UML : Пример
class Clock { // name
// state
private
int seconds;
private int minutes;
private int hours;
// behavior
public void start();
public void
adjustTime(int value);
public void reset();
}
Java Code
Class Diagram
Слайд 81Диаграмма классов
Представление структуры класса
General In Java
Name Name
State Variables
Behavior Methods
Слайд 82Зависимость
Зависимость может быть вызвана
локальной переменной
параметром
возвращаемым значением
Пример
Class A { Class B {
B
Foo(B x) { …
B y = new B(); …
return y; …
} } }
Слайд 83Пример зависимости
Класс Driver зависит от класса Car
Слайд 84Обобщение
Обозначение наследования между классами
Laptop, Клавиатура, Дисплей наследуют состояние и поведение
от Компьютер
Слайд 85Использование
Обозначает, что класс наследует Java интерфейс
A использует интерфейс B
A
«B»
Слайд 86Пример UML модели
В соответствии с принципами моделирования процессов управления сложными
динамическими системами в проблемных ситуациях разработан комплекс метамоделей представления и
обработки знаний.
Слайд 93Автор: Л.Р. Черняховская
проф. каф. технической кибернетики