Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Объектно-ориентированное проектирование).pdf

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

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

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

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

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

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

Этот пример наводит на мысль, что мы обращались с термином иерархия в весьма приблизительном смысле. Наиболее интересные сложные системы содержат много разных иерархий. На корабле, например, можно выделить несколько систем: освещения, управления курсом, и многие другие. Такая градация дает структурную иерархию типа «быть частью»^[9].

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

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

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

Рисунок 1-1. Каноническая форма сложной системы.

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

Большинство из нас формально обучено структурному проектированию «сверху вниз», и мы воспринимаем декомпозицию как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. Представим, что у этой задачи существует некий другой способ декомпозиции. Мы разделили систему, выбрав в качестве критерия декомпозиции принадлежность ее элементов к различным абстракциям данной проблемной области. Хотя обе схемы решают одну и ту же задачу, но они делают это каждая по-своему. Во второй декомпозиции мир представлен совокупностью автономных действующих лиц, которые взаимодействуют друг с другом, чтобы обеспечить поведение системы, соответствующее более высокому уровню. «Получить изменения в отформатированном виде» больше не присутствует в качестве независимого алгоритма. Это действие существует теперь как операция над объектом «Файл изменений». Эта операция создает другой объект - «Изменения в карте». Тем самым, каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Каждый объект совершает определенные действия, и мы можем, отправив им какое-то сообщение, попросить их совершить какие-либо действия. Так как наша декомпозиция основана на объектах, а не на алгоритмах, мы называем ее объектно-ориентированной декомпозицией. Какая декомпозиция сложной системы позволит справится с задачей лучше - по алгоритмам или по объектам? Тут есть один небольшой нюанс, а именно то, что правильный ответ на этот вопрос заключается в том, что важны оба аспекта^[12]. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Все же мы не можем сконструировать сложную систему одновременно двумя способами, тем более, что эти способы по сути ортогональны.  Необходимо начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения. Практика, однако, показывает, что полезнее начинать с объектной декомпозиции^[13]. Такое начало поможет нам лучше справиться с приданием организованности сложности программных систем. Выше этот объектный подход помог нам при описании таких непохожих систем, как компьютер и крупная компания. Объектная декомпозиция имеет несколько чрезвычайно важных преимуществ перед алгоритмической. Объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии выразительных средств. Объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируется на устойчивых промежуточных формах. Действительно, объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых мы уже уверены. Более того, объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.

Другим способом, расширяющим информационные единицы, является организация внутри системы иерархий классов и объектов. Объектная структура необходима, так как она показывает нам схему взаимодействия объектов друг с другом, которая осуществляется с помощью определенных механизмов взаимодействия. Структура классов не менее важна. Она определяет общность структур и поведения внутри системы. Так, например, нет смысла исследовать целый лист дерева для того, чтобы понять, как работает фотосинтез, вполне достаточно всего одной клетки, ведь вполне ожидаемо, что остальные клетки ведут себя точно так же. И хотя мы рассматриваем каждый объект определенного типа как отдельный, можно предположить, что его поведение будет похоже на поведение других объектов того же типа. Классифицируя объекты по группам родственных абстракций, как например, типы клеток растений в противовес клеткам животных, мы четко разделяем общие и уникальные свойства разных объектов, что помогает нам затем справляться со свойственной им сложностью. Определить иерархии в сложной программной системе не всегда легко, так как это требует разработки моделей многих объектов, поведение каждого из которых может отличаться чрезвычайной сложностью. Однако после их определения, структура сложной системы и, в свою очередь, наше понимание ее сразу во многом проясняются^[14].

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

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

- условные обозначения - язык для описания каждой модели;

- процесс - правила проектирования модели;

- инструменты - средства, которые ускоряют процесс создания моделей, и в которых уже воплощены законы функционирования моделей. Инструменты помогают выявлять ошибки в процессе разработки^[15].

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

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

Объектно-ориентированный анализ и проектирование - это метод, логически приводящий нас к объектно-ориентированной декомпозиции. Применяя объектно-ориентированное проектирование, мы создаем гибкие программы, написанные экономными средствами. При разумном разделении пространства состояний мы добиваемся большей уверенности в правильности нашей программы. В итоге, мы уменьшаем риск при разработке сложных программных систем^[16].

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

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

Рисунок 1-2. Объектно-ориентированные модели.