Architectural Description Languages Patrick Steyaert

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 2 Reference 4Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison Wesley, 1997.

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 3 Goal Designing, maintaining and reasoning about ‘complex’ object-oriented software systems at a high level of abstraction.

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 4 à What we know how to build. ‘Programs’ 4Single purpose 4Single developer (or very small group) 4Short lived 4Single version 4Scalability is not an issue 4No openness to other systems

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 5 ‘ Software Systems’ 4Multi purpose, or complex single purpose 4High change, multiple versions (variations) 4Multiple point of entry 4Open to other systems (e.g. legacy) 4Scalable in size and time à What we need to build.

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 6 The Challenge 4Extremely complex systems... 4more than one mind can handle at once … 4interacting with other systems... 4in a fast changing environment. 4must manage complexity 4must manage interactions 4must manage variations 4must manage evolution

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 7 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

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 8 Application Families 4application systems that are intended to work together »e.g. MS Office 4application systems with variants in a domain »e.g. telephone switches »e.g planning systems »e.g. ERP systems 4application systems that share certain foundations or are interoperable in some way »e.g. running on the same windowing system

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 9 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”

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 10 Architectural Models Emphasize 4understanding of overall structure »components 4interaction »connectors, communication protocols, relationships between components 4evolution »guiding principles for evolution 4structure is determined by the observer »different structures are possible

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 11 Architectural Structures 4Module structure 4Conceptual of logical structure 4Process of coordination structure 4Physical structure 4Uses structure 4Class structure 4Calls structure 4Data flow, Control flow

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 12 Concerns that Influence Architecture 4Different stakeholders »customer, end-user, developer, maintenance, marketing, sales 4 With different concerns (conflict) »cost, time-to-market, many changes, few changes, many features, few features, reliable, future-oriented, standard, customisable 4With different scope and requirements »functional and non-functional 4With different technical environment, experience and background Architect

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 13 System Quality Attributes 4Performance 4Scalability 4Security 4Availability 4Usability 4Tracability 4Functionality 4Configurability 4Variability in functionality 4Change-tolerance 4Portability 4Reusability 4Integrability 4Interoperability  Non-functional Requirements

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 14 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]

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 15 Example: LAN Application System Node WorkStation Node OutputServer #John from: #John to: #Printer1 bla bla bla bla accept: packet #Printer1 packet End user: LAN expert Services: simulations

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 16 LAN classes Workstation originate (p : Packet) Printserver print (p : Packet) Node name accept(p:Packet) send(p:Packet) 1 nextNode 1 Packet originator addressee contents

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 17 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); }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 18 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); }}

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 19 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); }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 20 Packet public class Packet { public String originator; public String addressee; public String contents; public Packet(String a, String c) { addressee = a; contents = c; }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 21 LAN Architecture Node Packet PSPrinter ASCIIPrinter Components MyPacket 4Components = classes 4Connections = message passing

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 22 Architectural Styles 4Analoguos to architectural style in buildings such as Gothic, Roman, … 4It defines key features and rules for combining them 4An architectural style is determined by: »component types »topological layout of components »semantic constraints »connectors

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 23 Example styles 4Independent components »communication processes »event systems 4Data flow »batch sequential »pipes and filters 4Data-centered »repository »blackboard 4Virtual Machine »interpreter »rule based system 4Call and return »main program and subroutine »object-oriented »layered

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 24 Pipes and Filters

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 25 Acme 4Home page: » 4Acme descriptions: » acme.htmlhttp:// acme.html » e/www/paper_abstracts/acme-cascon97.html 4Acme studio manual: » al.zip

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 26 Acme features 4An architectural ontology consisting of seven basic architectural design elements; 4A flexible annotation mechanism supporting association of non-structural information using externally defined sublanguages; 4A type mechanism for abstracting common, reusable architectural idioms and styles; and 4An open semantic framework for reasoning about architectural descriptions.

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 27 Acme elements 4components 4connectors 4systems 4ports 4roles, 4representations and rep-maps

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 28 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; }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 29 Acme Elements

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 30 Acme elements (cont’d)

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 31 Components Component TheFilter = { Port in; Port out; Property implementation : String = "while (!in.eof) { in.read; in.read; compute; out.write}"; }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 32 Component ports Component Server = { // Particular requests available through this port Port requests = { Property validRequests = < [name="getCreditReport"; type="secure-request" ]; > }; }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 33 Connectors Connector collaboration = { Role requestor; Role slave1; Role slave2; Property distributionMap = "requestor.requestA -> slave1.doX, slave2.doY; requestor.requestB -> slave1.doU | slave2.doV" }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 34 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; }

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 35 Representations Component 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 };

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 36 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;... };

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 37 Types Component Type EventListenerT = { Property eventMap; Property implementation; }; Connector Type EventBusT = { Role broadcaster; Property glue; };

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 38 Instances Component AListener: EventListenerT = { Property eventMap = < [ name="eventA"; operation="OnEventA"; ],... >; Property implementation = [file="AListener.cpp"; classname="CAListener"]; };

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 39 Property Types Property Type ExecutableNameT = String; Property Type ExecutablesListT = Sequence ; Property Type EventDescriptionT = Record [ eventName: String; argc:Integer; argv=Sequence ]; Property Type MessageTypesT = Enum { change_announcment, command };

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 40 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.

Objects, Frameworks, Patterns and Architecture, 2000, Part 1 41 Conclusion 4Engineering ‘complex’ software systems requires new models and processes »cater for system quality attributes »cater for software families 4Software architecture is the study of models and processes to design, analyze, customize, reuse and evolve complex software systems