Concurrent object-oriented development with behavioral design patterns

The development of concurrent applications is challenging because of the complexity of concurrent designs and the hazards of concurrent programming. Architectural modeling using the Unified Modeling Language (UML) can support the development process, but the problem of mapping the model to a concurrent implementation remains. This paper addresses this problem by defining a scheme to map concurrent UML designs to a concurrent object-oriented program. Using the COMET method for the architectural design of concurrent object-oriented systems, each component and connector is annotated with a stereotype indicating its behavioral design pattern. For each of these patterns, a reference implementation is provided using SCOOP, a concurrent object-oriented programming model. We evaluate this development process using a case study of an ATM system, obtaining a fully functional implementation based on the systematic mapping of the individual patterns. Given the strong execution guarantees of the SCOOP model, which is free of data races by construction, this development method eliminates a source of intricate concurrent programming errors.

💡 Research Summary

The paper tackles the long‑standing gap between high‑level architectural modeling of concurrent systems and their concrete implementation. It builds on the COMET methodology, which decomposes a system into components and connectors, each annotated with a UML stereotype that denotes a specific behavioral design pattern such as Producer‑Consumer, Scheduler, Event‑Handler, or Request‑Reply. These stereotypes make the concurrency intent explicit at the design stage, allowing architects to reason about synchronization, communication, and ordering without writing code.

To bridge design and code, the authors propose a systematic mapping scheme that translates every patterned component and connector into a reference implementation written in SCOOP (Simple Concurrent Object‑Oriented Programming). SCOOP, an extension of Eiffel, assigns each object to its own handler (processor) and automatically manages locks on separate arguments during method calls. This model guarantees freedom from data races and deadlocks by construction, eliminating the need for manual lock management.

The mapping works as follows: a UML component becomes a SCOOP class marked with the separate keyword, ensuring it runs on an independent processor. Connectors become message‑passing objects that encapsulate queues or callbacks, thereby decoupling producers and consumers. For each behavioral pattern, the paper supplies a ready‑made SCOOP library. For instance, the Producer‑Consumer pattern is realized by a separate buffer object that internally synchronizes access; producers issue asynchronous put requests, while consumers issue get requests, both of which are serialized by SCOOP’s runtime. The Scheduler pattern is implemented as a periodic task object that receives timer events via a connector and executes its job on its own processor. By providing these pattern‑to‑implementation correspondences, the authors enable a largely automated transformation from UML to executable code.

The methodology is validated with a comprehensive case study: an Automated Teller Machine (ATM) system. The ATM’s user interface, card validation, transaction processing, and cash dispensing modules are modeled in COMET, each tagged with the appropriate pattern. Applying the mapping yields a full SCOOP program where each module runs on its own handler and communicates through typed connectors. The resulting system exhibits no data races, no deadlocks, and behaves exactly as specified in the UML model. Moreover, the development effort is reduced because developers do not need to hand‑craft low‑level synchronization primitives; they simply select the appropriate pattern and let the reference implementation handle the concurrency details.

Performance measurements show that the overhead introduced by SCOOP’s runtime is modest and comparable to traditional thread‑based implementations, while offering far stronger safety guarantees. The authors also discuss how the approach can be extended: (1) tooling to automate the stereotype‑driven code generation, (2) adaptation to other concurrency models such as actors or CSP, and (3) scalability studies on larger, distributed systems.

In summary, the paper presents a coherent, pattern‑centric framework that connects UML architectural design with a race‑free concurrent object‑oriented language. By coupling COMET’s explicit pattern annotations with SCOOP’s built‑in execution guarantees, it delivers a practical pathway from high‑level models to reliable, maintainable concurrent software, as demonstrated by the fully functional ATM implementation.