Architecture-Centric Component-Based Development Needs a Three-Level ADL

Zhang, Huaxi; Urtado, Christelle; Vauttier, Sylvain

doi:10.1007/978-3-642-15114-9_22

Cited by 14 publications

(15 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Release Years SARA 53 1986 Artek, 76 Acme, 35,36 C2SADL, 41 Darwin, 11,12 UniCon, 77 SADL (Structure) 78 1994-1997 ADML, 79 Koala, 16 Olan, 80,81 π-space, 82 AEmilia, 83,84 Zeta, 85 ComUnity, 86,87 DAOP-ADL, 88 Korrigan, 89 AADL, 14,15 Mae, 90 π-ADL, 91 Service-ADL 92 2000-2004 ADLARS, 93 Clara, 60 East-ADL, 32 π-net ADL, 17 SafArchie, 94 Secure X-ADL, 34 AspectualAcme, 37 Backbone, 95 EAADL, 96 Prisma, 28,97 Ambient-Prisma, 29,30 ALI, 98,99 WADL, 100 DEMO, 101 DiaSpec, 102 Dedal, 103 EADL, 104,105 AO-ADL, 51 MontiArc, 104,105 C3, 106 DPD, 107 Primitive-C 57 2005-2012…”

Section: Architectural Languagesmentioning

confidence: 99%

“…Extensibility and customization herein is concerned with the ability of extending a language with the requirements of interest. This includes the support for new viewpoints, adding domain-specific features (eg, specifying and analyzing 156,157 2002 HappyWork 180 2004 ABACUS 56 2005 AADL 14,15 2006 FAC 48 2006 FRACTAL 46,47 2006 Autosar 179 2008 ArchiMate 181,182 2009 Palladio 67 2009 Ambient-Prisma 29,30 2010 Dedal 103 2010 Stratus ML 75 2015…”

Section: Extensibility and Customizationmentioning

confidence: 99%

See 1 more Smart Citation

The analysis of architectural languages for the needs of practitioners

Özkaya

2018

Softw Pract Exp

View full text Add to dashboard Cite

Summary Architectural languages (ALs) have attracted much attention as the modeling notations for specifying and reasoning about important design decisions. In this study, 124 different existing ALs have been analyzed for a set of requirements that are crucial for practitioners. These requirements are concerned with language definition, language features, and tool support. Some of the important findings obtained from the analysis are as follows: (1) performance is the top popular nonfunctional requirement supported by ALs; (2) no ALs offer both textual and visual notation sets, one of which could be used independently; (3) process algebras are the top preferred formal method by formal ALs; (4) the physical, deployment, and operational viewpoints are rarely supported by ALs; (5) the top preferred extension mechanism of the extensible ALs is XML for syntax extension; (6) Java is the top preferred programming language in generating software code; (7) the exhaustive model checking is the top preferred automated analysis method; (8) the logic‐based formal techniques are so popular in specifying system requirements; (9) among the analysis properties considered, consistency is the top supported property for the automated checking; and (10) most ALs do not provide any discussion platform (eg, forums). Hence, these findings can be used by the new AL developers in addressing the needs of practitioners and bridging the gaps in the field. Practitioners can also use the findings to find out about the existing ALs and compare them to choose the one(s) that suits their needs best.

show abstract

Section: Architectural Languagesmentioning

confidence: 99%

Section: Extensibility and Customizationmentioning

confidence: 99%

The analysis of architectural languages for the needs of practitioners

Özkaya

2018

Softw Pract Exp

View full text Add to dashboard Cite

show abstract

“…In this section, we present a three-level architecture description language named Dedal [21,15], which aims at supporting the main steps of software development. By nature, Dedal is an ideal candidate ADL to keep a record of software evolution during its whole life-cycle using versions.…”

Section: Background and Motivationsmentioning

confidence: 99%

Substitutability-Based Version Propagation to Manage the Evolution of Three-Level Component-Based Architectures

Borgne¹,

Delahaye²,

Huchard³

et al. 2017

International Conferences on Software Engineering and Knowledge Engineering

Self Cite

View full text Add to dashboard Cite

An important issue of software architecture evolution is the capability for architects to keep a trace of the evolution of their work. This paper states that existing research on versioning does not cope well with software architectures. Indeed, it does not propose any adapted solutions to manage the co-evolution of the different architecture representations produced during the development process. We base our work on a three-level architecture description language (ADL) named Dedal, which represents architectures at three abstraction levels. Moreover, Dedal provides a formal base for managing version propagation. It is based on component substitutability that generalizes Liskov's substitutability principle. We propose a set of rules to support the prediction of version compatibility in terms of impact on the different architecture levels.

show abstract

“…In this paper, we propose an evolution management model that deals with all these issues. It is based on our Dedal architectural model [5,6] that covers the three main steps of component-based software development: specification, implementation and deployment. The model uses architecture properties and evolution rules proposed in previous work [7,8] to generate evolution plans that preserve the consistency of all architecture descriptions as well as coherence between them.…”

Section: Introductionmentioning

confidence: 99%

An evolution management model for multi-level component-based software architectures

Mokni¹,

Huchard²,

Urtado³

et al. 2015

International Conferences on Software Engineering and Knowledge Engineering

Self Cite

View full text Add to dashboard Cite

Handling evolution in component-based software architectures is a non trivial task. Indeed, a series of changes applied on software may alter its architecture leading to several inconsistencies. In turn, architecture inconsistencies lead to software erosion and shorten its lifetime. To avoid architectural inconsistencies and increase software reliability, architecture evolution must be handled at all steps of the software lifecycle. Moreover, changes must be treated as first class entities. In this paper, we propose an evolution management model that takes these criteria into account. The model is a support for our three-level Dedal architectural model. It captures and handles change at any of the Dedal abstraction levels: specification, implementation and deployment. It generates evolution plans using evolution rules proposed in previous work. The generation process is implemented using the ProB model checker and evaluated through three evolution scenarios of a Home Automation Software.

show abstract

Architecture-Centric Component-Based Development Needs a Three-Level ADL

Cited by 14 publications

References 14 publications

The analysis of architectural languages for the needs of practitioners

The analysis of architectural languages for the needs of practitioners

Substitutability-Based Version Propagation to Manage the Evolution of Three-Level Component-Based Architectures

An evolution management model for multi-level component-based software architectures

Contact Info

Product

Resources

About