7 Введение в объектно-ориентированный анализ

## 7.1 Объектно-ориентированный анализ

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

Известны несколько подходов к проведению ООА.

В книге Салли Шлеер и Стефана Меллора "Объектно-ориентированный анализ: моделирование мира в состояниях" выделено три этапа ООА:

- Построение информационной модели, абстрагирование реальных сущностей в терминах объектов и атрибутов.

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

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

В книге Гради Буча “Объектно-ориентированное проектирование с примерами применения” отмечаются альтернативные подходы к ООА:

#### - Метод неформального описания, в котором выделяются существительные и глаголы в описании предметной области. Существительные рассматриваются как кандидаты для образования классов. а глаголы - кандидаты в операции над классами.

#### - Структурный анализ, при котором на основе модели системы, представленной диаграммами потоков данных, выделяются внешние события и объекты, база данных, поток управления, преобразования потока управления. Далее, на основе анализа потока данных и потока управления, выделяются классы и методы классов.

##

## 7.2 Пример объектно-ориентированного анализа

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

Предметная область ППП для решения расчетных задач может быть формально описана совокупностью трех множеств:

#### - множества данных X;

#### - множества функциональных связей (задач, решаемых с использованием пакета) F;

#### - множества связей по определению R.

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

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

Данные (множество X):

множество данных,

элемент множества данных.

Элемент множества данных должен описываться его типом, уровнем агрегирования и наличием или отсутствием конкретного значения.

Задачи (множество F):

множество задач,

элемент множества задач (конкретная задача),

набор аргументов (входных и выходных данных задачи),

аргумент задачи.

Связи по определению (множество R):

множество связей,

элемент множества связей,

тип связи (старший - младший, функция-предикат).

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

Модули (множество M):

множество модулей,

элемент множества модулей,

список параметров модуля,

параметр модуля.

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

Рисунок 1- Связи между множествами

Кроме понятий - существительных следует выделить понятия - глаголы (действия), относящиеся к понятиям - существительным. В рассматриваемом примере действиями могут быть:

#### - определить новый элемент множества данных, задач или связей;

#### - добавить новый элемент в множество (данных, задач, связей);

#### - удалить элемент из множества (данных, задач, связей);

#### - ввести значение элемента множества данных;

#### - вывести на экран (в файл, на принтер) значение элемента множества данных;

#### - выполнить задачу.

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

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

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

#### - Имя класса, т.е. присвоенный классу идентификатор.

#### - Множественность экземпляров класса (0/1/n).

#### - Иерархия класса (базовые классы).

#### - Структура и интерфейс класса.

Здесь под структурой понимаются как атрибуты класса (элементы-данные), так и действия (методы). Данные и методы разбиваются по уровням доступа, например, предполагая использование при программировании C++, выделяются уровни доступа public, protected и private.

Под интерфейсом класса понимаются элементы-данные, доступные из экземпляров других классов, и методы, которые могут вызываться из других классов.

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

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

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

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

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

Если пользователь указал все характеристики данного правильно, нужно построить экземпляр объекта “данное” и включить его в множество данных.

7.3 Объектно-ориентированное проектирование

Само по себе проектирование на объектно-ориентированном языке не обеспечивает объектно-ориентированного программирования. Самое важное в ООП – техника проектирования, основанная на выделении и распределении обязанностей.

Объектно-ориентированное проектирование - это тема отдельного курса и можно отослать к книге Г. Буча "Объектно-ориентированный анализ и проектирование". В библиотеки ВГУЭС находится первое издание этой книги. Второе издание с примерами приложений на С++ можно заказать на Мистрале.

Первый шаг в проектировании - уточнение спецификации.

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

Интерфейс и реализация модуля - принцип Парнаса.

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

Говорят, что компонента инкапсулирует поведение объекта, если она умеет выполнять некоторые действия, но подробности, как именно она это делает, скрыты. Это приводит к двум представлениям о программной системе. Вид со стороны интерфейса - это лицевая сторона. В интерфейсной части описывается, что умеет делать компонента. Вид со стороны реализации - это изнанка, она определяет, как компонента выполняет задание.

Разделение интерфейса и реализации является наиболее важной идеей в программировании. Итак, принцип Парнаса:

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

· Разработчик программного обеспечения должен знать только требуемое поведение компоненты и ничего кроме того.

## 7.4 Процесс объектно-ориентированного проектирования

Объектно-ориентированное проектирование (Object-Oriented Design - OOD) - это поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.

В рассмотренном выше примере были выделены классы “множество данных” и “данное”. Пусть классу “множество данных” присвоено имя TXSet.

С учетом имеющихся инструментальных средств класс TXSet может быть построен на основе класса Array из библиотеки CLASSLIB, т.е. это множество может быть интерпретировано массивом. Массив представляет собой упорядоченную совокупность однотипных элементов, в то же время данные могут принадлежать различным типам и каждому тип соответствует свой набор характеристик. Это противоречие можно преодолеть, если элементами массива TXSet будут указатели на экземпляры данных.

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

Пусть требуется обеспечить возможность использования числовых скалярных данных и массивов (векторов и прямоугольных матриц), а также данных типа строк и массива строк. Естественно определить для каждого такого типа свой класс: TDScal, TDArray, TDString, TDStringArray. В каждом из этих классов должно быть поле идентификатора данного ident, поле описания данного head и, возможно, поле flags, представляющее собой набор битов, дополняющих описание данного. Может оказаться удобным иметь и поля, содержащие количество знаков при представлении скаляра или элементов массивов (width) и количество цифр в дробной части для представления чисел (dec). Все эти данные можно объединить в классе TData, базовом для остальных классов данных. Таким образом, вместо одного класса “данное”, выделенного на этапе анализа, появилось пять классов. После этого следует вернуться к этапу анализа и оформить рабочие документы анализа для новых классов.

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

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

Таким образом, процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:

#### - Определение классов и объектов на определенном уровне абстракции.

#### - Определение семантики классов.

#### - Определение (идентификация) связей между классами и объектами.

#### - Реализация классов.

#### На каждом повторении этого цикла уточняются описания классов и перерабатываются проектные документы.

7.5 Понятие жизненного цикла программных изделий

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

- этап постановки задачи, на котором необходимо сформировать представление о том, в создании какого вычислительного процесса, с использованием каких данных состоит цель работы;

- этап проектирования, в рамках которого необходимо принять решение о составе данных и их типах и представить вычислительный процесс в терминах граф - схемы алгоритма;

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

- этап тестирования и отладки, в рамках которого предполагается использование средств отладки программной среды для локализации ошибок в коде.