ООП Лекция 18. Домены. Объектно ориентированное проектирование
Домен - отдельный реальный, абстрактный или гипотетический мир, населенный отчетливым набором объектов, которые ведут себя соответственно определёнными доменом правилам или линиям поведения.
Нашу систему мы разбиваем на домены.
Классификация доменов:
- Прикладной домен – непосредственно та задача, которую мы решаем. Его часто называют бизнес-логикой нашей системы.
- Сервисные домены – обеспечивают какие-то сервисные функции.
Например, пользовательский интерфейс. Домен, который реализует взаимодействие пользователя с прикладным доменом, выделяем как сервисный домен. Мы можем читать данные из базы данных из архива - это тоже сервисный домен, то есть то, что необходимо нашей задаче.
- Архитектурный домен – предоставляет общие механизмы и структуры управления данными и в общем всей системы, как единым целым.
Задача, который решает архитектурный домен: придать однородность структуре ПО.
- Арх. домен должен организовывать доступность данных, реализовывать каналы управления;
- Арх. домен задает структуру прикладного и сервисного доменов;
- Арх. домен обеспечивает взаимодействие между разными частями кода: между доменами, между подсистемами;
- Арх. домен обеспечение работу с системой как с единым целым(предоставлять инструменты для сохранения данных, восстановления данных, решать проблемы с исключительными ситуациями) Решений построения архитектурных доменов может быть очень много.
Домены реализации – домены, связаные с общими библиотеками классов, функционал ОС...
Когда в домене большое количество классов (где-то 50 штук), его разбивают на подсистемы по принципу минимума связей между выделенными подсистемами.
Для домена (или для каждой подсистемы):
- ДСС – диаграмма сущность-связь (информационная модель).
- МВО – модель взаимодействия объектов (событийная модель). Можем реализовать как синхронно, так и асинхронно (нужно стремиться к асинхронной модели.
- МДО – модель доступа к объектам (аксессорная модель). Можем реализовать только синхронно.
Если мы домен разбиваем на подсистемы, нужно для домена реализовать соответствующие диаграммы:
- МСП - модель связи подсистем
- МВП - модель взаимодействия подсистем
- МДП - модель доступа подсистем Получается такое соотношение:
- ДСС ---> МСП
- МВО ---> МВП
- МДО ---> МДП
Желательно чтобы все эти диаграммы можно было накладывать друг на друга. То есть расположение всех этих подсистем на трех диаграммах одинаковое. Отличаются только связями: МСП - общее представление о связях, МВП - на уровне событий, МДП - аксессерное взаимодействие.
На модели связей подсистем: можно изобразить множество связей, как одну связь, и перечислить все связи, которые входят в это множество. На модели взаимодействия подсистем: необходимо указать все события (стрелочка от порождающего к принимающему). На модели доступа подсистем: -//-, но стрелочки это не события, а аксессорные процессы между подсистемами.
Внутри прямоугольника, обозначающего подсистему, характеризуем ее: имя, если есть, и диапазон номеров объектов, которые входят в эту подсистему.
Домен, который предоставляет что-то другому домену, называется серверным. О связи между доменами: существует мост между одним доменом и другим. Клиенту не важно, кто предоставляет ему возможности, которые он использует. Серверу не важно, кто использует возможности, которые он предоставляет.
Диаграмма взаимодействия доменов: выделяем, кто клиент, а кто - сервер.
Используется язык объектно-ориентированного программирования (Object-Oriented design language - OODLE)
В этой нотации выделяется 4 диаграммы:
- Диаграмма класса - диаграмма внешнего представления одного класса – Гради Буч
- Схема структуры класса – чтоб оказать внутреннюю структуру класса и доступа к данным
- Диаграмма зависимостей – показывает дружественные связи и клиент-серверный доступ
- Диаграмма наследования
Последние две диаграммы в других нотациях как правило объединяются одной диаграммой.
Мы проектируем класс вокруг данных, атрибутов этого класса. У нас есть информационная модель, в которой мы выделили каждую сущностью, и каждая сущность для нас должна быть классом. У нас есть имя этой сущности(имя класса) , есть данные, есть атрибуты этого класса, которые становятся компонентами или членами класса при проектировании.
Когда мы выделяли атрибуты, мы четко перечисляли значения, которые может принимать атрибут для разных объектов. Это перечисление нам теперь необходимо для того, чтобы понять какого типа будет компонент.
Имя компонента берём то, которое уже было на информационной модели. И на основе тех значений, которые может принимать атрибут, определяем тип компонента. На диаграмме рисуется так:
Так делаем для каждого компонента.
Для каждой сущности мы выделяем идентификатор. Если идентификатор (не?)формальный, то на диаграмме классов мы его не записываем, то есть при проектировании мы его убираем. А если это формальный атрибут, то на диаграмме мы это преобразуем в компонент. Прим.: на видео Тассов не очень внятно сказал, поэтому я не понял где формальный, а где нет.
Таким образом мы рассмотрели то, что внутри диаграммы класса.
Теперь наша задача выявить те методы, которые мы можем выполнять над нашим объектом. Стоит сказать, что все методы мы можем разделить на 2 группы:
- Операции над объектом
- Операции над классом С правой стороны рисуются операции над классом, с левой стороны над объектом.
Примером операции над классом является операция “создать”. Дело в том, что, когда мы используем эту операцию, объекта ещё нет. Объект появляется после выполнения этой операции. Это может быть конструктор или какой-то статический метод, который порождает объект данного класса.
Для операции мы рисуем линию, на которой мы должны показать какие данные получает процесс, какие изменяет, какие возвращают. Над линией мы показываем данные, которые получает. На самой линии изменяемые параметры. Под линией возвращаемые параметры:
Когда речь идет об операции создания, нас интересуют только получаемые данные. Результатом является объект, но мы это не указываем на диаграмме. Получаемые компоненты мы рисуем аналогично членам самого класса.
Если метод обрабатывает исключительную ситуацию, то мы у него рисуем ромбик:
Если метод связан и вызывается во время выполнения, мы помечаем его чертой. Это обработчик состояний:
Если метод скрытый, то в принципе его можно помечать на диаграмме, но нас тут интересует интерфейс. Но отметить некоторые операции, которые происходят внутри, можно. В таком случае мы не рассматриваем данные, которые они получают. Если класс перегружен, то можно вообще эти классы не зарисовывать.
Возможно такое, что метод принимает или возвращает несколько данных. Тогда мы рисуем тот же “гробик” и приписываем N:
Диаграмма внешнего представления одного класса
Наша задача проследить потоки данных и доступ к непосредственно данным самого класса. На данной диаграмме всё строится вокруг данных объектов. Это то, что на дпдд мы называли архивом данных. Вот он:
Допустим у нас есть методы. Здесь задача четко посмотреть какие это методы. Нас интересовать будут не только методы, которые получают данные извне, но ещё и методы, которые используют методы, которые вызываются извне(сложна, не?).
Например, есть три метода.
Мы соединяем их линиями. Линии - это линии по доступу передачи данных. На каждой линии мы показываем какие данные получает метод и какие возвращает. Опять рисуем гробики. Если стрелочка вниз, это параметр, которые принимает метод. Если стрелочка вверх, то возвращает. Если и вверх и вниз, то и то, и другое:
Мы четко выделяем слои. Слой методов, которые вызываются извне – общедоступные, и методы скрытные, которые не вызываются извне. Желательно, чтоб методы интерфейса не вызывали друг друга. Если есть что-то общее в разных методах, то мы выделяем метод скрытого слоя, который объединяет эти методы общедоступного слоя. Четко прослеживаются потоки данных
Если метод обрабатывает исключения, выделяем квадратиком:
Если метод, получает или передает как результат какие-то данные во внешний модуль, то мы показываем это таким образом:
Общий вид схемы:
На схеме структуры класса четко прослеживаются потоки данных.
На диаграмме зависимостей на нужно имя класса и возможно те методы, которые участвуют во взаимодействии.
Двойная стрелочка – дружественные связи, одна – схема использования. На этой диаграмме можно показать, какой метод имеет доступ к методу другого класса и какой метод вызывается
На данной диаграмме нас интересуют какие методы и компоненты объектов.
Нам надо четко понимать какие компоненты есть у суперкласса и подклассов, и какие методы. Напомним, что в объектно-ориентированном анализе у нас суперкласс всегда абстрактный. К этому надо стремиться и при проектировании.
