Объектно-ориентированное проектирование ПС

Содержание

Слайд 2

Способы декомпозиции системы Функциональная декомпозиция– на основе потока данных с выделением

Способы декомпозиции системы

Функциональная декомпозиция– на основе потока данных с выделением обрабатывающих

функций
Объектная декомпозиция – на основе выделения сущностей, обладающих собственными наборами данных, состояниями и наборами операций

*

Слайд 3

Способы декомпозиции системы В первом случае внимание концентрируется на порядке происходящих

Способы декомпозиции системы

В первом случае внимание концентрируется на порядке происходящих событий

(действиях)
Во втором – на агентах, являющихся либо объектами, либо субъектами действий

*

Слайд 4

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

Структурные единицы

Основной структурной единицей при функциональной декомпозиции является процедура, как программная

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

*

Слайд 5

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

Начало проектирования

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

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

*

Слайд 6

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

Ключевые абстракции

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

это класс или объект, который входит в словарь проблемной области

*

Слайд 7

Выделение объектов Ключевые абстракции определяют границы системы: выделяют то, что входит

Выделение объектов

Ключевые абстракции определяют границы системы: выделяют то, что входит в

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

*

Слайд 8

ПРЕЦЕДЕНТЫ И ТРЕБОВАНИЯ *

ПРЕЦЕДЕНТЫ И ТРЕБОВАНИЯ

*

Слайд 9

Требования Уточним понятие прецедента и его связь с понятием «требования к

Требования

Уточним понятие прецедента и его связь с понятием «требования к программной

системе»
Требования (requirements) – это возможности или условия, которым должна удовлетворять разрабатываемая система

*

Слайд 10

Требования и риски *

Требования и риски

*

Слайд 11

Формулировка требований Требования к системе могут быть представлены в виде списка

Формулировка требований

Требования к системе могут быть представлены в виде списка кратких

утверждений типа: «система должна обеспечивать выполнение такой-то операции»
Такой подход связан, по крайней мере, с двумя недостатками:
нечеткостью формулировки требований,
неполнотой их списка

*

Слайд 12

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

Формулировка требований

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

на использовании прецедентов (Ivar Jacobson, 1986)
Прецедент (use case) – это описание способа использования системы с целью получения некоторого результата, значимого для исполнителя

*

Слайд 13

Прецедент и сценарии Прецедент однозначно связан с результатом, но достижение одного

Прецедент и сценарии

Прецедент однозначно связан с результатом, но достижение одного и

того же результата может происходить разными путями, в зависимости от тех или иных условий
Конкретная последовательность действий или взаимодействий между системой и исполнителем в рамках одного прецедента называется сценарием (scenario)

*

Слайд 14

Прецедент и сценарии Таким образом, прецедент – это набор различных сценариев

Прецедент и сценарии

Таким образом, прецедент – это набор различных сценариев использования

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

*

Слайд 15

Исполнитель Под исполнителем (actor) в предыдущих определениях понималась некоторая сущность, обладающая

Исполнитель

Под исполнителем (actor) в предыдущих определениях понималась некоторая сущность, обладающая поведением

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

*

Слайд 16

ПРИМЕР РАЗРАБОТКИ Это т пример описан в книге Крэга Лармана «Применение UML и шаблонов проектирования» *

ПРИМЕР РАЗРАБОТКИ

Это т пример описан в книге Крэга Лармана «Применение UML

и шаблонов проектирования»

*

Слайд 17

Постановка задачи Разработать программное обеспечение для системы организации товарооборота и обработки

Постановка задачи

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

в магазинах розничной торговли

*

Слайд 18

Модель разработки Разработка системы будет вестись в рамках модели RUP -

Модель разработки

Разработка системы будет вестись в рамках модели RUP - адаптивного

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

*

Слайд 19

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

Фазы процесса разработки

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

и основных требованиях к ней
Развитие –реализация базовой части системы и уточнение требований; осуществляется через последовательность итераций

*

Слайд 20

Фазы процесса разработки Конструирование – разработка системы в полном объеме и

Фазы процесса разработки

Конструирование – разработка системы в полном объеме и окончательная

формулировка требований; осуществляется через последовательность итераций, каждая из которых завершается созданием релиза
Внедрение – развертывание системы и бета-тестирование

*

Слайд 21

ЭТАП НАЧАЛО Основные задачи: формирование представления о проекте формулирование исходных требований

ЭТАП НАЧАЛО

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

проекта
идентификация основных рисков

*

Слайд 22

Анализ предметной области Предметная область – ро́зничная торго́вля (англ. retail) Что

Анализ предметной области

Предметная область – ро́зничная торго́вля (англ. retail)
Что делается –

производится продажа товаров конечному потребителю (частному лицу)
Как делается – покупатель отбирает необходимые ему товары и производит оплату в кассе

*

Слайд 23

Анализ предметной области Где делается – основным предприятием розничной торговли является

Анализ предметной области

Где делается – основным предприятием розничной торговли является магазин

(дискаунтер, универмаг, универсам и т.д.)
Кто делает – субъектами процесса розничной торговли являются продавец (менеджер торгового зала, кассир) и покупатель

*

Слайд 24

Анализ предметной области Когда делается – каждый магазин имеет фиксированный график

Анализ предметной области

Когда делается – каждый магазин имеет фиксированный график работы
Зачем

делается – розничная торговля обеспечивает удовлетворение потребностей населения в товарах различного назначения и получение торговой прибыли

*

Слайд 25

Проблемы Низкая скорость выполнения операции оплаты покупок Ошибки кассиров при подсчете

Проблемы

Низкая скорость выполнения операции оплаты покупок
Ошибки кассиров при подсчете стоимости товаров

и расчете с покупателями
Сложность ведения учета проданных товаров
Большие объемы работ по подготовке данных для системы анализа

*

Слайд 26

Пути решения Создание компьютеризированной системы оплаты покупок Point-Of-Sale (POS-система) Интеграция этой

Пути решения

Создание компьютеризированной системы оплаты покупок Point-Of-Sale (POS-система)
Интеграция этой системы с

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

*

Слайд 27

POS-терминал POS-система реализуется в виде набора POS-терминалов Каждый POS-терминал представляет собой

POS-терминал

POS-система реализуется в виде набора POS-терминалов
Каждый POS-терминал представляет собой

программно-аппаратный комплекс, установленный на месте, где кассир осуществляет прием платежей от клиентов (АРМ кассира)

*

Слайд 28

Аппаратная часть Аппаратная часть POS-терминала включает: системный блок ПК, фискальный регистратор,

Аппаратная часть

Аппаратная часть POS-терминала включает:
системный блок ПК,
фискальный регистратор,
POS-монитор

кассира,
денежный ящик,
программируемую клавиатуру,
считыватель карт,
считыватель штрих-кодов

*

Слайд 29

Фискальный регистратор Фискальный регистратор (ФР) – это устройство, обеспечивающее не корректируемую

Фискальный регистратор

Фискальный регистратор (ФР) – это устройство, обеспечивающее не корректируемую ежесуточную

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

*

Слайд 30

Аппаратная часть POS-терминала *

Аппаратная часть POS-терминала

*

Слайд 31

Интерфейс пользователя POS-терминал должен иметь интерфейс взаимодействия с пользователем для поиска

Интерфейс пользователя

POS-терминал должен иметь интерфейс взаимодействия с пользователем для
поиска нужного товара

и получения его характеристик;
формирования и печати чеков;
подсчета сдачи;
выполнения различных отчетов

*

Слайд 32

Определение границ системы Границы системы проще всего определить установив основных исполнителей,

Определение границ системы

Границы системы проще всего определить установив основных исполнителей,

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

*

Слайд 33

Границы системы *

Границы системы

*

Слайд 34

Основные исполнители Кассир оформляет продажи, выполняет возврат товара, регистрирует выручку; Системный

Основные исполнители

Кассир
оформляет продажи,
выполняет возврат товара,
регистрирует выручку;
Системный администратор
редактирует

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

*

Слайд 35

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

Основные исполнители

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

оценивает производительность

*

Слайд 36

Прецеденты Следует иметь в виду, что прецеденты могут быть определены на

Прецеденты

Следует иметь в виду, что прецеденты могут быть определены на разных

уровнях детализации
При анализе требований следует сосредоточить внимание на уровне элементарных бизнес-процессов, т.е. задач достаточно высокого уровня
Основной сценарий таких прецедентов содержит 5 – 10 шагов

*

Слайд 37

Прецеденты для POS-системы Включение системы Регистрация в системе Оформление покупки Возврат

Прецеденты для POS-системы

Включение системы
Регистрация в системе
Оформление покупки
Возврат товара
Регистрация выручки
Управление списком

пользователей
Управление безопасностью
Анализ деятельности
Выключение системы

*

Слайд 38

Ранжирование прецедентов Учитываются следующие факторы: влияние на архитектуру (например, добавление новых

Ранжирование прецедентов

Учитываются следующие факторы:
влияние на архитектуру (например, добавление новых классов);
наличие рискованных,

срочных или сложных функций;
потребность в дополнительных исследованиях;
степень важности соответствующего бизнес-процесса

*

Слайд 39

Ранжирование прецедентов *

Ранжирование прецедентов

*

Слайд 40

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

Функциональные требования

Требования этой категории исследуются и формулируются в процессе разработки модели

прецедентов (вариантов использования)
Как правило, одной задаче исполнителя соответствует один прецедент

*

Слайд 41

Диаграмма прецедентов *

Диаграмма прецедентов

*

Слайд 42

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

Описание прецедентов

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

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

*

Слайд 43

Описание прецедентов Текстовое описание прецедента может быть развернутым или кратким На

Описание прецедентов

Текстовое описание прецедента может быть развернутым или кратким
На начальном этапе

развернутое описание дается лишь для основных прецедентов (10-20% от их общего числа)
Пример развернутого описания для прецедента Оформление продажи

*

Слайд 44

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

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

Важно иметь в виду, что главное в работе

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

*

Слайд 45

Нефункциональные требования Определяются в дополнительной спецификации Приведем пример такой спецификации для POS-системы *

Нефункциональные требования

Определяются в дополнительной спецификации
Приведем пример такой спецификации для POS-системы

*

Слайд 46

Эргономичность Для достижения высокой скорости обслуживания покупателей при его высоком качестве

Эргономичность

Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:
обеспечить

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

*

Слайд 47

Надежность При сбое в работе внешних систем (анализ деятельности) необходимо обеспечить

Надежность

При сбое в работе внешних систем (анализ деятельности) необходимо обеспечить возможность

локальной обработки данных, их сохранение и последующую передачу
Этот вопрос требует дальнейшей проработки

*

Слайд 48

Производительность Покупатель хочет оформить покупку как можно быстрее Одна из основных

Производительность

Покупатель хочет оформить покупку как можно быстрее
Одна из основных причин задержки

– низкая скорость авторизации
Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев

*

Слайд 49

Недостатки существующих решений Не обеспечивается автоматический переход из интерактивного в автономный

Недостатки существующих решений

Не обеспечивается автоматический переход из интерактивного в автономный режим

при сбоях внешних систем;
Отсутствие простой возможности интеграции с внешними системами;
Отсутствие поддержки новых терминальных технологий

*

Слайд 50

Итоги этапа Начало Выделены основные исполнители, задачи и прецеденты Выполнено ранжирование

Итоги этапа Начало

Выделены основные исполнители, задачи и прецеденты
Выполнено ранжирование и описание

прецедентов
Сформулированы в черновом варианте требования к системе

*

Слайд 51

ЭТАП РАЗВИТИЕ Создается базовая архитектура системы Производится разрешение высоких рисков Определяется

ЭТАП РАЗВИТИЕ

Создается базовая архитектура системы
Производится разрешение высоких рисков
Определяется большинство требований (до

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

*

Слайд 52

Первая итерация Программная реализация базового сценария прецедента Оформление продажи Реализация прецедента

Первая итерация

Программная реализация базового сценария прецедента Оформление продажи
Реализация прецедента Включение системы

(необходим для предыдущего)
Взаимодействие с внешними службами не реализуется

*

Слайд 53

Словарь предметной области Для дальнейшей работы над системой требуется выделить основные

Словарь предметной области

Для дальнейшей работы над системой требуется выделить основные сущности

предметной области и зафиксировать их в словаре
Register – реестр (терминал)
Item – товар
Store – магазин
Sale – продажа
Sales LineItem – элемент продажи

*

Слайд 54

Словарь предметной области Cashier –кассир Customer – покупатель Manager – менеджер

Словарь предметной области

Cashier –кассир
Customer – покупатель
Manager – менеджер
Payment

– платеж
Product Catalog – каталог товаров
Product Specification – спецификация товара

*

Слайд 55

Концептуальная модель Выделенные таким образом сущности рассматриваются как классы понятий предметной

Концептуальная модель

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

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

*

Слайд 56

Концептуальная модель Отображает наиболее важные для цели моделирования классы понятий предметной

Концептуальная модель

Отображает наиболее важные для цели моделирования классы понятий предметной области

(концептуальные классы)
Кроме того концептуальная модель может отображать
ассоциации между концептуальными классами,
атрибуты концептуальных классов

*

Слайд 57

Классы и атрибуты *

Классы и атрибуты

*

Слайд 58

Концептуальная модель *

Концептуальная модель

*

Слайд 59

Поведение системы Это описание действий, выполняемых системой, без детализации механизма их

Поведение системы

Это описание действий, выполняемых системой, без детализации механизма их реализации
Для

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

*

Слайд 60

Диаграммы последовательностей Диаграммы последовательностей – это составная часть модели прецедентов, позволяющая

Диаграммы последовательностей

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

взаимодействие объектов в процессе реализации прецедента

*

Слайд 61

Диаграмма последовательностей *

Диаграмма последовательностей

*

Слайд 62

Системные операции Диаграмма последовательностей системы позволяет выделить набор системных операций Операцией

Системные операции

Диаграмма последовательностей системы позволяет выделить набор системных операций
Операцией называется любое

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

*

Слайд 63

Описание операций Операции требуют отдельного описания, если они достаточно сложны и

Описание операций

Операции требуют отдельного описания, если они достаточно сложны и

их содержание не раскрыто в описании соответствующего прецедента

*

Слайд 64

Структура описания операции *

Структура описания операции

*

Слайд 65

Категории постусловий Создание или удаление экземпляра объекта Модификация атрибута экземпляра объекта Формирование или разрыв ассоциации *

Категории постусловий

Создание или удаление экземпляра объекта
Модификация атрибута экземпляра объекта
Формирование или разрыв

ассоциации

*

Слайд 66

Системные операции POS *

Системные операции POS

*

Слайд 67

Системные операции POS *

Системные операции POS

*

Слайд 68

*

*

Слайд 69

Модель проектирования Созданием концептуальной модели завершается анализ требований в рамках первой

Модель проектирования

Созданием концептуальной модели завершается анализ требований в рамках первой итерации
На

следующем этапе внимание фокусируется на разработке проектного решения, удовлетворяющего требованиям данной итерации, т.е. модели проектирования

*

Слайд 70

Концептуальные и программные классы Концептуальная модель содержит концептуальные классы с указанием

Концептуальные и программные классы

Концептуальная модель содержит концептуальные классы с указанием их

атрибутов
Модель проектирования содержит программные классы с указанием их атрибутов и методов

*

Слайд 71

*

*

Слайд 72

Распределение обязанностей Основной задачей этапа проектирования является построение логики взаимодействия объектов,

Распределение обязанностей

Основной задачей этапа проектирования является построение логики взаимодействия объектов, обеспечивающей

выполнение системных требований
Это достигается путем распределения обязанностей объектов

*

Слайд 73

Знания и действия Обязанность определяется как контракт объекта и делятся на

Знания и действия

Обязанность определяется как контракт объекта и делятся на
знания (наличие

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

*

Слайд 74

Реализация обязанностей Обязанности реализуются посредством методов программных классов Метод может реализовывать

Реализация обязанностей

Обязанности реализуются посредством методов программных классов
Метод может реализовывать обязанность самостоятельно,

либо во взаимодействии с методами других классов

*

Слайд 75

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

Диаграммы взаимодействия

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

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

*

Слайд 76

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

Шаблоны

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

принципы формулируются в виде шаблонов проектирования (design patterns)

*

Слайд 77

Шаблон Expert Проблема Каков наиболее общий принцип распределения обязанностей? Решение Назначить

Шаблон Expert

Проблема Каков наиболее общий принцип распределения обязанностей?
Решение Назначить обязанность классу,

владеющему информацией, необходимой для выполнения обязанности

*

Слайд 78

Формулировка обязанности Вычислить общую сумму продажи Какая информация нужна для выполнения

Формулировка обязанности

Вычислить общую сумму продажи
Какая информация нужна для выполнения этой обязанности?
стоимость

каждого вида товаров,
цену каждого вида товаров
Какой класс должен выполнять эту обязанность?

*

Слайд 79

Вычисление общей стоимости *

Вычисление общей стоимости

*

Слайд 80

Распределение обязанностей Класс Sale – эксперт для вычисления общей суммы продажи

Распределение обязанностей

Класс Sale – эксперт для вычисления общей суммы продажи
Класс Sales

LineItem– эксперт для вычисления промежуточной суммы элемента продажи
Класс Product Specification – эксперт для определения цены товара

*

Слайд 81

Диаграмма кооперации *

Диаграмма кооперации

*

Слайд 82

Создание программных объектов Объекты программных классов должны быть созданы, чтобы их

Создание программных объектов

Объекты программных классов должны быть созданы, чтобы их можно

было использовать
Проблема Какие классы должны отвечать за создание объектов классов Sale, Sales LineItem, Product Specification?

*

Слайд 83

Шаблон Creator Решение Назначить классу B создавать объекты класса A, если

Шаблон Creator

Решение Назначить классу B создавать объекты класса A, если выполняется

одно из условий:
Класс B агрегирует объекты A
Класс B содержит объекты A
Класс B записывает объекты A
Класс B активно использует объекты A
Класс B обладает данными для инициализации объектов класса A

*

Слайд 84

Шаблон Creator Под агрегацией классом B объектов класса A подразумевается, что

Шаблон Creator

Под агрегацией классом B объектов класса A подразумевается, что последние

являются составляющими частями объектов класса B
Если же объект класса B выступает лишь в роли контейнера для объектов класса A, то говорят, класс B содержит объекты класса A

*

Слайд 85

Выявление объекта-создателя *

Выявление объекта-создателя

*

Слайд 86

Шаблон Creator Определяет способ распределения обязанностей, связанный с процессом создания объектов

Шаблон Creator

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

– выявление объекта-создателя:
класс-контейнер
класс-регистратор
класс, владеющий информацией, необходимой при инициализации объекта

*

Слайд 87

Создание объектов SalesLineItem Класс Sale агрегирует объекты класса SalesLineItem и поэтому

Создание объектов SalesLineItem

Класс Sale агрегирует объекты класса SalesLineItem и поэтому является

хорошим кандидатом на роль создателя объектов этого класса

*

Слайд 88

Диаграмма последовательностей *

Диаграмма последовательностей

*

Слайд 89

Обеспечение низкого сцепления Необходимо создать объект Payment и связать его с

Обеспечение низкого сцепления

Необходимо создать объект Payment и связать его с объектом

Sale
Возможны два альтернативных пути:
объект Payment создается объектом Register, который затем уведомляет об этом объект Sale;
объект Payment создается объектом Sale, который получает соответствующее указание от объекта Register

*

Слайд 90

Два способа создания Payment *

Два способа создания Payment

*

Слайд 91

Шаблон Low Coupling Этот шаблон поддерживает независимость классов и слабое сцепление

Шаблон Low Coupling

Этот шаблон поддерживает независимость классов и слабое сцепление между

ними
В соответствии с данным шаблоном предпочтение следует отдать второму способу, т.к. при этом не возникает дополнительной связи между Register и Payment

*

Слайд 92

Шаблон Low Coupling Высокая степень сцепления объектов сама по себе не

Шаблон Low Coupling

Высокая степень сцепления объектов сама по себе не является

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

*

Слайд 93

Шаблон High Cohesion Проблема Как обеспечить управление сложностью? Решение Распределить обязанности

Шаблон High Cohesion

Проблема Как обеспечить управление сложностью?
Решение Распределить обязанности способом, обеспечивающим

высокую степень функциональной связности
Функциональная связность– это мера взаимосвязи обязанностей класса
Класс с низкой степенью связности выполняет много разнородных функций

*

Слайд 94

Два способа создания Payment *

Два способа создания Payment

*

Слайд 95

Шаблон High Cohesion Классы с высокой степенью связности просты в понимании,

Шаблон High Cohesion

Классы с высокой степенью связности просты в понимании, поддержке

и повторном использовании
Сцепление и связность взаимозависимы: неправильное сцепление порождает слабую связность, и наоборот

*

- Предыдущая
Проект внеурочной краеведческой деятельности по географии «Моя малая родина»
Следующая -
Dziecko

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

Кафедра медицинской биологии, микробиологии, вирусологии и иммунологии Возбудители анаэробных инфекций
Становление науки государственного управления
санитарное состояние природной среды человека
Принципы выделения частей речи в истории языкознания
Арийцы
Трансмісія бронетранспортера БТР-80
Конвейер команд
Презентация Осенний букет аппликация оригами
Роботи
тундра
Презентация "Использование нетрадиционных техник в рисовании" - скачать презентации по МХК
Презентация "Путешествие от барокко к классицизму 2" - скачать презентации по МХК
Материалдарды қысыммен өңдеу
Необходимое оборудование. Профессия фотограф
Презентация "Бизнес под ключ" - скачать презентации по Экономике
Agency of a Healthy Life AHL. Дорожная карта
Политическая система и политический режим
Кривая Филлипса. Выбор между безработицей и инфляцией. (Лекция 12)
ВЫБОР ПОТРЕБИТЕЛЯ И ФАКТОРЫ ВЛИЯЮЩИЕ НА НЕГО. Студентка группы ММ – 10 Абильтарова Лиля
Итоговый творческий проект «Набор для кумыса»
Инновационный процесс и инновационная деятельность
Роль информации в управлении
Prezentatsia_1
Саяси ғылымның даму тарихы және негізгі кезеңдері
Мои домашние питомцы – это попугаи
Адаптация высшего образования РФ к потребностям рынка труда: проблема достоверных сигналов Адаптация высшего образования РФ
К миру без войн
Грыжи живота
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть