ICS 123 Software Architecture ICS 123 Spring 2002

ICS 123 Software Architecture ICS 123 Spring 2002 Richard N. Taylor and Eric M. Dashofy* UC Irvine http: //www. isr. uci. edu/classes/ics 123 s 02/ * with very special thanks to David S. Rosenblum for the use of his materials.

Software Architecture (Perry & Wolf 92) Topic 2 Software Architecture ICS 123 “Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design. ” (vs. design…) “Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements. ” 2

Software Architecture (Garlan & Shaw 93) Topic 2 Software Architecture ICS 123 “Software architecture is a level of design that goes beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives. ” 3

Software Architecture (Shaw & Garlan 96) Topic 2 Software Architecture ICS 123 “The architecture of a software system defines that system in terms of computational components and interactions among those components. … In addition to specifying the structure and topology of the system, the architecture shows the correspondence between the requirements and elements of the constructed system, thereby providing some rationale for the design decisions. ” 4

Analogies with Civil Architecture Topic 2 Software Architecture ICS 123 Civil Engineering and Civil Architecture are concerned with the engineering and design of civic structures (roads, buildings, bridges, etc. ) • Architecture vs. Construction • Multiple views – Civil: Artist renderings, elevations, floor plans, blueprints – Software: Code, object design, boxes-and-arrows, GUI • Architectural styles – Civil: Classical, Romanesque, Gothic, Renaissance, Baroque, Art Deco – Software: Pipe-and-filter, client/server, layered system • Influence of style on engineering principle • Influence of style on choice of materials 5

Differences Between Civil and Software Architecture Topic 2 Software Architecture • Physical vs. conceptual • Static vs. dynamic • Little evolution vs. frequent evolution • Different mathematical and scientific bases • Different notions of “reuse” 6 ICS 123

Elements of Software Architecture Topic 2 Software Architecture ICS 123 • Perry & Wolf – Structural Elements » Processing » Data » Connecting (“glue”) – Form: Weighted Properties and Relationships – Rationale • Shaw & Garlan: – – 7 Components Interconnections Rules of Composition Rules of Behavior This Class • Components • Connectors • Interfaces • Configurations • (implies) Links

Components Topic 2 Software Architecture ICS 123 • A component is a building block that is … – A unit of computation or a data store, with an interface specifying the services it provides – A unit of deployment – A unit of reuse 8

The Difference Between Components and Objects Topic 2 Software Architecture ICS 123 • Lifecycle – Objects are created and destroyed constantly – Components are created and destroyed infrequently • Purpose of use – Graphics toolkit (component) vs. graphics widget (object) – Data store (component) vs. data structure (object) • Type system – Objects are instances of a class, with classes arranged in hierarchies according to inheritance relationships – Components may have their own type system (may be trivial), often very few components of the same type • Size – Objects tend to be small – Components can be small (one object) or large (a library of objects or a complete application) 9

Connectors Topic 2 Software Architecture • A connector is a building block that enables interaction among components – – – Shared variables Procedure calls (local or remote) Messages and message buses Events Pipes Client/server middleware • Connectors may be implicit or explicit – Implicit: procedure calls – Explicit: First-class message buses 10 ICS 123

The Difference Between Components and Connectors Topic 2 Software Architecture ICS 123 • Task Performed – Components focus on computational tasks – Connectors focus on communication tasks • Application Semantics – Components generally implement most of the application semantics – Connectors do not (they may change the form of the message, but do not generally change its meaning) • “Awareness” – Components (should be) unaware of who is using them and for what purpose – Connectors are more aware of components connected to them so they can better facilitate communication 11 Not everybody agrees on this!

Interfaces Topic 2 Software Architecture ICS 123 • An interface is the external “connection point” on a component or connector that describes how other components/connectors interact with it • Provided and required interfaces are important • Spectrum of interface specification – Loosely specified (events go in, events go out) – API style (list of functions) – Very highly specified (event protocols across the interface in CSP) • Interfaces are the key to component interoperability (or lack thereof) 12

Configurations Topic 2 Software Architecture ICS 123 • A configuration is … – The overall structure of a software architecture – The topological arrangement of components and connectors » Implies the existence of links among components/connectors – A framework for checking for compatibility between interfaces, communication protocols, semantics, … • “If links had semantics, they’d be connectors. ” • Usually constructed according to an architectural style 13

Topic 2 Software Architecture Graphically… ICS 123 Interfaces Clock Component Connector Bus 1 Interfaces 14

Graphically (cont). Clock Bus 1 LCD Driver 15 Topic 2 Software Architecture ICS 123 Configuration Links

Example: Architectures for a Compiler Scanner File Semantic Analyzer Parser 16 Component Code Generator File Parse Tree Legend: ICS 123 Semantic Analyzer Parser File Topic 2 Software Architecture Connector Code Generator

What does architecture buy you? Topic 2 Software Architecture ICS 123 • On its face, nothing! • A bad architecture can imply a spaghetti code system – See “Big Ball of Mud, ” http: //www. devcentre. org/mudmain. htm • How can we use architecture to improve the qualities (-ilities) of our software systems? • Answer: Architectural Styles 17

Architectural Styles Topic 2 Software Architecture ICS 123 • An architectural style is … – A set of constraints you put on your development to elicit desirable properties from your software architecture. – These constraints may be: » Topological » Behavioral » Communication-oriented » etc. – Working within an architectural style makes development harder – BUT architectural styles help you get beneficial system properties that would be really hard to get otherwise 18

The Classical Style of Civil Architecture The Pantheon Rome, Italy 19 Topic 2 Software Architecture ICS 123

The Gothic Style Topic 2 Software Architecture ICS 123 Nôtre-Dame Cathedral Paris, France 20

The Mediterranean Style Irvine, California 21 Topic 2 Software Architecture ICS 123

Common Software Architectural Styles (Shaw & Garlan 96) Topic 2 Software Architecture • Dataflow Systems – Batch sequential – Pipes and filters • Call-and-Return Systems – Main program and subroutines – Object-oriented systems – Hierarchical layers (onion layers) • Independent Components – Communicating processes (client/server and peer-to-peer) – Event systems – Implicit invocation 22 ICS 123

Common Software Architectural Styles (Cont. ) • Virtual Machines – Interpreters – Rule-based systems • Data-Centered Systems (Repositories) – Databases – Hypertext systems – Blackboards 23 Topic 2 Software Architecture ICS 123

Pipe and Filter Example Topic 2 Software Architecture ICS 123 • You, too, are a software architect! • ls –l *. java | grep “foobar” | lpr –P gaston – Components: Filters – Connectors: Stream-based pipes – Interfaces: One in, one out on each pipe or filter, exchange byte streams – Links: Implicit in above command line – Configuration: Specified by ordering on the command line 24

Pipe & Filter Constraints Topic 2 Software Architecture ICS 123 • All communication via byte streams • One “in, ” one “out” interface on each component • Only connectors are pipes • A pipe is mandatory between each pair of sequential filters • Filters must be ordered sequentially, starting and ending with a filter • What software qualities are brought out by this style? 25

Pipe & Filter Qualities Topic 2 Software Architecture ICS 123 • Configurability: Any set of filters may be combined in any order – Although reasonable semantics are not guaranteed by this style • Efficiency: All data does not have to be processed for the next • • 26 filter to start working Customizability: Filters can be easily inserted, removed into the software architecture Domain-specific: Works very well for text-processing problems.

The Vision: Architecture- Based Composition & Reuse Topic 2 Software Architecture ICS 123 • A framework for design and implementation of largescale software systems • A basis for early analysis of software system properties • A framework for selection and composition of reusable off-the-shelf components • A basis for controlled evolution of software • A basis for runtime evolution of software 27

The Reality: Architectural Mismatch Topic 2 Software Architecture ICS 123 • Architectural mismatch refers to a mismatch between assumptions made by different components about the structure of the system and the nature of the environment in which they operate • Assumptions about the nature of the components – substrate on which a component is built – control model – data model • Assumptions about the nature of the connectors – protocols – data model 28

Architectural Mismatch (Cont. ) Topic 2 Software Architecture ICS 123 • Assumptions about the global configuration – topology – presence of certain components or connectors – absence of certain components or connectors • Assumptions about the system construction process – order in which elements are instantiated – order in which elements are combined • Assumptions about the operating environment – Threading concerns – Availability or characteristics of lower-level functionality (OS-level, network) 29

Standards: The Solution? Topic 2 Software Architecture ICS 123 • Standards define a set of “assumptions” that all components must adhere to – Component interface standards (e. g. , Java. Beans, Active. X, Netscape Plug-in API) – Component interoperability standards (e. g. , CORBA, DCOM, Java RMI) – Standard component frameworks (e. g. , Microsoft Foundation Classes) • But standards also reduce design flexibility 30

More Reality: “Architectural Drift” Topic 2 Software Architecture • How are architectures implemented now? ICS 123 Python 1. 5. 2 (#1, Apr 18 1999, 16: 03: 16) Copyright 1991 -1995 Stichting Mathematisch Centrum, Amsterdam >>> import asynchat # create an instance >>> channel = asynchat. async_chat() # access to attributes from an instance >>> channel. ac_in_buffer '' >>> channel. ac_in_buffer_size 4096 # now let's look at the name spaces >>> channel. __dict__['ac_in_buffer'] '' >>> channel. __dict__['ac_in_buffer_size' ] Traceback (innermost last): File "<pyshell#11>", line 1, in ? channel. __dict__['ac_in_buffer_size' ] Key. Error: ac_in_buffer_size # not found in the instance's namespace! # check the class namespace >>> asynchat. async_chat. ac_in_buffer_siz e 4096 Brilliant Software Architecture 31 Semi-Cohesive Object Design in UML Incomprehensible Python Code

Why does drift happen? Topic 2 Software Architecture ICS 123 • Eventually, software must become code – Programming languages and operating systems provide poor support for entities at the architecture level of abstraction • Induces “architectural drift” (Garlan & Allen) – As the system gets built and (especially) maintained, the system drifts further away from its original intended design/architecture – Increases software costs and failures dramatically 32

Solutions for Drift Topic 2 Software Architecture • Maintain a persistent view of architecture at implementation time • Co-evolve requirements and architecture • Use architecture as the basis for: – – System Design Maintenance System evolution Deployment • Much of this is still “research!” 33 ICS 123

ICS 123 Architecture Tools and “Real” Technologies ICS 123 Richard N. Taylor and Eric M. Dashofy UC Irvine http: //www. isr. uci. edu/classes/ics 123 s 02/

Overview Topic 2 Software Architecture ICS 123 • Architecture-centric Development Environments – Arch. Studio • Architecture Description Languages – x. ADL 2. 0 • Architecture Frameworks – c 2. fw and others 35

The Vision Topic 2 Software Architecture ICS 123 • Architecture-driven Software Development – Architecture as the primary abstraction for design – The architecture is defined very early in the development cycle (possibly in parallel with the requirements) – The architecture persists into the implementation and maintenance phases of development • Gap analysis: how do we get there from here? – Ways to represent, manipulate, and visualize architectures – Tool support for designing, implementing and evolving architectures – Development of Architecture-centric Development Environments » Think “Visual Studio” but for architectures, rather than code Can you name some tools that would go in a {code-based/architecture-based} environment? 36

Contrast: IDE vs. Architecture-based DE ICS 123 Code-based IDE Tools: Architecture-based Tools: • Text editor • Visual Editor • GUI Builder • Composition assistants • Compiler • Code generator • Debugger • Instantiation & Evolution Management • Static Analysis Tools • Project Management • Source file configuration management 37 Topic 2 Software Architecture • Various analysis tools • Style-specific constraint management • Component-based configuration management

Arch. Studio Topic 2 Software Architecture ICS 123 • Arch. Studio is an extensible architecture-centric development environment – Tools within the environment have special support for the C 2 architectural style – The environment itself is built in the C 2 style • Arch. Studio Tools (integrated in various versions): – Editors (visual, syntax-directed, and command-line) – Analysis tools (static & dynamic analysis, design critics) – Off-the-shelf integrations » Code-based IDEs (Eclipse, Metamata, etc. ) » OOAD tools (Rational Rose) » Hypermedia systems (Browsers, Chimera) – And more… 38

Holds architecture descriptions Arch. Studio 3 Today Manages open issues Critics watch architecture for problems Manages design critics Architecture-to-implementation mappings GUIs for various high-level tools Graphical and syntax-directed editors 39 Manages open files and tools Topic 2 Software Architecture ICS 123

Architecture Description Languages Topic 2 Software Architecture ICS 123 • How do we “write down” a software architecture? • An architecture description language (or architecture definition language, or ADL) is a formal notation for describing the structure and behavior of a software architecture • ADLs provide – – a concrete syntax a formal semantics a conceptual framework for explicitly modeling the conceptual architecture of a system • Contrast with programming languages, which define the implementation of a system 40

What Goes in a Software Architecture Description? Topic 2 Software Architecture ICS 123 • From Medvidovic and Taylor, 2000: – “An ADL must explicitly model components, connectors, and their configurations; furthermore, to be truly usable and useful, it must provide tool support for architecture-based development and evolution. These four elements of an ADL are further broken down into constituent parts. ” – “In order to infer any kind of information about an architecture, at a minimum, interfaces of constituent components must also be modeled. Without this information, an architectural description becomes but a collection of (interconnected) identifiers, similar to a “boxes and lines” diagram with no explicit underlying semantics. ” What else would you model about a software system you were designing? 41

What people have put in their descriptions Distribute d Systems Events Configuration Management Dynamic Systems 42 Product Families Topic 2 Software Architecture ICS 123 Behaviora l Properties Implementatio n Mappings Mobile, Dynamic Architectures

What really goes in an ADL? Topic 2 Software Architecture ICS 123 • “There is, however, still little consensus in the research community on what an ADL is, what aspects of an architecture should be modeled by an ADL…” • This can be a good thing! – Model only what you will find useful. – Model things that your tools can work with or analyze. – Model critical aspects of your software system in more detail. • This can be a bad thing! – Limits on architectural interchange. – Limits applicability of tools on divergent notations. Do you think this occurs in the programming language domain? 43

Problem and (Potential) Solution Topic 2 Software Architecture ICS 123 • Problem: How can we exploit commonalities and experiment with different features in an ADL without duplicating effort? • Solution: An extensible ADL – Start with a core of “common” features » Components, Connectors, Interfaces, Links (configurations) – Extend that core by adding features as necessary • Benefits – Shared features may imply shared tools – “Pick and choose” features that model aspects you care about – Reuse other people’s modeling constructs and the effort therein 44

x. ADL 2. 0: An Extensible ADL Topic 2 Software Architecture ICS 123 • x. ADL 2. 0 is an example of an extensible ADL • Has a core set of features (called x. Arch) that model the usual core ADL features: – Components, Connectors, Interfaces, Links – BUT! These are “semantically neutral”—nothing is said about what these things are/do. • Has several extensions that you can choose and incorporate into your modeling efforts if you want. – – – 45 Design-time/Run-time separation Type system for components, connectors, interfaces Implementation Mappings Variants, Options, and Versions (Product Families and Architecture CM) More on the way!

How does extensibility work in x. ADL 2. 0? Topic 2 Software Architecture ICS 123 • x. ADL 2. 0 is built as an XML-based language • Uses extensibility constructs from XML schemas (more on this later in the quarter) • Simplified explanation : Architecture{ comp*: Component; conn*: Connector; link*: Link; } Component{ id: String; if: Interface* } 46 Interface{ id: String } Component. With. Version extends Component{ add{ version. ID: String; } remove{ } } Architecture. With. Versions extends Architecture{ add{ vtree*: Version. Tree } … }

Design-Time vs. Run-Time Behavior information for static analysis Comp 1_Beh{ If(recv(evt(q))){ do. Process(q) emit(evt(b)); } } Comp 1 Run-time State aba - - State= BLOCKED Comp Inst 1 Waiting on event “A” Comp Inst 2 Comp 2 Conn Inst 1 Conn 1 Comp 3 Invariant a{ comp 1. interface. type = top -> comp 1. interface. link. type = bottom } 47 ICS 123 Event queue contents Design-oriented Properties Author=André Author=Dick Last Update: 08/18/2001 Topic 2 Software Architecture Constraints Comp Inst 3 Machine = magister Pid = 242 CPU = 1 Port = 8080 … Information about distributed components

Implementation Mappings Topic 2 Software Architecture ICS 123 Comp 1 Foo. class Comp 2 Baz. dll Conn 1 Comp 4 Comp 3 . NET Service Adding information about implementations to component, connector, and interface types is essential if the architecture is to be instantiated. 48 Bar. jar Helps prevent architectural drift!

Product Families & Architecture Evolution Topic 2 Software Architecture ICS 123 1. 0 Component With Variant Type Comp 1 Version Graph for Type T 1. 1 Comp 2 2. 0 1. 1. 1 Comp 4 1. 1. 2 Comp 3 Optional Component & Link 3. 0 Can you think of an example of where a lack of this sort of support has caused you problems? 49

x. ADL 2. 0 Feature Dependencies Topic 2 Software Architecture ICS 123 Instances Structure & Types Versions Options Variants Abstract Implementation Java Implementation 50 Architecture Diffing Messaging Interfaces Type Relationships

x. ADL 2. 0 Tool Support Topic 2 Software Architecture ICS 123 • x. ADL 2. 0 is meant to be read & written by people and computers – Contrast with a formal notation like Z (“Zed”)… – People need some way of creating, editing x. ADL 2. 0 documents – Programs need some way of creating, editing x. ADL 2. 0 documents programmatically • Several tools available – XML Tools off-the-shelf » XML Spy, Tibco XML Authority, Apache Xerces, Xalan, etc. – x. ADL 2. 0 Tools » Apigen: Can generate Java objects for x. ADL 2. 0 (and extensions!) constructs based entirely on the language definition » Data Binding Library: Java objects for x. ADL 2. 0 constructs, generated by Apigen » Arch. Edit: Syntax-directed Editor for x. ADL 2. 0 » Visio for x. ADL: Graphical box & arrow editor for x. ADL 2. 0 documents 51

x. ADL 2. 0 Tool Relationships x. ADL 2. 0 Schemas uses Apigen Arch. Edit Apache Xerces Topic 2 Software Architecture ICS 123 uses generates Data Binding Library changes the interface to events uses x. Arch. ADT Visio for x. ADL uses use Design Critics Arch. Studio Components 52

Gratuitous Graphics: Arch. Edit 53 Topic 2 Software Architecture ICS 123

Gratuitous Graphics: Visio 54 Topic 2 Software Architecture ICS 123

Gratuitous Graphics: Critics 55 Topic 2 Software Architecture ICS 123

Architecture Frameworks Topic 2 Software Architecture ICS 123 • How do you implement a software architecture? • Programming language constructs are often insufficient Programming Language: Architecture: • Objects • Components • Procedure calls, callbacks • Connectors, Events • Threads of control • Threading Policy • Design Patterns • Architectural Styles 56 Can you think of a concrete example from your favorite programming language?

Architecture Frameworks Topic 2 Software Architecture ICS 123 • An architecture framework is software that assists developers in building implementations of a software architecture faithful to the target style by providing services and tools that are not available in the existing development environment. • Frameworks can vary in: – – – 57 Fidelity Platform/Language Any –ility Size Reliance on other software Each layer may make use of services provided by any layer below, although should concentrate on upper layers. Architecture-Based Application Architecture Framework Middleware (JMS, CORBA) Programming Language OS/Filesystem/Network

C 2 Frameworks Topic 2 Software Architecture ICS 123 • Original C 2 Frameworks (Java & C++, UCI) – Highly faithful to C 2 concepts – Some dynamism support, support for various threading policies • o. C 2 Framework (Java, USC) – Version of the Original C 2 Java Framework optimized for performance • e. C 2 Framework (Java, USC) – Built to be lightweight for embedded devices (Palms, i. PAQ, etc. ) – Used central message queues, limited number of threads, low resource consumption (memory, etc. ) • c 2. fw Framework (Java, UCI) – – 58 Highly flexible C 2 framework Supports pluggable message queuing, threading, topology managers More message types allowed Improved support for distribution, dynamism

A closer vision: architecturebased evolution and reuse Process Support Tools? Topic 2 Software Architecture ICS 123 Feedback and Planning Analysis Tools Framework ADL 59 Architecture Evolution Manager Implementation Issues

ICS 123 Other Architecture Approaches and Tools ICS 123 Richard N. Taylor and Eric M. Dashofy UC Irvine http: //www. isr. uci. edu/classes/ics 123 s 02/

Recall… Topic 2 Software Architecture ICS 123 • Architecture Description Languages are ways of writing down software architectures. • ADLs include, at minimum – – Components Connectors Interfaces Configurations ( links) • Not everybody agrees on what else goes in an ADL • x. ADL 2. 0 is an attempt at an extensible ADL 61

Topic 2 Software Architecture A Quick Look at ADLs… Darwin Rapide Koala Distribute d Systems Events Mae Configuration Management Darwin, C 2 SADL 62 ICS 123 Dynamic Systems Product Families Wright Behaviora l Properties Implementatio n Mappings x. ADL 1. 0 Mobile, Dynamic Architectures ? ?

A Brief Look at Three Other Approaches Topic 2 Software Architecture ICS 123 • Rapide (Stanford, D. Luckham) • Darwin (Imperial College London, J. Kramer & J. Magee) • ACME (Carnegie-Mellon, D. Garlan) 63

Rapide • Key foci – – – 64 Model behaviors of components, interactions Events are the method of communication Events organized in POSETs (Partially Ordered SETs) Specified systems can be simulated by Rapide toolset Simulations can be visualized in a graph format Topic 2 Software Architecture ICS 123

Topic 2 Software Architecture POSETs ICS 123 • Consider events that a person might emit at a gas station: – – – Pull up Leave Use Credit Card Machine Wash Windows Pump Gas Credit Card What are the orderings between these events? Pump Gas Wash Leave Pull Up Wash Credit Card 65 Credit Card Pump Gas

A Rapide Interface Topic 2 Software Architecture type Pump is interface action in On(), Off(), Activate(Cost : Dollars); out Report(Amount : Gallons; Cost : Dollars); “disjoint AND” behavior Free : var Boolean : = True; Reading, Limit : var Dollars : = 0; action In_Use(), Done(); begin (? X : Dollars)(On ~ Activate(? X)) where $Free => Free : = False; Limit : = ? X; In_Use; ; In_Use => Reading : = $Limit; Done; ; Off or Done => Free : = True; Report($Reading); ; -- constraint end Pump; 66 ICS 123

A Rapide Configuration Topic 2 Software Architecture architecture gas_station 1() return root is O : Operator; P : Pump; C 1, C 2 : Customer; connect (? C : Customer; ? X : Dollars) ? C. Pre_Pay(? X) => O. Request(? X); (? X : Dollars) O. Schedule(? X) => P. Activate(? X); (? X : Dollars) O. Schedule(? X) => C 1. Okay; -- change this (? C : Customer) ? C. Turn_On => P. On; (? C : Customer) ? C. Turn_Off => P. Off; (? X : Gallons; ? Y : Dollars)P. Report(? X, ? Y) => O. Result(? Y); end gas_station 1; 67 ICS 123

The Result Can you identify a potential problem revealed by this event trace? 68 Topic 2 Software Architecture ICS 123

The Result Could this be a problem? Ability to specify Constraints (patterns that should or should not happen) are important in finding these issues. 69 Topic 2 Software Architecture ICS 123

Darwin • Key foci – Model distributed systems – Model dynamic systems 70 Topic 2 Software Architecture ICS 123

Darwin Example component filter{ provide output<stream char>; require input<stream char>; }; component pipeline(int n){ provide output; require input; array F[n]: filter; forall k: 0. . n-1{ inst F[k] @ k+1; when k < n-1; bind F[k+1]. input -- F[k]. output; } bind F[0]. input -- input; output -- F[n-1]. output; } } 71 Topic 2 Software Architecture ICS 123

Darwin: Specifying Change Topic 2 Software Architecture Adding a node to a ring of components (dining philosophers, in this case) MERGE: : unlink pa[1] from pa[(1 mod N))+1], pa[(1 mod N))+1] from pa[1], pb[1] from pb[(1 mod M))+1], pb[(1 mod M))+1] from pb[1]; link pa[1] to pb[1], pb[1] to pa[1]; pa[(1 mod N))+1] to pb[ (1 mod M))+1], pb[ (1 mod M))+1] to pa[(1 mod N))+1]; 72 ICS 123

Darwin: Tools 73 Topic 2 Software Architecture ICS 123

ACME • Key Foci: – Genericity (Usual Suspects + Name-Value Properties) – Function as an “architecture interchange language” • Later Developments – Constraints on elements – Constraint based type system 74 Topic 2 Software Architecture ICS 123

Topic 2 Software Architecture ACME Example* ICS 123 Component Type Client. T = { Port send. Req; … }; Component Type Server. T = { Port receive. Req; … }; Connector Type RPCT = { Roles {caller; callee}; … }; System Simple. Client. Server = { Component viewer : Client. T; Component database : Server. T; Connector conn : RPCT; Attachments = { viewer. send. Req to conn. caller; viewer. receive. Req to conn. callee; }; }; 75 viewer database *Slides From Bob Monroe’s ICSE’ 99 Tutorial

ACME Example (cont). Topic 2 Software Architecture ICS 123 Component Type Server. T = { Port receive. Req : ODBCPort. T = { Property supports. ODBCLevel : int = 2; Property supports. Concurrent. Trans : boolean = true; }; Property max. Concurrent. Trans : int = 20; Property average. Trans. Processing. Latency : float; Property ODBCCompliance. Level : int; }; Can you identify potential drawbacks to using this approach for architectural interchange? 76 *Slides From Bob Monroe’s ICSE’ 99 Tutorial

Summary Topic 2 Software Architecture ICS 123 • No “one true approach” • Flexibility, interchange, evolvability of ADLs is still unachieved – But we’re getting there, and hopefully will be there soon! 77