Стратегия повторного использования

Объектно-ориентированный подход к разработке компьютерных обучающих систем с использованием универсального языка моделирования UML и CASE-средства IBM Rational Rose позволяет создавать визуальные модели, обобщенные архитектурными и процедурными представлениями. Системное проектирование программных систем включает два основных аспекта: архитектурное проектирование и детализированное проектирование.

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

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

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

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

Реализация повторного использования зависит не только от применения объектно-ориентированной технологии и корректного описания классов, но и от многих технических, организационных и социальных аспектов разработки программных систем. Предпосылкой ускорения процесса перехода на компоненты многократного использования является применение языка моделирования UML, обладающего свойствами расширяемости и хорошо определенной семантикой. В UML повторное использование (reuse) определяется как «использование уже существующего артефакта (artefact)» [17].

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

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

Среди образцов для повторного использования наиболее распространенными являются следующие категории: шаблоны анализа, архитектурные шаблоны, шаблоны проектирования, шаблоны кодирования. Основное различие между категориями образцов состоит в уровне абстракции. Например, архитектурные шаблоны предназначены для работы со структурой программных систем, подсистем или компонентов и их взаимоотношениями. Шаблоны проектирования, напротив, работают на уровне классов и объектов и базируются на проверенных решениях проблем, которые возникают при проектировании программного обеспечения в определенном контексте [23, 89].

Для шаблонов проектирования в дальнейшем будем использовать термины «паттерны» (pattern) или «проектные паттерны», поскольку термин «шаблоны» употребляется в отечественной литературе для данной предметной области чаще всего как синоним шаблонов кодирования.

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

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

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

Следует подчеркнуть возрастающую роль паттернов как архитектурных сущностей в связи с новыми тенденциями в разработке программного обеспечения, в частности с переносом акцента с написания кода на моделирование. С этой инициативой в 2001 г. выступил международный консорциум OMG, предложив идею модульно-управляемой архитектуры — Model Driven Architecture (MDA)^[1].

Суть MDA можно кратко охарактеризовать следующим образом. После формирования набора требований разработчики создают системную модель, согласно этим требованиям. В исходной модели фиксируются эти требования, но отсутствует привязка к какой-либо конкретной технологической платформе. С использованием набора правил среда модельно-управляемой разработки затем преобразует эту платформенно-независимую модель (Platform-Independent Model, PIM) в модель конкретной платформы (Platform-Specific Model, PSM).

Термин «платформа» в спецификациях MDA используется достаточно свободно, означая не только конкретную операционную систему, но и языковую платформу, например, Java или Python, и даже распространенные практические приемы разработки, такие как создание методов доступа к атрибутам класса. С идейной точки зрения, эти преобразования понижают уровень абстракции путем уточнения некоторых аспектов PIM.

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

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

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

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

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

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

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

• [1] Отметим, что средства моделирования в составе IBM Rational Software Architect поддерживают Model Driven Architecture (MDA)