Advanced OOSA State of the Art on Software Architecture Declarative Meta Programming Session 2: Software Architecture Nantes, EMOOSE 2000–2001 Dr. Kim Mens, PROG, VUB

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 2 Course overview ÊIntroduction ËSoftware Architecture ÌDeclarative Meta Programming ÍSoftware Classification ÎLightweight Architectural Tools ÏAutomated Architectural Conformance Checking ÐAn Architecture-driven Software Development Tool ÑAssignments

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 3 References n L. Bass, P. Clements & R. Kazman Software Architecture in Practice Addison Wesley Longman, 1998 n M. Shaw and D. Garlan Software Architecture — Perspectives on an Emerging Discipline Prentice Hall, 1996 n Special Issue on Software Architecture Transactions on Software Engineering, vol. 21, April 1995 IEEE Press, 1995 n Course “Techniques of Software Architecture” by Patrick Steyaert, Vrije Universiteit Brussel RECAP

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 4 References n K. Walden Seamless Object-Oriented Software Architecture; Analysis And Design Of Reliable Systems Prentice Hall n C. Hofmeister Applied Software Architecture Addison Wesley - Longman n D. C. Schmidt Pattern-Oriented Software Architecture John Wiley & Sons Inc n J. Bosch Design And Use Of Software Architectures: Adopting and Evolving A Product-Line Approach Addison Wesley - Longman RECAP

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 5 Session overview n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 6 Goals of software architecture n Designing, maintaining and reasoning about large and complex software at a high level of abstraction n Provide a simple picture of the overall structure of a software system

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 7 Some definitions n “The software architecture is the structure of a system, which comprises software components, the externally visible properties of those components and the relationship among them.” n “A software architecture is a specification of a set of components and a communication pattern or protocol among them.” n “Architecture is the structure of the components of a system, their interrelationships and principles and guidelines governing their design and evolution over time.” n “Architecture defines a system in terms of components, connectors and constraints”

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 8 Some definitions n “The software architecture is the structure of a system, which comprises software components, the externally visible properties of those components and the relationships among them.” n “A software architecture is a specification of a set of components and a communication pattern or protocol among them.” n “Architecture is the structure of the components of a system, their interrelationships and principles and guidelines governing their design and evolution over time.” n “Architecture defines a system in terms of components, connectors and constraints”

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 9 Architectural models emphasize n understanding of overall structure u components n interaction u connectors, communication protocols, relationships between components n evolution u guiding principles for evolution n structure is determined by the observer u different structures are possible u architectural views

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 10 Architectural structures n Module structure n Conceptual or logical structure n Process or coordination structure n Physical structure n Uses structure n Class structure n Calling structure n Data flow n Control flow n...

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 11 Session overview n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 12 “Forces” that influence architecture n Different stakeholders … u customer, end-user, developer, maintenance, marketing, sales n … with different (conflicting) concerns u cost, time-to-market, many changes, few changes, many features, few features, reliable, future-oriented, standard, customizable n … with different scope and requirements u functional and non-functional n … with different technical environment, experience and background

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 13  Non-functional Requirements System quality attributes n Performance n Scalability n Security n Availability n Usability n Traceability n Functionality n Configurability n Variability in functionality n Change-tolerance n Portability n Reusability n Integrability n Interoperability

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 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]

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 15 Session overview n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 16 Architectural styles n Analogous to architectural style in buildings such as Gothic, Roman, … n It defines key features and rules for combining them n An architectural style is determined by: u component types u topological layout of components u semantic constraints u connectors

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 17 Example styles n Independent components u communication processes u event systems n Data flow u batch sequential u pipes and filters n Data-centered u repository u blackboard n Virtual Machine u interpreter u rule based system n Call and return u main program and subroutine u object-oriented u layered

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 18 Pipes and filters (pipeline) n Components: u Filters n Connectors: u Pipes n Constraint: u filters can only be connected to other filters through pipes u every filter has at most one incoming and outgoing port u every pipe has exactly one incoming and outgoing role u every filter port is linked to exactly one pipe role u every pipe role is linked to exactly one filter port Filter Pipe

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 19 Pipes and filters (pipeline) Code Generator Lexical Analyser Parser Pipe n Example: the architecture of a traditional compiler

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 20 Session overview n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 21 ACME n Home page: u n ACME descriptions: u u _abstracts/acme-cascon97.html _abstracts/acme-cascon97.html n ACME Studio manual: u

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 22 Uses Data 1 Uses Data 2 Asks 2 Asks 1 Updates 1 Clause Selector Knowledge Base Rule Interpreter Working Memory ACME Studio Example: the architecture of a rule-based interpreter

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 23 ACME Studio

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 24 ACME features n architectural ontology consisting of seven basic architectural design elements n flexible annotation mechanism supporting association of non-structural information using externally defined sub-languages n type mechanism for abstracting common, reusable architectural idioms and styles n open semantic framework for reasoning about architectural descriptions

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 25 ACME elements (1) n components n connectors n systems n ports n roles n representations and rep-maps

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 26 System simple_cs = { Component client = { Port send-request; }; Component server = { Port receive-request; }; Connector rpc = { Role caller; Role callee }; Attachments {client.send-request to rpc.caller; server.receive-request to rpc.callee;} Simple example

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 27 ACME elements (2)

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 28 ACME elements (3)

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 29 Components Component TheFilter = { Port in; Port out; Property implementation : String = "while (!in.eof) { in.read; compute; out.write }"; }

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 30 Component ports Component Server = { // Particular requests available through this port Port requests = { Property validRequests = < [name="getCreditReport"; type="secure-request" ]; > }; }

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 31 Connectors Connector collaboration = { Role requestor; Role slave1; Role slave2; Property distributionMap = "requestor.requestA -> slave1.doX, slave2.doY; requestor.requestB -> slave1.doU | slave2.doV" }

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 32 Systems System ClientServerSystem = { Component server = { Port requests; }; Component client1 = { Port makeRequest; }; Connector req = { Role requestor; Role requested; }; Attachments { server.requests to req.requestor; … client.makeRequest to req.requestee; }

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 33 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 } ; }; } ;

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 34 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;... };

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 35 Types Component Type EventListenerT = { Property eventMap; Property implementation; }; Connector Type EventBusT = { Role broadcaster; Property glue; };

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 36 Instances Component AListener: EventListenerT = { Property eventMap = < [ name="eventA"; operation="OnEventA"; ], … >; Property implementation = [ file="AListener.cpp"; classname="CAListener” ]; };

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 37 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 };

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 38 Defining an ACME Family 1. Define model vocabulary. 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.

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 39 Session overview n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 40 Conclusion n Software architecture is the study of models and processes to design, analyze, customize, reuse and evolve complex software systems

State of the Art on Software Architecture — Declarative Meta ProgrammingSession 2, page 41 Session overview n Software architecture n Quality attributes n Architectural styles n ACME n Conclusion Time for a break