Automated Software Tool Support for Checking the Inconsistency of Requirements

Handling inconsistency in software requirements is a complicated task which has attracted the interest of many groups of researchers. Formal and semi-formal specifications often have inconsistencies in the depicted requirements that need to be managed and resolved. This is particularly challenging when refining informal to formalized requirements. We propose an automated tool with traceability and consistency checking techniques to support analysis of requirements and traceability between different representations: textual, visual, informal and formal

Logical Approach: Consistency Rules between Activity Diagram and Class Diagram

Requirements engineering (RE) is a fundamental in software development process. Requirements engineering encompasses activities ranging from requirements elicitation and analysis to specification, verification and validation. Poor requirements have been proved to be a major cause of software problems such as cost overruns, delivery delays, failure to meet expectation and degradation. Requirements validation especially models validation has gained quite an interest from a lot of researchers. In recent times, several researchers have expressed a great deal of interest in requirements validation, specifically models validation. The field of research related to consistency checking has undergone a considerable boom from time to time. Numerous methods, approaches and techniques have been recommended to address the requirements inconsistency issues, particularly in models validation. In the software development industry, UML modelling has been extensively used. The different forms of the UML model that characterise the system from various perspectives somehow establish a relation among the models to keep them inseparable from one another. This is the reason why the inconsistency becomes unavoidable. The inconsistency in the models arises when there is an overlap of the elements of the various models representing the different parts of the system and an absence of cooperation. In this paper, the emphasis is given on the consistency rules that exist between the two models. The focus is also on the class diagrams and activity, and the conversion of the rules into logical predicates, where the logical predicates are assessed with a sample case study that constitutes of the two models

A UML Reuse Framework and Tool for Requirements Engineering

Requirement Engineering (RE) activities are critical by nature and mostly manual. Some automated support for tasks helps requirements engineers to reduce manual labor and, consequently, reduce defects rates and increase reuse and motivation. In this paper, we introduce a UML framework and tool support which automates part of the RE process. Using UML stereotypes as the core of this solution, we created a set of integrated tools composed by: (1) a reusable framework that models RE behavior patterns that are typically present in information system projects; (2) a function that allows the reuse of information provided by entity modeling; (3) a tool that automates the generation of application prototypes; (4) a tool for counting IFPUG Function Points; and (5)a tool that analyzes specific types of defects. Our findings indicate that the framework and the automated support are effective at RE modeling and review.  In addition, they increase motivation and promote team engagement, through elimination of repetitive activities.Sociedad Argentina de Informática e Investigación Operativ

Especificación formal en OCL de reglas de consistencia entre los diagramas de clases y casos de uso de UML y el modelo de interfaces

En el ciclo de vida del software, durante las fases de definición y análisis, se realiza una especificación de los requisitos. Para ello, es necesario realizar un proceso de captura de las necesidades y expectativas de los interesados, que se traduce posteriormente en un conjunto de modelos que representan tanto el problema como su solución. Por lo general, la mayoría de esos modelos se expresan en el lenguaje de modelado unificado –UML-, que define un conjunto de artefactos que permiten especificar los requisitos del software, los cuales deberían guardar consistencia, cuando se trate del mismo modelo. Sin embargo, la consistencia entre diferentes artefactos no se encuentra definida en la especificación de UML y poco se ha trabajado con este tipo de consistencia. En este artículo se propone un método para verificar la consistencia entre el diagrama de clases y el diagrama de casos de uso de UML de una manera formal. Dicho proceso se lleva a cabo evaluando una serie de reglas definidas en el lenguaje de restricciones de objetos –OCL- que se deben cumplir para garantizar que la información brindada por dichos modelos sea consistente. Como se reconoce la participación de los dos diagramas en la elaboración de las interfaces gráficas de usuario –GUI–, se define adicionalmente la consistencia con este artefacto

Especificación formal en OCL de reglas de consistencia entre los diagramas de clases y casos de uso de UML y el modelo de interfaces

En el ciclo de vida del software, durante las fases de definición y análisis, se realiza una especificación de los requisitos. Para ello, es necesario realizar un proceso de captura de las necesidades y expectativas de los interesados, que se traduce posteriormente en un conjunto de modelos que representan tanto el problema como su solución. Por lo general, la mayoría de esos modelos se expresan en el lenguaje de modelado unificado –UML-, que define un conjunto de artefactos que permiten especificar los requisitos del software, los cuales deberían guardar consistencia, cuando se trate del mismo modelo. Sin embargo, la consistencia entre diferentes artefactos no se encuentra definida en la especificación de UML y poco se ha trabajado con este tipo de consistencia. En este artículo se propone un método para verificar la consistencia entre el diagrama de clases y el diagrama de casos de uso de UML de una manera formal. Dicho proceso se lleva a cabo evaluando una serie de reglas definidas en el lenguaje de restricciones de objetos –OCL- que se deben cumplir para garantizar que la información brindada por dichos modelos sea consistente. Como se reconoce la participación de los dos diagramas en la elaboración de las interfaces gráficas de usuario –GUI–, se define adicionalmente la consistencia con este artefacto

rCOS: A refinement calculus for object systems

This article presents a mathematical characterization of object-oriented concepts by defining an observation-oriented semantics for a relational objectoriented language with a rich variety of features including subtypes, visibility, inheritance, type casting, dynamic binding and polymorphism. The language is expressive enough for the specification of object-oriented designs and programs. We also propose a calculus based on this model to support both structural and behavioral refinement of object-oriented designs. We take the approach of the development of the design calculus based on the standard predicate logic in Hoare and He’s Unifying Theories of Programming (UTP). We also consider object reference in terms of object identity as values and mutually dependent methods

Especificación formal en OCL de reglas de consistencia entre el modelo de clases y de casos de uso de UML

Resumen: En el ciclo de vida del software, durante las fases de definición y análisis se realiza una especificación de los requisitos. Para ello, es necesario realizar un proceso de captura de las necesidades y expectativas de los interesados, que se traduce posteriormente en un conjunto de modelos que representan tanto el problema como su solución. Por lo general, la mayoría de esos modelos se expresan en el Lenguaje Unificado de Modelamiento (UML), dirigido por el Grupo de Gestión de Objetos (Object Management Group, OMG). UML define un conjunto de artefactos que permiten especificar los requisitos del software, los cuales deberían guardar consistencia cuando se traten del mismo modelo, ya que están definidos bajo las reglas de buena formación (Well-Formedness Rules, WFR), las cuales se encuentran definidas dentro de la especificación de UML en el Lenguaje de Restricciones de Objetos (Object Constraint Language, OCL). La consistencia interna de cada artefacto está por tanto definida en la especificación de UML y algunas de las herramientas CASE (Computer-Aided Software Engineering) utilizan esas reglas intramodelo para validar este tipo de consistencia. Sin embargo la consistencia entre diferentes artefactos no se encuentra definida en la especificación de UML y poco se ha trabajado con este tipo de consistencia; además, los trabajos que se han realizado en este tema se identifican por: • No se suele definir de manera formal la consistencia entre los diferentes artefactos. • Por lo general se estudia sólo la consistencia entre alguno de los artefactos y el código resultante. •Algunos establecen reglas formales de consistencia, pero únicamente a nivel de intramodelo. Entre los artefactos más utilizados para especificar una pieza de software se encuentran el diagrama de clases y el diagrama de casos de uso, los cuales suministran dos perspectivas diferentes del desarrollo de software: por un lado el diagrama de clases, de tipo estructural, muestra los objetos del mundo y sus relaciones; por otro lado, el diagrama de casos de uso, de tipo comportamental, se concentra en las funciones que realizan los actores del mundo para lograr un resultado en el software. Estos dos puntos de vista deberían ser complementarios y, por ello, tener información común, susceptible de ser sometida a un análisis de consistencia. En esta Tesis se propone un método para verificar la consistencia entre el diagrama de clases y el diagrama de casos de uso de UML de una manera formal. Dicho proceso se lleva a cabo evaluando una serie de reglas definidas en OCL que se deben cumplir para garantizar que la información brindada por dichos modelos sea consistente. Como se reconoce la participación de los dos diagramas en la elaboración de las Interfaces Gráficas de Usuario (Graphical User Interfaces, GUI), se define adicionalmente la consistencia con este artefacto. Las reglas se implementaron en XQuery, utilizando como diagramas de entrada representaciones en XML generadas con la herramienta CASE ArgoUML® (en el caso del diagrama de clases y de casos de uso) y con Microsoft Visio® (en el caso de las GUI). Finalmente, se muestra un caso de estudio donde se aplican estas reglas y se muestran los posibles errores y advertencias que se tienen entre los elementos de tales artefactos.Abstract: Requirements specification is made throughout the definition and the analysis phases of software development lifecycle. For completing this task, a capture process of the stakeholder’s needs and expectations is needed; the results of this process are then translated into representative diagrams, for modeling both the problem domain and the solution. Commonly, most of these diagrams are expressed in the Unified Modelling Language (UML), a directed standard of the Object Management Group (OMG). UML defines a set of artifacts for specifying the software requirements; the UML artifacts are defined by means of Well-Formedness Rules (WFR) in the Object Constraint Language (OCL) and, consequently, must be consistent with each other. The intra-model consistency of each artifact is guaranteed by the UML specification, and some of the CASE (Computer-Aided Software Engineering) tools use intra-model rules for consistency checking. However, consistency among different UML artifacts is not defined by the UML specification, and the research about inter-model consistency is still immature. Some of the issues for this research topic are: • Inter-model consistency is not usually defined in a formal way. • In most cases, only consistency between one artifact and the resultant code is studied. • Some of the works in this area establish formal consistency rules, but only in the intra-model level. Two of the most useful artifacts for making a specification of a software piece are class and use case diagram. These diagrams present two different viewpoints of software development: firstly, class diagram gives a structural viewpoint, and it can represent the objects of the world and its relationships; secondly, the use case diagram gives a behavioural viewpoint, and it concentrates in the functions that the actors of the world carry out for achieving a result in the software piece. These two viewpoints should be complementary and, as a consequence, they should contain information in common. This information is susceptible of being checked by means of a consistency analysis.Maestrí