Architecturedriven Modeling and Analysis By David Garlan and

Architecture-driven Modeling and Analysis By David Garlan and Bradley Schmerl Presented by Charita Feldman

Deficiencies of Architectural Design Specifications Common practices in representing software architecture luck an ability to: l Express architectural descriptions precisely and unambiguously l Establish criteria for soundness and consistency of architectural designs l Analyze designs to determine implied properties l Apply and enforce design patterns l Guarantee that system implementation is consistent with its architectural design

Modeling Architectural Structures l There are three distinctive views that describe architectural design, each exposing certain aspect of the system: 1. Coding structures views (modules, packages, classes and relationships between them) 2. Run-time structures or component and connector views (databases, clients, servers, and connectors indicating communication ways) 3. Allocation structures views (deployment and work break down structures)

Elements of Components and Connectors view l l Components model principal run-time elements that have a set of ports Ports model component’s interfaces through which component interacts with other components via connectors Connectors model the pathways of communication between components and have a set of roles Roles model the specifications of behavior requires of the components that use a given connector

Example of Component and Connector (C&C) Model in Acme ADL l Simple-cs system consist of a single client and a single server, interacting through rpc based connector l In this representation we can analyze our C&C model to see if there any unattached roles or ports, name collisions and etc.

Modeling Architectural Properties in Acme ADL l l Properties are name-value pairs that can be associated with any architectural element: component, port, connector Sync-request port property indicates if rpc-request port is synchronous or asynchronous, max-transactions-per-second and max-clients-supported component properties indicate maximum properties of server component and protocol property of rpc connector indicates the name of the communication protocol

Example of Modeling Architectural Properties in Acme Studio l Clients queue request for database through set of servers l Using arrival rate, average service time and degree of server replication properties analysis tool calculates average service utilization, queue length and response time. It determined that one of the servers is overloaded

Modeling Architectural Behavior l l l l Which is reading and writing end of the pipe? Is writing syncronous? What if F 2 tries to read and the pipe is empty? Does it wait for input? Can F 1 choose to stop writing? Can F 2 choose to stop reading? Can F 1 close and reopen the pipe? Can F 1 write indefinetey if F 2 never reads from pipe?

Modeling Architectural Behavior in Wright specification language l l l Events model architecturally relevant actions Processes represent patterns of events Sequences represent the ability to follow one behavior by another Choices model branching Composition model partial description

Modeling Architectural Behavior in Wright specification language (cont. ) l Wright specifications of architectural behavior can be associated with various architectural structures, including ports and roles From the model we can see that l Writer pipe can close at any time and cannot reopen l Reader can close at any time l No deadlocks in glue specifications l Component interface of filters F 1 and F 2 or ports satisfy the requirements of connector’s roles

Modeling Architectural Styles l Some systems share a common architectural design vocabulary and a set of constraints on that vocabulary (for example, “client-server systems”, “pipe-filter systems” and etc. is vocabulary, “clients cannot talk directly to other clients” is constrain) l Architectural styles can specified in Acme ADL by defining components, connectors, properties and defining constraints on how instances of components, connectors and properties can be combined in a system description.

Modeling Architectural Styles in Acme ADL l l l Family represents architectural style Invariant represents constraints – data type written to a pipe must match the data read from it Systems can be defined as an instance of the style, components and connectors may de declared as instances of the types defined in family.

Mapping between Architecture and Implementation l There are two methods of insuring that the implementation system is consistent with intended architecture: 1. Construction – concrete model is constructed by applying well-defined refinement rules to an abstract model. This method can be completely automated – called generation 2. Comparison – of the concrete model and abstract model by providing mapping relationships between the two models

Mapping between Architecture and Implementation by Construction l l Applying well defined refinement rules to a more abstract model can be difficult Can be simplified by using architectural styles – limiting the problem to a specific class system and a specific class of implementations. This way it’s possible to automate the process and generate code

Mapping between Architecture and Implementation by Comparison l There are two approaches to compare implementation and architecture: 1. Static analysis – infer architecture by analyzing the code. This approach is effective for inferring moduleoriented structures 2. Dynamic analysis – capture run-time behavior of the system and relate it architectural models. This approach is effective when inferring run-time structure such as C&C models.

Related Work l l l ADLs and associated toolsets focus mostly on component and connector structures and their properties (UML 2. 0) Specification and analysis of architectural behaviors that are mostly focused on finding mismatches in component compositions (Wright, Chemical Abstract Machine, POSets, Category Theory, Pi Calculus, Statecharts) Refinement and generation to map architectures and implementations (Uni. Con, Arch. Java, MDA)

Conclusion l A little formality goes a long way l l Reuse of existing methods l l Most of the formal modeling can be done using existing tools, simulators and model generators One size does not fit all l l Simple structures with types, properties, relations and behavioral descriptions can help provide a clear and unambiguous architecture The more general-purpose a model, the fewer opportunities for deep analysis Areas for improvement l Dynamic Architectures – modeling architectural structures that change dynamically l SA for Emerging Systems – modeling for different computational units, adaptive components l Managing Multiple Views – most of the tools focus on component and connector views, need to manage relationships between different views