slide1
Download
Skip this Video
Download Presentation
Объектно-ориентированный подход к проектированию ИС

Loading in 2 Seconds...

play fullscreen
1 / 62

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


  • 217 Views
  • Uploaded on

Объектно-ориентированный подход к проектированию ИС. Введение. Основное внимание уделяется разработке подробных моделей объектно-ориентированного проекта системы Модели используются программистами для кодирования системы

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

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


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2
Введение
  • Основное внимание уделяется разработке подробных моделей объектно-ориентированного проекта системы
  • Модели используются программистами для кодирования системы
  • Две наиболее важные модели проекта: диаграммы классов и диаграммы взаимодействия (диаграммы последовательностей и кооперативные диаграммы)
  • Разрабатываются диаграммы классов для реализации бизнес-правил (controller), интерфейса (view) и уровень доступа к базе данных (Model)
  • Диаграммы взаимодействия расширяют диаграммы последовательностей
object oriented design
Object-Oriented Design—Мост между анализом и программированием
  • Проект представляет собой мост между требованиями пользователей и программированием новой системы
  • Object-oriented design – процесс посредством которого строятся подробные ОО модели
  • Также требуется (если помните) проектирование и моделирования пользовательского интерфейса, сети, системы управления, безопасности и базы данных
slide5
ОО приложения
  • ОО приложение - набор объектов, которые кооперируются для достижения результата
  • Объект содержит программную логику и необходимые атрибуты в одном месте
  • Объекты посылают друг другу сообщения и сотрудничают для поддержки функций основной программы
  • Проектировщик OO систем обеспечивает необходимые спецификации для программистов
    • Состав: Проект диаграммы классов, диаграммы взаимодействия и некоторые диаграммы состояния машины
student
Диаграмма последовательности для корректировки Student
student1
Пример диаграмм класса Student на этапах анализа и проектирования
slide10
Процессы и модели ОО проектирования
  • Диаграммы этапа анализа/требований
    • Варианты использования, описание прецедентов и диаграмма деятельностей (activity), диаграммы классов предметной области и диаграммы последовательностей (sequence)
  • Диаграммы этапа проектирования
    • Диаграммы взаимодействия и диаграммы пакетов
    • Диаграммы проекта классов – включают ОО классы, навигацию между классами, имена атрибутов и методов, а также свойства, необходимые для программирования
slide12
Итеративный процесс OO проектирования: шаги проектирования

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

Весь процесс проектирования:

1. Разрабатывается первоначальная диаграмма проекта класса, показывающая связи

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

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

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

3. Изменяется проект классов добавлением сигнатур и информацией о связях

4. Принимается решение о разделении на пакеты соответствующим образом

12

slide13
Проектируются классы, взаимодействие и процессы
  • Проектируются диаграммы классов и подробные диаграммы взаимодействия
    • Классы, использующие входы и выходы друг друга разрабатываются параллельно
  • Диаграмма первоначального проекта класса основывается на модели предметной области и принципах проектирования системы
  • Первоначальная диаграмма последовательности для прецедента расширяется из диаграммы последовательности системы - system sequence diagram (SSD)
    • Показывает взаимодействующие объекты
  • Диаграмма последовательности разрабатывается послойно
    • Бизнес-логика, доступ к данным и представление
  • Диаграмма классов изменяется на основе диаграммы последовательности
slide14
Некоторые основные принципы проектирования
  • Инкапсуляция (Encapsulation)– каждый объект представляет собой замкнутый компонент, который включает данные и методы, имеющие доступ к данным
  • Повторное использование объектов (Object reuse)– проектировщики многократно используют одни и те же классы
  • Сокрытие информации (Information hiding)–данные, связанные с объектом не видимы за пределами объекта
  • Защита от изменений (Protection from variations)– часть системы, изменения которой мало вероятны отделяется от изменяемой части
  • Опосредованность (Indirection)–класспомещается между двумя промежуточными классами для того, чтобы разъединить их, но оставить связь между ними
slide15
Несколько основных принципов проектирования (Продолжение)
  • Связность (Coupling)– качественная мера того, насколько тесно в проектируемой диаграмме классы связаны
    • Количество стрелок навигации в диаграмме классов или сообщений в диаграмме последовательностей
    • Слабо связанные (Loosely coupled) – система легче понимается и поддерживается
  • Сцепление (Cohesion)– качественная мера согласованности функций внутри одного класса
    • Разделение ответственности (Separation of responsibility)– разделение слабо согласованного класса на несколько сильно согласованных классов
    • Сильно связанные классы – система легче понимается , поддерживается и многократно используется
slide16
Символы проекта классов
  • UML не различается в нотациях классов этапа моделирования предметной области и проектирования
  • Классы предметной области представляют концептуальные классы в среде пользователя
  • Диаграмма проекта класса конкретно определяет классы приложения
  • UML использует нотации стереотипов для классификации модели элементов по их характеристикам и назначению
slide18
Стандартные классы проекта
  • Сущность (Entity)– идентифицируются в проекте для классов предметной области.
    • Это постоянный класс (Persistent class)– он существуют после завершения работы системы
  • Управление (Control)– класс-посредник между граничными классами и классами сущностями, между уровнем представления и моделью предметной области
  • Граница (Boundary)– проектируется для представления системы на ее границе пользователю
    • Пользовательский интерфейс и оконные классы
  • Доступ данных (Data access)– обменивается данными с базой данных.
slide19
Определяются связи
  • Принцип проектирования при котором один объект может ссылаться к другому объекту
    • Могут взаимодействовать друг с другом, отправляя сообщения
slide20
Нотация проекта класса
  • Имя (Name) – имя класса и информация стереотипа (stereotype information)
  • Видимость атрибута (Attribute visibility)(private или public) – имя атрибута, тип, начальное значение, свойство
  • Сигнатура метода (Method signature) – информация , необходимая для вызова метода
    • Видимость метода, имя метода, тип (возвращаемый параметр), список параметров метода (входящие аргументы)
    • Перегружаемый метод– метод с таким же именем, но с альтернативным списком параметров
    • Метод уровня класса – метод, связанный с классом, а не с объектом (static или shared метод), отмечается подчеркиванием
slide23
Процесс разработки начальной диаграммы проекта классов
  • Расширяется диаграмма модели предметной области
    • Конкретизируются атрибуты с информацией о типе и начальной информации
  • Подробное проектирование выполняется по прецедентам
    • Диаграммы взаимодействия выполняют навигацию по классам
    • Стрелки навигации изменяются соответствующим образом
    • К каждому классу добавляются сигнатуры методов
slide24
Разработка начальной диаграммы проекта классов (Продолжение)
  • Выбираются классы, связанные с прецедентом
  • Добавляется контроллер (controller)
  • Конкретизируются атрибуты
    • Видимость, тип, начальное значениеe, свойства
  • Устанавливается первоначальная видимость навигации
    • Направление отношения один-ко-многим обычно устанавливается от главного к подчиненному
    • Обязательные отношения обычно ориентируются от независимого объекта к зависимому (например, отношение между клиентом и заказом)
    • Когда объекту требуется информация от другого объекта, стрелки навигации указывает на сам объект или на его родителя в иерархии
    • Навигация может быть в двух направлениях (двунаправленная стрелка)
slide25
Начинается с модели диаграммы классов предметной области

Связана с прецедентом

“Look up item available”

rmo look up item availability
Первоначальная диаграмма проекта RMO для прецедента Look Up Item Availability
slide27
Паттерны проектирования и контроллер прецедента
  • Паттерн проектирования-
    • Шаблон стандартного решения для требований проекта, который соответствует принципам хорошего дизайна
  • Шаблон контроллера прецедента
    • Требования проекта состоит в том, чтобы определить какой класс предметной области должен получать данные от пользователя для прецедента
    • Решение – в выборе класса, который будет использоваться как точка сбора для всех входящих сообщений для прецедента.Контроллер действует как посредник между внешним миром и внутренностью системы
    • Артифакт–класс, созданный дизайнером системы для обработки требуемых системных функций, например, такой как контроллер.
slide28
Понимание прецедентов и определение методов—Проектирование с диаграммами последовательности
  • Реализация прецедента производится через разработку диаграммы взаимодействия
  • Определяется какие объекты кооперируются путем передачи сообщений друг другу для выполнения прецедента
  • Диаграммы последовательностей и диаграммы коммуникаций представляют результаты проектных решений
    • Используются хорошо обоснованные принципы проектирования такие как связь (coupling), сцепление (cohesion), разделение ответственности
slide29
Ответственность объекта
  • Объекты отвечают за обработку в системе
  • Ответственность включает знание (knowing) и действие (doing)
    • Знания о собственных данных объекта и других классов объектов, с которыми они кооперируются для выполнения прецедентов
    • Выполнение действий для содействия в выполнении прецедента
      • Прием и обработка сообщений
      • Создание новых объектов, требуемых для выполнения прецедента
  • Проектирование означает назначение ответственности для соответствующих классов, основываясь на принципах проектирования и использовании шаблонов проектирования
slide30
Проектирование диаграмм последовательностей
  • Диаграммы последовательностей используются для понимания взаимодействия объектов и документирования проектных решений
  • Документируются входы и выходы системы для одного прецедента или сценария
  • Фиксируется взаимодействие между системой и внешней средой, которая представлена актором
  • Входы являются сообщениями от актора системе
  • Выходы являются возвращаемыми сообщениями, показывающими данные
system sequence diagram ssd look up item availability
Диаграмма последовательности системы -System Sequence Diagram (SSD) для прецедента Look Up Item Availability
slide32
Первоначальная диаграмма последовательностей
  • Начинается с элементов SSD
  • Заменяется объект :Systemна контроллер прецедента (use case controller)
  • Добавляются другие объекты, которые должны быть включены в прецедент
    • Выбирается входное сообщение из прецедента
    • Добавляются все объекты, которые должны кооперироваться
  • Определяются другие сообщения, которые должны быть посланы
    • Какие объекты являются источниками и адресатами для каждого сообщения?
slide34
Принципы разработки диаграммы последовательности для прецедента
  • Для каждого входного сообщения определяется внутреннее сообщение, которое является результатом этого входа
    • Для этого сообщения определяется назначение
    • Требуемая информация, класс назначения, класс источник и созданные в результате объекты
    • Еще раз проверяются все требуемые классы
  • Конкретизируются компоненты для каждого сообщения
    • Повторяемость, условия защиты, передаваемые параметры, возвращаемые значения
look up item availability1
Пример первоначальной диаграммы последовательности для прецедента Look Up Item Availability
slide36
Допущения первоначальной диаграммы последовательности
  • Допущение идеальной технологии
    • В систему не включаются такие элементы управления как login/logout (пока)
  • Допущение идеальной памяти
    • Не беспокоиться о хранении объектов во внешней памяти (пока)
    • Предполагается, что объекты находятся в оперативной памяти и готовы к работе
  • Предположение об идеальном решении
    • Не беспокоиться об обработке исключительных ситуаций (пока)
    • Предполагается решение с отсутствием проблем реализации
maintain product information ssd
Прецедент Maintain Product Information—Начинаем с SSD
controller
Добавляем Controller и определяем классы предметной области и взаимодействие
system ssd
Заменяется объект :SystemвSSD на контроллер и объекты предметной области
maintain product information
Первоначальная диаграмма последовательностей для прецедентаMaintain Product Information
slide41
Разработка многоуровневого проекта
  • В первоначальной диаграмме последовательности – контроллер прецедента плюс классы в предметной области
  • Добавляется уровень доступа–проект классов для доступа данных и для отделения взаимодействия с базой данных
    • Снимаются допущения идеальной памяти
    • Выполняется разделение ответственности
  • Добавляется уровень презентации – проект классов пользовательского интерфейса
    • Добавляются формы как оконные классы в диаграмму последовательности между актором и контроллером
slide43
Подходы к уровню доступа данных (Продолжение)
  • Создается класс доступа к данным для каждого класса предметной области
    • CustomerDA добавляется для Customer
    • Утверждения соединения с базой данных и SQL – утверждения выделяются в класс доступа к данным.
    • Классы предметной области ничего не должны знать о структуре или реализации базы данных
  • Подход (a) – контроллер создает экземпляр нового клиента (customer) aC; новый экземпляр запрашивает класс DA заполнить его атрибуты, читая из базы данных
  • Подход (b) – контроллер запрашивает класс DA создать экземпляр нового клиента (customer) aC; Класс DA читает из базы данных и передает значения в конструктор
    • Следующие примеры используют этот подход.
look up item availability2
Добавление уровня доступа к данным для прецедента Look Up Item Availability
maintain product information1
Добавление уровня доступа к данным для прецедента Maintain Product Information
slide46
Проектирование уровня представления
  • Добавляются формы GUI или Web страницы между актором и контроллером для каждого прецедента
    • Минимизируется бизнес-логика, присоединенная к форме
  • Некоторые прецеденты требуют только одну форму; некоторые требуют несколько форм и диалоговых окон
  • Проект уровня представления концентрируется на высоко-уровневой последовательности диалога в виде форм/страниц
view productquery look up item availability
<<View>> Форма ProductQueryдобавляется для прецедента Look Up Item Availability
maintain product information2
Полный прецедент Maintain Product Informationс уровнем презентации
slide51
Проектирование кооперативных диаграмм
  • Кооперативные диаграммы и диаграммы последовательности
    • Обе являются диаграммами взаимодействия
    • Обе фиксируют одну и ту же информацию
    • Процесс проектирования одинаков для обоих
  • Используемая модель зависит от предпочтений проектировщика
    • Диаграмма последовательностей– описание прецедента и диалоги следуют в последовательности шагов
    • Диаграммы связи– акцентируются на сцеплении
look up item availability4
Кооперативная диаграмма для прецедентаLook Up Item Availability
look up item availability iconic
Прецедент Look Up Item Availability, использующий специальные (Iconic)символы
slide55
Замещение диаграммы классов проекта
  • Проект диаграммы классов разрабатывается для каждого уровня
    • Новые классы для уровня представления и уровня доступа к данным
    • Новые классы для контроллера предметной области
  • Диаграммы последовательности добавляют методы
    • Методы конструктора
    • Методы get и set
    • Специальные методы прецедента
productitem
Проект класса с сигнатурами методов для класса ProductItem
slide57
Измененная диаграмма классов для уровня предметной области
slide58
Диаграмма пакетов —структурирование основных компонент
  • Высокоуровневая диаграмма UML для объединения классов в связанные группы
  • Идентифицируются главные компоненты системы и зависимости между ними
  • Определяются окончательные части программы для каждого уровня
    • Представление, бизнес-правила, доступ к данным
  • Система может разделяться на подсистемы и показывать вложенность внутри пакета
slide59
Неполная диаграмма пакетов проекта трех-уровневогоRMO
slide61
Итоги
  • OOD является мостом между требованиями пользователей (в моделях анализа) и целевой системой (построенной в среде программирования)
  • Проект системы строится на основе прецедентов, проектов диаграмм классов и диаграмм последовательностей
    • Диаграммы бизнес-классов преобразуются в диаграммы проекта класса
    • Диаграммы последовательностей являются расширениями диаграмм последовательностей системы - system sequence diagrams (SSDs)
slide62
Итоги (продолжение)
  • Должны применяться принципы ОО проектирования
    • Инкапсуляция– поля данных размещаются в класс вместе с методами обработки этих данных
    • Low coupling – связность между классами
    • High cohesion – сущность индивидуального класса
    • Защита от изменения– части системы, изменения которых маловероятно отделяются от вероятно изменяемых
    • Опосредованность–промежуточный класс помещается между двумя классами, чтобы разъединить их, но оставить связь между ними
  • Трех-уровневый проект используется для улучшения сопровождения
ad