Диссертация (1145120), страница 19
Текст из файла (страница 19)
После реализации этой обратной связи пользователи продолжают использовать решение.Следует отметить, что пилотного проекта может и не быть, если пользователи активно вовлечены в процесс разработки решения, или создаётся следующая версия решения и пользователи знакомы с его функционалом. В этихслучаях может использоваться более плавный вариант внедрения решения.Передача — после того как реализован основной функционал решения ибюджет проекта заканчивается, требуется, чтобы команда разработчиков передала решение заказчику. Обычно решение уже фактически внедрено, нотребуется передать исходные коды, инфраструктуру разработки, соответ-102ственно обучить разработчиков сопровождения (если они не из команды разработчиков решения).На этой фазе также может проводиться дополнительное обучение пользователей, создание и передача пользовательской документации. Однако основное обучение проходит в рамках проекта, на базе промежуточных демонстраций продукта, пилотного проекта, и этапа «Разработка и использование».Тем не менее, круг пользователей может быть расширен после сдачи решения.После передачи решения команда ещё некоторое время осуществляетнадзор — помогает разработчикам сопровождения, исправляет некоторыеошибки, консультирует пользователей.
После того, как будет принято решение, что продукт стабильно функционирует, а команда сопровождениясправляется со своими задачами, команда разработчиков завершает свою работу.Эксплуатация и сопровождение — здесь ключевым фактором являетсяналичие постоянно действующей команды сопровождения. Этой командойможет быть и один человек — главный автор решения, которому выделяются, при необходимости, дополнительные ресурсы.
Важно, чтобы DSMрешение было постоянно «живым»: исправлялись ошибки, реализовываласьновая функциональность и, что особенно важно, — решение должно переноситься на новые версии DSM-платформы, чтобы не превращаться в legacyсистему. При этом важно уделять должное внимание вопросам миграциипрежних моделей пользователей [32].Сопровождение лучше организовать как последовательность регулярноговыпуска новых версий, не допуская замены отдельных бинарных файлов свысылкой обновлений по электронной почте. С другой стороны, не следуетдопускать излишнего формализма — связь авторов и пользователей должнабыть живой, открытой, не обременительной для сторон. Процесс эксплуатации и сопровождения схематично изображён на рис.
2.4.103ЭксплуатацияПланированиеновой версииВыпуск новойверсииПередача вэксплуатациюМиграциямоделейпользователейРис. 2.4. Эксплуатация и сопровождение DSM-решенияУспешные DSM-решения эксплуатируются годами, иногда — десятилетиями. Это, в частности, означает, что они могут устареть: так, для генерационных DSM-решений, которые генерируют целевые приложения или их фрагменты по моделям, устаревают целевые платформы генерации.
Меняютсятакже версии DSM-платформ, могут меняться и другие технологи, с помощью которых было реализовано решение. Наконец, меняется тот контекст, вкотором решение работает, и этот контекст тоже может требовать коренныхизменений DSM-решения. Таким образом, оказывается необходимой модернизация решения.Важно отметить, что модернизация является весьма трудоёмким процессом, и её лучше не проводить в фоновом режиме, то есть рамках эксплуатации и сопровождения DSM-решения. Более целесообразно организовать новый DSM-проект, который уже не будет имеет многих рисков, существовавших при исходном созданиияDSM-решений. Попытки делать модернизациюв фоновом режиме часто приводят к провалам.1042.5 Сравнения и соотнесенияК настоящему времени выполнено большое количество исследований вобласти предметно-ориентированного моделирования — см.
обзорные работы [171], [237], [258], [358], [301]. Описание различных DSM-платформ можно найти в работах [115], [82], [301]32. Следует отметить, что в данной диссертационной работе в рамках сравнения и соотнесения предложенной методологии, нас интересуют в большей степени концептуальные разработки вобласти DSM, нежели отдельные методы и решения. Поэтому сконцентрируемся на результатах тех исследований, которые описывают DSM-подход какединое целое, или же концентрируются на аспектах, затронутых в предложенной методологии.Пожалуй, первой фундаментальной работой, в которой систематическирассматриваются предметно-ориентированные языки и их роль в программировании, является монография K.
Czarnecki и U. Eisenecker [204]. Несмотряна то что авторы пишут о предметно-ориентированных языках программирования, ряд ясно сформулированных в монографии идей активно использовался впоследствии при развитии предметно-ориентированного моделирования.Вот эти идеи. Контекст применения предметно-ориентированных языков — разработка линеек программных продуктов (именно в этом направлениидвигались более поздние исследователи, в частности, J. Greenfield иего исследовательская группа [259], [260], [261], [262], [263]). Рассмотрение предметно-ориентированных языков как более абстрактных средств разработки, приближенных к предметной области— см.
определения предметно-ориентированного моделирования в[301] и модельно-ориентированной разработки в [186], которые32Следует отметить, что в области DSM очевидна нехватка обзоров — существует многоразных направлений и, собственно, самих исследований, однако структурированного систематического обзора данной области на настоящий момент отсутствует.105очень близки к определению предметно-ориентированных языков вданной монографии. Использование предметно-ориентированных языков в контексте генерации кода. Этой точки зрения придерживается большинство исследователей и, в частности, она полностью определила и даже обусловила исследования крупнейшей группы в области предметноориентированного моделирования —J.–P. Tolvanen, S. Kell и др.[300], [301], [302], [303], [304], [305], [306], [374], [375], [440].Предмет монографии — генерационное программирование, определяемоеавторами как парадигма программной инженерии, предназначенная для разработки линеек программных продуктов и позволяющая автоматическое создание (на основе специфицированных требований) финальных или промежуточных продуктов, собранных из элементарных повторно используемыхкомпонент, гибко настраиваемых с помощью конфигурационной информации(configurationknowledge).Парадигмаиспользуетмодельно-ориентированный подход для описания модели линейки (domain modeling).Авторы вводят понятие generative domain model, обозначающее специфическую инфраструктуру (среду разработки) линейки, куда входит модель линейки, сборочные компоненты, из которых формируются продукты линейкии конфигурационная информация, которая позволяет сделать выборку изсборочных компонент при разработке конкретного продукта на основе модели линейки (последняя таким образом выполняет в некотором роде навигационную задачу).
При этом предметно-ориентированный язык (Domain Specific Language, DSL) понимается как средство программирования, наряду,например, с аспектно-ориентированным программированием [141]: авторывидят задачу DSL в том, чтобы повысить уровень абстрактности разработки,предоставив пользователям возможности разработки ПО в терминах предметной области, то есть вместо обычного программирования конфигурировать целевое ПО в терминах элементов предметной области (модель линей106ки), адресуясь к реализованным повторно используемым компонентам.
Приэтом DSL используется уровнем ниже моделирования предметной области,обслуживая последнее, то есть конфигурирование повторно используемыхкомпонент происходит без помощи визуального моделирования. Авторытакже предполагают, что в одном проекте может использоваться несколькоDSL. В целом разнообразие различных языковых средств, предполагаемоеавторами при разработке линейки продуктов, напоминает разнообразие языков при разработке больших систем на менфреймах — там кроме основногоязыка программирования также мог использоваться язык вызова функцийоперационной системы, язык запросов к базе данных, язык разработкиэкранных форм33.
Более того, идея DSL явно прослеживается при разработкебольших информационных систем с помощью языка PL/1 с активным применением макросредств — фактически, с помощью макроопределений создавались дополнительные DSL [320].Следует отметить, что дальнейшее развитие предметно-ориентированногомоделирования пошло по пути визуализации более значительной части информации, чем это предлагалось в монографии K. Czarnecki и U.
Eisenecker.Однако при этом произошло «замалчивание» тестовых DSL в контексте модельно-ориентированной разработки. Но автор диссертационной работы считает, что для генерации программного кода по моделям недостаточно узкойспециализации моделей и наличия только визуальных спецификаций. Необходима также спецификация различных соглашений и часто — использование урезанных версий обычных языков программирования для «текста в ку-33Однако идея использовать множество DSL в одном (пусть даже очень крупном) проекте, на взгляд автора диссертационной работы, является не очень практичной, так как разработчикам непросто преодолевать возникающие разрывы. В качестве дополнительногоаргумента в пользу этого мнения можно привести проблемы практического примененияформальных методов, активно обсуждаемые в литературе [310], [402], [444], [414].
Можносказать, что в этом случае также стоит задача внедрить в производство специфическихязыков (DSLs).107биках»34. Но в этой работе мы не будем вдаваться в детали генерации кодапо моделям, отметим лишь, что, во многом, дополнительную информацию,необходимую для генерации и других видов формальной обработки моделей,стали описывать в виде ограничений корректности/целостности, используядля этого язык OCL.Опишем, как K. Czarnecki и U. Eisenecker определили процесс реализацииинфраструктуры линейки — данный процесс в некотором смысле похож намодель разработки DSM-решений, представленную в данной диссертационной работе. Предложенный процесс делится на следующие шаги: анализ предметной области (domain analysis); проектирование предметной области (domain design), включая разработку DSL; реализация (domain implementation), включающая реализацию DSL, атакже основных повторно используемых активов семейства.Каждый из шагов подробно детализирован, но эта детальность в монографии уменьшается от начала к концу процесса: первый шаг описан подробнеевсего, второй шаг — уже существенно менее, третий шаг, фактически, не детализирован вовсе.
То есть основной упор процесса делается именно на анализ предметной области. Следует отметить, что монография не даёт строгогоопределения поставки разрабатываемой инфраструктуры, концентрируясьлишь на методах и подходах и являясь, скорее, энциклопедией, чем промышленным руководством.Исследовательская группа в составе J. Greenfield, K. Short и др. выпустилав начале 2000-х годов ряд статей [259], [260], [261], [262] и монографию34Именно по такому пути в 80-х годах пошли создатели отечественной линейки телекоммуникационных систем В.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
