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


Объектно-ориентированное проектирование презентация, доклад

Содержание

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

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

Слайд 1Вопросы проектирования ПО
Объектно-ориентированное проектирование

Вопросы проектирования ПООбъектно-ориентированное проектирование

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

понимается период
разработки и эксплуатации ПО, в котором выделяют следующие этапы:


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


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

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

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

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

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

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

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

ПО, во время которого разрабатывается структура и взаимосвязи элементов ПО.

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

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

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

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

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

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

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

ПО в контексте предметной области.
Специфицировать функциональные требования к ПО в

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




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

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

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

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

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

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




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

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

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

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

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

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

Слайд 10Объектно-ориентированное проектирование

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

содержит поведение, определенное в другом прецеденте, например:






Отношение расширения (extend) определяет

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

Слайд 11Объектно-ориентированное проектирование

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

что один элемент модели является специальным или частным случаем другого

элемента модели.
Например, так:





Или так:








Легко видеть, что отношение обобщения действует аналогично отношению наследования, но направлено оно «в обратную сторону».
Объектно-ориентированное проектированиеОтношение обобщения (generalization relationship) предназначено для отражения того факта, что один элемент модели является специальным или

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

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

к ПО
Требование к ПО – это некоторое

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

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

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

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

акторов - Клиент банкомата и Банк. Каждый из акторов взаимодействует

с банкоматом. Функциональные требования к банкомату следующие: 1) снятие наличных по банковской карточке; 2) получении справки о состоянии счета. Эти функциональные требования специфицируются двумя базовыми прецедентами:












Для выполнения базовых прецедентов необходимо идентифицировать банковскую карточку и проверить её PIN-код, поэтому оба базовые прецедента обращаются к дополнительным сервисам (другим прецедентам).

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

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

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

<>

<>

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

<>

<>

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

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

отражены в виде прецедентов?
Не содержат ли диаграммы прецедентов лишнее поведение,

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

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

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

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

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

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



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

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



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

Слайд 18Объектно-ориентированное проектирование

Раздел «Исключения»



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

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

модель проектируемой системы.
Диаграмма классов (class diagram) - предназначена для представления

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



Операции

+origin : Point

+move(p:Point)

+resize(s:Scale)

+display()

#invalidateRegion()

Фигура

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

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

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

Атрибуты

Имя класса

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

секция

Видимость

Сигнатура

операции

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

Слайд 20Объектно-ориентированное проектирование
Основные обозначения на Диаграмме классов


Местоположение
1
Операции
Кратность
Ассоциация

имя : String
фамилия : String
должность

: String

getPhoto(p:Photo)
getContactInform()
getPersonalRecords()

Сотрудник
Атрибуты
Класс
Зависимость
Композиция
Ограничение
Имя
ассоциации
*

Сотрудничество
IsSecureInformation
Имя конца
ассоциации
Обобщение

Компания

адрес : String
телефон :
Number


Офис

название : String


Отдел





{subset}
*
*
*
1
1..
*
1..
*
1..
*
*
0..1
Сотрудник
Менеджер

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


адрес : String
телефон

: int

Number



Контактная

Информация



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

зарплата : Curency



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



Объектно-ориентированное проектированиеОсновные обозначения на Диаграмме классовМестоположение1ОперацииКратностьАссоциацияимя : Stringфамилия : Stringдолжность : StringgetPhoto(p:Photo)getContactInform()getPersonalRecords()СотрудникАтрибутыКлассЗависимостьКомпозицияОграничениеИмяассоциации*СотрудничествоIsSecureInformationИмя концаассоциацииОбобщениеКомпанияадрес : Stringтелефон :NumberОфисназвание :

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


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

Слайд 29Объектно-ориентированное проектирование

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

который имеет свойства как ассоциации, так и класса, и предназначен

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


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

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

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

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

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

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

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

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

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

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

классами, когда один из классов представляет собой некоторую сущность, которая

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




Пример 2. Персональный компьютер


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

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

которой с уничтожением объекта класса-контейнера (класса-композита) уничтожаются и все объекты,

являющимися его составными частями.
Пример 1. Композитный класс





Пример 2. Окно приложения


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

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


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

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

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

русскоязычное название «Данные-Представление-Обработка».



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

Слайд 36Объектно-ориентированное проектирование











Взаимодействие между элементами паттерна MVC
Пользователь взаимодействует с элементом пользовательского

интерфейса(например, нажимает на кнопку в представлении);
Представление отправляет событие о нажатии

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

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

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

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

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

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


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

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