Role-based Adaptation of Business Reference Models to Application Models: An Enterprise Modeling Methodology for Software Construction

Large software systems are in need of a construction plan to determine and define every concept and element used in order to not end up in complex, unusable, and cost-intensive systems. Different modeling languages, like UML, support the development of these construction plans and visualize them for the system’s stakeholders. Reference models are a specific kind of construction plan, used as templates for information systems and already capture business domain knowledge for reuse and tailoring. By adaptation, reference models are tailored to enterprise-specific application models, which can be used for software construction and maintenance. However, current adaptation methods suffer from the limitations of pure object-oriented development (e.g., identity issues, large inheritance trees, and inflexibility). In this thesis, the usage of roles as the sole adaptation mechanism is proposed to solve these challenges. With the help of conceptual roles, it is possible to create rich model variations and adaptations from existing (industry standard) reference models, and it is simpler to react to model evolution and changing business logic. Adaptations can be specified with more precision by maintaining or even increasing the model’s expressiveness. As a consequence, the role-enriched final application model can be used to describe software systems in more detail, with different perspectives, and, if available, can be implemented with a role supporting programming language. However, even without this step, the application model itself will provide valuable insights into the overall construction plan of a software system by the combination of structure and behavior and a clear separation of relatively stable domain knowledge from its use case specific adaptation

Verification and validation of UML and SysML based systems engineering design models

In this thesis, we address the issue of model-based verification and validation of systems engineering design models expressed using UML/SysML. The main objectives are to assess the design from its structural and behavioral perspectives and to enable a qualitative as well as a quantitative appraisal of its conformance with respect to its requirements and a set of desired properties. To this end, we elaborate a heretofore unattempted unified approach composed of three well-established techniques that are model-checking, static analysis, and software engineering metrics. These techniques are synergistically combined so that they yield a comprehensive and enhanced assessment. Furthermore, we propose to extend this approach with performance analysis and probabilistic assessment of SysML activity diagrams. Thus, we devise an algorithm that systematically maps these diagrams into their corresponding probabilistic models encoded using the specification language of the probabilistic symbolic model-checker PRISM. Moreover, we define a first of its kind probabilistic calculus, namely activity calculus, dedicated to capture the essence of SysML activity diagrams and its underlying operational semantics in terms of Markov decision processes. Furthermore, we propose a formal syntax and operational semantics for the input language of PRISM. Finally, we mathematically prove the soundness of our translation algorithm with respect to the devised operational semantics using a simulation preorder defined upon Markov decision processes

To Do or Not to Do: Semantics and Patterns for Do Activities in UML PSSM State Machines

State machines are used ubiquitously in engineering software-intensive systems. UML State Machines extend simple finite state machines with powerful constructs. Among the many extensions, there is one seemingly simple and innocent language construct that fundamentally changes state machines' reactive model of computation: doActivity behaviors. DoActivity behaviors describe behavior that is executed independently from the state machine once entered in a given state, typically modeling complex computation or communication as background tasks. However, the UML specification or textbooks are vague about how the doActivity behavior construct should be appropriately used. This lack of guidance is a severe issue as, when improperly used, doActivities can cause concurrent, non-deterministic bugs that are especially challenging to find and could ruin a seemingly correct software design. The Precise Semantics of UML State Machines (PSSM) specification introduced detailed operational semantics for state machines. To the best of our knowledge, there is no rigorous review yet of doActivity's semantics as specified in PSSM. We analyzed the semantics by collecting evidence from cross-checking the text of the specification, its semantic model and executable test cases, and the simulators supporting PSSM. We synthesized insights about subtle details and emergent behaviors relevant to tool developers and advanced modelers. We reported inconsistencies and missing clarifications in more than 20 issues to the standardization committee. Based on these insights, we studied 11 patterns for doActivities detailing the consequences of using a doActivity in a given situation and discussing countermeasures or alternative design choices. We hope that our analysis of the semantics and the patterns help vendors develop conformant simulators or verification tools and engineers design better state machine models

Web service composition : architecture, frameworks, and techniques

OASIS defines Service Oriented Architecture (SOA) as a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. One approach to realize SOA is Web services. A Web service is a software system that has a machine processable Web Services Description Language (WSDL) interface; other systems interact with it using SOAP messages in a manner prescribed by its description. Descriptions enable Web services to be discovered, used by other Web services, and composed into new Web services. Composition is a mechanism for rapid creation of new Web services by reusing existing ones. Web services have functional, behavioral, semantic, and non-functional characteristics. These characteristics have to be considered for composition, as they provide essential information about the services. In order to compose Web services with these characteristics, they have to be described appropriately. However, the existing techniques do not consider all these aspects together for description and composition. This thesis proposes a business model, also referred to as architecture, a description framework, and a composition framework for Web service composition. Techniques for matching, categorizing, and assembling the composite services are also proposed as a part of the composition framework. The architecture, frameworks, and techniques describe, discover, manipulate, and compose Web services by taking into account all their characteristics. The standard Web service business model is extended by the proposed business model to support Web service composition. In the model, based on their demand, the requested Web services are composed by the Web service composer. In the proposed architecture, Web services are described using the description framework languages. The proposed framework combines Semantic Annotations for WSDL and XML Schema (SAWSDL) for functional and semantic description, Message Sequence Charts (MSC) for behavioral description, and a simple and new Non Functional Specification Language (NFSL) for the non-functional properties description of Web services. It uses Higher Order Logic (HOL) for formalizing and integrating the three languages. The role of Web service composer in the architecture is realized by the composition framework. It essentially defines the architecture of the composer. In this framework, matchmaking, categorization, and assembly techniques are used to create the requested composite service. These techniques manipulate the Web services at HOL-level. The formal matchmaking technique discovers the primitive Web services by using a HOL theorem prover. The categorization and the assembly techniques manipulate the matched services and orchestrate the composite service. The concepts of the model, frameworks, and techniques are implemented, and their working is illustrated using case studies. Prototypes of the model's components (extended registry and extended requester) and the composition framework are developed, and their performance is analyzed. Case studies to illustrate the description and the composition frameworks are also presente

Quality of (Digital) Services in e-Government

Internet growth in the nineties supported government ambition to provide better services to citizens through the development of Information and Communication Technologies based solutions. Thanks to the Lisbon conference, which in 2000 covered and investigated this topic, e-government has been recognized as one of the major priorities in Public Administration innovation process. As a matter of\ud fact in the last 10 years the number of services provided to citizens through Information and Communication Technologies has increased rapidly. Nevertheless the increasing rate, the access and usage of digital services do not follow the same trend. Nowadays Public Administrations deliver many electronic services which\ud are seldom used by citizens. Different reasons contribute to the highlighted situation.\ud The main assumption of the thesis is that quality of e-government digital services strongly affects real access to services by citizens. According to the complexity of quality in e-government, one of the main challenges was to define a suitable quality model. To reach such aim, domain-dependent characteristics on the services delivery have been investigated. The defined model refers to citizen,\ud technology and service related quality characteristics. Correspondingly a suitable way to represent, assess, and continuously improve services quality according to\ud such domain requirements has been introduced.\ud Concerning the service related quality aspects a methodology and a tool permitting to formally and automatically assess the quality of a designed service with\ud respect to the quality model has been defined. Starting from an user friendly notation, both for service and quality requirements, the proposed methodology has\ud been implemented as an user friendly tool supported by a mapping from user friendly notations to formal language. The tool allows to verify formally via model checking, if the given service satisfies one by one the quality requirements addressed by the quality model.\ud Additionally in some case an unique view on e-government service quality is quite useful. A mathematical model provides a single value for quality starting from the assessment of all the requirements defined in the quality model. It relies on the following activities: homogeneity, interaction and grouping.\ud A set of experiments has been performed in order to validate the goodness of the work. Services already implemented in a local Public Administration has\ud been considered. Literature review and domain experts knowledge were the main drivers of this work. It proofs the goodness of the quality model, the application of formal techniques in the complex field of study such as e-government and the quality aggregation via the mathematical model.\ud This thesis introduces advance research in e-government by providing the contributions that quality oriented service delivery in Public Administration promotes services used by the citizens. Further applications of the proposed approaches could be investigated in the areas of practical benchmarking and Service Level Agreement specification

Domain specific modeling and analysis

It is desirable to model software systems in such a way that analysis of the systems, and tool development for such analysis, is readily possible and feasible in the context of large scientific research projects. This thesis emphasizes the methodology that serves as a basis for such developments. I focus on methods for the design of data-languages and their corresponding tools.UBL - phd migration 201

Traceability of Requirements and Software Architecture for Change Management

At the present day, software systems get more and more complex. The requirements of software systems change continuously and new requirements emerge frequently. New and/or modified requirements are integrated with the existing ones, and adaptations to the architecture and source code of the system are made. The process of integration of the new/modified requirements and adaptations to the software system is called change management. The size and complexity of software systems make change management costly and time consuming. To reduce the cost of changes, it is important to apply change management as early as possible in the software development cycle. Requirements traceability is considered crucial in change management for establishing and maintaining consistency between software development artifacts. It is the ability to link requirements back to stakeholders’ rationales and forward to corresponding design artifacts, code, and test cases. When changes for the requirements of the software system are proposed, the impact of these changes on other requirements, design elements and source code should be traced in order to determine parts of the software system to be changed. Determining the impact of changes on the parts of development artifacts is called change impact analysis. Change impact analysis is applicable to many development artifacts like requirements documents, detailed design, source code and test cases. Our focus is change impact analysis in requirements and software architecture. The need for change impact analysis is observed in both requirements and software architecture. When a change is introduced to a requirement, the requirements engineer needs to find out if any other requirement related to the changed requirement is impacted. After determining the impacted requirements, the software architect needs to identify the impacted architectural elements by tracing the changed requirements to software architecture. It is hard, expensive and error prone to manually trace impacted requirements and architectural elements from the changed requirements. There are tools and approaches that automate change impact analysis like IBM Rational RequisitePro and DOORS. In most of these tools, traces are just simple relations and their semantics is not considered. Due to the lack of semantics of traces in these tools, all requirements and architectural elements directly or indirectly traced from the changed requirement are candidate impacted. The requirements engineer has to inspect all these candidate impacted requirements and architectural elements to identify changes if there are any. In this thesis we address the following problems which arise in performing change impact analysis for requirements and software architecture. Explosion of impacts in requirements after a change in requirements. In practice, requirements documents are often textual artifacts with implicit structure. Most of the relations among requirements are not given explicitly. There is a lack of precise definition of relations among requirements in most tools and approaches. Due to the lack of semantics of requirements relations, change impact analysis may produce high number of false positive and false negative impacted requirements. A requirements engineer may have to analyze all requirements in the requirements document for a single change. This may result in neglecting the actual impact of a change. Manual, expensive and error prone trace establishment. Considerable research has been devoted to relating requirements and design artifacts with source code. Less attention has been paid to relating Requirements (R) with Architecture (A) by using well-defined semantics of traces. Designing architecture based on requirements is a problem solving process that relies on human experience and creativity, and is mainly manual. The software architect may need to manually assign traces between R&A. Manual trace assignment is time-consuming, expensive and error prone. The assigned traces might be incomplete and invalid. Explosion of impacts in software architecture after a change in requirements. Due to the lack of semantics of traces between R&A, change impact analysis may produce high number of false positive and false negative impacted architectural elements. A software architect may have to analyze all architectural elements in the architecture for a single requirements change. In this thesis we propose an approach that reduces the explosion of impacts in R&A. The approach employs semantic information of traces and is supported by tools. We consider that every relation between software development artifacts or between elements in these artifacts can play the role of a trace for a certain traceability purpose like change impact analysis. We choose Model Driven Engineering (MDE) as a solution platform for our approach. MDE provides a uniform treatment of software artifacts (e.g. requirements documents, software design and test documents) as models. It also enables using different formalisms to reason about development artifacts described as models. To give an explicit structure to requirements documents and treat requirements, architecture and traces in a uniform way, we use metamodels and models with formally defined semantics. The thesis provides the following contributions: A modeling language for definition of requirements models with formal semantics. The language is defined according to the MDE principles by defining a metamodel. It is based on a survey about the most commonly found requirements types and relation types. With this language, the requirements engineer can explicitly specify the requirements and the relations among them. The semantics of these entities is given in First Order Logic (FOL) and allows two activities. First, new relations among requirements can be inferred from the initial set of relations. Second, requirements models can be automatically checked for consistency of the relations. Tool for Requirements Inferencing and Consistency Checking (TRIC) is developed to support both activities. The defined semantics is used in a technique for change impact analysis in requirements models. A change impact analysis technique for requirements using semantics of requirements relations and requirements change types. The technique aims at solving the problem of explosion of impacts in requirements when semantics of requirements relations is missing. The technique uses formal semantics of requirements relations and requirements change types. A classification of requirements changes based on the structure of a textual requirement is given and formalized. The semantics of requirements change types is based on FOL. We support three activities for impact analysis. First, the requirements engineer proposes changes according to the change classification before implementing the actual changes. Second, the requirements engineer indentifies the propagation of the changes to related requirements. The change alternatives in the propagation are determined based on the semantics of change types and requirements relations. Third, possible contradicting changes are identified. We extend TRIC with a support for these activities. The tool automatically determines the change propagation paths, checks the consistency of the changes, and suggests alternatives for implementing the change. A technique that provides trace establishment between R&A by using architecture verification and semantics of traces. It is hard, expensive and error prone to manually establish traces between R&A. We present an approach that provides trace establishment by using architecture verification together with semantics of requirements relations and traces. We use a trace metamodel with commonly used trace types. The semantics of traces is formalized in FOL. Software architectures are expressed in the Architecture Analysis and Design Language (AADL). AADL is provided with a formal semantics expressed in Maude. The Maude tool set allows simulation and verification of architectures. The first way to establish traces is to use architecture verification techniques. A given requirement is reformulated as a property in terms of the architecture. The architecture is executed and a state space is produced. This execution simulates the behavior of the system on the architectural level. The property derived from the requirement is checked by the Maude model checker. Traces are generated between the requirement and the architectural components used in the verification of the property. The second way to establish traces is to use the requirements relations together with the semantics of traces. Requirements relations are reflected in the connections among the traced architectural elements based on the semantics of traces. Therefore, new traces are inferred from existing traces by using requirements relations. We use semantics of requirements relations and traces to both generate/validate traces and generate/validate requirements relations. There is a tool support for our approach. The tool provides the following: (1) generation/validation of traces by using requirements relations and/or verification of architecture, (2) generation/validation of requirements relations by using traces. A change impact analysis technique for software architecture using architecture verification and semantics of traces between R&A. The software architect needs to identify the impacted architectural elements after requirements change. We present a change impact analysis technique for software architecture using architecture verification and semantics of traces. The technique is semi-automatic and requires participation of the software architect. Our technique has two parts. The first part is to identify the architectural elements that implement the system properties to which proposed requirements changes are introduced. By having the formal semantics of requirements relations and traces, we identify which parts of software architecture are impacted by a proposed change in requirements. We have extended TRIC for determining candidate impacted architectural elements. The second part of our technique is to propose possible changes for software architecture when the software architecture does not satisfy the new and/or changed requirements. The technique is based on architecture verification. The output of verification is a counter example if the requirements are not satisfied. The counter example is used with a classification of architectural changes in order to propose changes in the software architecture. These changes produce a new version of the architecture that possibly satisfies the new or the changed requirements

Formal Methods Specification and Analysis Guidebook for the Verification of Software and Computer Systems

This guidebook, the second of a two-volume series, is intended to facilitate the transfer of formal methods to the avionics and aerospace community. The 1st volume concentrates on administrative and planning issues [NASA-95a], and the second volume focuses on the technical issues involved in applying formal methods to avionics and aerospace software systems. Hereafter, the term "guidebook" refers exclusively to the second volume of the series. The title of this second volume, A Practitioner's Companion, conveys its intent. The guidebook is written primarily for the nonexpert and requires little or no prior experience with formal methods techniques and tools. However, it does attempt to distill some of the more subtle ingredients in the productive application of formal methods. To the extent that it succeeds, those conversant with formal methods will also nd the guidebook useful. The discussion is illustrated through the development of a realistic example, relevant fragments of which appear in each chapter. The guidebook focuses primarily on the use of formal methods for analysis of requirements and high-level design, the stages at which formal methods have been most productively applied. Although much of the discussion applies to low-level design and implementation, the guidebook does not discuss issues involved in the later life cycle application of formal methods