otvety_118

81

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

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

Объектно-ориентированные метрики для измерения характеристик систем

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

1.Количество строчек кода (LOC)

Метрика (Lines of Сode) для подсчета исполняемых строчек кода. Метрика позволяет измерить не пустые и не закомментированные строчки кода. Может существовать несколько вариаций: LOCf - количество строчек кода в функциях, LOCm – в модулях (при ОО проектировании – модуль = класс), или LOCp – количество строк кода во всем проекте. Эта метрика одна из первых и наиболее часто используемых, так как, опираясь на нее, можно получить грубую оценку об изменениях в проекте.

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

2.Цикломатическая сложность Мак-Кейба (MVG)

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

Цикломатическое число l (G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина l (G) = m - n + p.

Существует теорема о том, что число базисных путей в орграфе равно его цикломатическому числу, увеличенному на единицу. При этом, цикломатической сложностью ПО Р с управляющим графом G называется величина n (G) = l (G) +1 = m - n + 2. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает психологическую сложность ПО. К достоинствам меры относят простоту ее вычисления и повторяемость результата, а также наглядность и содержательность интерпретации. В качестве недостатков можно отметить: нечувствительность к размеру ПО, нечувствительность к изменению структуры ПО, отсутствие корреляции со структурированностью ПО, отсутствие различия между конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов.

Формальное определение цикломатической сложности – это подсчет линейно независимых частей в графе потока управления полученного из программы. Примерное приближение может быть получено путем подсчета ключевых слов языка и операторов. Можно показать, что это будет достаточно точное приближение во многих случаях. В случае С++ подсчет идет по следующим маркерам - if, while, for, switch, break, &&, ||. Необходимо обратить внимание, что булевские операторы добавляют дополнительные ветвления в код, при том что не все булевское выражение может быть выполнено в зависимости от составляющих частей

82

операнда. Кроме того, обработка switch оператора достаточно проблематично: не все case могут указывать на один блок кода, следовательно, подсчет таких операторов может немного завысить итоговое значение.

3.Количество комментариев (COM)

Метрика для подсчета комментированных строчек кода(Comment Lines). Это грубая мера сравнимая с LOC показывающая объем комментариев внутри региона кода. Подобную меру достаточно сложно использовать отдельно от LOC, но при использовании отношений к LOC или MVG подобный коэффициент покажет пропорциональное отношение комментариев к исполняемому коду или его сложности. L_C = LOC/COM; M_C = MVG/COM.

4. Число классов – получателей сообщений данного класса (Fan-out, Fan-in) Число классов – получателей сообщений данного класса (Fan-out, the number of other

collaborating classes irrespective of the number of references) - число дуг в простейшей модели передачи сообщений, выходящих из вершины, соответствующей классу, т.е. число классов, к методам которых есть обращения в методах данного класса.

Для заданного модуля А, метрика Fan-out покажет количество классов которые используют модуль А, тогда как метрика Fan-in покажет количество модулей которое использует модуль А. Определение Fan-in - число вершин, из которых входят дуги в данную вершину в простейшей модели взаимодействия компонентов

5.Количество взвешенных методов на класс (WMC)

Количество взвешенных методов на класс (Weighted Methods Per Class - WMC) позволяет измерять сложность классов с учетом сложности его методов. Весом метода в этом случае называется количественная характеристика (метрика) сложности метода.

Рассмотрим простейший случай, когда сложность метода определяется количеством строк текста этого метода в программе. Пусть L[i] - это количество строк текста у метода с номером i, а всего в классе n методов. Тогда для этой метрики измерения методов сложность класса Point вычисляется следующим образом:

WMC(Point) = L[0] + ... + L[n]

Как можно заметить, метрика WMC для измерения сложности класса зависит от способа измерения сложности методов этого класса.

Часто используется разновидность метрики WMC, когда все методы имеют одинаковый вес. Она называется Количество методов на класс (Number of Methods - NM). Используется метрика NM для измерения сложности классов на ранних этапах разработки системы, когда еще нет детальной информации о методах. Возможно, что класс со слишком большим количеством методов на этапе проектирования системы следует разделить на несколько классов.

Вероятное влияние метрики на характеристики системы:

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

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

класса.
	Классы с большим числом методов с большой долей вероятности

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

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

6.Глубина дерева наследования (DIT)

Глубина дерева наследования (Depth of Inheritance Tree - DIT) позволяет определить количество классов-предков, которые потенциально оказывают влияние на данный класс.

Вероятное влияние метрики DIT на характеристики системы:

83

1.Большое количество предков делает поведение класса менее предсказуемым.

2.Глубокие деревья наследования усложняют проект, поскольку включают большее число атрибутов и методов в классах-потомках.

3.Чем глубже положение класса в дереве иерархии, тем больше повторное использование его методов.

Глубина класса в дереве наследования – длина пути в простейшей модели иерархии наследования классов от корня до вершины, соответствующей рассматриваемому классу. Шкала значений абсолютная.

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

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

Пример:

Рассмотрим программу:

class GrandFather {};

class Father : public GrandFather {}; class Son : public Father {}

В этом случае:

4.DIT(GrandFather) = 0

5.DIT(Father) = 1

6.DIT(Son) = 2.

Количество потомков (NOC)

Количество потомков (Number Of Children - NOC) позволяет определить количество непосредственных потомков данного класса. Число дуг в простейшей модели иерархии наследования классов, выходящих из вершины, соответствующей классу.

Шкала значений: абсолютная.

Вероятное влияние метрики на характеристики системы:

0.Чем больше потомков у класса, тем больше повторное использование его методов. Это положительное свойство.

1.Чем больше потомков у класса, тем больше вероятность неправильного использования базового класса-родителя. Это отрицательное свойство.

2.Чем больше потомков у класса, тем большее влияние он оказывает на систему в целом. Такой класс требует более тщательного тестирования.

Пример:

Рассмотрим программу: class GrandFather {};

class Father : public GrandFather {}; class Mother : public GrandFather {}; class Son : public Father, Mother{}

В этом случае:

3.NOC(GrandFather) = 2

4.NOC(Father) = 1

5.NOC(Mother) = 1

6.NOC(Son) =0.

Ширина иерархии наследования (BIH)

84

The breadth of the inheritance hierarchy (BIH). Максимальное число вершин на одном уровне в простейшей модели наследования классов. Шкала значений: абсолютная. Эта метрика применима только в том случае, когда иерархия наследования представлена деревом.

Глубина класса в графе наследования (NL)

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

	сумма длин всех путей в простейшей модели наследования от корневых
вершин до рассматриваемой вершины;
	длина максимального пути в простейшей модели наследования от

корневых вершин до рассматриваемой вершины.

Nesting level (class-to-root-depth) is 1) the number of ancestors of a class) 2) the maximum length from the node to a root of the tree. Кроме этих определений метрики существуют и другие. Например, приводится пример вычисления глубины класса в графе наследования как среднего арифметического значений глубины класса всех вершин – непосредственных предков (parents) данной вершины. (Шкала значений интервальная.).

Данное определение справедливо только для ОО проектов и программ, в которых использовано множественное наследование. Метрика связана с сопровождаемостью и повторной используемостью программ аналогично DIT

Связанность между классами объектов (CBO)

Связанность между классами объектов (Coupling Between Object classes-CBO) позволяет определить количество классов, с которыми связан данный класс. Это означает, что один класс использует методы или экземпляры другого класса.

Вероятное влияние метрики на характеристики системы:

0. Слишком большая связанность классов отрицательно влияет на модульность проекта и не позволяет повторно использовать классы.

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

2. Сильно взаимосвязанная система требует большего количества тестов и времени на тестирование.

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

66. Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code). LOC-оценка - это количество строк в программном продукте. Принято регистрировать следующие показатели:

-общие затраты (в человеко-месяцах - чел.-мес);

-объем программного изделия (в тысячах строк исходного кода -KLOC);

-стоимость разработки (в тыс.рублей или в долларах $);

-объем документации (в страницах документов -СД);

-ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО);

-число людей, работавших над изделием (человек);

-срок разработки (в календарных месяцах).

На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):

Достоинства размерно-ориентированных метрик: 1) широко распространены;

85

2) просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

1)зависимы от языка программирования;

2)требуют исходных данных, которые трудно получить на начальной стадии проекта;

3)не приспособлены к непроцедурным языкам программирования.

67. Функционально-ориентированные метрики.

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик.

1.Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

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

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

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

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

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

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

Область применения метода функциональных указателей - коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО. ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика - количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 6.

Достоинства функционально-ориентированных метрик:

1.Не зависят от языка программирования.

2.Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.

68. Конструктивная модель стоимости

В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) —дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в

ее состав три разные по сложности статистические подмодели [1]. Иерархию подмоделей Боэма (версии 1981 года) образуют:

базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;

86

промежуточная СОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;

усовершенствованная СОСОМО — объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).

Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

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

полунезависимый тип — средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

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

Уравнения базовой подмодели имеют вид Е=аbx(KLOC)[чел-мес];

D = cbx (E) [мес],

где Е — затраты в человеко-месяцах, D — время разработки, KLOC — количество строк в программном продукте.

Коэффициенты аb, bb, сb, db берутся из табл. 2.14.

Таблица 2.14. Коэффициенты для базовой подмодели СОСОМО 81

Тип проекта	аb	bb	сb	db
Распространен	2,4	1,0	2,5	0,3
ный		5		8
Полунезависим	3,0	1,1	2,5	0,3
ый		2		5
Встроенный	3,6	1,2	2,5	0,3
		0		2

В1995 году Боэм ввел более совершенную модель СОСОМО II, ориентированную на применение в программной инженерии XXI века [21].

Всостав СОСОМО II входят:

q модель композиции приложения;

q модель раннего этапа проектирования; q модель этапа пост-архитектуры.

Для описания моделей СОСОМО II требуется информация о размере программного продукта. Возможно использование LOC-оценок, объектных указателей, функциональных указателей.

69. Объектно-ориентированный подход к проектированию ПО. Понятие объекта, класса.

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

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

87

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

Понятию ―объект‖ сопоставляют ряд дополняющих друг друга определений. Ниже приведены некоторые из них.

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

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

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

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

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

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

-конструктор, создание и инициализация объекта;

-деструктор, разрушающий объект;

-модификатор, изменяющий состояние объекта;

-селектор для доступа к переменным объекта без их изменения;

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

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

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

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

Отношение использования реализуется посылкой сообщений от объекта A к объекту B. При этом объект A может выступать в роли:

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

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

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

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

Между классами также могут быть установлены отношения:

-отношение разновидности (кошка - вид определенного биологического семейства или кошка - домашнее животное);

-включения или составной части (лапа - часть кошки);

-ассоциативности, когда между классами есть чисто смысловая связь (кошки и собаки - домашние животные).

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

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

88

Приведенная выше характеристика объектного подхода соответствует применению его для построения и программирования имитационных моделей реальных процессов и систем.

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

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

Объектно-ориентированный подход к проектированию программных изделий предполагает:

-проведение объектно-ориентированного анализа предметной области;

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

-разработку программного изделия с использованием объектно-ориентированного языка программирования.

70. Объектно-ориентированный анализ и проектирование Объектно-ориентированный анализ (ООА) - это метод отождествления важных

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

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

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

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

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

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

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

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

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

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

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

89

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

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

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

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

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

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

Данные (множество X): множество данных, элемент множества данных.

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

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

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

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

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

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

Модули (множество M): множество модулей, элемент множества модулей, список параметров модуля, параметр модуля.

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

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

90

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

экземпляр объекта ―данное‖ и включить его в множество данных.

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

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