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

1. Достоинства и недостатки объектно-ориентированного проектирования

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

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

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

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

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

---

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

Недостатки объектно-ориентированного проектирования могут повлиять на характеристики системы и на начальные затраты. Рассмотрим сначала ухудшение характеристик. Существует определенная плата за посылку сообщения от одного объекта к другому, выражающаяся в некотором ухудшении быстродействия. Для тех обращений к методам, которые не могут быть реализованы статически, необходимо провести динамический поиск, чтобы найти соответствующий метод, определенный в классе, которому принадлежит объект, получающий сообщение. Опыт показывает, что обращение к методу может занимать в 1,75-2,5 раза больше времени, чем обращение к обычной подпрограмме [3, 5]. Как правило, динамический поиск оказывается нужен, примерно, в 20% случаев от общего числа обращений. Поэтому транслятор в хорошо типизированном языке часто может сам определить, какие вызовы могут быть статически реализованы, и написать код вызова подпрограммы, а не поиска метода.

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

---

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

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

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

---

Но, не смотря ни на что, плюсы объектно-ориентированных систем, зачастую, перевешивают все перечисленные минусы. Быстродействие программы, написанной на языке программирования C++, часто выше, чем у такой же программы с теми же функциональными возможностями, написанной на языке Си [4]. Это объясняется использованием виртуальных функций, которые в некоторых случаях исключают необходимость прямой проверки типов данных и структур. Более того, размер исполняющих модулей объектно-ориентированных систем обычно меньше, чем у функционально равносильных им систем, созданных с помощью традиционных методов.

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

Глава 2. ПРИМЕРЫ ПРОГРАММНЫХ ПРОДУКТОВ, КОТОРЫЕ МОГУТ БЫТЬ ИСПОЛЬЗОВАНЫ ДЛЯ РЕАЛИЗАЦИИ ПОДХОДА

1. CASE-технологии

В районе 70-х и 80-х годов при разработке ИС довольно обширно применялась структурная методология, обеспечивающая разработчикам строгие формализованные методы описания ИС и принимаемые технические решения. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Благодаря наглядности и строгости средств структурного анализа разработчики и будущие пользователи системы имели возможность с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Ручная разработка обычно порождала следующие проблемы:

---

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

Вышеприведенные факторы привели к появлению программно-технологических средств специального класса - CASE-средств, которые реализуют CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) сегодня используется в достаточно широком смысле [6]. Изначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время имеет новый смысл, охватывающий процесс разработки сложных ИС в целом. Итак, теперь под термином CASE-средства подразумеваются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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

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

CASE-технология – это методология проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей [6]. Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, которые используют диаграммы или тексты для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

---