Заключение

Компонентное программирование

Ключевое направление развития парадигм программирования связано с тенденцией компонентного подхода к разработке программ, верификации свойств их компонент и межязыковой интеграции программных комплексов. Такой подход интенсивно развивается в проектах типа .Net [].

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

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

Реально понятие "компонент" проявляется как взаимосвязь понятий "обьекты", из которых строится текст или код программы, и "процессы", возникающие при функционировании, взаимодействии и разработке ряда ИС. С одной стороны, компонентами называют конструкции, используемые в разных программах. С другой стороны, этим же термином называют части или элементы структурированных данных, включая системы файлов и информационные комплексы. Совмещение этих сторон в общем понятии соответствует пониманию программ как разновидности данных. Разноплановость подходов к выделению компонентов подобно различиям в рассмотрении структуры материи с точки зрения физики, химии, геологии, биологии и других наук. Оно обусловлено независимостью влияния отдельных аспектов изучения, проектирования, построения и функционирования ИС на характер их применения и результативность разработки. Эта независимость фактически признана в технологии UML, поддерживающией ряд автономно создаваемых, одновременно существующих форм представления и структуризации проектируемой программы (бизнес-логика, ООП, временные диаграммы и размещение компонентов) [,].

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

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

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

Перенос внимания с разработки программ на разработку их компонентов требует пересмотра моделей ЖЦ, охватывающих процессы разработки множества программ и их версий, в которых происходит накопление типовых компонентов и удостоверение их работоспособности. За 50 лет программирования доля изученных задач разработки ИС систематически возрастала, что и явилось основанием перехода к компонентному программированию. Функциональный подход способствует повышению уровня изученности задач, технологичное решение которых выходит за пределы стандартных парадигм программирования [].

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

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

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

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

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

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

Анализ функционирования

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

Производительность зависит от следующих факторов:

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

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

Основная идея анализа поведения РИС - вся система однородна и исходный текст ее компонентов доступен для анализа. Это не соответсвует практике применения и создания компонентов по ряду причин:

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

Методика такого анализа технически подобна мемо-функциям в функциональном программировании.

Моделирование парадигм программирования

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

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

Современные ИТ сделали доступным для практики богатейший материал, само обилие которого является серьезной проблемой для его освоения и применения []. Этот материал является базой для оттачивания профессионального мастерства по определению ИС из готовых компонентов. Работа с компонентами подразумевает многократность использования, вариативность реализации и повторность разработки. Это влечет необходимость учета разных критериев и требований, подвергающихся непредсказуемой эволюции. Функциональный подход к компонентному программированию позволяет формализовать на метауровне особенности разных технологий программирования, что дает основания для методики активного обучения программированию и конструированию ИС из компонентов СФП.

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

В данном ознакомительном курсе не рассмотрены такие парадигмы, как учебное и теоретическое программирование, программирование баз данных, сайтов, сервисов, языки разметки и ряд других, освоение которых происходит естественно на практике при начальном обучении программированию. В таблице 15.1. указаны курсы Интернет-Университета информационных технологий, дополняющие материал лекций данного курса.