architectural description languages patrick steyaert [email protected]

Architectural Description Languages

Patrick Steyaert

[email protected]

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 2

Reference

Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison Wesley, 1997.


Goal

Designing, maintaining and reasoning about ‘complex’ object-oriented software

systems at a high level of abstraction.


What we know how to build.

‘Programs’

Single purpose Single developer (or very small group) Short lived Single version Scalability is not an issue No openness to other systems


‘Software Systems’

Multi purpose, or complex single purpose High change, multiple versions (variations) Multiple point of entry Open to other systems (e.g. legacy) Scalable in size and time

What we need to build.


The Challenge

Extremely complex systems ... more than one mind can handle at once … interacting with other systems ... in a fast changing environment.

must manage complexity must manage interactions must manage variations must manage evolution


Families

We consider a set of programs to constitute a family whenever it is worthwhile to study

programs from the set by first studying the common properties of the set and then

determening the special properties of the individual family members.

- David L. Parnas


Application Families

application systems that are intended to work together» e.g. MS Office

application systems with variants in a domain» e.g. telephone switches

» e.g planning systems

» e.g. ERP systems

application systems that share certain foundations or are interoperable in some way

» e.g. running on the same windowing system


Need for New Models

“The software architecture … is the structure of structures of a system, which comprise software components, the externally visible properties of those components and the

relationship among them.”

“A software architecture is a specification of a set of components and a communication pattern or protocol among them.”

“Architecture is the structure of the components of a system, their interrelationships and principles and guidelines [or guiding principles] governing their design and evolution over

time.”

“Architecture defines a system in terms of components, connectors and constraints”


Architectural Models Emphasize

understanding of overall structure» components

interaction» connectors, communication protocols,

relationships between components

evolution» guiding principles for evolution

structure is determined by the observer» different structures are possible


Architectural Structures

Module structure Conceptual of logical structure Process of coordination structure Physical structure Uses structure Class structure Calls structure Data flow, Control flow


Concerns that Influence Architecture

Different stakeholders» customer, end-user, developer, maintenance, marketing,

sales

With different concerns (conflict)» cost, time-to-market, many changes, few changes, many

features, few features, reliable, future-oriented, standard, customisable

With different scope and requirements» functional and non-functional

With different technical environment, experience and background

Architect


System Quality Attributes

Performance Scalability Security Availability Usability Tracability Functionality

Configurability Variability in functionality Change-tolerance Portability Reusability Integrability Interoperability

Non-functional Requirements


Aesthetic Qualities

“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and

improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” [Brooks95]

“Unity is the master principle of great art. And I have seen over and over that unity is the master principle of great software. … The theme of your software is the dominant idea that constitutes the basis of the design. … You’ve got to have a

purpose for your product, and ‘unity of purpose’ is a good phrase to describe the impact of having a theme.” [McCarthy95]


Example: LAN Application System

NodeNode

WorkStationWorkStation

NodeNode OutputServerOutputServer

#John

from: #Johnto: #Printer1bla bla blabla bla

accept: packet

#Printer1

packet

End user: LAN expertServices: simulations


LAN classes

Workstation

originate (p : Packet)

Printserver

print (p : Packet)

Node

name

accept(p:Packet)send(p:Packet) 1

nextNode1

Packet

originatoraddresseecontents


Node

public class Node {protected Node nextNode;protected String name;

public Node(String n) {name = n;

}

public void accept(Packet thePacket) {this.send(thePacket);

}

void send(Packet thePacket) {nextNode.accept(thePacket);

} }


Workstation

public class Workstation extends Node {

public Workstation(String n) {name = n;

}

public void accept(Packet thePacket) {if (thePacket.originator == name)

System.out.println("Node " + thePacket.originator + " not found");else super.accept(thePacket);

}

public void originate(Packet thePacket) {thePacket.originator = name;this.send(thePacket);

}}


Printserver

public class Printserver extends Node {

public Printserver(String n) {name = n;

}

public void accept(Packet thePacket) {if (thePacket.addressee == name)

System.out.println("Packet " + thePacket.contents + "printed on " + name);

else super.accept(thePacket);}}


Packet

public class Packet {

public String originator;

public String addressee;

public String contents;

public Packet(String a, String c) {

addressee = a;

contents = c;

}

}


LAN Architecture

Nod

e

Pac

ket

PSPrinter

ASCIIPrinterComponents

MyPack

et

Components = classes Connections = message passing


Architectural Styles

Analoguos to architectural style in buildings such as Gothic, Roman, …

It defines key features and rules for combining them

An architectural style is determined by:» component types» topological layout of components» semantic constraints» connectors


Example styles

Independent components» communication processes» event systems

Data flow» batch sequential» pipes and filters

Data-centered» repository» blackboard

Virtual Machine

»interpreter

»rule based system

Call and return

»main program and subroutine

»object-oriented

»layered


Pipes and Filters

PackageCompress Capitalize


Acme

Home page: » http://www.cs.cmu.edu/~acme/acme_home.htm

Acme descriptions:» http

://www.cs.cmu.edu/~acme/acme_extending_acme.html

» http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_abstracts/acme-cascon97.html

Acme studio manual:» http://www.cs.cmu.edu/~acme/

AcmeStudioManual.zip


Acme features

An architectural ontology consisting of seven basic architectural design elements;

A flexible annotation mechanism supporting association of non-structural information using externally defined sublanguages;

A type mechanism for abstracting common, reusable architectural idioms and styles; and

An open semantic framework for reasoning about architectural descriptions.


Acme elements

components connectors systems ports roles, representations and rep-maps


Simple example

System simple_cs = {Component client = { Port send-request; };Component server = { Port receive-request; };Connector rpc = { Roels { caller, callee}};Attachments {client.send-request to rpc.caller;server.receive-request to rpc.callee;}


Acme Elements


Acme elements (cont’d)


Components

Component TheFilter = { Port in; Port out; Property implementation : String = "while (!in.eof) { in.read; in.read; compute; out.write}"; }


Component ports

Component Server = { // Particular requests available through this port Port requests = { Property validRequests = < [name="getCreditReport"; type="secure-request" ]; > }; }


Connectors

Connector collaboration = { Role requestor; Role slave1; Role slave2; Property distributionMap = "requestor.requestA -> slave1.doX, slave2.doY; requestor.requestB -> slave1.doU | slave2.doV" }


Systems

System ClientServerSystem = {

Component server = { Port requests; };

Component client1 = { Port makeRequest; };

Connector req = { Role requestor; Role requestee; };

Attachments { server.requests to req.requestor; ...client.makeRequest to req.requestee; } }


RepresentationsComponent theComponent = { Port easyRequests; Port hardRequests;

Representation { System details = { Component fastButDumbComponent = { Port p; }; Component slowButSmartComponent = { Port p; }; }; Bindings { easyRequests to fastButDumbComponent.p; hardRequests to slowButSmartComponent.p }; }; };


Families

Family PipesAndFiltersFam = { Component Type FilterT = {}; Connector Type PipeT = {}; };

System APFSystem : PipesAndFiltersFam = { Component filter1 : FilterT = new FilterT; Component filter2: FilterT = new FilterT; Connector pipe : PipeT = new PipeT;

... };


Types

Component Type EventListenerT = {

Property eventMap;

Property implementation;

};

Connector Type EventBusT = {

Role broadcaster;

Property glue;

};


Instances

Component AListener: EventListenerT = { Property eventMap = < [ name="eventA"; operation="OnEventA"; ], ... >;

Property implementation = [file="AListener.cpp"; classname="CAListener"]; };


Property Types

Property Type ExecutableNameT = String;

Property Type ExecutablesListT = Sequence <ExecutableNameT>;

Property Type EventDescriptionT =

Record [ eventName: String;

argc:Integer;

argv=Sequence<String> ];

Property Type MessageTypesT =

Enum { change_announcment, command };


Defining an Acme Family

1. Define model vocabularly. That is, define a family of component and connector types. This includes both a description in Acme as well

as a description of the assumptions made about components and connectors under this model.

2. Define a set of property types to encode properties needed by the model. This includes the Acme description as well as a description of

the meaning of the properties under the model. 3. Define constraints that define what it means for a description to

be "well-formed" under this model. These include constraints on individual properties (e.g., a probability must be between 1 and

0), as well as design constraints.


Conclusion

Engineering ‘complex’ software systems requires new models and processes

» cater for system quality attributes» cater for software families

Software architecture is the study of models and processes to design, analyze, customize, reuse and evolve complex software systems

architectural description languages patrick steyaert [email protected]

Documents