Анализ состояния вопроса «архитектура, управляемая моделью»
Причины, предпосылки появления mda
В последнее десятилетие наблюдается процесс активной разработки различных информационных технологий уровня предприятия, таких, как перечисленные программные платформы типа Microsoft .NET, CORBA, JAVA и т. д. Каждая из подобных технологий является сложной и объёмной программной системой, содержащей множество взаимно увязанных составляющих, интерфейсов, объединённых массой специальных правил и ограничений. И хотя каждая из этих технологий, как правило, претендует на комплексное решение всех проблем построения информационных систем, это, как показывает практика, с одной стороны, не мешает всем им существовать одновременно, а с другой ¬ не гарантирует, что в ближайшее время не появятся новые технологии или платформы разработки. В настоящее время уже очевидно, что наличие довольно большого количества подобных платформ и активизация процесса их разработки отнюдь не способствуют ускорению их практического внедрения. Главная причина этого явления ¬ отсутствие единого механизма интеграции. Руководителям крупных организаций и предприятий сначала приходится тратить значительные материальные средства для приобретения и разработки информационных систем, их сопровождения, обучения персонала и т. д. А впоследствии, в случае перехода на другую платформу, приходится, по сути, все повторять заново, опять тратя при этом материальные ресурсы. На крупных предприятиях нередко возникает необходимость внедрения и одновременной эксплуатации нескольких информационных систем, построенных с использованием различных платформ разработки, которые при этом должны взаимодействовать между собой. В этом случае требуемые затраты на высококвалифицированный персонал могут легко выйти за рамки допустимых, поскольку специалисты, владеющие одновременно несколькими подобными технологиями, встречаются весьма редко, а их «цена» растёт отнюдь не пропорционально количеству освоенных программных платформ. Перечисление подобных ситуаций можно продолжить, но уже из сказанного, очевидно, что необходимо каким-то образом решать проблемы интеграции, чтобы унифицировать все имеющиеся ныне и предполагаемые в будущем разнообразные технологии разработки программного обеспечения информационных систем. Задачу эту можно решать, по крайней мере, двумя способами. Первый способ ¬ внешняя унификация информационных интерфейсов. Одним из распространённых средств реализации такого подхода в настоящее время является язык XML. Этот путь облегчает задачу внешней интеграции, но не обеспечивает решения проблемы повторного проектирования систем при переходе на другую платформу. Консорциум OMG [29] предлагает идти другим путём, интегрируя платформы «изнутри», то есть путём создания платформенно-независимых моделей.
Привычный подход к разработке приложений, в самом общем виде выглядит следующим образом:
Рисунок 1.1 Этапы традиционной разработки программного обеспечения
На первом этапе создаётся проект приложения на основе требований к разработке. Он может быть описан словесно или представлен в графическом виде с отображением структуры и состава будущего приложения. Как правило, при обычном проектировании разработчик уже имеет представление, на какой платформе будет создаваться и функционировать будущее приложение, поэтому проект может включать специфические для выбранной платформы элементы. Например, проектируя иерархию классов приложения при программной реализации на языке C++, разработчик вправе использовать и заложить на этом этапе возможность множественного наследования, а для разработки на Delphi ¬ применять другие методы. На втором этапе происходит собственно программирование приложения на выбранном языке. Наконец, третий этап включает проведение отладки и тестов. Тесты в данном случае подразумевают и демонстрацию приложения заказчику. На практике в подавляющем большинстве случаев разработка на этом не заканчивается вследствие того, что третий этап выявляет некоторое количество замечаний. Замечания могут быть как объективными, то есть вызванными некорректно реализованным этапом программирования, так и субъективными в этом случае заказчик или менеджер уточняют постановку задачи. Поэтому процесс разработки достаточно сложного приложения всегда носит итерационный характер, то есть включает в себя возврат к предыдущим этапам. И вот здесь в практике традиционной разработки наблюдается следующее устойчивое явление ¬ разработчики «забывают» возвращаться на этап I (пунктирная линия на рис. 1.1). Вместо пересмотра проекта приложения зачастую происходит просто модификация кода, то есть повторение этапа II (сплошная линия на рис. 1). К чему это приводит? Для относительно простых приложений ничего страшного, в принципе, не происходит, код приложения просто модифицируется, количество итерации в этом случае невелико, объем кода также невелик. Совершенно другая ситуация с крупными программными проектами, особенно при их коллективной разработке. Происходит «отрыв» проекта от фактически разработанного программного обеспечения, то есть проект с каждой итерацией все больше «расходится» с собственной реализацией. В результате во многих случаях разработка становится неуправляемой модификация кода все более затруднительной, так как, по сути, отсутствует документированность в виде проекта. При наличии коллектива программистов ситуация усугубляется по тон же причине - отсутствие документа-проекта приводит к увеличению количества ошибок, нарушению связей между отдельными частями программного продукта. Стоит ли говорить о том, что к подобной разработке практически невозможно вернуться через какое-то время для ее доработки или создания на ее базе нового продукта. К сожалению, описанная ситуация не так уж редко встречается на практике.
Другое ограничение при традиционной разработке необходимость перепрограммирования приложения «вручную» или его перепроектирования при переходе на другую платформу. Несмотря на некоторые имеющиеся средства много-платформенной разработки, нельзя утверждать на 100 %, что при создании больших программных систем полностью отсутствует необходимость «ручной» доработки программного кода.
Нельзя не упомянуть и о такой довольно часто встречающейся на практике проблеме, как отсутствие ясного «взаимопонимания» между коллективом разработчиков и заказчиком и плохая управляемость разработкой. В силу изложенных выше причин, когда фактически отсутствует описание приложения, менеджер и заказчик полностью теряют контроль над состоянием разработки, так как выполнение этой функции потребовало бы от них владения языками программирования и других специфических знаний, что на практике встречается редко.
Также очевидно, что создание больших программных систем традиционными методами, включающими этап «ручного» кодирования, требует достаточно больших временных затрат, и разработка таких приложений растягивается на годы.