Принципы проектирования объектно-ориентированной программной системы.

Этот подход подразумевает выполнение трёх этапов при проектировании:

1. Объектно–ориентированный анализ. Создание объектно–ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты–сущности и операции, выполняемые этими объектами.

2. Объектно–ориентированное проектирование. Разработка объектно–ориентированной модели системы ПО (системной архитектуры) с учётом требований.

В этой модели определение всех объектов подчинено решению конкретной задачи.

3. Объектно–ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно–ориентированного языка программирования (С++,С#, Java) для определения объектов и средств определения классов объектов.

Объектно–ориентированные системы можно рассматривать как совокупность автономных и независимых объектов. Изменение реализации какого–нибудь объекта или добавление ему новых функций не влияет на другие объекты системы. Четкое соответствие между реальными объектами (например, аппаратными средствами) и управляющими объектами программной системы облегчает понимание и реализацию проекта.

Объекты могут быть повторно используемыми компонентами, они независимо инкапсулируют данные о состоянии и операциях. Архитектуру ПО можно разрабатывать проект на базе объектов, ранее созданных в предыдущих проектах. Это снижает стоимость проектирования, программирования и тестирования ПО. Кроме того, возможность использования стандартных объектов уменьшает риск, связанный с разработкой ПО.

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

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

Модель использования системы – динамическая модель, которая показывает взаимодействие данной системы со своим окружением (средой).

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

Существует два типа моделей системной архитектуры:

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

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

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

Язык моделирования UML поддерживает большое количество возможных статических и динамических моделей, в том числе модель подсистем и модель последовательностей.

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

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

Механизмы повторного использования

Наследование (white-box reuse). внутреннее устройство родительских классов видимо подклассам.

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

Делегирование (агрегирование) получатель поручает выполнение операций уполномоченному. Оба объекта могут существовать независимо. Замена вложенных объектов на стадии выполнения программы позволяет динамически изменять её поведение.

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

Сквозная функциональность.

Сквозная функциональность

могут применяться ко всем слоям, компонентам и уровням.

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

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

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

Управление конфигурацией. Выявить данные, которые должны быть настраиваемыми, где и как хранить данные конфигурации, как защищать и обрабытывать конфиденциальные данные конфигурации. 

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

Протоколирование. Выбрать данные, подлежащие протоколированию, как сделать протоколирование настраиваемым.

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