From Object-Oriented Specification to Implementation: A Formal Refinement Methodology.

Traditionally, software development models use different methods and techniques in each phase from specification through design to implementation. Significant changes in the representations between phases have been common. The formal development method based on formal specification and stepwise development has been suggested to reduce the change in representation. The formal development method consists of a formal specification and verified design. In the formal specification step, a formal specification language is used to specify an accurate, consistent, and complete system. Vienna Development Method (VDM) is one of the most widely used formal specification languages. A verified design guides the development of the system from specification to executable code. A refinement method is used in VDM for that purpose. The use of the object-oriented paradigm is another important trend in software engineering. Initially, object-oriented methods were applied primarily during the implementation phase using object-oriented languages. Eiffel is an object-oriented programming language which has many strong facilities such as assertions and genericity. Numerous object-oriented specification languages exist, including object-oriented extensions to VDM. We defined Object-VDM to help remove limitations from existing object-oriented VDM languages. In this dissertation, we investigate a formal development method in the object-oriented environment since limited research hss been done in the area. We defined a refinement method that refines an Object-VDM specification to Eiffel code. There are three stages in this refinement: data refinement, operation refinement, and structure refinement. In data refinement, the mathematical data models in Object-VDM are converted to Eiffel data structures by creating Eiffel libraries. We proved the correctness of the conversion. In operation refinement, we modified and added rules to the original refinement to obtain Eiffel code. Object-oriented features are converted in the structure refinement step. In summary, this research provides a refinement method in object-oriented environments. Specifically, the refinement converts Object-VDM specifications to Eiffel codes

Monitoring-Oriented Programming: A Tool-Supported Methodology for Higher Quality Object-Oriented Software

This paper presents a tool-supported methodological paradigm for object-oriented software development, called monitoring-oriented programming and abbreviated MOP, in which runtime monitoring is a basic software design principle. The general idea underlying MOP is that software developers insert specifications in their code via annotations. Actual monitoring code is automatically synthesized from these annotations before compilation and integrated at appropriate places in the program, according to user-defined configuration attributes. This way, the specification is checked at runtime against the implementation. Moreover, violations and/or validations of specifications can trigger user-defined code at any points in the program, in particular recovery code, outputting or sending messages, or raising exceptions. The MOP paradigm does not promote or enforce any specific formalism to specify requirements: it allows the users to plug-in their favorite or domain-specific specification formalisms via logic plug-in modules. There are two major technical challenges that MOP supporting tools unavoidably face: monitor synthesis and monitor integration. The former is heavily dependent on the specification formalism and comes as part of the corresponding logic plug-in, while the latter is uniform for all specification formalisms and depends only on the target programming language. An experimental prototype tool, called Java-MOP, is also discussed, which currently supports most but not all of the desired MOP features. MOP aims at reducing the gap between formal specification and implementation, by integrating the two and allowing them together to form a system

Object-Oriented Modeling and Design Using DELTA, an Incremental Design Language.

Object-oriented technology has opened the doors for many new ideas in system development. The object-oriented paradigm has produced many new object-oriented programming languages. As with any new methodology, a need for formalism arises to remove ambiguities and inconsistencies and to bring a sense of continuity to software design. Formal languages provide a sound basis for software development throughout the software life cycle. This work presents a set of characteristic features for object-oriented design languages and defines a formal object-oriented design language, DELTA. The rapidly changing face of software has led to an ever increasing need to update out-of-date methods and user interfaces. Software developers want to be able to use the same type of visual interfaces available in application software. The introduction of windowing environments has led to a market for methodologies which incorporate graphical features to supplement textual components of software. The present genre of formal languages must evolve in the same direction to be considered as effective in the design process. DELTA meets this need by providing a modern development environment with graphical features to complement the text that is necessary in any design specification. Researchers and prominent software engineers have provided a litany of object-oriented methodologies. The commonality of these methods is the step-by-step approach to software development. Software engineers agree in theory that the best approach to designing software which will stand the test of time is one which has a sound established discipline. Such a discipline produces a design in incrementations. DELTA supports this theory by providing established levels of incremental design representation. The advent of computer-aided design has led to the evolution of rapid-prototyping. Changes in system requirements, detection of errors, competition in the market, and the ongoing maintenance of software systems can be addressed by the development of system prototypes. DELTA responds to this challenge by establishing a design specification representation which can be easily mapped to an object-oriented programming language. This transition from design to prototype can be enhanced by formal annotations to the chosen implementation language. Annotations have been developed for DELTA software designs prototyped in the object-oriented language Actor

Language concepts and design patterns

Programming languages aim at the construction of simple but expressive programs. To achieve this, plenty of language concepts have arisen over time. Design patterns aim at the solution of common design problems. To achieve this, plenty of approved design concepts have been collected. We claim that language concepts and design patterns are essentially the same. Indeed, a language may offer a design pattern as a language concept; we call such patterns "language patterns". A design pattern can be implemented in terms of other design or language patterns. Since a concrete programming language only supports a subset of language patterns, every other pattern must be expressed in terms of this subset. We call such an implementation a "workaround". The specification of a workaround imposes proof obligations: it must be shown that a workaround simulates the pattern. Once proved correct, we can collect patterns and their workarounds in a trustworthy catalogue. This helps software developers to correctly apply patterns in any language and helps the language designer to decide which patterns to put into the language core. We demonstrate this pattern integration process with well-known design patterns and concepts of object-oriented languages. Additionally, we list important language patterns together with their workarounds

Extending an object-oriented design method: a C++extension for IDEF4

Due to the character of the original source materials and the nature of batch digitization, quality control issues may be present in this document. Please report any quality issues you encounter to [email protected], referencing the URI of the item.Includes bibliographical references.This research introduces an object-oriented implementation design method IDEF4/C++. IDEF4/C++ is an extension of the IDEF4 object-oriented design method that incorporates C++ language considerations and practice to provide guidance and structure to ease the transition from an IDEF4 conceptual design to its implementation in C++. To guide the development of IDEF4/C++, three IDEF5 ontological models are built: (1) an ontology of general object-oriented concepts; (2) an ontology of the IDEF4 method concepts; and (3) an ontology of the C++ programming language. Together these ontologies form the conceptual foundation of this research effort. They also provide a formal platform for understanding the mappings between the terminology and primitive concepts in these domains. Extensions included in the IDEF4/C++ are: (1) an extended method syntax; (2) a transformation heuristic for transforming an IDEF4 conceptual design to an IDEF4/C++ implementation specification; (3) an IDEF3 model of the IDEF4/C++ design process with design evolution configuration management; and (4) best practice guidelines for the application of IDEF4/C++, especially focusing on design reuse. The thesis concludes with a discussion of an integrated framework for object-oriented system development. Without increasing the complexity of the IDDEF4 method, IDEF4/C++ takes advantage of C++ language features and best practice experience to bridge the gap between the conceptual design phase and the implementation phase in a software development project

An Analysis of Composability and Composition Anomalies

The separation of concerns principle aims at decomposing a given design problem into concerns that are mapped to multiple independent software modules. The application of this principle eases the composition of the concerns and as such supports composability. Unfortunately, a clean separation (and composition of concerns) at the design level does not always imply the composability of the concerns at the implementation level. The composability might be reduced due to limitations of the implementation abstractions and composition mechanisms. The paper introduces the notion of composition anomaly to describe a general set of unexpected composition problems that arise when mapping design concerns to implementation concerns. To distinguish composition anomalies from other composition problems the requirements for composability at the design level is provided. The ideas are illustrated for a distributed newsgroup system

Automated Verification of Design Patterns with LePUS3

Specification and [visual] modelling languages are expected to combine strong abstraction mechanisms with rigour, scalability, and parsimony. LePUS3 is a visual, object-oriented design description language axiomatized in a decidable subset of the first-order predicate logic. We demonstrate how LePUS3 is used to formally specify a structural design pattern and prove (‗verify‘) whether any JavaTM 1.4 program satisfies that specification. We also show how LePUS3 specifications (charts) are composed and how they are verified fully automatically in the Two-Tier Programming Toolkit

Aspect-oriented design model.

Designing crosscutting concerns (aspects) is a challenging task. Since crosscutting concerns were not addressed while developing contemporary software design techniques, so they lack support for accommodating representation of such concerns along with base program. Some design languages like UML have been extended to express aspects and their elements but they do not fully represent aspects. Some lack adequate representation of aspect elements and some lack an efficient and reusable composition technique. In this paper, some of the aspect-oriented design techniques have been critically discussed. A proposed aspect model has been discussed which helps in overcoming the deficiencies in the contemporary aspect-oriented design techniques. This model represents aspects and their elements throughout the software development life cycle