Объектно-ориентированные подходы

1.

Объектно-ориентированные методы,
предлагающие подходы объектноориентированного анализа и разработки.
План:
1. Диаграммы классов;
2. Нотация UML ;
3. Формальные методы

2. Объектно-ориентированные подходы

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

3. Диаграммы классов (class diagrams)

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

4.

Пример диаграмм классов (или объектов).

5.

Основной причиной появления этого подхода было желание сделать
разработку программного обеспечения более близкой к моделированию, а,
следовательно, и более естественной.
На диаграмме классов изображается информация о классах объектов и
связях между ними.
Во многом диаграмма классов похожа на диаграмму сущность-связь. Так
же как на диаграмме сущность-связь, диаграмма классов показывает, как
объекты определенных классов связаны с другими объектами этого же класса,
или других классов.
Основные добавленные элементы информации это:
• операции (методы);
• концепция обобщения (generalization);
• атрибуты внутри объекта.
Прецеденты (Use cases) описывают взаимодействие, которое может иметь
место между системой и ее пользователями (актерами; в иностранной
литературе- actors).
Прецеденты изображаются овалами, так же как и процессы на диаграммах
потоков данных (DFD). На диаграммах прецедентов изображаются прецеденты,
актеры и связи между ними.
При этом каждый прецедент определяет функциональное требование к
системе.

6.

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

7.

Нотация UML
UML предполагает разработку нескольких моделей, совокупность которых
описывает разрабатываемую систему. Каждая модель относится к
соответствующей фазе и имеет собственное предназначение. При этом
каждая из моделей состоит из одной или нескольких UML-диаграмм,
которые можно классифицировать следующим образом:
• структурные (structure) диаграммы;
• диаграммы поведения (behaviour);
• диаграммы взаимодействия (interaction).
Системное моделирование для разработки требований
На рис. представлены все типы диаграмм, существующих в нотации UML 2
и доступных системным инженерам

8.

9.

UML-диаграмма классов для банковской системы (диаграмма классов является
базовой в UML). На диаграмме показан набор классов, используемый для
моделирования системы, - классы«Счет», «Владелец», «Текущий Счет»
и«Выписанный Чек». Каждый класс имеет собственное имя, набор атрибутов
и операций, а также связи с одним или более классов.

10.

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

11.

Диаграмма отражает пользовательские требования, которые явно относятся
к проблемной области. Для системы транспортировки багажа были
определены следующие классы: «Пассажир», «Служащий» и «Конвейер», а
также были выделены две встроенные системы – «Система Регистрации
Багажа» и «Весы». Ассоциации между системами и классами помогают
более четко определить контекст работы системы.
Переходя к области решений, необходимо задуматься о функционале и
поведении системы. Следовательно, диаграмма классов должна быть
уточнена и дополнена так, чтобы отобразить все эти атрибуты (классов),
которые будут необходимы для последующего моделирования системных
требований

12.

Для описания функциональных требований к системе используется
моделирование прецедентов. В качестве примера можно рассмотреть две
диаграммы прецедентов – одна для системы транспортировки багажа, а
другая для системы регистрации багажа.
На рис.1 первая из систем представлена как система верхнего уровня.
На рис. 2 изображена диаграмма прецедентов для системы регистрации
багажа.
На обеих диаграммах определены относительные границ систем
(обозначены прямоугольником), а также различные типы заинтересованных
сторон, называемые актерами, которые находятся за границами системы.
Необходимо отметить, что прецеденты представляют собой высокоуровневые
цели заинтересованных сторон. Связь типа «включает» показывает, что этот
прецедент является частью другого прецедента (включается), т.е. таким
образом показывается иерархическая декомпозиция прецедентов.

13.

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

14.

Диаграмма прецедентов для системы регистрации багажа.

15.

UML также
дает
проектировщикам
возможность
моделировать
функциональность системы и ее поведение. Диаграмма последовательности
показывает взаимодействие и совместную работу объектов, и таким
образом позволяет моделировать сложное поведение системы с помощью
сообщений, которыми обмениваются объекты друг с другом в процессе
взаимодействия. Сообщения изображаются в порядке их появления с
помощью стрелок между линиями времени объектов. Одна диаграмма
последовательности может ссылаться на другую с помощью специального
символа–
прямоугольника
с названием
другой
диаграммы
последовательности и пометкойref (“reference”). Это обозначает, что часть
взаимодействия между объектами в этом промежутке времени изображена
на другой диаграмме. В нашем случае- это«Взвешивание Багажа» и
«Маркировка Багажа».

16.

Компонентный подход к проектированию
По оценкам экспертов, 75 % работ по программированию в мире дублируются
(например, программы складского учета, начисления зарплаты, расчета затрат
на производство продукции и т.п.). Большинство из этих программ типовые, но
каждый раз находятся особенности, которые влияют на их повторную
разработку.
Компонентное проектирование сложных программ из готовых компонентов
является наиболее производительным .
Один компонент может быть реализацией нескольких объектов или даже
некоторой части объектной системы, полученной на уровне проектирования.
Компоненты конструируются как некоторая абстракция, которая состоит из трех
частей: информационной, внешней и внутренней.
Информационная часть представляет собой информацию о компоненте:
назначение, дата изготовления, условия применения (ОС, среда, платформа и
т.п.); уровень повторного использования; контекст или окружение; способ
взаимодействия между собою компонентов.

17.

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

18.

Внутренняя часть компонента состоит из : интерфейса (interfaces), реализации
(implementation), схемы развертки (deployment).
Основные составные элементы компонента
Интерфейс
Реализация
Схемы
развертывания
♦ Один или несколько;
♦ Уникальность
именования в
пределах системы;
♦ Клиентский или
серверный (входной
или выходной);
♦ определенная
сигнатура;
♦ описание методов
взаимодействия
♦ одна или несколько;
♦ ориентация на
конкретную
платформу и
операционное
окружение
♦ выбор конкретной
реализации;
♦ поддержка
интерфейсов
компонента
♦ типовость
процедуры
развертывания;
♦ управляемость;
♦ настраиваемость на
операционную среду;
♦ модифицируемость

19.

Интерфейсы отображают взгляд пользователя на компонент, то есть
что компонент будет делать, когда к нему обращаются.
Реализация – это код, который будет использоваться при обращении к
операциям, которые определены в интерфейсах компонента. Компонент
может иметь несколько реализаций, например, в зависимости от
операционной среды или от модели данных и соответствующей системы
управления базами данных, которая необходима для функционирования
компонента.
Развертка – это физический файл или архив, готовый к выполнению,
который передается пользователю и содержит все необходимые способы
для создания, настройки и функционирования компонента.
Компонент описывается в языке программирования, не зависит от
операционной среды (например, от среды виртуальной машины JAVA) и от
реальной платформы (например, от платформ в системе CORBA), где он
будет функционировать.

20.

Интерфейс компонентов.
Для объединения компонентов в компонентную модель необходимым
условием является наличие формально определенных интерфейсов в
языках IDL и APL, а также механизмов динамического контроля связей между
компонентами в современных средах.
Спецификация интерфейса в API и IDL включает описание функциональных
свойств компонентов, их типов и порядка задания операций передачи
аргументов и результатов для взаимодействия компонентов. То есть,
компонент – физическая сущность, которая реализует определенную
совокупность интерфейсов. Сами интерфейсы являются понятием, которое
связывает логическую и физическую модели. Для описания самих
компонентов, как правило, применяется ООП и его свойства: наследование,
инкапсуляция, полиморфизм. В языке JAVA понятие интерфейса и класса
являются базовыми. Компонентные модели – Javabeans и Enterprise
Javabeans, а также модель CORBA используют объектно–ориентированные
свойства.

21.

Формальные методы
Формальные методы обеспечивают более строгое представление,
основанное на математике, и, таким образом, могут быть использованы
для математического обоснования полноты спецификаций и правильности
их исполнения. Применение формальных методов дает возможность
строгой проверки позволяющей избавиться от ошибок определенных
видов. Использование таких методов необходимо для определенных
классов систем, например для атомной энергетики, разработки оружия,
систем управления воздушным транспортом.
Z (Spivey, 1989), VDM (Jones, 1896), LOTOS (Bjorner, 1987) иB (Abrial, 1996)
являются наиболее распространенными формальными методами для
формального описания функциональности. LOTOS (Language of Temporal
Ordering Specification –
язык
для определения
временной
последовательности), VDM (Vienna Definition Language – язык венского
определения) и Z стандартизированы ISO. Языки B и LOTOS исполняемые, B
также может быть переведен в программный код.
Формальные методы применяются для критических систем, там, где
потенциальные человеческие или финансовые потери могут быть очень
значительны и стоимость применение точных математических методов,
таким образом, вполне оправдана.

22.

Z–метод для формального моделирования
Z - это нотация для моделирования основанная на логике предикатов
первого порядка и теории множеств. Нотация позволяет представлять
данные
в
виде
множеств,
отображений, кортежей,
связей,
последовательностей и декартовых произведений. Также существуют
функции и символы операций для обработки данных этих типов.

23.

Z-схема для операции «выдача» (книги) в библиотеке, где общее поведение
библиотеки как системы могло бы быть представлено с помощью схемы
под названием«библиотека». Условное обозначение
∆ Библиотека
называется«дельта схема» и обозначает, что схема«выдача» вызывает
изменение состояния в Библиотеке.
Схема разделяет вход и выход, и состояние до и после. Эти операции
обозначаются следующим образом:
• ?- обозначает входящую переменную для операции;
• !- обозначает переменную на выходе операции.
Состояние после операции обозначается штрихом, например, учет′ ′′ ′, для
отделения его от состояния до операции.