Ключевые концепции. Описание отношений и структурирование ПО

Описание отношений и структурирование ПО

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

B является клиентом A, если каждый объект типа B содержит информацию об одном или нескольких объектах типа A.

B является наследником A, если B представляет специализированную версию A.

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

[x]. Отношение "быть клиентом" достаточно широкое и покрывает многие виды зависимостей. Примерами таких зависимостей является отношение, часто называемое агрегацией (присутствие в каждом объекте типа B подобъекта типа A), а также зависимость по ссылке и родовая зависимость.

[x]. Отношение наследования покрывает многочисленные формы специализации.

[x]. Многие зависимости можно выразить в общем виде другими способами. Например, для описания зависимости "от 1-го до n " (каждый объект типа B связан с не менее чем одним и не более чем с n объектами типа A) укажем, что B является клиентом A, и присоединим инвариант класса, точно определяющий природу отношения "быть клиентом". Так как инварианты классов выражаются с помощью логического языка, они покрывают намного больше различных отношений, чем может предложить подход сущность-связь или другие аналогичные подходы.

[x]. Вычисление включает три вида ингредиентов: процессоры (или потоки управления), действия (или функции) и данные (или объекты).

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

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

[x]. Как правило, неестественно считать, что задача системы состоит в реализации только одной функции. У реальной системы обычно имеется не одна "вершина" и ее лучше описывать как систему, предоставляющую множество услуг.

[x]. На ранних стадиях проектирования и разработки системы не нужно уделять много внимания ограничениям на порядок действий. Многие временные соотношения могут быть описаны более абстрактно в виде логических ограничений.

[x]. Функциональное проектирование сверху вниз не подходит для программных систем с долгим жизненным циклом, включающим их изменения и повторное использование.

[x]. При ОО-конструировании ПО структура системы основывается на типах объектов, с которыми она работает.

[x]. При ОО-разработке первоначальный вопрос не в том, что система делает, а в том, с какими типами объектов она это делает. Решение о том, какая функция является самой верхней функцией системы (и имеется ли таковая), откладывается на последние этапы процесса проектирования.

[x]. Чтобы проектируемое ПО было расширяемым и допускало повторное использование, ОО-конструирование должно выводить архитектуру из достаточно абстрактных описаний объектов.

[x]. Между типами объектов могут существовать два вида отношений: "быть клиентом" и наследование.

Дата добавления: 2014-01-07