Современные исследования в области формирования оценки изменений программного обеспечения

Мадорская Ю.М.

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

  • Разработка трассировочных схем для существующих методов моделирования программных систем  и реализация трассировки для конкретной технологии проектирования.
  • Разработка методов автоматического распознавания связей между проектными данными и определения наиболее вероятной области распространения изменений
  • Формализация и проработка семантики трассировочных моделей

Рассмотрим подробнее каждое направление.

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

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

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

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

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

Классической работой в данном направлении является работа Letelier «A Framework for Requirements Traceability in UML-based Projects» [76].

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

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

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

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

Авторы указывают на то, что использование внутренних механизмов нотации UML для управления трассировочной информации «загрязняет» проектную модель, понижает степень единообразия, осложняет обмен между инструментарием проектирования, а главное, не позволяет использовать общий механизм трассировки в случае, если при проектировании используется не только нотация UML, но и другие методы моделирования.  Rech и соавторы рассматривают альтернативные варианты реализации и предлагают использовать обобщенный механизм аннотаций, не зависящий от механизмов расширения UML, но заложенный в MOF – обобщенном языке моделирования, являющимся базовым для рассматриваемых в работе нотаций BPMD и UML.

В работе [94]  отмечается важность поддержания трассировочных связей, начиная с уровня так называемых CIM-моделей, которые представляют собой модели программного обеспечения, не зависящие от технологии разработки, например, модели бизнес-процессов предприятия. Для реализации этой концепции предлагается снабжать трассировочными аннотациями модели, выполненные в соответствии с Business Process Modeling Notation BMPN и Business Process Definition Metamodel BPMD, где первая является графической нотацией для второй, а также трассировать проектные данные этого уровня к моделям UML.

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

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

Так же как и в работе [76], в работе [94] не обозначены конкретные цели выполнения трассировки.

Разработка методов автоматического распознавания связей между проектными данными и определения наиболее вероятной области распространения изменений

Идеальное решение проблемы нахождения трассировочных связей между основными проектными моделями лежит в области архитектуры, управляемой моделями — Model Driven Architecture MDA. Подход, декларируемый в рамках данной концепции, предполагает разработку платформенно-независимой модели системы, затем ее автоматическую трансформацию  в платформенно-зависимую модель, на основании которой должна производиться автоматическая генерация программного кода. Если набор таких трансформаций осуществим, то в ходе их проведения возможно фиксировать трассировочные связи и использовать их впоследствии для оценки распространения изменений.

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

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

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

Другая группа исследователей, ориентируясь на то, что в рамках одного проекта, как правило, применяется более широкий спектр методологий разработки и документации, (что в большей степени соответствует практике, чем позиция Briand и соавторов), предлагает использовать различные методы информационного поиска (information retrieval), в частности, методы анализа и ранжирования связей в проектной документации в соответствии с алгоритмами латентно-семантического индексирования (Latent Semantic Indexing LSI).

LSI основывается на том принципе, что слова, используемые в одинаковом контексте часто имеют одинаковое значение [103] и это позволяет выявлять неявные семантические связи между понятиями в неструктурированном тексте.

В публикации [78] приведен хороший обзор работ по данной тематике, а также приведено описание нескольких проектов, в которых проводилась оценка LSI для задач трассировки. Для структурирования данных, полученных при помощи алгоритмов LSI, а также ограничения множества поиска, авторы предлагают использовать модель трассировки, определяющую разрешенное множество типов проектных данных (документов) и связей между ними. Предложенная модель трассировки является отражением процесса разработки одной из компаний разработчиков ПО, на базе которой проводилось исследование, и содержит такие категории как Требование заказчика, Техническое требование, Артефакт проектирования, Системный тест и несколько других.

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

По результатам работы Lormans и Deursen приходят к выводу, что для получения приемлемых результатов необходимо, чтобы проектные решения были хорошо структурированы.

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

В работе [112] авторы также апеллируют к тому, что качественная трассировка невозможна без учета глубоких семантических связей между проектной документацией. Понимая процесс трассировки в широком смысле  как выявление связей между всеми проектными артефактами, авторы делают упор на выявление связей между проектной документацией и исходным кодом. Для этого предлагается использовать онтологический подход. Zhang и соавторы разработали две обширные онтологии, включающие в себя более ста понятий, связанных с исходным кодом, и еще больше понятий, связанных с документацией. Онтология исходного кода построена в соответствии с объектно-ориентированной парадигмой и содержит такие понятия как Файл, Источник, Пакет, Класс, Метод, Переменная, Выражение, а также понятия, ориентированные на программирование на языке java. Онтология документации содержит как текстовую модель, включающую такие понятия как Параграф, Предложение, так и понятия предметной области разработки, например, Паттерн проектирования.

Между категориями онтологий определено множество отношений.  Используя возможности логики предикатов, авторы определяют транзитивные отношения и отношения категоризации (подкласс), что позволяет выявлять отношения между элементами онтологии, не определенные в явном виде. Две представленные онтологии – онтология документации и онтология исходного кода объединяются авторами на том основании, что документация и код должны содержать одинаковые экземпляры понятий, такие как класс, метод и переменная. Безусловно, это является ограничением данного метода.

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

Возможность отражения опыта оценки изменений в виде такого показателя как стабильность элемента архитектуры, представлена в публикации [98]. Авторы предлагают разработчикам использовать модель трассировки, связывающую элементы архитектуры и причины, обуславливающие то или иное проектное решение. Каждому элементу архитектуры, участвующему в трассировке, проектировщик, на основании собственного опыта, должен назначить вероятность изменения. Например, если это стандарт предметной области, то авторы предлагают указывать стабильность – 100%. Тогда, используя аппарат Байесовских сетей,  возможно оценить вероятность распространения тех или иных изменений по предложенной модели трассировки.

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

Формализация и проработка семантики трассировочных моделей

В работе [58] требование определяется как «свойство которое должна демонстрировать система» и дается следующая формализация:

Требование R определяется как пара <P, S>, где P это предикат (свойство) и S это множество систем, удовлетворяющих P, т.е для любого s входящего в S: P(s).

Авторы формализуют такие отношения между требованиями как «требует», «уточняет», «содержит», «конфликтует». Например, отношение «требует» описывается следующим образом:

Пусть R1 и R2 требования, такие, что R1=<P1, S1> и R2=<P2,S2>. R1 требует R2 тогда и только тогда когда для каждого s1 принадлежащего  S1 выполняется, что s1 принадлежит S2. Из этого определения следует, что S1 принадлежит S2. Это отношение является нерефлексивным, несимметричным и транзитивным. На основании определений выводятся семь ограничений для проверки согласованности модели, например:

  • Если (R1 уточняет R2), то отрицание (R2 требует R1)
  • Если (R1 требует R2), то отрицание (R1 конфликтует R2)

Авторы предлагают рассматривать следующие типы изменений модели требований (см. таб. 1.2):

Таблица 1.2 Типы изменений модели требований.

Изменения в требовании Изменения в отношении между требованиями
Добавлено новое требование

Требование удалено

Требование изменено

Добавлено новое отношение

Отношение удалено

Отношение изменено

Для каждого типа отношений между требованиями и варианта изменений предлагается правило распространения изменений.

Например:

  • Если R1 уточняет R2 и R1 удалено, то R2 попадает в измененные, и отношение «уточняет» должно быть удалено.
  • Если R1 уточняет R2 и отношение между R1 и R2 удалено, то требований подлежащих изменению нет, а отношения, наследуемые от данного отношения, попадают в изменяемые отношения.

В качестве технологии реализации модели авторы предлагают выполнять описание моделей в виде онтологий с использованием языка OWL. Это дает возможность использовать механизмы вывода инструментов управления онтологиями. Для того, чтобы проводить вывод и проверки на непротиворечивость, пользователь должен представить требования в виде экземпляров (не классов) в онтологии. В качестве инструмента поддержки выбрана система проектирования онтологий Protégé [13].

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

Проблема, с которой столкнется реальный проектировщик системы при использовании данной модели, – это  сложность восприятия и отражения категорий модели на реальные объекты проектирования.

Формализация понятия «требование», введенная Goknil и соавторами [62], предполагает воображение множества некоторых систем, в то время как в ходе разработки речь идет об одной системе, к которой определяются требования. Определение отношений между требованиями в предложенной авторами модели строится уже на двух множествах систем вместо одной системы, относительно которой аналитик формулирует требования. Аналитик должен вручную определить все связи между требованиями, мысленно оперируя абстрактными категориями, не находящими отражения в реальности. Такой подход существенно затрудняет работу аналитика на самом раннем этапе проектирования системы. Где аналитику взять (пусть даже в мысленном эксперименте) два множества систем для того, чтобы определить, существует ли отношение заданного типа между требованиями или нет, когда все его мысли сконцентрированы относительно одной разрабатываемой системы?

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

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

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

Хотите сослаться на эту статью? Используйте правильную ссылку:

Мадорская Ю.М. Современные исследования в области формирования оценки изменений программного обеспечения. //Практика проектирования систем.-2013. [электронный ресурс] — Режим доступа: http://reqcenter.pro/traceability-review/, свободный. — Загл. с экрана

Литература

  • [13] Добров Б. В.  Онтологии и тезаурусы: модели, инструменты, приложения: учебное пособие / Б.В. Добров, В.В. Иванов, Н.В. Лукашевич, В.Д. Соловьев. – М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаб. знаний, 2009. – 173 с.
  • [51] Briand L.C., Labiche Y., Yue,T. Automated traceability analysis for UML model refinements // Inf. Softw. Technol. 51, 2, 2009. – P. 512-527.
  • [58]  Göknil A.Kurtev I.  and van den Berg, K.G.  Change Impact Analysis based on Formalization of Trace Relations for Requirements // ECMDA Traceability Workshop (ECMDA-TW), Berlin, Germany, 2008. – P.  59-75.
  • [62].Hove D.,  Göknil A., Kurtev I.,  van den Berg K.G.,  de Goede K.  Change Impact Analysis for SysML Requirements Models based on Semantics of Trace Relations // Proceedings of the ECMDA Traceability Workshop  2009, Enschede, the Netherlands.  Centre for Telematics and Information Technology, University of Twente, 2009. –  P. 17-28.
  • [76]  Letelier P.  A Framework for Requirements Traceability in UML-based Projects // Proc. of 1st International Workshop on Traceability in Emerging Forms of Software Engineering. In conjunction with the 17th IEEE International Conference on Automated Software Engineering, Edinburgh, U.K., 2002. – P. 32-41.
  • [78]  Lormans M, van Deursen A.  Reconstructing requirements traceability in design and test using latent semantic indexing / Preprint available as technical report TUD-SERG-2007-007. Delft University of Technology, 2009. – 39 p.
  • [84] Mirarab S., Hassouna A., Tahvildari L. Using Bayesian Belief Networks to Predict Change Propagation in Software Systems // 15th IEEE International Conference on Program Comprehension, (ICPC ’07), 2007. – P. 177-188.
  • [94] Rech J., Schmitt V.  Embedding Information about Defects, Decisions, Context, Quality, and Traceability in CIM- and PIM-level Software Models // Information and Software Technology (IST), 2009. – P.  21.
  • [98] Tang A., Jin Y., Han J. A rationale-based architecture model for design traceability and reasoning// J. Syst. Softw. 80, 6, 2007. – P.  918-934.
  • [112] Zhang Y., Witte R., Rilling J., Haarslev V. Ontological approach for the semantic recovery of traceability links between software artefacts // Software, IET, 2008.  – P. 185-203.