О БЪЕКТНО - ОРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС. - презентация

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

2 В ВЕДЕНИЕ Основное внимание уделяется разработке подробных моделей объектно-ориентированного проекта системы Модели используются программистами для кодирования системы Две наиболее важные модели проекта: диаграммы классов и диаграммы взаимодействия (диаграммы последовательностей и кооперативные диаграммы) Разрабатываются диаграммы классов для реализации бизнес-правил (controller), интерфейса (view) и уровень доступа к базе данных (Model) Диаграммы взаимодействия расширяют диаграммы последовательностей 2

3 3

4 O BJECT -O RIENTED D ESIGNМ ОСТ МЕЖДУ АНАЛИЗОМ И ПРОГРАММИРОВАНИЕМ Проект представляет собой мост между требованиями пользователей и программированием новой системы Object-oriented design – процесс посредством которого строятся подробные ОО модели Также требуется (если помните) проектирование и моделирования пользовательского интерфейса, сети, системы управления, безопасности и базы данных 4

5 ОО ПРИЛОЖЕНИЯ ОО приложение - набор объектов, которые кооперируются для достижения результата Объект содержит программную логику и необходимые атрибуты в одном месте Объекты посылают друг другу сообщения и сотрудничают для поддержки функций основной программы Проектировщик OO систем обеспечивает необходимые спецификации для программистов Состав: Проект диаграммы классов, диаграммы взаимодействия и некоторые диаграммы состояния машины 5

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

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

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

9 П РИМЕР ОПРЕДЕЛЕНИЯ КЛАССА НА J AVA ДЛЯ КЛАССА S TUDENT 9

10 П РОЦЕССЫ И МОДЕЛИ ОО ПРОЕКТИРОВАНИЯ Диаграммы этапа анализа/требований Варианты использования, описание прецедентов и диаграмма деятельностей (activity), диаграммы классов предметной области и диаграммы последовательностей (sequence) Диаграммы этапа проектирования Диаграммы взаимодействия и диаграммы пакетов Диаграммы проекта классов – включают ОО классы, навигацию между классами, имена атрибутов и методов, а также свойства, необходимые для программирования 10

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

12 И ТЕРАТИВНЫЙ ПРОЦЕСС OO ПРОЕКТИРОВАНИЯ : ШАГИ ПРОЕКТИРОВАНИЯ 12 Реализация прецедента – спецификация подробной обработки системы для каждого прецедента. Весь процесс проектирования: 1. Разрабатывается первоначальная диаграмма проекта класса, показывающая связи 2. Проектируется каждый прецедент путем создания диаграммы последовательности (а) Разрабатывается первоначальные диаграммы последовательностей (б) Разрабатываются много-уровневые диаграммы последовательностей 3. Изменяется проект классов добавлением сигнатур и информацией о связях 4. Принимается решение о разделении на пакеты соответствующим образом 12

13 П РОЕКТИРУЮТСЯ КЛАССЫ, ВЗАИМОДЕЙСТВИЕ И ПРОЦЕССЫ Проектируются диаграммы классов и подробные диаграммы взаимодействия Классы, использующие входы и выходы друг друга разрабатываются параллельно Диаграмма первоначального проекта класса основывается на модели предметной области и принципах проектирования системы Первоначальная диаграмма последовательности для прецедента расширяется из диаграммы последовательности системы - system sequence diagram (SSD) Показывает взаимодействующие объекты Диаграмма последовательности разрабатывается послойно Бизнес-логика, доступ к данным и представление Диаграмма классов изменяется на основе диаграммы последовательности 13

14 Н ЕКОТОРЫЕ ОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ Инкапсуляция (Encapsulation) – каждый объект представляет собой замкнутый компонент, который включает данные и методы, имеющие доступ к данным Повторное использование объектов (Object reuse) – проектировщики многократно используют одни и те же классы Сокрытие информации (Information hiding) – данные, связанные с объектом не видимы за пределами объекта Защита от изменений (Protection from variations) – часть системы, изменения которой мало вероятны отделяется от изменяемой части Опосредованность (Indirection) – класс помещается между двумя промежуточными классами для того, чтобы разъединить их, но оставить связь между ними 14

15 Н ЕСКОЛЬКО ОСНОВНЫХ ПРИНЦИПОВ ПРОЕКТИРОВАНИЯ (П РОДОЛЖЕНИЕ ) Связность (Coupling) – качественная мера того, насколько тесно в проектируемой диаграмме классы связаны Количество стрелок навигации в диаграмме классов или сообщений в диаграмме последовательностей Слабо связанные (Loosely coupled) – система легче понимается и поддерживается Сцепление (Cohesion) – качественная мера согласованности функций внутри одного класса Разделение ответственности (Separation of responsibility) – разделение слабо согласованного класса на несколько сильно согласованных классов Сильно связанные классы – система легче понимается, поддерживается и многократно используется 15

16 С ИМВОЛЫ ПРОЕКТА КЛАССОВ UML не различается в нотациях классов этапа моделирования предметной области и проектирования Классы предметной области представляют концептуальные классы в среде пользователя Диаграмма проекта класса конкретно определяет классы приложения UML использует нотации стереотипов для классификации модели элементов по их характеристикам и назначению 16

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

18 С ТАНДАРТНЫЕ КЛАССЫ ПРОЕКТА Сущность (Entity) – идентифицируются в проекте для классов предметной области. Это постоянный класс (Persistent class) – он существуют после завершения работы системы Управление (Control) – класс-посредник между граничными классами и классами сущностями, между уровнем представления и моделью предметной области Граница (Boundary) – проектируется для представления системы на ее границе пользователю Пользовательский интерфейс и оконные классы Доступ данных (Data access) – обменивается данными с базой данных. 18

19 О ПРЕДЕЛЯЮТСЯ СВЯЗИ 19 u Принцип проектирования при котором один объект может ссылаться к другому объекту l Могут взаимодействовать друг с другом, отправляя сообщения

20 Н ОТАЦИЯ ПРОЕКТА КЛАССА Имя (Name) – имя класса и информация стереотипа (stereotype information) Видимость атрибута (Attribute visibility) (private или public) – имя атрибута, тип, начальное значение, свойство Сигнатура метода (Method signature) – информация, необходимая для вызова метода Видимость метода, имя метода, тип (возвращаемый параметр), список параметров метода (входящие аргументы) Перегружаемый метод– метод с таким же именем, но с альтернативным списком параметров Метод уровня класса – метод, связанный с классом, а не с объектом (static или shared метод), отмечается подчеркиванием 20

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

22 П РИМЕР ПРОЕКТА КЛАССА S TUDENT 22

23 П РОЦЕСС РАЗРАБОТКИ НАЧАЛЬНОЙ ДИАГРАММЫ ПРОЕКТА КЛАССОВ Расширяется диаграмма модели предметной области Конкретизируются атрибуты с информацией о типе и начальной информации Подробное проектирование выполняется по прецедентам Диаграммы взаимодействия выполняют навигацию по классам Стрелки навигации изменяются соответствующим образом К каждому классу добавляются сигнатуры методов 23

24 Р АЗРАБОТКА НАЧАЛЬНОЙ ДИАГРАММЫ ПРОЕКТА КЛАССОВ (П РОДОЛЖЕНИЕ ) Выбираются классы, связанные с прецедентом Добавляется контроллер (controller) Конкретизируются атрибуты Видимость, тип, начальное значениеe, свойства Устанавливается первоначальная видимость навигации Направление отношения один-ко-многим обычно устанавливается от главного к подчиненному Обязательные отношения обычно ориентируются от независимого объекта к зависимому (например, отношение между клиентом и заказом) Когда объекту требуется информация от другого объекта, стрелки навигации указывает на сам объект или на его родителя в иерархии Навигация может быть в двух направлениях (двунаправленная стрелка) 24

25 Н АЧИНАЕТСЯ С МОДЕЛИ ДИАГРАММЫ КЛАССОВ ПРЕДМЕТНОЙ ОБЛАСТИ 25 Связана с прецедентом Look up item available

26 П ЕРВОНАЧАЛЬНАЯ ДИАГРАММА ПРОЕКТА RMO ДЛЯ ПРЕЦЕДЕНТА L OOK U P I TEM A VAILABILITY 26

27 П АТТЕРНЫ ПРОЕКТИРОВАНИЯ И КОНТРОЛЛЕР ПРЕЦЕДЕНТА Паттерн проектирования- Шаблон стандартного решения для требований проекта, который соответствует принципам хорошего дизайна Шаблон контроллера прецедента Требования проекта состоит в том, чтобы определить какой класс предметной области должен получать данные от пользователя для прецедента Решение – в выборе класса, который будет использоваться как точка сбора для всех входящих сообщений для прецедента. Контроллер действует как посредник между внешним миром и внутренностью системы Артифакт – класс, созданный дизайнером системы для обработки требуемых системных функций, например, такой как контроллер. 27

28 П ОНИМАНИЕ ПРЕЦЕДЕНТОВ И ОПРЕДЕЛЕНИЕ МЕТОДОВ П РОЕКТИРОВАНИЕ С ДИАГРАММАМИ ПОСЛЕДОВАТЕЛЬНОСТИ Реализация прецедента производится через разработку диаграммы взаимодействия Определяется какие объекты кооперируются путем передачи сообщений друг другу для выполнения прецедента Диаграммы последовательностей и диаграммы коммуникаций представляют результаты проектных решений Используются хорошо обоснованные принципы проектирования такие как связь (coupling), сцепление (cohesion), разделение ответственности 28

29 О ТВЕТСТВЕННОСТЬ ОБЪЕКТА Объекты отвечают за обработку в системе Ответственность включает знание (knowing) и действие (doing) Знания о собственных данных объекта и других классов объектов, с которыми они кооперируются для выполнения прецедентов Выполнение действий для содействия в выполнении прецедента Прием и обработка сообщений Создание новых объектов, требуемых для выполнения прецедента Проектирование означает назначение ответственности для соответствующих классов, основываясь на принципах проектирования и использовании шаблонов проектирования 29

30 П РОЕКТИРОВАНИЕ ДИАГРАММ ПОСЛЕДОВАТЕЛЬНОСТЕЙ Диаграммы последовательностей используются для понимания взаимодействия объектов и документирования проектных решений Документируются входы и выходы системы для одного прецедента или сценария Фиксируется взаимодействие между системой и внешней средой, которая представлена актором Входы являются сообщениями от актора системе Выходы являются возвращаемыми сообщениями, показывающими данные 30

31 Д ИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ СИСТЕМЫ - S YSTEM S EQUENCE D IAGRAM (SSD) ДЛЯ ПРЕЦЕДЕНТА L OOK U P I TEM A VAILABILITY 31

32 П ЕРВОНАЧАЛЬНАЯ ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ Начинается с элементов SSD Заменяется объект :System на контроллер прецедента (use case controller) Добавляются другие объекты, которые должны быть включены в прецедент Выбирается входное сообщение из прецедента Добавляются все объекты, которые должны кооперироваться Определяются другие сообщения, которые должны быть посланы Какие объекты являются источниками и адресатами для каждого сообщения? 32

33 О БЪЕКТЫ, ВКЛЮЧЕННЫЕ В L OOK U P I TEM A VAILABILITY 33

34 П РИНЦИПЫ РАЗРАБОТКИ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ ДЛЯ ПРЕЦЕДЕНТА Для каждого входного сообщения определяется внутреннее сообщение, которое является результатом этого входа Для этого сообщения определяется назначение Требуемая информация, класс назначения, класс источник и созданные в результате объекты Еще раз проверяются все требуемые классы Конкретизируются компоненты для каждого сообщения Повторяемость, условия защиты, передаваемые параметры, возвращаемые значения 34

35 П РИМЕР ПЕРВОНАЧАЛЬНОЙ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ ДЛЯ ПРЕЦЕДЕНТА L OOK U P I TEM A VAILABILITY 35

36 Д ОПУЩЕНИЯ ПЕРВОНАЧАЛЬНОЙ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ Допущение идеальной технологии В систему не включаются такие элементы управления как login/logout (пока) Допущение идеальной памяти Не беспокоиться о хранении объектов во внешней памяти (пока) Предполагается, что объекты находятся в оперативной памяти и готовы к работе Предположение об идеальном решении Не беспокоиться об обработке исключительных ситуаций (пока) Предполагается решение с отсутствием проблем реализации 36

37 П РЕЦЕДЕНТ M AINTAIN P RODUCT I NFORMATION Н АЧИНАЕМ С SSD 37

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

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

40 П ЕРВОНАЧАЛЬНАЯ ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ ДЛЯ ПРЕЦЕДЕНТА M AINTAIN P RODUCT I NFORMATION 40

41 Р АЗРАБОТКА МНОГОУРОВНЕВОГО ПРОЕКТА В первоначальной диаграмме последовательности – контроллер прецедента плюс классы в предметной области Добавляется уровень доступа–проект классов для доступа данных и для отделения взаимодействия с базой данных Снимаются допущения идеальной памяти Выполняется разделение ответственности Добавляется уровень презентации – проект классов пользовательского интерфейса Добавляются формы как оконные классы в диаграмму последовательности между актором и контроллером 41

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

43 П ОДХОДЫ К УРОВНЮ ДОСТУПА ДАННЫХ (П РОДОЛЖЕНИЕ ) Создается класс доступа к данным для каждого класса предметной области CustomerDA добавляется для Customer Утверждения соединения с базой данных и SQL – утверждения выделяются в класс доступа к данным. Классы предметной области ничего не должны знать о структуре или реализации базы данных Подход (a) – контроллер создает экземпляр нового клиента (customer) aC; новый экземпляр запрашивает класс DA заполнить его атрибуты, читая из базы данных Подход (b) – контроллер запрашивает класс DA создать экземпляр нового клиента (customer) aC; Класс DA читает из базы данных и передает значения в конструктор Следующие примеры используют этот подход. 43

44 Д ОБАВЛЕНИЕ УРОВНЯ ДОСТУПА К ДАННЫМ ДЛЯ ПРЕЦЕДЕНТА L OOK U P I TEM A VAILABILITY 44

45 Д ОБАВЛЕНИЕ УРОВНЯ ДОСТУПА К ДАННЫМ ДЛЯ ПРЕЦЕДЕНТА M AINTAIN P RODUCT I NFORMATION 45

46 П РОЕКТИРОВАНИЕ УРОВНЯ ПРЕДСТАВЛЕНИЯ Добавляются формы GUI или Web страницы между актором и контроллером для каждого прецедента Минимизируется бизнес-логика, присоединенная к форме Некоторые прецеденты требуют только одну форму; некоторые требуют несколько форм и диалоговых окон Проект уровня представления концентрируется на высоко-уровневой последовательности диалога в виде форм/страниц 46

47 > Ф ОРМА P RODUCT Q UERY ДОБАВЛЯЕТСЯ ДЛЯ ПРЕЦЕДЕНТА L OOK U P I TEM A VAILABILITY 47

48 П ОЛНЫЙ ПРЕЦЕДЕНТ L OOK U P I TEM A VAILABILITY С УРОВНЕМ ПРЕЗЕНТАЦИИ 48

49 P RODUCT W INDOW И M SG W INDOW ДЛЯ ПРЕЦЕДЕНТА M AINTAIN P RODUCT I NFORMATION 49

50 П ОЛНЫЙ ПРЕЦЕДЕНТ M AINTAIN P RODUCT I NFORMATION С УРОВНЕМ ПРЕЗЕНТАЦИИ 50

51 П РОЕКТИРОВАНИЕ КООПЕРАТИВНЫХ ДИАГРАММ Кооперативные диаграммы и диаграммы последовательности Обе являются диаграммами взаимодействия Обе фиксируют одну и ту же информацию Процесс проектирования одинаков для обоих Используемая модель зависит от предпочтений проектировщика Диаграмма последовательностей– описание прецедента и диалоги следуют в последовательности шагов Диаграммы связи– акцентируются на сцеплении 51

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

53 К ООПЕРАТИВНАЯ ДИАГРАММА ДЛЯ ПРЕЦЕДЕНТА L OOK U P I TEM A VAILABILITY 53

54 П РЕЦЕДЕНТ L OOK U P I TEM A VAILABILITY, ИСПОЛЬЗУЮЩИЙ СПЕЦИАЛЬНЫЕ ( I CONIC ) СИМВОЛЫ 54

55 З АМЕЩЕНИЕ ДИАГРАММЫ КЛАССОВ ПРОЕКТА Проект диаграммы классов разрабатывается для каждого уровня Новые классы для уровня представления и уровня доступа к данным Новые классы для контроллера предметной области Диаграммы последовательности добавляют методы Методы конструктора Методы get и set Специальные методы прецедента 55

56 П РОЕКТ КЛАССА С СИГНАТУРАМИ МЕТОДОВ ДЛЯ КЛАССА P RODUCT I TEM 56

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

58 Д ИАГРАММА ПАКЕТОВ СТРУКТУРИРОВАНИЕ ОСНОВНЫХ КОМПОНЕНТ Высокоуровневая диаграмма UML для объединения классов в связанные группы Идентифицируются главные компоненты системы и зависимости между ними Определяются окончательные части программы для каждого уровня Представление, бизнес-правила, доступ к данным Система может разделяться на подсистемы и показывать вложенность внутри пакета 58

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

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

61 И ТОГИ OOD является мостом между требованиями пользователей (в моделях анализа) и целевой системой (построенной в среде программирования) Проект системы строится на основе прецедентов, проектов диаграмм классов и диаграмм последовательностей Диаграммы бизнес-классов преобразуются в диаграммы проекта класса Диаграммы последовательностей являются расширениями диаграмм последовательностей системы - system sequence diagrams (SSDs) 61

62 И ТОГИ ( ПРОДОЛЖЕНИЕ ) Должны применяться принципы ОО проектирования Инкапсуляция– поля данных размещаются в класс вместе с методами обработки этих данных Low coupling – связность между классами High cohesion – сущность индивидуального класса Защита от изменения– части системы, изменения которых маловероятно отделяются от вероятно изменяемых Опосредованность– промежуточный класс помещается между двумя классами, чтобы разъединить их, но оставить связь между ними Трех-уровневый проект используется для улучшения сопровождения 62