Changing and Tracing of Software Requirements at Level of Conceptual Classes

Abstract

The article explores the problem of automating the description of Use Cases at the stage of forming requirements in the design of software products. Methods for correcting the model of conceptual classes in connection with changes in the formulation of various items of scenarios for Use Cases are proposed and tracing of each item of the Use Case scenario in conceptual classes and their methods and attributes. Changing requirements at the level of use cases description means deleting previously compiled items of the scenario and/or adding new ones. Deleting a Use Case is considered to be a consecutive deletion of all of its items, and editing a scenario item as a deletion followed by a new edition. The methods of removing all types of scenario items of the proposed classification in various possible situations are considered: the class created earlier was not used in other items of this or other use cases; the class created earlier was not used in other items of this or other use cases, but the function contained in the class has references to other functions; the class created earlier was used in other items of this or other use cases and the function contained in the class has no reference to other functions; the class created earlier was used in other items of this or other use cases and the function contained in the class has references to other functions. Methods have been developed for determining the relationships of Use Case and its item with classes, their methods and attributes that implement this item (direct tracing), and determining the relationship of any data element or class method with various Use Case and their items (reverse tracing). The proposed method for conceptual classes correcting allows automatic deleting various items in scenarios while maintaining the correct presentation of conceptual classes. It is shown that there is a significant reduction in time for correcting classes in an automated mode compared to the traditional manual mode. The tracing method also significantly reduces the time it takes to find the connections between the Use Case.

У статті досліджується проблема автоматизації опису варіантів використання на етапі формування вимог при проектуванні програмних продуктів. Запропоновано методи коригування моделі концептуальних класів у зв'язку зі змінами в формулюванні різних пунктів сценаріїв варіантів використання або Use Case і трасування кожного пункту сценарію Use Case в концептуальні класи, в їх методи і атрибути. Зміна вимог на рівні опису прецедентів означає видалення раніше складених пунктів сценарію і / або додавання нових. Видалення Use Case розглядається як послідовне видалення всіх його пунктів, а редагування пункту сценарію - як видалення з подальшим складанням у новій редакції. Розглянуто способи видалення всіх типів пунктів сценарію запропонованої класифікації в різних можливих ситуаціях: створений раніше клас не використовувався в інших пунктах даного, або інших прецедентів; створений раніше клас не використовувався в інших пунктах даного, або інших прецедентів, але функція, що міститься в класі, має посилання на інші функції; створений раніше клас використовувався в інших пунктах даного, або інших прецедентів і функція, що міститься в класі, не має посилання на інші функції; створений раніше клас використовувався в інших пунктах даного, або інших прецедентів і функція, що міститься в класі, має посилання на інші функції. Розроблено методи визначення зв'язків Use Case і його пункту з класами, їх методами і атрибутами, які реалізують цей пункт (пряме трасування) і визначення зв'язку будь-якого даного або методу класу з різними Use Case і їх пунктами (зворотнє трасування). Запропонований метод коригування концептуальних класів дозволяє в автоматизованому режимі видаляти різні пункти сценаріїв, зберігаючи коректне уявлення концептуальних класів. Показано, що спостерігається істотне скорочення часу на коригування класів в автоматизованому режимі порівняно з традиційним ручним режимом. Метод трасування також істотно скорочує час на пошук зв'язків між Use Case.

В статье исследуется проблема автоматизации описания вариантов использования на этапе формирования требований при проектировании программных продуктов. Предложены методы корректировки модели концептуальных классов в связи с изменениями в формулировке различных пунктов сценариев вариантов использования или Use Case и трассировки каждого пункта сценария Use Case в концептуальные классы, в их методы и атрибуты. Изменение требований на уровне описания прецедентов означает удаление ранее составленных пунктов сценария и/или добавления новых. Удаление Use Case рассматривается как последовательное удаление всех его пунктов, а редактирование пункта сценария – как удаление с последующим составлением в новой редакции. Рассмотрены способы удаления всех типов пунктов сценария предложенной классификации в различных возможных ситуациях: созданный ранее класс не использовался в других пунктах данного, либо иных прецедентов; созданный ранее класс не использовался в других пунктах данного, либо иных прецедентов, но функция, содержащаяся в классе, имеет ссылки на другие функции; созданный ранее класс использовался в других пунктах данного, либо иных прецедентов и функция, содержащаяся в классе, не имеет ссылки на другие функции; созданный ранее класс использовался в других пунктах данного, либо иных прецедентов и функция, содержащаяся в классе, имеет ссылки на другие функции. Разработаны методы определения связей Use Case и его пункта с классами, их методами и атрибутами, реализующими этот пункт (прямая трассировка) и определения связи любого данного или метода класса с различными Use Case и их пунктами (обратная трассировка). Предложенный метод корректировки концептуальных классов позволяет в автоматизированном режиме удалять различные пункты сценариев, сохраняя корректное представление концептуальных классов. Показано, что наблюдается существенное сокращение времени на корректировку классов в автоматизированном режиме сравнительно с традиционным ручным режимом. Метод трассировки также существенно сокращает время на поиск связей между Use Case.