A case study in architectural modeling: the AEGIS system

Allen, Robert J.; Garlan, David

doi:10.1109/iwssd.1996.501142

Cited by 20 publications

(24 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This is because, following Wright [4], these languages allow architects to specify connectors that are potentially unrealizable in a distributed manner [5] (c) An unavoidable bad behaviour [5] 1 c o n n e c t o r Plant_ Conn ect or = 2 r o l e P1 = ur → na → P1 . 3 r o l e P2 = ur → na → P2 . 4 r o l e UR = inc → UR 2 double → UR .…”

Section: Connector Realizabilitymentioning

confidence: 99%

Design-by-contract for reusable components and realizable architectures

Özkaya

Kloukinas

2014

Proceedings of the 17th International ACM Sigsoft Symposium on Component-Based Software Engineering

View full text Add to dashboard Cite

Architectural connectors can increase the modularity and reusability benefits of Component-based Software Engineering, as they allow one to specify the general case of an interaction pattern and reuse it from then on. At the same time they enable components to be protocol-independent -components do not need to know under which interaction patterns they will be used, as long as their minimal, local interaction constraints are satisfied. Without connectors one can specify only specific instances of such patterns and components need to specify themselves the interaction protocols that they will follow, thus reducing their reusability.Connector frameworks so far allow designers to specify systems that are unrealizable in a decentralized manner, as they allow designers to impose global interaction constraints. These frameworks either ignore the realizability problem altogether, ignore connector behaviour when generating code, or introduce a centralized controller that enforces these global constraints but does so at the price of invalidating any decentralized properties of the architecture.We show how the XCD ADL extends Design-by-Contract (DbC) for specifying (i) protocol-independent components, and (ii) arbitrary connectors that are always realizable in a decentralized manner as specified by an architecture -XCD connectors impose local constraints only. Use of DbC will hopefully make it easier for practitioners to use the language, compared to languages using process algebras. We show how XCD specifications can be translated to ProMeLa so as to verify that (i) provided services local interaction constraints are satisfied, (ii) provided services functional pre-conditions are complete, (iii) there are no race-conditions, (iv) event buffer sizes suffice, and (v) there is no global deadlock. Without formally analyzable architectures errors can remain undiscovered for a long time and cost too much to repair.

show abstract

Section: Connector Realizabilitymentioning

confidence: 99%

Design-by-contract for reusable components and realizable architectures

Özkaya

Kloukinas

2014

Proceedings of the 17th International ACM Sigsoft Symposium on Component-Based Software Engineering

View full text Add to dashboard Cite

show abstract

“…The Aegis has firstly been tackled by Wright [Allen, 1997] in [Allen and Garlan, 1996], which can informally be specified as Figure 2 comprising a set of components interacting with each other. The Experiment Control, at the top of the diagram, essentially provides linked components the information obtained via sensors.…”

Section: Xcd Adl Via Aegis Case Studymentioning

confidence: 99%

“…However, its global nature causes potentially unrealisable specifications for distributed systems, as explained in [Ozkaya and Kloukinas, 2013b]. Indeed, the Aegis connector in [Allen and Garlan, 1996] includes such a glue for coordinating the client and server component behaviours. Therefore, XCD connectors may only impose local constraints on the components via the roles; glues are not allowed.…”

Section: Automated Formal Verificationmentioning

confidence: 99%

Architectural Specification and Analysis with XCD - The Aegis Combat System Case Study

Ozkaya

Kloukinas

2014

Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development

View full text Add to dashboard Cite

Abstract:Despite promoting precise modelling and analysis, architecture description languages (ADLs) have not yet gained the expected momentum. Indeed, practitioners prefer using far less formal languages like UML, thus hindering formal verification of models. One of the main issues with ADLs derives from process algebras which practitioners view as having a steep learning curve. In this paper, we introduce a new ADL called XCD which enables designers to model their software architectures through a Design-by-Contract approach, as for example in the Java Modelling Language (JML). We illustrate how XCD can be used in architectural modelling and analysis using the Aegis combat software system.

show abstract

“…Some of the more well known architecture description are UniCon [23], Wright [24,25] and Rapide [26,27]. Each of these languages allow the definition of components and connectors to define a software architecture.…”

Section: Related Workmentioning

confidence: 99%

A brief summary of VSPEC

Alexander

Rangarajan

Baraona

1999

FM’99 — Formal Methods

View full text Add to dashboard Cite

Abstract. This paper provides an overview of the vspec behavioral interface specification language for vhdl. Although operational specification language such as vhdl provide exceptional specification capabilities, at the systems requirements level the operational style is a hindrance. vspec provides vhdl users with a declarative mechanism for defining functional requirements and performance constraints. In the tradition of behavioral interface specification languages, vspec adds clauses to the vhdl entity construct allowing axiomatic specification of functional requirements. Because system constraints play an ever increasing role in systems design, vspec also provides performance constraint specification capability. This paper presents the basics of vspec, its semantics, semantic analysis, and briefly describes current and future applications.

show abstract

A case study in architectural modeling: the AEGIS system

Abstract: Abstract

Cited by 20 publications

References 12 publications

Design-by-contract for reusable components and realizable architectures

Design-by-contract for reusable components and realizable architectures

Architectural Specification and Analysis with XCD - The Aegis Combat System Case Study

A brief summary of VSPEC

Contact Info

Product

Resources

About