Проектирование ООП

Август 12, 2022

Главная
Информатика
Проектирование ООП

Содержание

2. Объектно-ориентированное проектирование Модели жизненного цикла ПО Под жизненным циклом программного обеспечения (ПО) понимается период разработки и
3. Объектно-ориентированное проектирование Спиральная модель жизненного цикла ПО
4. Объектно-ориентированное проектирование Проектирование ПО (основные понятия) Проектирование – это этап жизненного цикла ПО, во время которого
5. Объектно-ориентированное проектирование UML (основные понятия) Unified Modeling Language – унифицированный язык моделирования, который предназначен для описания,
6. Объектно-ориентированное проектирование Канонические диаграммы языка UML 2.х
7. Объектно-ориентированное проектирование Диаграммы прецедентов (нотация и семантика) Назначение диаграмм прецедентов: Определить границы функциональности ПО в контексте
8. Объектно-ориентированное проектирование Прецедент (use case) есть общая спецификация совокупности выполняемых системой действий с целью предоставления некоторого
9. Объектно-ориентированное проектирование Как выделить акторов? Типовые вопросы для идентификации акторов в системе: Какие организации или лица
10. Объектно-ориентированное проектирование Отношение включения (include) отражает тот факт, что некоторый прецедент содержит поведение, определенное в другом
11. Объектно-ориентированное проектирование Отношение обобщения (generalization relationship) предназначено для отражения того факта, что один элемент модели является
12. Объектно-ориентированное проектирование Диаграммы прецедентов (примеры разработки) Диаграммы прецедентов должны отражать функциональные требования к ПО Требование к
13. Объектно-ориентированное проектирование Пример 1. Диаграмма прецедентов для продажи товаров через Интернет-магазин
14. Объектно-ориентированное проектирование Пример 2. Диаграмма прецедентов для модели банкомата Система имеет двух акторов - Клиент банкомата
15. Объектно-ориентированное проектирование Показатели качества диаграмм прецедентов: Все ли функциональные требования к ПО отражены в виде прецедентов?
16. Объектно-ориентированное проектирование Сценарии выполнения прецедентов (пример) Для каждого базового прецедента диаграммы прецедентов необходимо продумать, разработать и
17. Объектно-ориентированное проектирование Раздел «Типичный ход событий»
18. Объектно-ориентированное проектирование Раздел «Исключения»
19. Объектно-ориентированное проектирование Диаграммы классов (нотация и семантика) Диаграмма классов есть основная логическая модель проектируемой системы. Диаграмма
20. Объектно-ориентированное проектирование Основные обозначения на Диаграмме классов Местоположение 1 Операции Кратность Ассоциация имя : String фамилия
21. Объектно-ориентированное проектирование Пример Диаграммы классов. Имеется два пакета классов: «Холдинг» и «Персонал». Класс «Предприятие» многократно ассоциирован
22. Объектно-ориентированное проектирование Диаграммы классов (атрибуты) Атрибуты класса задают свойства, которые являются общими для всех объектов данного
23. Объектно-ориентированное проектирование - выражение, которое служит для задания начального значения или значений данного атрибута в момент
24. Объектно-ориентированное проектирование Диаграммы классов (операции) Операции класса задают поведение, которое является общим для всех объектов данного
25. Объектно-ориентированное проектирование - указывает дополнительные свойства значений данного формального параметра. Имеет тот же смысл что и
26. Объектно-ориентированное проектирование Диаграммы классов (отношения) В диаграммах классов используются отношения следующих шести видов: Ассоциация является наиболее
27. Объектно-ориентированное проектирование Отношения ассоциации Имя конца ассоциации специфицирует роль, которую играет класс, расположенный на соответствующем конце
28. Объектно-ориентированное проектирование Пример 2. Исключающая ассоциация Пример 3. 4-арная ассоциация
29. Объектно-ориентированное проектирование Пример 4. Ассоциация класс Ассоциация класс есть элемент диаграммы классов, который имеет свойства как
30. Объектно-ориентированное проектирование Отношения обобщения Обобщение – это таксономическое отношение между некоторым общим классификатором (предком) и более
31. Объектно-ориентированное проектирование Пример 2. Спецификация ограничений при обобщении. Рядом со стрелкой отношения обобщения может размещаться текст
32. Объектно-ориентированное проектирование Отношения агрегации Отношение агрегации – это направленное отношение между двумя классами, когда один из
33. Объектно-ориентированное проектирование Отношения композиции Отношение композиции есть сильная форма отношения "часть-целое", при которой с уничтожением объекта
34. Объектно-ориентированное проектирование Пример 3. Применение различных нотаций при композиции
35. Объектно-ориентированное проектирование Паттерн проектирования MVC Паттерн MVC (Model-View-Controller) применяется при разработке интерактивных приложений (в том числе
36. Объектно-ориентированное проектирование Взаимодействие между элементами паттерна MVC Пользователь взаимодействует с элементом пользовательского интерфейса(например, нажимает на кнопку
38. Скачать презентацию

Слайд 2

Объектно-ориентированное проектирование
Модели жизненного цикла ПО
Под жизненным циклом программного обеспечения (ПО) понимается

период
разработки и эксплуатации ПО, в котором выделяют следующие этапы:
Спецификация требований к ПО.
Проектирование ПО.
Реализация ПО (кодирование).
Отладка и тестирование ПО.
Внедрение ПО (ввод в эксплуатацию).
Эксплуатация и сопровождение ПО.

Каскадная модель жизненного цикла ПО

Итерационная модель

Артефакты – это любые информационные сущности и документы, которые порождаются в течение жизненного цикла ПО.

Слайд 3

Объектно-ориентированное проектирование
Спиральная модель жизненного цикла ПО

Слайд 4

Объектно-ориентированное проектирование
Проектирование ПО (основные понятия)
Проектирование – это этап жизненного цикла ПО,

во время которого разрабатывается структура и взаимосвязи элементов ПО. Результатом является проект, содержащий достаточное количество артефактов, необходимых для реализации ПО.
В российской практике результат проектирования ПО представляется в виде комплекса документов под названием «Технический проект» или «Эскизный проект», а в зарубежной практике - Software Architecture Document или Software Design Document.
Проектирование выполняется на основе: моделей предметной области, требований к ПО, паттернов (шаблонов) проектирования, опыта проектировщиков.
Предметная область - это часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования ПО.
Требования к ПО – это документ, задающий внешние (видимые) свойства ПО, рассматриваемого как чёрный ящик.
Проектированию обычно подлежат: архитектура ПО, пользовательские интерфейсы, модули и компоненты ПО.
Архитектура ПО - это схемы, диаграммы и другие артефакты, которые дают представление о компонентах, составляющих систему, о взаимосвязях между этими компонентами и правилах, регламентирующих эти взаимосвязи.
Проектирование, кодирование, тестирования и внедрение ПО выполняют команды разработчиков. Для организации работ применяются методы проектного управления.
В зависимости от уровня сложности создаваемого ПО, процесс проектирования может осуществляться «вручную» или при помощи специальных CASE-средств.
CASE-средство – программный комплекс, который автоматизирует технологический процесс проектирования, реализации, тестирования и сопровождения сложного ПО.

Слайд 5

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

предназначен для описания, визуализации и документирования объектно-ориентированных систем в процессе их анализа и проектирования.
Язык UML обеспечивает стандартный способ написания проектной документации для ПО, включая концептуальные аспекты (бизнес процессы, функции системы, др.), и конкретные аспекты (классы, объекты, выражения языков программирования, схемы баз данных, повторно используемые компоненты, др.).
Язык UML не является методологией, процессом, языком программирования или формальным языком. UML = нотация + семантика.
Здесь под нотацией понимается система условных обозначений для графического представления визуальных моделей. Семантика – это система правил и соглашений, определяющая смысл и интерпретацию конструкций языка.
В языке UML различают диаграммы (модели) следующих двух видов:
Структурные модели (structured models) – модели, предназначенные для описания статической структуры сущностей или элементов некоторой системы, включая классы, интерфейсы, атрибуты и отношения.
Модели поведения (behavioral models) – модели, предназначенные для описания процесса функционирования элементов системы, включая методы и правила взаимодействия между ними, а также процесс изменения состояний отдельных элементов и системы в целом.

Слайд 6

Объектно-ориентированное проектирование
Канонические диаграммы языка UML 2.х

Слайд 7

Объектно-ориентированное проектирование
Диаграммы прецедентов (нотация и семантика)
Назначение диаграмм прецедентов:
Определить границы функциональности ПО

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

ассоциация
(коммуникация)

обобщение
(наследование)

Слайд 8

Объектно-ориентированное проектирование
Прецедент (use case) есть общая спецификация совокупности выполняемых системой действий

с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких акторов.
Прецедент отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?».
Прецедент именуется отглагольным существительным или глаголом в неопределенной форме.
Актор есть любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач.
Примеры акторов: кассир, клиент банка, банковский служащий, продавец магазина, пассажир авиарейса, администратор гостиницы, сотовый телефон.

Проверка состояния текущего счёта клиента

Слайд 9

Объектно-ориентированное проектирование
Как выделить акторов? Типовые вопросы для идентификации акторов в

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

Слайд 10

Объектно-ориентированное проектирование
Отношение включения (include) отражает тот факт, что некоторый прецедент содержит

поведение, определенное в другом прецеденте, например:
Отношение расширения (extend) определяет взаимосвязь одного прецедента с некоторым другим прецедентом, функциональность или поведение которого задействуется первым прецедентом не всегда, а только при выполнении некоторых дополнительных условий.

Слайд 11

Объектно-ориентированное проектирование
Отношение обобщения (generalization relationship) предназначено для отражения того факта, что

один элемент модели является специальным или частным случаем другого элемента модели.
Например, так:
Или так:
Легко видеть, что отношение обобщения действует аналогично отношению наследования, но направлено оно «в обратную сторону».

Слайд 12

Объектно-ориентированное проектирование
Диаграммы прецедентов (примеры разработки)
Диаграммы прецедентов должны отражать функциональные требования к

ПО
Требование к ПО – это некоторое свойство, которым должна обладать система или ее компонент, чтобы удовлетворять условиям контракта, положениям стандартов, формальной спецификации или технической документации.
Функциональные требования определяют действия, которые должна быть способна выполнить система, без рассмотрения физических особенностей их реализации. Функциональные требования определяют внешнее поведение системы. Лучше всего они описываются в форме прецедентов. Каждому функциональному требованию должен соответствовать отдельный прецедент
Последовательность разработки диаграмм прецедентов следующая:
Выявить основных акторов и определить их цели по отношению к системе.
Выявить и специфицировать все базовые (основные) прецеденты.
Выделить цели базовых прецедентов, интересы акторов в контексте этих прецедентов, предусловия и постусловия прецедентов.
Написать типовой успешный сценарий выполнения базовых прецедентов.
Определить исключения (нештатные ситуации) в сценариях прецедентов и написать сценарии для всех выявленных исключений.
Выделить прецеденты исключений и изобразить их со стереотипом «extend».
Выделить общие фрагменты функциональности прецедентов и отобразить их как отдельные прецеденты со стереотипом «include».
Проверить диаграмму на отсутствие дублирования прецедентов и акторов.

Слайд 13

Объектно-ориентированное проектирование
Пример 1. Диаграмма прецедентов для продажи товаров через Интернет-магазин

Слайд 14

Объектно-ориентированное проектирование
Пример 2. Диаграмма прецедентов для модели банкомата
Система имеет двух акторов

- Клиент банкомата и Банк. Каждый из акторов взаимодействует с банкоматом. Функциональные требования к банкомату следующие: 1) снятие наличных по банковской карточке; 2) получении справки о состоянии счета. Эти функциональные требования специфицируются двумя базовыми прецедентами:
Для выполнения базовых прецедентов необходимо идентифицировать банковскую карточку и проверить её PIN-код, поэтому оба базовые прецедента обращаются к дополнительным сервисам (другим прецедентам).

Снятие наличных по банковской карточке

Проверка PIN-кода банковской карточки

Получение справки о состоянии счета

Идентификация банковской карточки

Слайд 15

Объектно-ориентированное проектирование
Показатели качества диаграмм прецедентов:
Все ли функциональные требования к ПО отражены

в виде прецедентов?
Не содержат ли диаграммы прецедентов лишнее поведение, которого нет в требованиях?
Действительно ли необходимы все отношения включения, расширения и обобщения?
Правильно ли произведено деление модели на пакеты прецедентов?
Стала ли диаграмма (модель) в результате деления её на пакеты проще и/или удобнее для восприятия?
Можно ли на основе диаграмм прецедентов составить четкое представление о функционировании системы в контексте ее пользователей?
Типичные ошибки при разработке диаграмм прецедентов:
Превращение диаграммы прецедентов в диаграмму деятельности за счет желания детально отразить все функциональные действия (излишняя детализация).
Инициатором действий является разрабатываемая система, а не акторы.
Преждевременная спецификация свойств и методов классов до того, как сформулированы все прецеденты.
Использование кратких, невыразительных имен для прецедентов.
Описание прецедентов в терминах, непонятных пользователям и заказчикам.
Отсутствие описаний альтернативных сценариев (исключений, нештатных ситуаций).
Тратится слишком много времени на решение вопросов о том, какие стереотипы и ассоциации использовать в диаграмме.

Слайд 16

Объектно-ориентированное проектирование
Сценарии выполнения прецедентов (пример)
Для каждого базового прецедента диаграммы прецедентов необходимо

продумать, разработать и описать текстовый сценарий его выполнения.
Сценарий выполнения каждого базового прецедента имеет, в общем случае, три раздела, которые оформляются как таблицы.
В качестве примера рассмотрим сценарий выполнения базового прецедента «Снятие наличных по банковской карточке» для модели банкомата (разделы сценария: «Общее описание сценария», «Типичный ход событий», «Исключения»).
Раздел «Общее описание сценария»

Слайд 17

Объектно-ориентированное проектирование
Раздел «Типичный ход событий»

Слайд 18

Объектно-ориентированное проектирование
Раздел «Исключения»

Слайд 19

Объектно-ориентированное проектирование
Диаграммы классов (нотация и семантика)
Диаграмма классов есть основная логическая модель

проектируемой системы.
Диаграмма классов (class diagram) - предназначена для представления статической структуры программной системы в терминах классов ООП.
Диаграмма классов представляет собой граф, узлами которого являются элементы типа “классификатор”, которые связаны различными типами структурных отношений.
Классификатор (classifier) - специальное понятие, предназначенное для классификации экземпляров (объектов), которые имеют общие характеристики.
Варианты графического изображения классов на Диаграмме классов:

Операции

+origin : Point

+move(p:Point)

+resize(s:Scale)

+display()

#invalidateRegion()

Фигура

Возможности:

- управляет формой

обеспечивает движение
и трансформацию

Атрибуты

Имя класса

Дополнительная

секция

Видимость

Сигнатура

операции

Слайд 20

Объектно-ориентированное проектирование
Основные обозначения на Диаграмме классов
Местоположение
1
Операции
Кратность
Ассоциация
имя : String
фамилия : String
должность :

String

getPhoto(p:Photo)

getContactInform()

getPersonalRecords()

Сотрудник

Атрибуты

Класс

Зависимость

Композиция

Ограничение

Имя

ассоциации

Сотрудничество

IsSecureInformation

Имя конца

ассоциации

Обобщение

Компания

адрес : String

телефон :

Number

Офис

название : String

Отдел

{subset}

1..

0..1

Сотрудник

Менеджер

Штаб-квартира

адрес : String

телефон : int

Number

Контактная

Информация

историяРаботы : String

зарплата : Curency

Персональное Дело

Слайд 21

Объектно-ориентированное проектирование
Пример Диаграммы классов.
Имеется два пакета классов: «Холдинг» и «Персонал».
Класс «Предприятие»

многократно ассоциирован с классами «Должность» и «Сотрудник».
Для С++ это значит, что в классе «Предприятие» есть два контейнера указателей на объекты этих классов.
Класс «Сотрудник» содержит объекты классов «ОпытРаботы» и «Квалификация». Также содержит контейнер указателей на объекты класса «Предприятие» (для С++).
Классы «Мужчина» и «Женщина» есть потомки класса «Сотрудник».
Класс «УровеньКвалификации» по сути представляет собой перечислимый тип. Он однократно ассоциирован с классом «Квалификация».

Слайд 22

Объектно-ориентированное проектирование
Диаграммы классов (атрибуты)
Атрибуты класса задают свойства, которые являются общими для

всех объектов данного класса. В С++ элементы данных класса по сути и есть атрибуты класса.
Формат задания атрибутов класса (БНФ):
<атрибут>::= [<видимость>] [‘/’] <имя атрибута> [‘:’<тип атрибута>] [‘[‘<кратность>‘]’]
[‘=’ <значение по умолчанию>] [‘{‘<модификаторы атрибута> ’}’]
<видимость> атрибутов может принимать следующие значения:
+ public (общедоступный).
- private (скрытый, видим только внутри класса).
# protected (защищенный, видим внутри класса и для потомков).
~ package (видим только в ближайшем охватывающем пакете)
Символ“/” означает, что атрибут является производным. Значение производного атрибута может быть вычислено на основе значений других атрибутов этого или других классов. Поэтому данный атрибут называют иногда вычислимым.
<имя атрибута> - строка текста, которая используется в качестве идентификатора атрибута. Имя должно быть уникальным в пределах данного класса.
<тип атрибута> - имя классификатора, который является типом данного атрибута.
<кратность> - характеризует общее количество конкретных значений для атрибута, которые могут быть заданы для объектов данного класса. По сути, задает мощность множества значений атрибута. Используется специальный синтаксис.

Слайд 23

Объектно-ориентированное проектирование
<значение по умолчанию> - выражение, которое служит для задания начального значения или

значений данного атрибута в момент создания объекта класса.
<модификатор атрибута> - текстовое выражение, которое придает атрибуту дополнительную семантику. Формат следующий (БНФ):
<модификатор атрибута> ::= ‘readOnly’ | ‘union’ | ‘subsets‘ <имя атрибута> | ‘redefines’ <имя атрибута> | ‘ordered’ | ‘unique’ | <ограничение атрибута>

Слайд 24

Объектно-ориентированное проектирование
Диаграммы классов (операции)
Операции класса задают поведение, которое является общим для

всех объектов данного класса. В С++ функции-члены класса по сути и есть операции класса.
Формат задания операций класса (БНФ):
<операция> ::= [<видимость>] <имя операции> ‘(‘ [<список параметров>] ‘)’
[‘:’ [<тип результата>] ‘{‘ <свойства операции> ‘}’]
<список параметров> - список формальных аргументов, формат их следующий:
<параметр> ::= [<направление>] <имя параметра> ‘:’ <тип параметра> [‘[‘<кратность>’]’] [‘=’ <значение по умолчанию>] [‘{‘ <свойства параметра > ‘}’]
<направление> ::= ‘in’ | ‘out’ | ‘inout’| ‘return‘. Если не указано, по умолчанию “in”.
in – значения параметра передаются в операцию вызывающим объектом.
inout – значения параметра передаются в операцию вызывающим объектом и затем передаются вызывающему объекту после окончания выполнения операции.
out – значения параметра передаются вызывающему объекту после окончания выполнения операции.
return – значения параметра передаются в качестве возвращаемых значений вызывающему объекту после окончания выполнения операции.
<видимость>, <имя операции>, <имя параметра>, <тип параметра>, <кратность> и <значение по умолчанию> имеют тот же смысл, что и для атрибутов.

Слайд 25

Объектно-ориентированное проектирование
<свойства параметра > - указывает дополнительные свойства значений данного формального

параметра. Имеет тот же смысл что и <модификатор атрибута>.
<свойства операции> - может принимать следующие значения:
redefines <имя операции> – данная операция переопределяет некоторую наследуемую операцию с именем <имя операции>.
query – операция не изменяет состояния системы и не имеет побочных эффектов.
ordered – значения возвращаемого параметра являются упорядоченными.
unique – значения возвращаемого параметра не могут повторяться.

Слайд 26

Объектно-ориентированное проектирование
Диаграммы классов (отношения)
В диаграммах классов используются отношения следующих шести видов:
Ассоциация

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

Слайд 27

Объектно-ориентированное проектирование
Отношения ассоциации
Имя конца ассоциации специфицирует роль, которую играет класс, расположенный

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

Слайд 28

Объектно-ориентированное проектирование
Пример 2. Исключающая ассоциация
Пример 3. 4-арная ассоциация

Слайд 29

Объектно-ориентированное проектирование
Пример 4. Ассоциация класс
Ассоциация класс есть элемент диаграммы классов, который

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

Слайд 30

Объектно-ориентированное проектирование
Отношения обобщения
Обобщение – это таксономическое отношение между некоторым общим классификатором

(предком) и более специальным классификатором (потомком).
Пример 1. Геометрические фигуры

Слайд 31

Объектно-ориентированное проектирование
Пример 2. Спецификация ограничений при обобщении.
Рядом со стрелкой отношения

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

{complete} - все потомки рассматриваемого класса определены (возможно, не показаны на данной диаграмме), и список потомков не может быть расширен.
{disjoint} – запрещено множественное наследование.
{incomplete} - возможно появление новых классов-потомков.
{overlapping} – разрешено множественное наследование.

Слайд 32

Объектно-ориентированное проектирование
Отношения агрегации
Отношение агрегации – это направленное отношение между двумя классами,

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

Слайд 33

Объектно-ориентированное проектирование
Отношения композиции
Отношение композиции есть сильная форма отношения "часть-целое", при которой

с уничтожением объекта класса-контейнера (класса-композита) уничтожаются и все объекты, являющимися его составными частями.
Пример 1. Композитный класс
Пример 2. Окно приложения

Слайд 34

Объектно-ориентированное проектирование
Пример 3. Применение различных нотаций при композиции

Слайд 35

Объектно-ориентированное проектирование
Паттерн проектирования MVC
Паттерн MVC (Model-View-Controller) применяется при разработке интерактивных приложений

(в том числе web-приложений) с гибким пользовательским интерфейсом.
Иногда используется русскоязычное название «Данные-Представление-Обработка».

Слайд 36

Объектно-ориентированное проектирование
Взаимодействие между элементами паттерна MVC
Пользователь взаимодействует с элементом пользовательского интерфейса(например,

нажимает на кнопку в представлении);
Представление отправляет событие о нажатии на кнопке в контроллер для решения, как отреагировать на это событие;
Контроллер изменяет модель.
Модель информирует представление о том, что модель была изменена.
Представление читает информацию изменённой модели и изменяет себя.

Проектирование ООП

Содержание

Объектно-ориентированное проектированиеМодели жизненного цикла ПОПод жизненным циклом программного обеспечения (ПО) понимается

Объектно-ориентированное проектированиеСпиральная модель жизненного цикла ПО

Объектно-ориентированное проектированиеПроектирование ПО (основные понятия)Проектирование – это этап жизненного цикла ПО,

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

Объектно-ориентированное проектированиеКанонические диаграммы языка UML 2.х

Объектно-ориентированное проектированиеДиаграммы прецедентов (нотация и семантика)Назначение диаграмм прецедентов:Определить границы функциональности ПО

Объектно-ориентированное проектированиеПрецедент (use case) есть общая спецификация совокупности выполняемых системой действий

Объектно-ориентированное проектирование Как выделить акторов? Типовые вопросы для идентификации акторов в

Объектно-ориентированное проектированиеОтношение включения (include) отражает тот факт, что некоторый прецедент содержит

Объектно-ориентированное проектированиеОтношение обобщения (generalization relationship) предназначено для отражения того факта, что

Объектно-ориентированное проектированиеДиаграммы прецедентов (примеры разработки)Диаграммы прецедентов должны отражать функциональные требования к

Объектно-ориентированное проектированиеПример 1. Диаграмма прецедентов для продажи товаров через Интернет-магазин

Объектно-ориентированное проектированиеПример 2. Диаграмма прецедентов для модели банкоматаСистема имеет двух акторов

Объектно-ориентированное проектированиеПоказатели качества диаграмм прецедентов:Все ли функциональные требования к ПО отражены

Объектно-ориентированное проектированиеСценарии выполнения прецедентов (пример)Для каждого базового прецедента диаграммы прецедентов необходимо

Объектно-ориентированное проектированиеРаздел «Типичный ход событий»

Объектно-ориентированное проектированиеРаздел «Исключения»

Объектно-ориентированное проектированиеДиаграммы классов (нотация и семантика)Диаграмма классов есть основная логическая модель

Объектно-ориентированное проектированиеОсновные обозначения на Диаграмме классовМестоположение1ОперацииКратностьАссоциацияимя : Stringфамилия : Stringдолжность :

Объектно-ориентированное проектированиеПример Диаграммы классов.Имеется два пакета классов: «Холдинг» и «Персонал».Класс «Предприятие»

Объектно-ориентированное проектированиеДиаграммы классов (атрибуты)Атрибуты класса задают свойства, которые являются общими для

Объектно-ориентированное проектирование<значение по умолчанию> - выражение, которое служит для задания начального значения или

Объектно-ориентированное проектированиеДиаграммы классов (операции)Операции класса задают поведение, которое является общим для

Объектно-ориентированное проектирование<свойства параметра > - указывает дополнительные свойства значений данного формального

Объектно-ориентированное проектированиеДиаграммы классов (отношения)В диаграммах классов используются отношения следующих шести видов:Ассоциация

Объектно-ориентированное проектированиеОтношения ассоциацииИмя конца ассоциации специфицирует роль, которую играет класс, расположенный

Объектно-ориентированное проектированиеПример 2. Исключающая ассоциацияПример 3. 4-арная ассоциация

Объектно-ориентированное проектированиеПример 4. Ассоциация классАссоциация класс есть элемент диаграммы классов, который

Объектно-ориентированное проектированиеОтношения обобщенияОбобщение – это таксономическое отношение между некоторым общим классификатором

Объектно-ориентированное проектированиеПример 2. Спецификация ограничений при обобщении. Рядом со стрелкой отношения

Объектно-ориентированное проектированиеОтношения агрегацииОтношение агрегации – это направленное отношение между двумя классами,

Объектно-ориентированное проектированиеОтношения композицииОтношение композиции есть сильная форма отношения "часть-целое", при которой

Объектно-ориентированное проектированиеПример 3. Применение различных нотаций при композиции

Объектно-ориентированное проектированиеПаттерн проектирования MVCПаттерн MVC (Model-View-Controller) применяется при разработке интерактивных приложений

Похожие презентации