Specifying reactive system behavior

Fundamentally, the development of software applications involves dealing with two distinct domains: the real world and software domains; the two converge at the point where a software application is used to make an unsatisfactory real world situation into a satisfactory one. Thus, software application development is a problem solving activity that assumes a problem has been identified and a software application is desired to address this problem. In this context, it is necessary to take measures that ensure the solution will be both adequate and appropriate with respect to the problem. In particular, it is of utmost importance that the problem in hand and the application's role in helping to solve it are satisfactorily understood by the development team. If this condition is not observed then the application produced is doomed to be inadequate and/or inappropriate, independently of the capabilities of the available technologies and resources, and also independently of other wicked aspects of software development: constantly changing requirements, time-to-market pressures, significant social, political, ethical or economic issues in the project, etc. The principal objective of this thesis was to improve the state-of-the-art of specifications that are used to communicate to the development team the behavior of the (future) system. In addressing this objective, this work initially involved defining the essential requirements of specifications that could ensure that the development team has a precise, correct and common understanding of the way the system is required to behave. As a result of analyzing the identified requirements, two general kinds of specifications were distinguished and perceived to be necessary to address the requirements adequately; one that addresses the concerns of the designers, providing a precise description of the system responsibilities; and one that addresses the concerns of the stakeholders in general, providing an informal description of the goals that the stakeholders have against the system. The first specification is referred to as the Behavioral Design Contract and the second one is referred to as the Behavioral Stakeholders Contract. In this thesis, these two specifications were concretely realized as part of the ANZAC approach. The ANZAC approach defines two work artifacts called the ANZAC use case descriptions and the ANZAC specification, which express the Behavioral Stakeholders Contract and the Behavioral Design Contract, respectively. ANZAC use case descriptions offer an informal and usage-oriented description of the concordant goals that the stakeholders have against the system. An ANZAC specification offers a precise, operational description of the system's responsibilities in servicing all possible requests that it can receive over its lifetime; it uses a restricted subset of the Unified Modeling Language (UML) and its Object Constraint Language (OCL). In the ANZAC approach, the ANZAC use case descriptions are developed following the ANZAC use case framework. This framework defines the context, purpose, style and form of an ANZAC use case description, and it provides a goal-based approach to use case elicitation. Once a number of ANZAC use case descriptions are established, they can be refined to an ANZAC specification. This refinement procedure is (informally) defined by the ANZAC mapping technique. An ANZAC specification is developed by the description of three models, which each express a different but complementary view of the system. These three models are called the Concept Model, the Operation Model, and the Protocol Model. The Concept Model defines an abstract system state space in terms of concepts from the problem domain, the Operation Model describes the effect of system operations on the system state, and the Protocol Model defines the correct behavior of the system in terms of its (allowable) input protocol. As a "proof of concept", this thesis demonstrates the ANZAC approach applied to an elevator control system, which is used to show how ANZAC offers a clean approach for capturing the Behavioral Stakeholders and Design Contract. The elevator case study demonstrates the mapping between the Behavioral Stakeholders Contract and the Behavioral Design Contract using the ANZAC mapping technique. It also highlights the difference in the level of precision and formality that can be found between ANZAC use case descriptions and an ANZAC specification. Furthermore, it demonstrates some of the more advanced features of the ANZAC approach, in particular, its ability to specify performance constraints and concurrent behavior

Gauging the Quality of Examples for Teaching Design Patterns

What constitutes a good example in the context of teaching design patterns? How can instructors judge whether one example is better than another one for teaching a design pattern to students? How might an example be presented to best connect with students, equipping them with the necessary know-how? In this paper, I address these questions by offering a means to judge the quality of examples for teaching design patterns: a list of desirable characteristics. The proposed list can be used to gauge the quality of examples and/or it can be used to guide the development of examples

Specifying Concurrent System Behavior and Timing Constraints Using OCL and UML

Despite advances in implementation technologies of distributed systems during the last few years, little progress has been made on specification techniques for describing distributed systems in software development practice. The contribution of this paper is a UML-based approach for specifying concurrent behavior and timing constraints--often inherent characteristics of distributed systems. We propose a novel approach for specifying concurrent behavior of reactive systems in OCL and several constructs for precisely describing timing constraints on UML statemachines. More precisely, we show how we enriched operation schemas--pre- and postcondition assertions of system operations written in OCL--by extending the current calculus with constructs for asserting synchronization on shared resources. Also, we describe how we use new and existing constructs for UML statemachines to specify timing constraints on the system interface protocol (SIP)--a restricted form of UML protocol statemachine. Finally, we discuss how both the extended system operation and SIP models are complementary.LGLAlso available as Technical Report IC/2001/367, Ecole Polytechnique Fédérale de Lausanne (EPFL), School of Computer and Communication Science

Operation Schemas and OCL

This report describes the syntax and usage of operation schemas and it also shows how we use UML's object constraint language (OCL) in operation schemas

Specifying System Behavior in UML

The purpose of the paper is to present our approach for specifying system behavior. Our approach is based on operation schemas and a system interface protocol (SIP). Operation schemas describe the functionality of system operations by pre- and post-conditions; they are written in the Object Constraint Language (OCL), as defined by the Unified Modeling Language (UML). A SIP describes the temporal ordering of the system operations by a UML protocol statemachine. Operation schemas are hybrids of formal specifications approaches such as Z and VDM : hybrid in the sense that they are based on their formal counterparts but are targeted to developers that are more comfortable with procedural programming languages rather than declarative languages. Our approach offers a middle ground between the informal descriptions of use cases and the solution-oriented models of object interaction in UML. We believe that declarative behavioral specification techniques, like the one proposed in this paper, lead to more confidence in the quality of the software because they allow one to reason about system properties

Model Transformation the Heart and Soul of Model-Driven Software Development

The motivation behind model-driven software development is to move the focus of work from programming to solution modeling. The model-driven approach has a potential to increase development productivity and quality by describing important aspects of a solution with more human-friendly abstractions and by generating common application fragments with templates. For this vision to become reality, software development tools need to automate the many tasks of model construction and transformation, including construction and transformation of models that can be round-trip engineered into code. In this article, we briefly examine different approaches to model transformation and offer recommendations on the desirable characteristics of a language for describing model transformations. In doing so, we are hoping to offer a measuring stick for judging the quality of future model transformation technologies

Modeling Enterprise Web Applications

The purpose of this paper is to provide an overview of our approach for modeling enterprise web applications (EWA), which is use case driven and uses UML as the modeling language. Our approach delivers a conceptual, logical model of the application, which consists of three packages. Packages were chosen to model three logical level concerns: presentation, business, and data management logic. Our approach uses the principle of separation of concerns, in that our package partition was made with the goal of isolating as many changes, which are commonly made in EWAs, as possible within a single package. In this paper, we focus on the business logic concern, and only give a brief overview of the preliminary techniques used to model the other two concerns. Also, we propose to model each concern with different views. Finally, we briefly discuss how our proposed logical model is mapped to process and deployment models to give a complete model of EWAs

From Use Cases to System Operation Specifications

The purpose of this paper is to first showcase the concept of an operation schema - a precise form of system-level operation specification and secondly show how operation schemas enhance development when they are used as a supplement to use case descriptions. An operation schema declaratively describes the effects of a system operation by pre- and postconditions using the Object Constraint Language (OCL), as defined by the Unified Modeling Language (UML). In particular, the paper highlights techniques to map use cases to operation schemas and discusses the advantages of doing so in terms of clarifying the granularity and purpose of use cases and facilitating a more systematic transition to design

Using OCL and UML to Specify System Behavior

Use cases are an excellent tool for capturing behavioral requirements of software systems, but they are not an ideal work product for driving design activities. We believe that there is value from complementing use case descriptions with pre- and postcondition descriptions, not only to better support reasoning about system properties and a basis for testing and debugging, but also to better support a predictable decomposition level on which one can base a systematic transition to design. Nevertheless, we recognize that pre- and postcondition descriptions are not widely used in practice. We believe this is in part due to the formalism used. Either the formalism is too heavy to learn and use, or the formalism does not offer sufficient abstraction from the vocabulary of implementation. Via an example, the paper highlights our approach for specifying system behavior, which uses the Unified Modeling Language (UML) and its Object Constraint Language (OCL). We focus the paper on pre- and postconditions descriptions and in particular propose a number of enhancements and interpretations to OCL that we made while refining our approach. In particular, we describe a number of issues that cover areas such as the frame problem, incremental descriptions, structuring schemas, and events and exceptions

Enhancing OCL for Specifying Pre- and Postconditions

This paper proposes a number of enhancements to UML's Object Constraint Language to improve its usability for specifying operations by pre- and postconditions. In particular, we propose notational shortcuts and semantic modifications to OCL so that it can be more effectively used by developers. Also, the paper discusses an approach for specifying, in OCL, events and exceptions which are output and raised by an operation