Alfred Strohmeier

Reliable Software Technologies — Ada-Europe 2003

Starting in 2000, the ISO technical group in charge of maintaining the Ada language has been looking into possible changes for the next revision of the standard, around 2005. Based on the input from the Ada community, it was felt that the revision was a great opportunity for further enhancing Ada by integrating new programming practices, e.g., in the OOP area; by providing new capabilities for embedded and high-reliability applications; and by remedying annoyances encountered during many years of usage of Ada 95. This led to the decision to make a substantive revision rather than a minor one. This paper outlines the standardization process and schedule, and presents a number of key improvements that are currently under consideration for inclusion in Ada 2005.

Towards a UML profile for software architecture descriptions

To formally describe architectures of software systems, specific languages called Architecture Description Languages (ADLs) have been developed by academic institutions and research labs. However, more and more research and industrial projects are using the standard Unified Modeling Language (UML) for representing software architectures of systems. In this paper, we focus on how to extend the UML by incorporating some key abstractions found in current ADLs, such as connectors, components and configurations, and how the UML can be used for modeling architectural viewpoints. Our approach is demonstrated by the software architecture of a video surveillance system. It is therefore the purpose of the paper to show that a UML profile for software architecture abstractions is needed.

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 providing a precise specification of system behavior.

Reliable Software Technologies - Ada-Europe 2004

Formal methods for software development have been discussed for decades. This paper will try to explain when and under what circumstances formal methods and languages in general and the Object Constraint Language (OCL) in particular can be employed in a beneficial way. The success of using a formal approach is highly influenced by the expectations and pre-requisite knowledge of the developers, the role the formal support in the development process is given, and of course by the used tools.

Specifying Concurrent System Behavior and Timing Constraints Using OCL and UML

Despite advances in implementation technologies for distributed systems during the last few years, little attention has been given to distributed systems within software development methodologies. 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.

Open multithreaded transactions: keeping threads and exceptions under control

Although transactional models have proved to be very useful for numerous applications, the development of new models to reflect the ever-increasing complexity and diversity of modern applications is a very active area of research. Analysis of the existing models of multithreaded transactions shows that they either give too much freedom to threads and do not control their participation in transactions, or unnecessarily restrict the computational model by assuming that only one thread can enter a transaction. Another important issue, which many models do not address properly, is providing adequate exception handling features. A new model of multithreaded transactions is proposed. Its detailed description is given, including rules of thread behaviour when transactions start, commit and abort, and rules of exception raising, propagation and handling. This model is supported by enhanced error detection techniques to allow for earlier error detection and for localised recovery. General approaches to implementing transaction support are discussed and a detailed description of an Ada implementation is given. Special attention is paid to outlining typical applications for which this model is suitable and to comparing it with several known approaches (Coordinated Atomic actions, CORBA, and Argus).

Integrating CBSE, SoC, MDA, and AOP in a software development method

Component-based software engineering, separation of concerns, model-driven architecture, and aspect-oriented programming are four active research areas tat have been around for several years now. In this paper, we present how these four paradigms can be put together in the context of a new software development method and we show how they can complement each other are different stages in the development life-cycle of enterprise, middleware-mediated applications. Different software development methods, such as Fondue, Catalysis, KobrA, and the Rational Unified Process, are also analyzed, pointing out their differences and limitations. In the end, requirements for a dedicated tool infrastructure that would support the new development approach are discussed.

Bridging the gap between IEEE 1471, an architecture description language, and UML

Abstract.A lot of attention has been paid to software architecture issues in academia, industrial research and standardization organizations working in the software area. The software architecture research community has focused on the creation and improvement of special-purpose languages: architecture description languages (ADLs). However, ADLs lack adequate support for separating various kinds of stakeholders’ concerns along different viewpoints. But also, they do not address the difference between the architecture of a software system and its representations. In contrast, ANSI/IEEE-Std-1471 makes a clear distinction between the architecture and the architectural description of a software system.In this paper, we propose ConcernBASE, a UML-based approach to software architecture, which instantiates the conceptual framework defined in ANSI/IEEE-Std-1471 and complements the abstractions and mechanisms found in current ADLs. ConcernBASE provides a viewpoint for structural descriptions of software architectures that supports key concepts of ADLs and defines a UML profile as a viewpoint language. We validate this profile through a mapping between a representative ADL, called Structural ADL (SADL), and the new profile and by providing a UML-based tool prototype, called ConcernBASE Modeler, which integrates with SADL tools.

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.

Reliable Software Technologies — Ada-Europe 2002

Separating different aspects of a program, and encapsulating them inside well defined modules, is considered a good engineering discipline. This discipline is particularly desirable in the development of distributed agreement algorithms which are known to be difficult and error prone. For such algorithms, one aspect that is important to encapsulate is failure detection. In fact, a complete encapsulation was proven to be feasible in the context of distributed systems with process crash failures, by using black-box failure detectors. This paper discusses the feasibility of a similar encapsulation in the context of Byzantine (also called arbitrary or malicious) failures. We argue that, in the Byzantine context, it is just impossible to achieve the level of encapsulation of the original crash failure detector model. However, we also argue that there is some room for an intermediate approach where algorithms that solve agreement problems, such as consensus and atomic broadcast, can still benefit from grey-box failure detectors that partially encapsulate Byzantine failure detection.