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

Июль 30, 2022

Главная
Информатика
Объектно-ориентированные подходы

Содержание

2. Объектно-ориентированные подходы Объектно-ориентированные подходы моделирования существенно отличаются от структурных подходов. ООП направлены на максимизацию повторного использования
3. Диаграммы классов (class diagrams) Диаграмма классов является одной из основных нотаций объектно-ориентированного анализа и проектирования. Впервые
4. Пример диаграмм классов (или объектов).
5. Основной причиной появления этого подхода было желание сделать разработку программного обеспечения более близкой к моделированию, а,
6. Диаграмма прецедентов для банковской системы.
7. Нотация UML UML предполагает разработку нескольких моделей, совокупность которых описывает разрабатываемую систему. Каждая модель относится к
9. UML-диаграмма классов для банковской системы (диаграмма классов является базовой в UML). На диаграмме показан набор классов,
10. Моделирование также бывает полезным, когда существуют внешние системы, или устройства, которые разрабатываемая система будет использовать. Эти
11. Диаграмма отражает пользовательские требования, которые явно относятся к проблемной области. Для системы транспортировки багажа были определены
12. Для описания функциональных требований к системе используется моделирование прецедентов. В качестве примера можно рассмотреть две диаграммы
13. Диаграмма прецедентов для системы транспортировки багажа.
14. Диаграмма прецедентов для системы регистрации багажа.
15. UML также дает проектировщикам возможность моделировать функциональность системы и ее поведение. Диаграмма последовательности показывает взаимодействие и
16. Компонентный подход к проектированию По оценкам экспертов, 75 % работ по программированию в мире дублируются (например,
17. Внешняя часть определяет взаимодействие компонента со средой и с платформой, на которой он будет выполняться. Эта
18. Внутренняя часть компонента состоит из : интерфейса (interfaces), реализации (implementation), схемы развертки (deployment). Основные составные элементы
19. Интерфейсы отображают взгляд пользователя на компонент, то есть что компонент будет делать, когда к нему обращаются.
20. Интерфейс компонентов. Для объединения компонентов в компонентную модель необходимым условием является наличие формально определенных интерфейсов в
21. Формальные методы Формальные методы обеспечивают более строгое представление, основанное на математике, и, таким образом, могут быть
22. Z–метод для формального моделирования Z - это нотация для моделирования основанная на логике предикатов первого порядка
24. Скачать презентацию

Слайд 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 - это нотация для моделирования основанная на

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