Диссертация (1145120), страница 42
Текст из файла (страница 42)
Ближайшим аналогом таких метафорявляются результаты Model-Based Interface Development (различные типовыеэкранные формы, автоматически генерируемые, например, по схеме базыданных) [217]. Однако результаты этой области не распространялись на сферу разработки ПО для электронных и публичных услуг.Модель для проектирования программно-аппаратных систем. Идея сборки ПО из набора готовых компонент высказывалась давно. Можно вспомнитьидею компании Microsoft 90-х годов прошлого века о создании рынка готовых компонент (технологии OLE/ActivX), а также успешно используемуюдля разработки информационных систем предприятий парадигму ERPсистем. В последнем случае разработка конкретной системы происходит набазе стандартных компонент, предлагаемых такими средами, как технологиикомпании SAP или система 1С.Следует отметить, что подходящим контекстом для реализации даннойидеи послужили линейки (семейства) программных продуктов (SoftwareProduct Lines/ Product Families).
В связи с этим следует вспомнить известнуюмонографию «Generative Programming: Methods, Tools, and Applications»[204], уже обсуждавшуюся в данной диссертационной работе ранее, в кото257рой готовые компоненты семейства предлагается разрабатывать на основеDomain Modeling с использованием диаграмм возможностей (Feature Diagrams). Использование этих компонент при разработке целевых продуктовавторы предлагают осуществлять с помощью специального конфигурационного процесса: известно, что практическое использование готовых компонент сопровождается их изменением, и существует много способов по реализации этих изменений (см., например, работу автора данной диссертационнойработы по разработке семейств систем реинжиниринга [91]).
Однако данныйподход является, во многом, «рамочным» и предполагает создание на его основе конкретных, более прикладных методов. К тому же, визуальное моделирование в данном подходе применяется очень ограниченно, для конфигурированияпредлагаетсяиспользоватьтекстовыепредметно-ориентированные языки.Во многом, по сходному пути идут авторы серии работ по сборочномупрограммированию К. М. Лаврищева и В. Н. Грищенко [112], [265], [331],[332], [333].
В этих работах сборочное программирование определяется какспособ разработки ПО, «характеризующийся сборочным построением программ из готовых «деталей», которыми являются программные объекты различной степени сложности». Далее, «под методом сборки понимается способсопряжения разноязыковых программных объектов в языках программирования, основанный на теории спецификации, и отображения (mapping) типови структур данных языков программирования, представленных алгебраической системой». В монографии рассматриваются способы интеграции программных объектов, и в рамках порождающего программирования (генерация кода продуктов по верхнеуровневым спецификациям, выполненным втерминах предметной области) упоминается UML как одно из возможныхсредств верхнеуровневых спецификаций, наряду с текстовыми DSL.
Авторырассматривают также DSM-подход «как один из способов определения разных сторон реализуемой предметной области и их трансформации к конеч258ному результату». Далее в монографии подробно обсуждаются вопросы сборочного программирования и смежные вопросы (интерфейсы, типы данных,компонентные технологии и пр.). При этом сборочное программирование обсуждается с разных сторон — принципы построения средств автоматизациисборочного программирования, различные методы сборочного построенияпрограммных систем, вопросы управления разработкой при сборочном программировании и пр. Однако рассматриваемый в рамках диссертационнойработы класс задач не попал в поле зрения авторов данной монографии.
Также в монографии, кроме видов моделей, не рассматривались DSM-методыпроектирования семейства с автоматическим порождением кода/конфигурации систем, хотя общая схема генерации кода по DSM-моделям приводиласьи обсуждалась.Продолжением идей генерационного программирования является монография [263], рассмотренная в данной диссертационной работе ранее, присравнении и соотнесении методологии предметно-ориентированного моделирования. В монографии определяются фабрики ПО (software factories) иподходы к их разработке. В данной монографии предметно-ориентированноемоделирование уже активно используется при разработке повторноиспользуемых активов. Однако предложенный подход требует доработки принепосредственном применении, и остаётся актуальной задача создания методов для более узких классов линеек программных продуктов.В 1999–2001 годах прошло три конференции под названием «Generativeand Component-Based Software Engineering» (GCSE).
В рамках этих конференций обсуждалось много различный идей и подходов (включая аспектноориентированное программирование, использование шаблонов, особенностиразличных языков программирования, стратегии к организации повторногоиспользования компонент и пр.), которые могут быть применены в рамкахвысокоуровневой компонентной разработки программного обеспечения.259Остановимся на ряде работ, предлагавших конкретные технологии и решенияк сборке продуктов семейства из готовых компонент.В работе [377] представлена универсальная (Domain Independent) инфраструктура разработки продуктов семейства на основе повторно используемых компонент. Пользователь собирает своё приложение из этих компонент,находящихся в специальном репозитории.
Пользователь собирает приложение визуально, в виде графа потоков данных. Сами авторы не предлагаютсредств визуализации, но ссылаются на имеющиеся на рынке инструментыKhoros, AVS, WebFlow, Iris Explorer. Получившийся граф (точнее его XMLпредставление) передаётся на исполнение вычислительному кластеру.
Данный подход использует DSM для конфигурирования продуктов семейства,однако не может быть применён к задаче, решаемой в диссертационной работе ввиду простоты нотации потоков данных и невозможности, в связи сэтим, использовать её для описания конфигурации оборудования программно-аппаратной системы.В работах [167], [168] представлен метод разработки семейств программных продуктов PuLSE и его часть PuLSE-CDA, предназначенная для разработки области (Domain) семейства. Следует отметить, что данные подходыориентированы на широкий класс приложений и не фокусируются на специфических задачах, выделенных в данной диссертационной работе.В работе [189] рассматривается вопрос генерации архитектур для программных систем на основе графа свойств-решений (feature solution graph).Этот граф примечателен тем, что он содержит в себе информацию для выбора свойств архитектуры (свойства) конкретного продукта.
В предлагаемом вдиссертации подходе в качестве множества свойств выступает база данныхоборудования, повторно-используемые компоненты и их связи с элементамиоборудования (все это хранится в специальном XML-файле). То есть подход,представленный в [189], концептуально подобен нашему подходу, но реализован по-другому — он не использует визуальное моделирование для задания260выборки (в нашем случае эта выборка задаётся с помощью диаграмм чертежей оборудования), его свойства — это требования (у нас это элементы оборудования), наконец, он не ориентирован на рассматриваемый в диссертациикласс приложений.Из приведённого выше обзора можно заключить, что имеется большоеколичество подходов, исследующих сборку ПО из готовых компонент, поразному рассматривающих «готовность» компонент и сам процесс сборки.Приэтомвсеактивнееиспользуетсяпредметно-ориентированноемоделирование — сначала в виде Feature Diagrams [297], потом значительношире(см.,например,работу[263]).Послетакихисчерпывающихконцептуальных работ по сборке продуктов семейств из готовых компоненткак [112], [204], [263], а также многосторонних исследований в областисемейств программных продуктов (см.
[210], [373] и ряд других работ), и всвязисразвывшемсязапоследниегодыаппаратомпредметно-ориентированного моделирования, оказываются востребованными подходы,ориентированные на специализированные классы приложений и активноиспользующие DSM-подход не только для описания предметной областисемейства, но и для конфигурирования конечных продуктов, при этомопирающиеся на автоматическую генерацию различных артефактов (кода,конфигурации готовых компонент, загрузочного образа ПО и т.д.). Такое решение для специализированного класса приложений и было предложено вданной работе.Теперь соотнесём язык THCL с другими имеющимися языками проектирования программно-аппаратных систем. Общая структура языка THCL,предложенного в рамках моделидля проектирования программно-аппаратных систем, во многом, сходна с языком SDL [285], [286], которыйтакже имеет визуальную и не визуальную части, ориентирован на моделирование телекоммуникационных блоков (аппаратных и программных модулей) и связей между ними и т.д.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
