Разделы презентаций


Черняховская Л.Р. Презентация.ppt

Содержание

ЦЕЛЬ КУРСАФормирование знаний о принципах методологии объектно – ориентированного анализа и проектирования программных систем

Слайды и текст этой презентации

Слайд 1Технология объектно-ориентированного моделирования
Черняховская Л.Р.
Кафедра технической кибернетики
УГАТУ - 2006

Технология объектно-ориентированного моделированияЧерняховская Л.Р.Кафедра технической кибернетикиУГАТУ - 2006

Слайд 2 ЦЕЛЬ КУРСА
Формирование знаний о принципах методологии объектно – ориентированного анализа

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

ЦЕЛЬ КУРСАФормирование знаний о принципах методологии объектно – ориентированного анализа и проектирования программных систем

Слайд 3 ЗАДАЧИ КУРСА
усвоение знаний по принципам методологии объектно – ориентированного анализа

и проектирования, построения и использования моделей программных систем;
формирование умений применения

универсального языка моделирования и программных продуктов Rational;
отработка навыков использования инструментальных средств Rational.
ЗАДАЧИ КУРСАусвоение знаний по принципам методологии объектно – ориентированного анализа и проектирования, построения и использования моделей программных

Слайд 4Преимущества использования объектно-ориентированного подхода

Кодирование составляет небольшую часть разработки программного обеспечения
Оценка

временных затрат, в %
35% Спецификация, разработка
20% Кодирование, отладка


30% Тестирование, корректировка, фиксация
15% Оформление документации, поддержка
Объектно-ориентированный подход облегчает другие составляющие разработки программных систем
Преимущества использования объектно-ориентированного подходаКодирование составляет небольшую часть разработки программного обеспеченияОценка временных затрат, в %35%	Спецификация, разработка20%	Кодирование, отладка

Слайд 5 Основная идея объектного подхода
состоит в том, чтобы

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

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

Слайд 6 Объект - это абстракция множества предметов реального мира, обладающих одинаковыми

характеристиками и законами поведения. Объект представляет собой типичный неопределенный элемент

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

Слайд 7 Класс - это множество предметов реального мира, связанных общностью структуры

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

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

Слайд 8Важнейшие понятия объектного подхода
Инкапсуляция;
Наследование;
Полиморфизм.

Важнейшие понятия объектного подходаИнкапсуляция;Наследование;Полиморфизм.

Слайд 9Инкапсуляция -
сокрытие данных и методов в качестве собственных ресурсов объекта

Инкапсуляция -	сокрытие данных и методов в качестве собственных ресурсов объекта

Слайд 10Полиморфизм -
способность объекта принадлежать более чем одному типу. Существуют и

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

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

Слайд 11Наследование
Наследование означает построение новых классов на основе существующих с возможностью

добавления или переопределения данных и методов.

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

Слайд 12 Методология объектно-ориентированного анализа и проектирования реализуется с использованием унифицированного языка

моделирования Unified Modeling Language (UML)

Методология объектно-ориентированного анализа и проектирования реализуется с использованием унифицированного языка моделирования Unified Modeling Language (UML)

Слайд 13 Унифицированный язык моделирования UML –это язык визуального моделирования для решения

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

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

Слайд 14Основы UML
Разработка языка UML есть результат усилий по консолидации и

унификации многих объектно- ориентированных методов моделирования и обозначений артефактов программных

систем
Основные разработчики: Г. Буч, А. Якобсон, Дж. Рамбо [1]
Object Management Group – www.omg.org
Основы UMLРазработка языка UML есть результат усилий по консолидации и унификации многих объектно- ориентированных методов моделирования и

Слайд 15 Объектно-ориентированная модель предметной области
представляет собой совокупность диаграмм, описывающих с

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


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

Слайд 16Визуальное моделирование
В процессе разработки производится объектно-ориентированная модель проекта, на которой

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

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

Слайд 17UML
UML (Unified Modeling Language) - язык графического моделирования для описания объектно-ориентированного

программного обеспечения. Разрабатывается с 1994 Объединяет средства представления трех ведущих объектно-ориентированных

методов: OMT (James Rumbaugh) OOSE (Ivar Jacobson) Booch (Grady Booch)
Является промышленным стандартом
Обладает многими полезными свойствами и большой коллекцией изобразительных средств
Отображает множество видов
Содержит множество диаграмм

UMLUML (Unified Modeling Language) - язык графического моделирования для описания объектно-ориентированного программного обеспечения. Разрабатывается с 1994 Объединяет

Слайд 18Мотивация применения UML
Увеличиваются объемы и сложность программных систем
Трудно анализировать
Необходимо документировать

разработку программных систем
Ясно
Сжато
Точно
UML является графической моделью программной системы с адекватным

математическим основанием
Обеспечивает простое, но точное описание программной системы
Является CASE (Computer-aided software engineering) – средством разработки программной системы
Имеются средства для генерации и анализа UML - моделей
Мотивация применения UMLУвеличиваются объемы и сложность программных системТрудно анализироватьНеобходимо документировать разработку программных системЯсноСжатоТочноUML является графической моделью программной

Слайд 19Визуальное моделирование
Модель проекта представляет собой совокупность подмоделей структуры и поведения
Каждая

подмодель представлена набором диаграмм
Подмодели согласованы между собой

Визуальное моделированиеМодель проекта представляет собой совокупность подмоделей структуры и поведенияКаждая подмодель представлена набором диаграммПодмодели согласованы между собой

Слайд 20Контроль качества
Проблемы обходятся на два-три порядка дороже, если они возникают

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

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

Слайд 21Контроль качества
Концепции Rational Software Ink. предполагают объективно осуществляемое управление качеством
Оценка

качества всех действий и их участников выполняется с использованием объективных

измерений и критериев
Испытание (тестирование) качества производится на всех итерациях жизненного цикла
Контроль качестваКонцепции Rational Software Ink. предполагают объективно осуществляемое управление качествомОценка качества всех действий и их участников выполняется

Слайд 23Типы диаграмм
Диаграммы требований к системе
Структурные диаграммы – сфокусированы на статических

аспектах программных систем : диаграммы классов, объектов, компонентов и размещения
Диаграммы

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

Слайд 24Методология Rational Unified Process
Rational Unified Process (RUP)- это процесс

разработки программного обеспечения. Его цель состоит в том, чтобы гарантировать

высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков.
Методология Rational Unified Process 		Rational Unified Process (RUP)- это процесс разработки программного обеспечения. Его цель состоит в

Слайд 25Обзор Rational Unified Process
Процесс - это частично упорядоченный набор шагов, которые

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

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

Слайд 26Обзор Rational Unified Process
Цель: гарантировать получение высококачественной программной системы, отвечающей потребностям

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

обобщенный в концепциях Rational Software Inc.
инструментальную поддержку средствами Rational Suite
Обзор Rational Unified ProcessЦель: гарантировать получение высококачественной программной системы, отвечающей потребностям заказчиков, в пределах предсказуемого  временного

Слайд 27Схема организации RUP

Схема организации RUP

Слайд 28Rational Unified Process: Структура жизненного цикла
Жизненный цикл приложения разбивается на циклы,

каждый из которых работает над новым поколением изделия.
Каждый цикл развития состоит

из четырех последовательных стадий.

Стадии завершаются главными вехами.

Rational Unified Process:  Структура жизненного циклаЖизненный цикл приложения разбивается на циклы, каждый из которых работает над

Слайд 29Rational Unified Process: Структура жизненного цикла
Первый цикл выполнения этих стадий

- начальный цикл.
Последующие циклы развития - эволюционные циклы.
Каждый эволюционный цикл проходит

те же четыре стадии.
Rational Unified Process:  Структура жизненного циклаПервый цикл выполнения этих стадий  - начальный цикл.Последующие циклы развития

Слайд 30Rational Unified Process. Структура жизненного цикла
Итерации
Каждая стадия может быть разбита

на итерации.
Итерация - цикл, приводящий к выпуску изделия (внутренней или

внешней версии) или подмножества конечного продукта, возрастающего от итерации к итерации до законченной системы.
Rational Unified Process.  Структура жизненного циклаИтерацииКаждая стадия может быть разбита на итерации.Итерация - цикл, приводящий к

Слайд 31Структура процесса
Деловое моделирование
Требования
Анализ и проектирование
Выполнение
Испытание
Развертывание


Управление конфигурацией и изменением
Руководство проектом
Среда

Структура процессаДеловое моделирование Требования Анализ и проектирование Выполнение Испытание Развертывание Управление конфигурацией и изменением Руководство проектом Среда

Слайд 32Стадии RUP

Стадии RUP

Слайд 33Основные потоки работ

Основные потоки работ

Слайд 34Поток работ делового моделирования

Поток работ делового моделирования

Слайд 35Управление требованиями
Управление требованиями включает:
установление и поддержание соглашений
между заказчиком и

исполнителем об изменяющихся требованиях к системе
отслеживание изменений и
оценка их

влияния на процесс и уже реализованные решения

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

Управление требованиямиУправление требованиями включает: установление и поддержание соглашениймежду заказчиком и исполнителем об изменяющихся требованиях к системе отслеживание

Слайд 36Управление требованиями
Определения:
Экземпляр прецедента - последовательность действий, выполняемых системой; она имеет

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

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

Главные требования пользователя (что должна делать система) выражаются прецедентами.

Управление требованиямиОпределения:Экземпляр прецедента - последовательность действий, выполняемых системой; она имеет наблюдаемый результат, ценный для конкретного субъектаПрецедент -

Слайд 37Управление требованиями
Через требования, прецеденты управляют технологическими маршрутами разработки системы от

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

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

Слайд 38Диаграммы UML I. Диаграмма требований

Диаграммы UML  I. Диаграмма требований

Слайд 39Стереотипы UML на диаграмме требований
На диаграмме элемент Use Case изображается в

виде эллипса. Линии соединяют актеров с элементами Use Case, в

которых они участвуют





Стереотипы UML на диаграмме требований	На диаграмме элемент Use Case изображается в виде эллипса. Линии соединяют актеров с

Слайд 40
Идентификация акторов
Для идентификации акторов системы могут быть заданы следующие вопросы:
Кто

заинтересован в конкретном требовании ?
Кто в организации будет использовать

систему ?
Кто извлечет пользу от системы ?
Кто будет пользоваться информационной поддержкой системы?
Нуждается ли система во внешних ресурсах ?
Взаимодействует ли система с другими системами ?

Идентификация акторовДля идентификации акторов системы могут быть заданы следующие вопросы:Кто заинтересован в конкретном требовании ? Кто в

Слайд 41Идентификация прецедентов (Use Cases)
Для идентификации прецедентов могут быть заданы следующие

вопросы:
Каковы задачи каждого актора ?
Будет ли актор создавать, хранить,

изменять, удалять или читать определенную информацию?
Будет ли актор информировать систему о внезапных, внешних изменениях?
Нуждается ли актор в информации о конкретных событиях, происходящих в системе?
Какие прецеденты будут поддерживаться и обслуживаться в системе?
Все ли функциональные требования будут выполняться посредством выделенных прецедентов? 
Идентификация прецедентов (Use Cases)Для идентификации прецедентов могут быть заданы следующие вопросы:Каковы задачи каждого актора ? Будет ли

Слайд 42Диаграмма Use Case помогает определить требования пользователя
Данная диаграмма - это

представление работы системы с точки зрения акторов (actors), то есть

объектов, выполняющих в системе определенные функции
Элемент Use Case - это согласованный блок функциональности, которую представляет система, подсистема или класс
RUP предполагает "управляемый прецедентами подход“, в соответствии с которым определенный для системы прецедент является основанием для всего процесса разработки

Назначение диаграммы Use Case

Диаграмма Use Case помогает определить требования пользователяДанная диаграмма - это представление работы системы с точки зрения акторов

Слайд 43Разработка требований в Rational RequisitePro
Помогает собирать программные требования, документировать их, располагать

по приоритетам, отслеживать выполнение и управлять изменениями.

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

Слайд 44Пример модели требований в Requisite Professional
Rational RequisitPro обеспечивает возможность формирования

терминологии предметной области составления словаря (Glossary)

Пример модели требований в Requisite ProfessionalRational RequisitPro обеспечивает возможность формирования терминологии предметной области составления словаря (Glossary)

Слайд 45Диаграммы UML II. Диаграмма классов

Диаграммы UML  II. Диаграмма классов

Слайд 46Диаграммы классов (class diagrams) описывают статическую структуру классов.
Диаграммы могут

описывать основные понятия предметной области на концептуальном уровне
На детальном

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

Диаграмма классов на UML

Диаграммы классов (class diagrams) описывают статическую структуру классов. Диаграммы могут описывать основные понятия предметной области на концептуальном

Слайд 47Диаграмма классов

Диаграмма классов

Слайд 48Атрибуты и операции класса
Атрибут - это значение, характеризующее объект в

его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса

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

Слайд 49Стереотипы классов

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

Слайд 50Если система содержит большое количество классов, они могут быть объединены

в пакеты, представляющие архитектуру системы

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

Слайд 51Типы отношений

Типы отношений

Слайд 52Отношения между классами (пиктограммы)
Ассоциация
Постоянное, структурное отношение, “has a”
Непрерывная линия со

стрелкой (в случае направленности ассоциации)
Зависимость
Временное отношение, “uses a”
Пунктирная линия со

стрелкой
Обобщение
Наследование, “is a”
Непрерывная линия со стрелкой (треугольной)
Использование
Пунктирная линия со стрелкой (треугольной)


OR


Отношения между классами (пиктограммы)АссоциацияПостоянное, структурное отношение, “has a”Непрерывная линия со стрелкой (в случае направленности ассоциации)ЗависимостьВременное отношение, “uses

Слайд 53Идентификация и представление сообщений
Когда мы говорим: объект A связан

отношением с объектом B,
мы должны ответить на следующие вопросы:
Каков

тип отношения?
Какие роли в отношении играют объекты A и B ?
Как определить мощность отношений (multiplicity) ?
Могут ли несколько объектов, принадлежащих одному классу, взаимодействовать друг с другом?

На языке UML мы можем представить отношения так, чтобы ответить на поставленные вопросы.
Идентификация и представление сообщений Когда мы говорим: объект A связан отношением с объектом B,мы должны ответить на

Слайд 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

Отношения

Индикатор мощности отношения (multiplicity indicator) : Мощность отношений (multiplicity) указывается для классов и определяет допустимое количество объектов,

Слайд 56Наследование или обобщение
Наследование или обобщение определяет отношение между классами, когда

структура и/или поведение одного класса распространяется на другой (или другие)

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

Слайд 57Разработка диаграмм классов (пример)

Разработка диаграмм классов (пример)

Слайд 58
Диаграммы

Ш. Для описания динамики используются диаграммы поведения (behavior diagrams),

которые подразделяются на:
диаграммы состояний (statechart diagrams),
диаграммы активностей (activity

diagrams) и
диаграммы взаимодействия (interaction diagrams), состоящие из:
диаграмм последовательности (sequence diagrams)
диаграмм взаимодействий (collaboration diagrams)
Диаграммы Ш. Для описания динамики используются диаграммы поведения (behavior diagrams), которые подразделяются на: диаграммы состояний (statechart diagrams),

Слайд 59Диаграмма последовательности действий (sequence diagram)
Диаграмма последовательности действий отображает взаимодействие объектов,

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

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

Слайд 60На диаграмме последовательности взаимодействие изображается в виде двухмерной схемы (в

формате графа). По вертикали проходит временная ось, где течение времени

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

Диаграммы взаимодействия объектов
(Sequence and Collaboration Diagrams)

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

Слайд 61Диаграмма последовательности
Объект
Сообщение
Активация
Диаграмма последовательности действий отображает взаимодействие объектов, упорядоченное по времени.

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

Слайд 62Диаграмма взаимодействия (Collaboration diagram)
С помощью диаграммы последовательности и диаграммы взаимодействия

мы можем описать динамику поведения системы как кооперацию между объектами

системы.
Диаграмма взаимодействия (Collaboration diagram)С помощью диаграммы последовательности и диаграммы взаимодействия мы можем описать динамику поведения системы как

Слайд 63Диаграмма состояний (State Chart diagram)
Формализм машины конечных состояний (FSM, Final

State Machine) представляет собой следующий кортеж:
FSM = (Q,Σ,Ψ,σ,q0),
Q – множество

символов, представляющих состояние,
Σ - множество входных символов,
Ψ - множество выходных символов,
σ - функция перехода (трансформация состояния, transition):
Q×Σ→Q×Ψ,
q0∈Q –начальное состояние.
Диаграмма состояний  (State Chart diagram)Формализм машины конечных состояний (FSM, Final State Machine) представляет собой следующий кортеж:FSM

Слайд 64FSM может быть представлена в виде ориентированного графа состояний и

переходов из одного состояния в другое. Вершины графа представляют собой

состояния моделей, в дуги – переходы. Каждая дуга маркирована парой «условие - действие», где первое представляет условие перехода, а второе – результат.

Диаграмма состояний (продолжение)

FSM может быть представлена в виде ориентированного графа состояний и переходов из одного состояния в другое. Вершины

Слайд 65Основные элементы и пиктограммы диаграммы состояний

Основные элементы и пиктограммы диаграммы состояний

Слайд 66Состояние – это некоторое положение в жизни объекта, при котором

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


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

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

Состояние – это некоторое положение в жизни объекта, при котором он удовлетворяет определенному условию, выполняет некоторое действие

Слайд 67 Действия, сопровождающие переходы в определенное состояние, можно рассматривать как входные

действия (entry action) для этого состояния. И наоборот, действия, сопровождающие

переходы из данного состояния, являются для него выходными (exit action). Поведение, возникающее внутри состояния, называется деятельностью (activity).

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


Действия, сопровождающие переходы в определенное состояние, можно рассматривать как входные действия (entry action) для этого состояния. И

Слайд 68Диаграмма состояний класса «Учебный курс»

Диаграмма состояний класса «Учебный курс»

Слайд 69button1&2Pressed
Диаграмма состояний
Состояние
Начало
Конец
Переход
Событие

button1&2PressedДиаграмма состоянийСостояниеНачалоКонецПереходСобытие

Слайд 70Программные средства, реализующие нотацию Unified Modeling Language
Rational Unified Process

– гипертекстовая база знаний;
Rational Rose – CASE средство объектного

моделирования;
SoDA - инструмент автоматизации документооборота моделирования;
Requisite PRO – инструмент управления требованиями;
ClearQuest - средство управления запросами на изменение .
Программные средства, реализующие нотацию Unified Modeling Language Rational Unified Process – гипертекстовая база знаний; Rational Rose –

Слайд 71Общая платформа группы




ClearQuest
RequisitePro
Rational Rose
Главная БД


БД пользователей


Коллективная БД
Документы

БД пользователя


Rational Test
БД Rational Test

БД RequisitePro



Rational SoDA
Документы Word

Репозиторий.

Правила синхронизации

Общая платформа группыClearQuestRequisiteProRational RoseГлавная БДБД пользователейКоллективная БДДокументыБД пользователяRational TestБД  Rational TestБД  RequisiteProRational SoDAДокументы WordРепозиторий. Правила

Слайд 72Поддержка потоков работ средствами Rational Suite

Поддержка потоков работ средствами Rational Suite

Слайд 73Инструменты для аналитиков. Rational Rose (Modeler Edition)
Обеспечивает возможность визуального моделирования архитектуры

и компонентов c использованием соответствующего промышленным стандартам Унифицированного языка моделирования

(UML).
Инструменты для аналитиков. Rational Rose (Modeler Edition)Обеспечивает возможность визуального моделирования архитектуры и компонентов c использованием соответствующего промышленным

Слайд 74Инструменты для разработчиков. Rational Rose (Modeler Edition)
Обеспечивает возможность визуального моделирования

архитектуры и компонентов
Автоматически создает каркас кода для Java, C++, XML

и др. языков
Автоматически поддерживает взаимодействие между Requisite Professional и SoDa
Инструменты для разработчиков. Rational Rose (Modeler Edition)Обеспечивает возможность  	визуального моделирования архитектуры и компонентовАвтоматически создает каркас кода

Слайд 75Общая платформа группы. Rational SoDA
Автоматически генерирует документы, извлекая информацию из файлов,

которые производятся при разработке проекта, включая исходный код и модели,

произведенные инструментами Rational.
Форматирует информацию согласно предопределенным шаблонам.
Общая платформа группы. Rational SoDAАвтоматически генерирует документы, извлекая информацию из файлов, которые производятся при разработке проекта, включая

Слайд 76Графический интерфейс пользователя Rational Rose






Графический интерфейс пользователя Rational Rose

Слайд 77Генерация программного кода Java на основе UML-модели
Базовые конструкции языка Java
Java-программа

представляет собой один или несколько классов.
Начало класса отмечается служебным словом

class, за которым следует имя класса. Все, что содержится в классе, записывается в фигурных скобках и составляет тело класса (class body)
Все действия производятся с помощью методов обработки информации (method).
Метод возвращает (returns) только одно значение, тип которого указывается перед именем метода
После имени метода в скобках перечисляются аргументы, или параметры метода. Тело метода записывается в фигурных скобках.

Генерация программного кода Java на основе UML-моделиБазовые конструкции языка JavaJava-программа представляет собой один или несколько классов.Начало класса

Слайд 78Пример Java программы
Class Helloworld{
Public static void main {String [] args

{
Systemout.println (“Hello, XXI Century World”);
}
}

Пример Java программыClass Helloworld{Public static void main {String [] args {	Systemout.println (“Hello, XXI Century World”);}}

Слайд 79От UML диаграммы классов ↔ к Java коду
Различное представление одинаковой

информации:
Имя, состояние, поведение класса
Отношения между классами
Обеспечение возможности перенести одно на

другое
UML ⇒ Java
Генерация кода, основанного на UML-модели
Java ⇒ UML
Создание UML-модели для документирования разрабатываемого кода
От UML диаграммы классов ↔ к Java кодуРазличное представление одинаковой информации:Имя, состояние, поведение классаОтношения между классамиОбеспечение возможности

Слайд 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

Java → UML : Примерclass Clock { // name	// state	private int seconds;	private int minutes;	private int hours;	// behavior	public

Слайд 81Диаграмма классов
Представление структуры класса
General In Java
Name Name
State Variables
Behavior Methods

Диаграмма классовПредставление структуры классаGeneral		In JavaName		NameState		VariablesBehavior	Methods

Слайд 82Зависимость
Зависимость может быть вызвана
локальной переменной
параметром
возвращаемым значением
Пример

Class A { Class B {
B

Foo(B x) { …
B y = new B(); …

return y; …
} } }



ЗависимостьЗависимость может быть вызваналокальной переменнойпараметромвозвращаемым значениемПримерClass A {				Class B {		B Foo(B x) {				…		   B y

Слайд 83Пример зависимости
Класс Driver зависит от класса Car

Пример зависимостиКласс Driver зависит от класса Car

Слайд 84Обобщение
Обозначение наследования между классами
Laptop, Клавиатура, Дисплей наследуют состояние и поведение

от Компьютер

ОбобщениеОбозначение наследования между классамиLaptop, Клавиатура, Дисплей наследуют состояние и поведение от Компьютер

Слайд 85Использование
Обозначает, что класс наследует Java интерфейс
A использует интерфейс B




A
«B»

ИспользованиеОбозначает, что класс наследует Java интерфейс A использует интерфейс B A«B»

Слайд 86Пример UML модели
В соответствии с принципами моделирования процессов управления сложными

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

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

Слайд 87Диаграмма требований

Диаграмма требований

Слайд 88Архитектура системы

Архитектура системы

Слайд 89Диаграмма классов

Диаграмма классов

Слайд 90Диаграмма последовательности

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

Слайд 91Диаграмма состояний

Диаграмма состояний

Слайд 92Диаграмма размещения

Диаграмма размещения

Слайд 93Автор: Л.Р. Черняховская проф. каф. технической кибернетики

Автор: Л.Р. Черняховская проф. каф. технической кибернетики

Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое TheSlide.ru?

Это сайт презентации, докладов, проектов в PowerPoint. Здесь удобно  хранить и делиться своими презентациями с другими пользователями.


Для правообладателей

Яндекс.Метрика