Объектно- ориентированный подход к созданию ИС

Объектноориентированный
подход к созданию ИС
Сравнение
структурного и
объектноориентированного
подходов
автоматическое
кодирование
«+»
проверенность
временем
простота
масштабирования
большое количество
CASE-средств
«открытость» UML для
дополнения
«наглядность» и
однозначность
объектно-
структурный
ориентированный
подход
подход
возможность
неоднозначной
трактовки диаграмм
сложность исправления
ошибок проектирования
сложность моделирования
высокие требования к
квалификации 
трудности для экспертов
динамики процесса
«-»
жесткий регламент
методологии
Жизненный цикл ИС
модели ЖЦ
каскадная поэтапная спиральная
По мнению ведущих
«+»: 1. на каждой стадии
«+»: межэтапные
специалистов в
формируется законченный
корректировки
набор проектной
обеспечивают большую области создания ИС,
«+»: возможность realдокументации, достаточной
гибкость и меньшую спиральная модель в
time работы с
для того, чтобы разработка
трудоемкость по
заказчиком;
наибольшей
мере
могла быть продолжена другой сравнению с каскадной
отсутствие
запаздывания
обеспечивает
группой разработчиков;
моделью 
результатов.
2. возможность планирования
повышается
решение
«-»: сложность
сроков завершения работ и
надежность.
возникающих
в
определения момента
затрат на их выполнение
«-»: время жизни
процессе
перехода
на работы
следующий
«-»: сложно уложить реальный каждого из этапов может
этап
проблем
процесс создания
растянуться на весь
программного обеспечения в
период создания
такую жесткую схему
системы
Стандарты ЖЦ ИС
краткий обзор стандартов ЖЦ ИС;
подход Уайта;
ISO/IEC 12207:1995;
ГОСТ 34.601 -90;
корпоративные стандарты ЖЦ ИС.
Основные положения
Существует целый ряд стандартов,
регламентирующих ЖЦ ПО, а в некоторых
случаях и процессы разработки.
Существующие стандарты ЖЦ ИС
ГОСТ
34.601 90
ISO/IEC
12207:
1995
Oracle
CDM
RUP
…
MSF
XP
подход
Уайта
Вопрос:
Перечислите известные Вам стандарты ЖЦИС
Вопросы:
Какие из перечисленных стандартов регламентируют
модель ЖЦИС?
Какие из перечисленных стандартов описывают структуру
ЖЦИС?
Какие из перечисленных стандартов описывают и модель
и структуру ЖЦИС???
Существующие стандарты ЖЦ ИС
ГОСТ
34.601 90
ISO/IEC
12207:
1995
Oracle
CDM
RUP
…
MSF
XP
подход
Уайта
Вопрос:
Перечислите известные Вам стандарты ЖЦИС
Вопросы:
Какие из перечисленных стандартов регламентируют
модель ЖЦИС?
Какие из перечисленных стандартов описывают структуру
ЖЦИС?
Какие из перечисленных стандартов описывают и модель
и структуру ЖЦИС???
Предпосылки
появления объектноориентированного
подхода к созданию ИС
Технологии программирования;
OOP;
OOA;
OOD;
Язык UML
Развитие технологий
программирования
Машинные
коды
Языки высокого уровня
Потерянное
поколение
(1970-198?)
3-е поколение
(1962-1970)
2-е поколение
(1959-1961)
1-е поколение
(1954-1958)
40-е – 50-е
50-е – 80-е
90-е – настоящее
время
Развитие технологий
программирования
Машинные
коды
Языки высокого уровня
алгоритмические
процедурные
Объектноориентированные
функциональные
…
40-е – 50-е
50-е – 80-е
90-е – настоящее
время
Понятие ООР
ООР (object-oriented programming) – это
методология программирования,
основанная на представлении программы в
виде совокупности объектов, каждый из
которых является экземпляром
определенного класса, а классы образуют
иерархию наследования
Понятие ООD
ООD (object-oriented design) – это
методология проектирования,
соединяющая в себе процесс объектной
декомпозиции и приемы представления
логической и физической, а также
статической и динамической моделей
проектируемой системы.
Понятие ООА
ООD (object-oriented analysis) – это
методология, при использовании которой
требования к проектируемой системе
воспринимаются с точки зрения классов и
объектов, выявленных в предметной
области.
Соотношение OOA, OOD и ООР
ООР
ООАП
ООD
ООА
Методы ООАП и ООР базируются на
стандартном (унифицированном) языке
моделирования UML
Язык UML
История UML;
Назначение UML;
Структура UML;
UML диаграммы;
ПО поддерживающее UML
Основные понятия
Унифицированный язык моделирования
(Unified Modelling Language, UML)
является графическим языком для визуального
представления, составления спецификаций,
проектирования и документирования систем, в
которых большая роль принадлежит
программному обеспечению.
Гради БУЧ.
История UML
RSC
Джеймс
Рамбо,
Метод
Рамбо
ГардиДжекобсон,
Буч, Метод
Буча
Айвар
Метод
(ОМТ-2),
ориентированный
(Booch'93),
Джекобсона
(метод OOSE),
на анализ процессов
ориентированный,
в первую
ориентированный
на
анализ
обработки
данных
в
очередь,
на моделирование
требований
к бизнесинформационных
системах
программного
обеспечения
приложениям
сложных систем
Требования к UML
Позволяет моделировать как программное обеспечение
сложных систем, так и широкие классы самих систем и бизнесприложений, с использованием объектно-ориентированных
понятий и методов
Обеспечивает взаимосвязь между базовыми понятиями
моделей концептуального, программного и физического
уровней
Понятен системным аналитикам и программистам
Поддерживается специальными инструментальными
программными средствами, реализованными на различных
компьютерных платформах
Назначение UML
ВОПРОСЫ
Зачем нужно моделирование при создании ИС?
В каком случае можно обойтись без
моделирования?
Что такое view point модели?
Назначение UML
Воображаемая
модель
компьютерной
программы
Объект
автоматизации
программист
Исходный
код
программы
Без UML
Исполнимый
код
Назначение UML
Воображаемая
модель
компьютерной
программы
Объект
автоматизации
программист
UML
диаграммы и
спецификации
Исходный
код
программы
С UML
Теория графов
и теория
множеств
Исполнимый
код
Модель с позиций ООАП
С точки зрения методологии ООАП достаточно
полная модель сложной системы представляет
собой определенное число взаимосвязанных
представлений (views), каждое из которых
адекватно отражает аспект поведения или
структуры системы.
При этом наиболее общими представлениями
сложной системы принято считать статическое и
динамическое, которые в свою очередь могут
подразделяться на другие более частные.
Структура UML
Сущности
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
Структурные
Поведенческие
Группирующие
Аннотационные
Отношения
Диаграммы
1. Классов
2. Объектов
3. Прецендентов
4. Последовательностей
5. Коопераций
6. Состояний
7. Действий
8. Компонентов
9. Развертывания
Структурные
Сущности являются основными объектноориентированными элементами языка. С их
Классы
помощью можно создавать корректные
Интерфейсы
модели. Структурные сущности - это имена
Кооперации
существительные в моделях на языке UML. Как
Преценденты
Поведенческие
правило, они представляют собой статические
Активные классы
Группирующие
Аннотационные
части модели,
соответствующие
Компоненты
1. Взаимодействия
концептуальным
или физическим
Узлы
2. Автоматы
1. Пакет
1. элементам
Примечания
системы
1.
2.
3.
4.
Включения
Ассоциаций
Обобщений
Расширения
Класс (class)
Класс (class) - это описание совокупности
объектов с общими атрибутами,
операциями отношениями и семантикой
Интерфейс (interface)
Интерфейс (interface) - это совокупность
операций, которые определяют определенную
службу (сервис, набор услуг), которые
предоставляет класс или компонент. На
диаграммах интерфейс изображается в виде
круга, под которым указывается его имя, как это
показано на рис. Интерфейс очень редко,
практически никогда, существует сам по себе обычно он присоединяется к реализующему его
классу или компоненту.
Кооперация (collaboration)
Кооперация (collaboration) определяет
взаимодействие, она представляет собой
совокупность ролей и других элементов,
которые, работая вместе, производят
некоторый кооперативный эффект, не
сводящийся к обычно сумме слагаемых.
Прецедент (use case)
Use Case (Прецедент/Вариант
использования) - это описание
последовательности выполняемых системой
действий, которая производит наблюдаемый
результат, значимый для какого-то
определенного актера (actor).
Активный классом (active
class)
Активным классом
(active class)
называется класс,
объекты которого
вовлечены в один или
несколько процессов,
или нитей (threads), и
поэтому могут
инициировать
управляющее
воздействие.
ClassName
-PrivateAttribute : char
#ProtectedAttribute
+PublicAttribute
+Operation1(in S : String)
+Operation2()
Компонент (component)
Компонент (component) - это физическая
заменяемая часть системы, которая соответствует
некоторому набору интерфейсов и обеспечивает
его реализацию.
Узел (node)
Узел (node) - это элемент реальной
(физической) системы, который существует во
время функционирования программного продукта
и представляет собой некоторый вычислительный
ресурс, обычно обладающий как минимум
некоторым объемом памяти, а часто еще и
возможностью обработки.
Перечисленные семь базовых элементов:
классы, интерфейсы, кооперации,
прецеденты, активные классы, компоненты
и узлы - являются основными структурными
сущностями, которые могут быть
использованы в модели UML. Существуют
и другие разновидности сущностей:
актеры, сигналы, утилиты (виды
классов), процессы и нити (виды
активных классов), приложения,
документы, файлы, библиотеки,
страницы и таблицы (виды
компонентов).
UML диаграммы
Общие положения
Совокупность диаграмм UML позволяет
получить интегрированную модель
сложной системы
Общие положения
Диаграмма
вариантов
использования
Диаграмма
кооперации
Диаграмма
компонентов
Диаграмма
классов
Интегрированная
модель системы
Диаграмма
последовательности
Диаграмма
состояний
Диаграмма
деятельности
Диаграмма
развертывания
Отношения диаграмм
ООАП ориентирован на итеративную
разработку UML диаграмм.
Порядок и составВОПРОС:
разработки диаграмм
ВОПРОС:
определяет:
В каком
порядке
рисовать
диаграммы???
Какие модели ЖЦ
ориентированы
на
1. выбранная итеративную
методология
(RUP, MSF, OrCDM…);
разработку???
Все ли виды диаграмм
рисовать???
2. специфика конкретного проекта.
UML НИКАК НЕ РЕГЛАМЕНТИРУЕТ ПОРЯДОК
И СОСТАВ РАЗРАБОТКИ ДИАГРАММ.
Отношения диаграмм
(вариант 1)
Component
diagram
Use Case
diagram
Class
diagram
Statechart
diagram
Use Case
Deployment
diagram
Sequence
diagram
Colloboration
diagram
Отношения диаграмм
(вариант 2)
потребности
пользователей
выявление
анализ
Use Case
diagram
Component
diagram
Use Case
Colloboration
diagram
Sequence
diagram
дизайн
программная
реализация
кодирование
Class
diagram
Statechart
diagram
Deployment
diagram
Отношения диаграмм
(вариант 3)
Отношения диаграмм
(вариант 4)
Отношения диаграмм
(вариант 5)
…
Отношения диаграмм
(вариант N)
UseCase диаграмма
Понятие Use Case диаграмма;
Назначение;
Элементы UseCase диаграммы
UseCASE диаграмма
UseCase диаграмма (диаграмма вариантов использования /
диаграмма прецедентов) – это
графическое представление всех или
ВОПРОСЫ:
части актеров, прецедентов и взаимодействий между ними. В каждой
1.Перечислите
лиц
системе
обычно всех
есть актеров
главная (действующих
диаграмма прецедентов,
которая
взаимодействующих
с банковским
в процессе
его
описывает
внешнюю границу
системы иавтоматом
основные внешние
функции
работы).
(внешнее
поведение) системы.
2.Перечислите
все отображает
прецеденты сферу
банковского
автомата,
UseCase
диаграмма
применения
создаваемой
инициируемые актерами.
системы.
Для каждого UseCase должно
быть проведено
документирование потока
событий (краткое описание;
предусловия; основной поток
событий; альтернативные потоки
событий;
потоки ошибок;
Отобразите
актеров и прецеденты
на схеме и проставьте стрелки,
постусловия)
Пример диаграммы UseCase
показывающие направление
потоков информации.
для банковского автомата
(ATM)
UseCASE диаграмма
Use Case диаграммы описывает общую
функциональность системы.
ПОЛЬЗОВАТЕЛИ
(для кого полезна Use Case диаграмма)
Менеджеры
проекта
Аналитики
Разработчики
Менеджеры
по качеству
ВСЕ, кого интересует система «в целом», изучая UseCase
диаграммы могут получить представление о том, что система
должна делать
Диаграмма прецедентов (use
case diagram)
Диаграмма
прецедентов
(use
case diagram)
Поскольку
в общем
случае
актер
– это графическое представление всех или части
всегда
находится
вне системы,
актеров,
прецедентов
и взаимодействий
между
егоВвнутренняя
структура
никак
ними.
каждой системе обычно
есть главная
диаграмма
прецедентов, которая
описывает
не определяется.
Для
актера
внешнюю границу системы и основные внешние
имеет
значение
только
его
функции (внешнее поведение) системы.
внешнее представление, т.е. то,
Актер (actor) — согласованное
как ролей,
он воспринимается
со
множество
которые
играют внешние сущности по
стороны системы.
отношению к вариантам
использования при
взаимодействии с ними
Типы связей UseCase
диаграмм
коммуникации использования
(communication)
(uses)
UseCase 
Actor
расширения
(extends)
UseCase  UseCase
Обобщения
действующего
лица (actor
generalization)
Actor  Actor
<<uses>>
Стрелки, используемые
для обозначения
Uses relationship
позволяет одному
клиент UseCase
<<extends>>
снятьне
деньгипоказывают
связей
направления
задействовать
функциональность
другого.
relationship
позволяет
одному UseCase
только
С Extends
помощью
actor generalization
relationship
показывают,
<<uses>>
информационных
потоков.
Стрелка
при
необходимости
задействовать
функциональность
что
у
нескольких
лиц
имеются
общие
Аутеннтифицировать
клиента моделируют
снятьдействующих
деньги
С помощью
Uses
relationship
обычно
клиент снять деньги
другого.
черты.
показывает
только
кто/что
инициирует
произвести
ускоренную
выплату
многократно применяемую
функциональность,
Положить деньги на счет
встречающуюся
в двух Корпоративный
или более UseCase.
Индивидуальный
коммуникацию
клиент
клиент
Пакеты
UML позволяет сгруппировать в пакеты
такие действующие лица как:
UseCase;
Class;
NewPackage
Components.
Отношения диаграмм
(повторение)
потребности
пользователей
выявление
анализ
Use Case
diagram
Component
diagram
Use Case
Colloboration
diagram
Sequence
diagram
дизайн
программная
реализация
кодирование
Class
diagram
Statechart
diagram
Deployment
diagram
Диаграммы
взаимодействия
Виды диаграмм взаимодействия;
Диаграмма Последовательности (Sequence);
Назначение диаграммы последовательности;
Элементы диаграмм последовательности;
Кооперативная диаграмма (Collaboration)
Назначение кооперативной диаграммы;
Элементы кооперативной диаграммы;
Отношение диаграммы последовательности и кооперативной
диаграммы;
Отношение диаграмм взаимодействия и UseCase диаграмм
Диаграммы взаимодействия
На диаграмме взаимодействия (Interaction)
отображают один из процессов обработки
информации в UseCase.
Виды диаграмм
взаимодействия
Диаграмма Последовательности
(Sequence)
Кооперативная диаграмма
(Collaboration)
Диаграммы
Последовательности
Диаграммы Последовательности (Sequence)
отражают поток событий, происходящих в рамках
UseCase. Разработка диаграмм
последовательности проводится на основе
документации по UseCase.
Понятие объект
Объектом называют нечто, заключающее
(инкапсулирующее) в себе некоторые данные и
поведение.
Это термин, описывающий реальные, конкретные
предметы.
Класс (class) - это некая сущность,
представляющая собой как бы схему объекта.
Класс определяет данные и поведение, которыми
должен обладать объект
Понятие класс
Диаграммы
Последовательности
Диаграммы Последовательности (Sequence)
отражают поток событий, происходящих в рамках
UseCase. Разработка диаграмм
последовательности проводится на основе
документации по UseCase.
ВОПРОСЫ:
Перечислите все действующие лица и объекты, необходимые
системе для выполнения прецедента снять деньги со счета.
Пример диаграммы
последовательности снятия
денег со счета через
банковский автомат
Диаграмма
последовательности
диаграмма Последовательности иллюстрирует
последовательность действий, реализующих
вариант использования
Аналитики видят последовательность (поток) действий,
разработчики — объекты, которые надо создать, и их операции.
Специалисты по контролю качества поймут детали процесса и
смогут разработать тесты для их проверки. Таким образом,
диаграммы Последовательности полезны всем участникам
проекта.
Кооперативная диаграмма
(Collaboration)
Подобно диаграммам
Последовательности,
Диаграммы
Последовательности
и
Кооперативные диаграммы отображают поток событий в
конкретном
сценарии прецедента.
В отличие от диаграмм
Кооперативные
диаграммы
Последовательности, Кооперативные диаграммы больше
содержат
одну
ту объектами
же
внимания
заостряют на
связях и
между
информацию, но используются
для разных ЦЕЛЕЙ.
ВОПРОС:
Зачем нужно создавать 2 разные диаграммы,
содержащие одну и ту же информацию?
Задание
Построить кооперативную диаграмму на
основе диаграммы Последовательности
А алгоритм-то тривиальный
Отношение диаграммы
последовательности и кооперативной
диаграммы
Существует тривиальный алгоритм
преобразования диаграмм
последовательности в кооперативные
диаграммы и обратно.
Rational Rose обеспечивает автоматическое
преобразование диаграммы последовательности
в кооперативную диаграмму.
Задание
Создайте диаграмму Последовательности и
Кооперативную диаграмму, отражающую
ввод нового заказа в систему обработки
заказов
Продавец
Форма выбора
варианта заказа:
ВыборЗаказа
Форма Детали
заказа:
ДеталиЗаказа
Менеджер
заказов:
МенеджерЗаказов
Заказ №1234:
Заказ
Компект
мебели:
ПозицияЗаказа
Менеджер
транзакций:
Менеджер
транзакций
1: Cre ate ()
2: Ope n()
3: Subm itInfo()
4: Save ()
5: Save Orde r()
6: Cre ate ()
7: Se tInfo()
8: Cre ate ()
9: Se tInfo()
10: SaveOrde r()
11: Ge tInfo()
12: Ge tInfo()
13: Com m it()
<<Граница>>
ВыборЗаказа
<<Управление>>
МенеджерЗаказов
0..1
Create()
0..1
SaveOrder()
0..1
1
0..1
0..1
<<Граница>>
ДеталиЗаказа
<<Управление>>
МенеджерТранзакций
0..1
0..1
Open()
SubmitInfo()
Save()
0..*
<<Сущность>>
Заказ
0..1
0..*
OrderNumber: Integer
CustomerName: String
OrderDate: Date
OrderFillDate: Date
Сreate(): Boolean
SetInfo(): Boolean
GetInfo(): String
1
1..*
<<Сущность>>
ПозицияЗаказа
ItemId: Integer
ItemDescription: String
Сreate()
SetInfo()
GetInfo()
SaveOrder()
Commit()
0..*