ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС

ВВЕДЕНИЕ

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

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

Две наиболее важные модели проекта: диаграммы классов и диаграммы взаимодействия (диаграммы последовательностей и кооперативные диаграммы)

Разрабатываются диаграммы классов для реализации бизнес-правил (controller), интерфейса (view) и уровень доступа к базе данных (Model)

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

3

OBJECT-ORIENTED DESIGN—МОСТ МЕЖДУ АНАЛИЗОМ И ПРОГРАММИРОВАНИЕМ

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

Object-oriented design – процесс посредством которого строятся подробные ОО модели

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

4

ОО ПРИЛОЖЕНИЯ

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

Объект содержит программную логику и необходимые атрибуты в одном месте

Объекты посылают друг другу сообщения и сотрудничают для поддержки функций основной программы

Проектировщик OO систем обеспечивает необходимые спецификации для программистов Состав: Проект диаграммы классов, диаграммы

взаимодействия и некоторые диаграммы состояния машины 5

6

ОО трех-уровневое приложение

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ ДЛЯ КОРРЕКТИРОВКИ STUDENT

7

ПРИМЕР ДИАГРАММ КЛАССА STUDENT НА ЭТАПАХ АНАЛИЗА И ПРОЕКТИРОВАНИЯ

8

ПРИМЕР ОПРЕДЕЛЕНИЯ КЛАССА НА JAVA ДЛЯ КЛАССА STUDENT

9

ПРОЦЕССЫ И МОДЕЛИ ОО ПРОЕКТИРОВАНИЯ

Диаграммы этапа анализа/требований Варианты использования, описание

прецедентов и диаграмма деятельностей (activity), диаграммы классов предметной области и диаграммы последовательностей (sequence)

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

пакетов Диаграммы проекта классов – включают ОО

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

СООТВЕТСТВИЕ МОДЕЛЕЙ ПРОЕКТА С МОДЕЛЯМИ АНАЛИЗА

11

ИТЕРАТИВНЫЙ ПРОЦЕСС OO ПРОЕКТИРОВАНИЯ: ШАГИ ПРОЕКТИРОВАНИЯ

12

Реализация прецедента – спецификация подробной обработки системы для каждого прецедента.

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

12

ПРОЕКТИРУЮТСЯ КЛАССЫ, ВЗАИМОДЕЙСТВИЕ И ПРОЦЕССЫ Проектируются диаграммы классов и

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

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

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

Первоначальная диаграмма последовательности для прецедента расширяется из диаграммы последовательности системы - system sequence diagram (SSD) Показывает взаимодействующие объекты

Диаграмма последовательности разрабатывается послойно Бизнес-логика, доступ к данным и

представление Диаграмма классов изменяется на основе

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

НЕКОТОРЫЕ ОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ

Инкапсуляция (Encapsulation) – каждый объект представляет собой замкнутый компонент, который включает данные и методы, имеющие доступ к данным

Повторное использование объектов (Object reuse) – проектировщики многократно используют одни и те же классы

Сокрытие информации (Information hiding) – данные, связанные с объектом не видимы за пределами объекта

Защита от изменений (Protection from variations) – часть системы, изменения которой мало вероятны отделяется от изменяемой части

Опосредованность (Indirection) – класс помещается между двумя промежуточными классами для того, чтобы разъединить их, но оставить связь между ними

14

НЕСКОЛЬКО ОСНОВНЫХ ПРИНЦИПОВ ПРОЕКТИРОВАНИЯ (ПРОДОЛЖЕНИЕ) Связность (Coupling) – качественная мера того,

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

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

Слабо связанные (Loosely coupled) – система легче понимается и поддерживается

Сцепление (Cohesion) – качественная мера согласованности функций внутри одного класса Разделение ответственности (Separation of

responsibility) – разделение слабо согласованного класса на несколько сильно согласованных классов

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

15

СИМВОЛЫ ПРОЕКТА КЛАССОВ UML не различается в нотациях классов этапа

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

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

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

UML использует нотации стереотипов для классификации модели элементов по их характеристикам и назначению

16

СТАНДАРТНЫЕ СТЕРЕОТИПЫ ПРОЕКТА

17

СТАНДАРТНЫЕ КЛАССЫ ПРОЕКТА

Сущность (Entity) – идентифицируются в проекте для классов предметной области. Это постоянный класс (Persistent class) – он

существуют после завершения работы системы Управление (Control) – класс-посредник

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

Граница (Boundary) – проектируется для представления системы на ее границе пользователю Пользовательский интерфейс и оконные классы

Доступ данных (Data access) – обменивается данными с базой данных.

18

ОПРЕДЕЛЯЮТСЯ СВЯЗИ

19

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

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

НОТАЦИЯ ПРОЕКТА КЛАССА

Имя (Name) – имя класса и информация стереотипа (stereotype information)

Видимость атрибута (Attribute visibility) (private или public) – имя атрибута, тип, начальное значение, свойство

Сигнатура метода (Method signature) – информация , необходимая для вызова метода Видимость метода, имя метода, тип

(возвращаемый параметр), список параметров метода (входящие аргументы)

Перегружаемый метод– метод с таким же именем, но с альтернативным списком параметров

Метод уровня класса – метод, связанный с классом, а не с объектом (static или shared метод), отмечается подчеркиванием 20

НОТАЦИЯ КЛАССА

21

ПРИМЕР ПРОЕКТА КЛАССА STUDENT

22

ПРОЦЕСС РАЗРАБОТКИ НАЧАЛЬНОЙ ДИАГРАММЫ ПРОЕКТА КЛАССОВ

Расширяется диаграмма модели предметной области Конкретизируются атрибуты с информацией о типе

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

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

по классам Стрелки навигации изменяются соответствующим

образом К каждому классу добавляются сигнатуры методов

23

РАЗРАБОТКА НАЧАЛЬНОЙ ДИАГРАММЫ ПРОЕКТА КЛАССОВ (ПРОДОЛЖЕНИЕ)

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

Добавляется контроллер (controller) Конкретизируются атрибуты

Видимость, тип, начальное значениеe, свойства Устанавливается первоначальная

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

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

от независимого объекта к зависимому (например, отношение между клиентом и заказом)

Когда объекту требуется информация от другого объекта, стрелки навигации указывает на сам объект или на его родителя в иерархии

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

24

НАЧИНАЕТСЯ С МОДЕЛИ ДИАГРАММЫ КЛАССОВ ПРЕДМЕТНОЙ ОБЛАСТИ

25

Связана с прецедентом “Look up item available”

ПЕРВОНАЧАЛЬНАЯ ДИАГРАММА ПРОЕКТА RMO ДЛЯ ПРЕЦЕДЕНТА LOOK UP ITEM AVAILABILITY

26

ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ И КОНТРОЛЛЕР ПРЕЦЕДЕНТА Паттерн проектирования-

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

Шаблон контроллера прецедента Требования проекта состоит в том, чтобы

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

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

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

27

ПОНИМАНИЕ ПРЕЦЕДЕНТОВ И ОПРЕДЕЛЕНИЕ МЕТОДОВ —ПРОЕКТИРОВАНИЕ С ДИАГРАММАМИ ПОСЛЕДОВАТЕЛЬНОСТИ

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

Определяется какие объекты кооперируются путем передачи сообщений друг другу для выполнения прецедента

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

Используются хорошо обоснованные принципы проектирования такие как связь (coupling), сцепление (cohesion), разделение ответственности

28

ОТВЕТСТВЕННОСТЬ ОБЪЕКТА

Объекты отвечают за обработку в системе Ответственность включает знание (knowing)

и действие (doing) Знания о собственных данных объекта и

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

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

выполнения прецедента Проектирование означает назначение

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

29

ПРОЕКТИРОВАНИЕ ДИАГРАММ ПОСЛЕДОВАТЕЛЬНОСТЕЙ

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

Документируются входы и выходы системы для одного прецедента или сценария

Фиксируется взаимодействие между системой и внешней средой, которая представлена актором

Входы являются сообщениями от актора системе

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

30

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ СИСТЕМЫ -SYSTEM SEQUENCE DIAGRAM (SSD) ДЛЯ ПРЕЦЕДЕНТА LOOK UP ITEM AVAILABILITY

31

ПЕРВОНАЧАЛЬНАЯ ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ Начинается с элементов SSD Заменяется объект :System на

контроллер прецедента (use case controller)

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

прецедента Добавляются все объекты, которые должны

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

которые должны быть посланы Какие объекты являются источниками и

адресатами для каждого сообщения?32

ОБЪЕКТЫ, ВКЛЮЧЕННЫЕ В LOOK UP ITEM AVAILABILITY

33

ПРИНЦИПЫ РАЗРАБОТКИ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ ДЛЯ ПРЕЦЕДЕНТА

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

источник и созданные в результате объекты Еще раз проверяются все требуемые классы

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

параметры, возвращаемые значения

34

ПРИМЕР ПЕРВОНАЧАЛЬНОЙ ДИАГРАММЫ

ПОСЛЕДОВАТЕЛЬНОСТИ ДЛЯ ПРЕЦЕДЕНТА

LOOK UP ITEM AVAILABILITY

35

ДОПУЩЕНИЯ ПЕРВОНАЧАЛЬНОЙ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ Допущение идеальной технологии

В систему не включаются такие элементы управления как login/logout (пока)

Допущение идеальной памяти Не беспокоиться о хранении объектов во

внешней памяти (пока) Предполагается, что объекты находятся в

оперативной памяти и готовы к работе Предположение об идеальном решении

Не беспокоиться об обработке исключительных ситуаций (пока)

Предполагается решение с отсутствием проблем реализации 36

ПРЕЦЕДЕНТ MAINTAIN PRODUCT INFORMATION— НАЧИНАЕМ С SSD

37

ДОБАВЛЯЕМ CONTROLLER И ОПРЕДЕЛЯЕМ КЛАССЫ ПРЕДМЕТНОЙ ОБЛАСТИ И ВЗАИМОДЕЙСТВИЕ

38

ЗАМЕНЯЕТСЯ ОБЪЕКТ :SYSTEM В SSD НА КОНТРОЛЛЕР И ОБЪЕКТЫ ПРЕДМЕТНОЙ ОБЛАСТИ

39

ПЕРВОНАЧАЛЬНАЯ ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ ДЛЯ ПРЕЦЕДЕНТА MAINTAIN PRODUCT INFORMATION

40

РАЗРАБОТКА МНОГОУРОВНЕВОГО ПРОЕКТА

В первоначальной диаграмме последовательности – контроллер прецедента плюс классы в предметной области

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

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

диаграмму последовательности между актором и контроллером 41

ПОДХОДЫ К УРОВНЮ ДОСТУПА ДАННЫХ

42

ПОДХОДЫ К УРОВНЮ ДОСТУПА ДАННЫХ (ПРОДОЛЖЕНИЕ)

Создается класс доступа к данным для каждого класса предметной области CustomerDA добавляется для Customer Утверждения соединения с базой данных и SQL –

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

структуре или реализации базы данных Подход (a) – контроллер создает экземпляр

нового клиента (customer) aC; новый экземпляр запрашивает класс DA заполнить его атрибуты, читая из базы данных

Подход (b) – контроллер запрашивает класс DA создать экземпляр нового клиента (customer) aC; Класс DA читает из базы данных и передает значения в конструктор Следующие примеры используют этот подход. 43

ДОБАВЛЕНИЕ УРОВНЯ ДОСТУПА К ДАННЫМ ДЛЯ ПРЕЦЕДЕНТА LOOK UP ITEM AVAILABILITY

44

ДОБАВЛЕНИЕ УРОВНЯ ДОСТУПА К ДАННЫМ ДЛЯ ПРЕЦЕДЕНТА MAINTAIN PRODUCT INFORMATION

45

ПРОЕКТИРОВАНИЕ УРОВНЯ ПРЕДСТАВЛЕНИЯ

Добавляются формы GUI или Web страницы между актором и контроллером для каждого прецедента Минимизируется бизнес-логика,

присоединенная к форме Некоторые прецеденты требуют только

одну форму; некоторые требуют несколько форм и диалоговых окон

Проект уровня представления концентрируется на высоко-уровневой последовательности диалога в виде форм/страниц 46

<<VIEW>> ФОРМА PRODUCTQUERY ДОБАВЛЯЕТСЯ ДЛЯ ПРЕЦЕДЕНТА

LOOK UP ITEM AVAILABILITY

47

ПОЛНЫЙ ПРЕЦЕДЕНТ LOOK UP ITEM AVAILABILITY С УРОВНЕМ ПРЕЗЕНТАЦИИ

48

PRODUCTWINDOW И MSGWINDOW ДЛЯ ПРЕЦЕДЕНТА MAINTAIN PRODUCT INFORMATION

49

ПОЛНЫЙ ПРЕЦЕДЕНТ MAINTAIN PRODUCT INFORMATION С УРОВНЕМ ПРЕЗЕНТАЦИИ

50

ПРОЕКТИРОВАНИЕ КООПЕРАТИВНЫХ ДИАГРАММ

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

Обе являются диаграммами взаимодействия

Обе фиксируют одну и ту же информацию

Процесс проектирования одинаков для обоих

Используемая модель зависит от предпочтений проектировщика

Диаграмма последовательностей– описание прецедента и диалоги следуют в последовательности шагов

Диаграммы связи– акцентируются на сцеплении

51

СИМВОЛЫ КООПЕРАТИВНОЙ ДИАГРАММЫ

52

КООПЕРАТИВНАЯ ДИАГРАММА ДЛЯ ПРЕЦЕДЕНТА LOOK UP ITEM AVAILABILITY

53

ПРЕЦЕДЕНТ LOOK UP ITEM AVAILABILITY, ИСПОЛЬЗУЮЩИЙ СПЕЦИАЛЬНЫЕ (ICONIC) СИМВОЛЫ

54

ЗАМЕЩЕНИЕ ДИАГРАММЫ КЛАССОВ ПРОЕКТА

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

уровня доступа к данным Новые классы для контроллера предметной

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

добавляют методы Методы конструктора Методы get и set Специальные методы прецедента

55

ПРОЕКТ КЛАССА С СИГНАТУРАМИ МЕТОДОВ ДЛЯ КЛАССА PRODUCTITEM

56

ИЗМЕНЕННАЯ ДИАГРАММА КЛАССОВ ДЛЯ УРОВНЯ ПРЕДМЕТНОЙ ОБЛАСТИ

57

ДИАГРАММА ПАКЕТОВ — СТРУКТУРИРОВАНИЕ ОСНОВНЫХ КОМПОНЕНТ

Высокоуровневая диаграмма UML для объединения классов в связанные группы

Идентифицируются главные компоненты системы и зависимости между ними

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

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

58

НЕПОЛНАЯ ДИАГРАММА ПАКЕТОВ ПРОЕКТА ТРЕХ-УРОВНЕВОГО RMO

59

ПАКЕТЫ ПОДСИСТЕМ RMO

60

ИТОГИ OOD является мостом между

требованиями пользователей (в моделях анализа) и целевой системой (построенной в среде программирования)

Проект системы строится на основе прецедентов, проектов диаграмм классов и диаграмм последовательностей

Диаграммы бизнес-классов преобразуются в диаграммы проекта класса

Диаграммы последовательностей являются расширениями диаграмм последовательностей системы - system sequence diagrams (SSDs)

61

ИТОГИ (ПРОДОЛЖЕНИЕ)

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

класс вместе с методами обработки этих данных

Low coupling – связность между классами High cohesion – сущность индивидуального

класса Защита от изменения– части системы,

изменения которых маловероятно отделяются от вероятно изменяемых

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

Трех-уровневый проект используется для улучшения сопровождения

62