Тема 1.2. Об'єктна модель предметного середовища, принципи її побудови

Мета – Навчити будувати об’єктну модель предметного середовища. Показати роль алгоритмів і структур даних у такій моделі. Навчити структурувати об’єктну модель.

Завдання – Пояснити поняття об’єктної моделі, рівнів абстрагування при її побудові. Охарактеризувати принципи її побудови. Навести приклади складання об’єктної моделі.

Очікувані результати (компетенції):

Обирати рівні абстрагування при побудові об’єктної моделі.

Розподіляти дані і алгоритми по обраних рівнях моделі.

Аналізувати міжоб’єктні зв’язки.

1. Поняття «Об'єктна модель предметного середовища». Порівнева конкретизація моделі. Конкретизація даних.

Далее в примерах будет использоваться такая постановка задачи:

Предметная область: авторалли по пересеченной местности на автомобилях-внедорожниках.

Задача: разработать программу прокладки курса автомобиля (в помощь штурману).

Известные данные:

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

- параметры автомобиля: емкость бака, зависимость расхода горючего от скорости, наклона дороги и характера грунта; ограничение на скорость в соответствии с наклоном дороги и характером грунта, связанные с мощностью двигателя; марка автомобиля, его масса, состав экипажа, номер, цвет и т.п.

- дата и время проведения авторалли, состав судейской коллегии, количество зрителей, размер взноса участников, название фирм-спонсоров.

Интерфейс с оператором: оператор (штурман) может корректировать проложенную трассу и скорость движения. При этом программа автоматически пересчитывает расход топлива и время в пути. При возможной перегрузке двигателя выводится сообщение.

Результат: проложенная трасса с указанием скорости на каждом участке.

Что такое «Объектная модель» в ооп?

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

Например: при прокладке курса автомобиля очевидны объекты «Автомобиль», «Карта», «Трасса». Менее очевидны объекты «Логика прокладки курса», «Граф путей», однако именно в них могут быть реализованы алгоритмы оптимизации маршрута.

Вопрос: Почему выбраны именно эти объекты? Что они из себя представляют? Как взаимодействуют?

Почему выбраны именно такие объекты?

Потому, что модель является результатом объектно-ориентированного анализа. Вот как мы могли рассуждать в начале такого анализа:

1. Рассмотрели известные нам данные и представили себе работу штурмана: Он смотрит на Карту (вот и первый объект нашей модели!). Проводит линию Трассы от старта к первому контрольному пункту, от него ко второму и т.д. Линия от пункта к пункту, очевидно, не прямая, так как приходится объезжать препятствия. Из личного опыта мы знаем, что при этом желательно не сильно отклоняться от прямой, стараясь ехать по ровной местности с твердым грунтом.

2. Очевидно, что возможно несколько вариантов прокладки трассы, для каждого из которых можно просчитать расход горючего, скорость и время движения. По какому алгоритму штурман выбирает участки движения (прокладывает вариант трассы) и производит такой расчет, пока не важно. Главное, чтобы в программе был объект, который сделает это за него. В принципе, расход топлива и скорость движения по конкретной дороге зависят от возможностей Автомобиля, поэтому такой объект тоже был включен в модель. Заметим, что в такой модели Автомобиль получает данные от Карты, строит несколько вариантов Трассы и сравнивает их между собой (эти объекты так взаимодействуют между собой в рамках данной модели).

3. Про объекты Логика прокладки курса и Граф путей пока говорить не будем. Они возникли позже при уточнении объектной модели.

Что представляют объекты, включенные в модель, и как они взаимодействуют?

В первую очередь - это данные, которые нам известны из описания предметной области и постановки задачи (структуры данных).

Во вторую очередь - это алгоритмы вычислений над этими данными и связь между объектами.

Мы объединили данные про местность в объект Карта, данные про автомобиль в объект Автомобиль, а данные о движении в объект Трасса.

Объект Карта не разрешает изменять свои данные, но может предоставлять нам их по запросу.

Объект Трасса позволяет добавлять и удалять участки, привязанные к Карте.

Объект Автомобиль формирует очередной вариант трассы, рассчитывает его параметры, сравнивает с параметрами предыдущих вариантов. Однако возникает вопрос, не слишком ли сложная математика сосредоточена в одном объекте? Если да, то его вполне можно разбить на несколько более простых объектов. В данном случае из Автомобиля выделились объекты «Логика прокладки курса», «Граф путей».

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

Объект Логика прокладки курса как раз и формирует данные для Графа путей на основе Карты и задания, выданного Автомобилем. При этом заранее отбрасываются непроходимые участки.

Таким образом, объектная модель задачи, это известные нам сведения о задаче, сгруппированные в объекты, а также операции, которые над ними производятся.

Каждый объект может содержать внешние данные, доступные для изменения другим объектам, и внутренние данные, недоступные извне. Запрещая доступ к данным и операциям, мы «абстрагируемся» от них и создаем «абстрактный тип данных».

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

Доступные извне данные (поля) и процедуры (методы) образуют интерфейс объекта, через который с ним могут взаимодействовать другие объекты.

При этом важны следующие моменты:

1. Мы не можем построить сложную модель целиком и сразу, поэтому процесс построения поэтапный.

2. Мы начинаем строить модель с простых объектов и пренебрегаем данными, которые на текущем этапе не кажутся существенными. При необходимости, мы можем ввести их в объекты на следующих этапах. Это же касается и процедур их обработки.

3. Не все данные объекта могут (должны) быть доступны извне при связи объектов в модели. Мы «абстрагируемся» от данных и операций, которые лучше скрыть от других объектов, и обеспечиваем связь через интерфейс.