Объектно-ориентированный подход к проектированию ИС

1. Объектно-ориентированныйподход к проектированию ИС

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

4. Object-Oriented Design—Мост между анализом и программированием • Проект представляет собой мост между требованиями пользователей и программированием новой системы • Object-oriented design – процесс посредством которого строятся подробные ОО модели • Также требуется (если помните) проектирование и моделирования пользовательского интерфейса, сети, системы управления, безопасности и базы данных

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

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

7. Диаграмма последовательности для корректировки Student

8. Пример диаграмм класса Student на этапах анализа и проектирования

9. Пример определения класса на Java для класса Student

10. Процессы и модели ОО проектирования • Диаграммы этапа анализа/требований • Варианты использования, описание прецедентов и диаграмма деятельностей (activity), диаграммы классов предметной области и диаграммы последовательностей (sequence) • Диаграммы этапа проектирования • Диаграммы взаимодействия и диаграммы пакетов • Диаграммы проекта классов – включают ОО классы, навигацию между классами, имена атрибутов и методов, а также свойства, необходимые для программирования

11. Соответствие моделей проекта с моделями анализа

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

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

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

15. Несколько основных принципов проектирования (Продолжение) • Связность (Coupling)– качественная мера того, насколько тесно в проектируемой диаграмме классы связаны • Количество стрелок навигации в диаграмме классов или сообщений в диаграмме последовательностей • Слабо связанные (Loosely coupled) – система легче понимается и поддерживается • Сцепление (Cohesion)– качественная мера согласованности функций внутри одного класса • Разделение ответственности (Separation of responsibility)– разделение слабо согласованного класса на несколько сильно согласованных классов • Сильно связанные классы – система легче понимается , поддерживается и многократно используется

16. Символы проекта классов • UML не различается в нотациях классов этапа моделирования предметной области и проектирования • Классы предметной области представляют концептуальные классы в среде пользователя • Диаграмма проекта класса конкретно определяет классы приложения • UML использует нотации стереотипов для классификации модели элементов по их характеристикам и назначению

17. Стандартные стереотипы проекта

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

19. Определяются связи • Принцип проектирования при котором один объект может ссылаться к другому объекту • Могут взаимодействовать друг с другом, отправляя сообщения

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

21. Нотация класса

22. Пример проекта класса Student

23. Процесс разработки начальной диаграммы проекта классов • Расширяется диаграмма модели предметной области • Конкретизируются атрибуты с информацией о типе и начальной информации • Подробное проектирование выполняется по прецедентам • Диаграммы взаимодействия выполняют навигацию по классам • Стрелки навигации изменяются соответствующим образом • К каждому классу добавляются сигнатуры методов

24. Разработка начальной диаграммы проекта классов (Продолжение) • Выбираются классы, связанные с прецедентом • Добавляется контроллер (controller) • Конкретизируются атрибуты • Видимость, тип, начальное значениеe, свойства • Устанавливается первоначальная видимость навигации • Направление отношения один-ко-многим обычно устанавливается от главного к подчиненному • Обязательные отношения обычно ориентируются от независимого объекта к зависимому (например, отношение между клиентом и заказом) • Когда объекту требуется информация от другого объекта, стрелки навигации указывает на сам объект или на его родителя в иерархии • Навигация может быть в двух направлениях (двунаправленная стрелка)

25. Начинается с модели диаграммы классов предметной области Связана с прецедентом “Look up item available”

26. Первоначальная диаграмма проекта RMO для прецедента Look Up Item Availability

27. Паттерны проектирования и контроллер прецедента • Паттерн проектирования- • Шаблон стандартного решения для требований проекта, который соответствует принципам хорошего дизайна • Шаблон контроллера прецедента • Требования проекта состоит в том, чтобы определить какой класс предметной области должен получать данные от пользователя для прецедента • Решение – в выборе класса, который будет использоваться как точка сбора для всех входящих сообщений для прецедента.Контроллер действует как посредник между внешним миром и внутренностью системы • Артифакт–класс, созданный дизайнером системы для обработки требуемых системных функций, например, такой как контроллер.

28. Понимание прецедентов и определение методов—Проектирование с диаграммами последовательности • Реализация прецедента производится через разработку диаграммы взаимодействия • Определяется какие объекты кооперируются путем передачи сообщений друг другу для выполнения прецедента • Диаграммы последовательностей и диаграммы коммуникаций представляют результаты проектных решений • Используются хорошо обоснованные принципы проектирования такие как связь (coupling), сцепление (cohesion), разделение ответственности

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

30. Проектирование диаграмм последовательностей • Диаграммы последовательностей используются для понимания взаимодействия объектов и документирования проектных решений • Документируются входы и выходы системы для одного прецедента или сценария • Фиксируется взаимодействие между системой и внешней средой, которая представлена актором • Входы являются сообщениями от актора системе • Выходы являются возвращаемыми сообщениями, показывающими данные

31. Диаграмма последовательности системы -System Sequence Diagram (SSD) для прецедента Look Up Item Availability

32. Первоначальная диаграмма последовательностей • Начинается с элементов SSD • Заменяется объект :Systemна контроллер прецедента (use case controller) • Добавляются другие объекты, которые должны быть включены в прецедент • Выбирается входное сообщение из прецедента • Добавляются все объекты, которые должны кооперироваться • Определяются другие сообщения, которые должны быть посланы • Какие объекты являются источниками и адресатами для каждого сообщения?

33. Объекты, включенные в Look Up Item Availability

34. Принципы разработки диаграммы последовательности для прецедента • Для каждого входного сообщения определяется внутреннее сообщение, которое является результатом этого входа • Для этого сообщения определяется назначение • Требуемая информация, класс назначения, класс источник и созданные в результате объекты • Еще раз проверяются все требуемые классы • Конкретизируются компоненты для каждого сообщения • Повторяемость, условия защиты, передаваемые параметры, возвращаемые значения

35. Пример первоначальной диаграммы последовательности для прецедента Look Up Item Availability

36. Допущения первоначальной диаграммы последовательности • Допущение идеальной технологии • В систему не включаются такие элементы управления как login/logout (пока) • Допущение идеальной памяти • Не беспокоиться о хранении объектов во внешней памяти (пока) • Предполагается, что объекты находятся в оперативной памяти и готовы к работе • Предположение об идеальном решении • Не беспокоиться об обработке исключительных ситуаций (пока) • Предполагается решение с отсутствием проблем реализации

37. Прецедент Maintain Product Information—Начинаем с SSD

38. Добавляем Controller и определяем классы предметной области и взаимодействие

39. Заменяется объект :SystemвSSD на контроллер и объекты предметной области

40. Первоначальная диаграмма последовательностей для прецедентаMaintain Product Information

41. Разработка многоуровневого проекта • В первоначальной диаграмме последовательности – контроллер прецедента плюс классы в предметной области • Добавляется уровень доступа–проект классов для доступа данных и для отделения взаимодействия с базой данных • Снимаются допущения идеальной памяти • Выполняется разделение ответственности • Добавляется уровень презентации – проект классов пользовательского интерфейса • Добавляются формы как оконные классы в диаграмму последовательности между актором и контроллером

42. Подходы к уровню доступа данных

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

44. Добавление уровня доступа к данным для прецедента Look Up Item Availability

45. Добавление уровня доступа к данным для прецедента Maintain Product Information

46. Проектирование уровня представления • Добавляются формы GUI или Web страницы между актором и контроллером для каждого прецедента • Минимизируется бизнес-логика, присоединенная к форме • Некоторые прецеденты требуют только одну форму; некоторые требуют несколько форм и диалоговых окон • Проект уровня представления концентрируется на высоко-уровневой последовательности диалога в виде форм/страниц

47. <<View>> Форма ProductQueryдобавляется для прецедента Look Up Item Availability

48. Полный прецедент Look Up Item Availabilityс уровнем презентации

49. ProductWindowи MsgWindowдля прецедента Maintain Product Information

50. Полный прецедент Maintain Product Informationс уровнем презентации