1. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.1 6. Architectural Extraction

2. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.2 Roadmap Definitions Modeling software architecture with UML Architectural Description Languages Reflexion Models Source-code Views Conclusion and references

3. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.3 Software Architecture is about… High-level design of the software Arrangements of larger parts of the system. (subsystems, large components) instead of classes and objects.

4. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.4 Preliminary Definitions A system is a set of components that accomplishes a specific function. A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. A module is a system component that provides services to other components but would not normally be considered as a separate system. A component is an independently deliverable unit of software that encapsulates its design and implementation and offers interfaces to the out-side, by which it may be composed with other components to form a larger whole.

5. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.5 Some Definitions [Shaw&Garlan] A Software Architecture defines a system in terms of computational components and interactions amongst those components. Provides a design plan — a blueprint of the system, and that is an abstraction to help manage the complexity of the system. …The purpose of the software architecture is not only to describe the important aspects for others, but to expose them so that the architect can reason about the design. …

6. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.6 Standardization: IEEE 1471 Definitions Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Architectural description is a set of products that document the architecture. Architectural View is a representation of a particular system or part of a system from a particular perspective. Architectural viewpoint is a template that describes how to create and use an architectural view. It includes a name, stakeholders, concerns addressed by the viewpoint, and the modeling and analytic conventions.

7. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.7 Architectural Descriptions Make the architecture explicit Can be used for:  Training  Making modifications  Helping Testers  Verification of requirements  Project Management  Operating a system

8. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.8 Architectural Patterns Capture solution to recurring architectural design problems. Define a general set of element types and their interactions. Examples:  Model-View-Controller  Reflection

9. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.9 Architectural Style [Shaw&Garlan] An Architectural Style defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. Dominant architectural pattern = architectural style. Examples:  pipes and filters  layered architecture

10. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.10 Summary Lots of definitions Open for interpretation Sometimes contradictory Does not matter as long as:  Make it explicit  Assign semantics  Describe as much as possible

11. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.11 Roadmap Definitions Modeling software architecture with UML Architectural Description Languages Reflexion Models Source-code Views Conclusion and references

12. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.12 Using UML to model architectures Remember: models are not the end goal, the deployed software system is! Models are for  Design exploration: understanding existing or creating new parts of the system.  Documentation: communication between new and existing team members. Do not get stuck in ‘analysis paralysis’. Top-down approach.

13. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.13 Using UML to model architectures Key issue: managing complexity  Use case focused modeling: focus on use case or scenario.  Element focused modeling: create views from the perspective of a particular model element.  Level of detail: should be ‘right’: not too abstract, certainly not too detailed.  Controlling the number of models: difference between exploratory models and documentation models. Extract detailed documentation models from code with tools.  Use supplemental textual information: diagrams are not always enough. Complement them with textual descriptions.

14. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.14 Architectural Viewpoint Template for creating views Representation of an architecture that can be used to guide construction, manage, explore, train personnel, test, … Use it for:  Capturing design decisions.  Capturing information about the runtime environment.  Providing constraints on lower-level design.  Providing input to the structure of the development organization.  Designing the system to meet non-functional requirements.  Facilitating communication.

15. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.15 Architectural Viewpoint Structure Name Purpose: what is modeled, and what for? When applicable: in what phase of the lifecycle can it be used? Stakeholders: what is the audience for this viewpoint? Modeling conventions: what kind of diagram/technique type is used for the model? Scalability: How is the diagram used to be scalable? Relation to other views: what other views have to remain consistent?

16. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.16 List of Viewpoints Like catalogs of design patters, architectural viewpoints can be collected. Lists of viewpoints to help with specific architectural development tasks. Split in different tables:  Conceptual and analysis viewpoints: highly abstracted software descriptions.  Logical design viewpoints: describe the software design.  Environment/Physical viewpoints: focus on the environment and physical aspects of the software.

17. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.17 Conceptual and analysis viewpoints ViewpointUML diagramDescription Analysis FocusedClassDescribe system entities in response to a scenario. Analysis Interaction InteractionInteraction diagram between objects for analysis. Analysis OverallClassCombination of all classes from all focused analysis viewpoints. ContextUse CaseShow the external system actors and the system under design.

18. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.18 Logical design viewpoints ViewpointUML diagramDescription Component component communications. Component Interaction InteractionInteraction among components. Component StateStateComponent(s) State transitions. Layered Subsystem Packagelayering and subsystems design. Logical DataClassCritical data views for integration. Subsystem inter- face dependency Classsubsystem dependencies and interfaces.

19. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.19 Environmental/Physical Viewpoints Viewpoint UML diagram Description Deployment Mapping of software to hardware for distributed systems. Physical DataDeploymentPhysical view of a particular database. ProcessDeploymentShow the processes of a particular system instance. Process StateStateShow the dynamic states of a process.

20. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.20 Example Viewpoint: Context Viewpoint Purpose Model the set of actors with which the system interacts and the interfaces between the system and these entities. When applicable Throughout the project lifecycle. Primarily prepared during the first stages of design and analysis, but is updated as information about external interfaces changes. Stakeholders Software Architecture Team, Software Systems Engineering Team, Subsystem Design Leads, Developers, Testers, System Engineers, Marketing, or others who are interested in or negotiate external interfaces.

21. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.21 Example Viewpoint: Context Viewpoint Scalability The system should always be located in the middle of the view. The external actors should be surrounding the system. If the number of actors become too large, they may need to be grouped into higher-level actors. Multiple Context Views should only be used as a last resort. Relation to other views Should be consistent with other static views that show external interfaces. For example, the subsystem interface, component, process, or deployment views.

22. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.22 Example view using Context Viewpoint «System» Banking System «External» Other banking Systems ATM Teller Web Customer Other branch Loan Officer Sysadmin Backup system Phone/Pager customer

23. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.23 Example view using Context Viewpoint Model complemented with table containing actor descriptions. Table can also contain more information, such as the estimated data throughput for an actor, critical time periods, … Model + table are combined in a software architecture document.

24. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.24 Summary: Using UML Models are not the goal! Use architectural viewpoints to create architectural views relevant for your system. Do not use informal notations, but stick to the UML diagram type appropriate for that Viewpoint. Use Case tools or drawing tools to help making and maintaining the diagrams. Augment models with textual descriptions that can be more detailed.

25. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.25 Roadmap Definitions Modeling software architecture with UML Architectural Description Languages Reflexion Models Source-code Views Conclusion and references

26. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.26 Architectural Description Languages ADLs formal languages for representing and reasoning about software architecture. provide a conceptual framework and a concrete syntax for characterizing architectures. executable, or implemented in general- purpose traditional programming language.

27. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.27 Common ADL Concepts Depicted System connector port role component

28. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.28 Common ADL Concepts Component: unit of computation or data store. Typically contains interface (ports) and formal behavioral description. Connector: architectural building block used to model interactions among components. Typically contains interface (roles) and formal behavioral description. Configuration: connected graphs of components and connectors that describe architectural structure.

29. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.29 Some ADLs Darwin: focuses on supporting distributed applications. Components are single- threaded active objects. Wright: underlying model is CSP, focuses on connectivity of concurrent components. C2: component- and message-based architectural style with concurrent components linked together by connectors in accordance with a set of style rules. Rapide: focuses on developing a new technology for building large-scale, distributed multi-language systems.

30. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.30 Example: Wright Configuration SimpleSimulation Component WorldModel(map: Function) Port Provide Computation Component VehicleModel Port Environment Computation Connector UpdateValues(n : 1.. ) Role Model 1..n Glue Instances Envt : WorldModel( ) V : VehicleModel Cn : UpdateValues(2) Envt Cn V

31. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.31 Example: Wright Connector (CSP) (open request  newVal?y  update!x  close where Operate =   Operate    Operate    §   § State v where State v = [] i:1..n  Model i.open  State v [] [] i:1..n  Model i.request  Model i.newVal!v  State v [] [] i:1..n  Model i.update?x  State x [] [] i:1..n  Model i.close  State v [] § Connector UpdateValues(n : 1.. ) Role Model 1..n = Glue =  Operate)

32. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.32 Summary: ADLs Formal approach. Real languages with semantics. Domain specific, depending on their formal background. ADLs do not integrate well (different languages).

33. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.33 Roadmap Definitions Modeling software architecture with UML Architectural Description Languages Reflexion Models Source-code Views Conclusion and references

34. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.34 Quote Automated tools and build systems are an essential part of creating large systems. These systems often provide the ability to analyze and understand the details of the implementation far better than UML diagrams. — [Garland&Anthony]

35. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.35 Problem Description Given:  Source code  High-Level model of that source code Then: How to help an engineer check that model against the source code?

36. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.36 Solution: Reflexion Model Reflexion  Reflection! Semi-automated approach Repeat  Define/Update high-level model of interest  Extract a source model  Define/Update declarative mapping between high- level model and source model  System computer a software reflexion model  Interpret the software reflexion model. Until ‘happy’

37. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.37 Reflexion Approach Source Code Extraction Tool Source Model Reflexion Model Tools Mapping High-Level Model Reflexion Model Extraction Specification

38. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.38 High-Level Model Describes boxes and arrows model of system. Memory HardwareTrans KernelFaultHandler Pager FileSystem VirtAddressMaint User VMPolicy

39. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.39 Mapping Relates source model entities to high-level model entities. Example: [ file=.*pager.*mapTo=Pager ] [ file= vm_map.*mapTo=VirtAddressMaint ] [ file=vm_fault\.cmapTo=KernelFaultHandler ] [ dir=[un]fsmapTo=FileSystem ] [ dir=sparc/mem.*]mapTo=Memory ] [ file=pmap.*mapTo=HardwareTrans ] [ file=vm_pageout\.cmapTo=VMPolicy ]

40. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.40 Source Model Particular information extracted from source code Calculated with Lightweight Source extraction:  Specifications easy to write  Flexible: few constraints on source  Tolerant: source code can be incomplete, not compilable, … Lexical Approach Intrinsically Approximate For every Source Model, a new scanner is generated

41. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.41 Source Model Specification Example Writing out C calls [ ] \( [ { }+ ] \) [ { ; }+ ] \{ @ write ( functionName, “ calls “, calledFunction ) @ \( [ { }+ ] \) ( \) | ; )

42. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.42 Software Reflexion Model Indicates where the source model and high-level model differ:  Convergences  Divergences  Absences Has to be interpreted by developer.

43. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.43 Software Reflexion Model Example Memory HardwareTrans KernelFaultHandler Pager FileSystem VirtAddressMaint User VMPolicy convergence divergence absence

44. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.44 Summary: Reflexion Models Reflexion model shows where a high- level model and a source model agree. Semi-automatic process Models involved  Source model  High-level model  Reflexion model Fast

45. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.45 Roadmap Definitions Modeling software architecture with UML Architectural Description Languages Reflexion Models Source-code Views Conclusion and references

46. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.46 Source-code Views Goal: expressing architectures at a sufficiently high-level of abstraction without losing the ability to perform automated conformance checking. How?  Source-code views  Relations between views  Tool to verify views and relations against source code Source-code views and relations are expressed in a logic programming language.

47. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.47 Example: Soul’s rule-based architecture Input Query Interpreter Working Memory Knowledge Base Results Rule Selection               uses creates uses uses* uses creates

48. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.48 Example: Subarchitectures Query Interpreter Knowledge Base Input Working Memory Results Rule Selection creates uses* uses creates uses* uses               Inter- pretation Substi- tution   Query Interpreter uses

49. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.49 Source-code Views A source-code view  Is a set of source-code entities that address a same concern  One view can contain many entities  Views may crosscut dominant implementation decomposition A source-code entity  Can be any tangible language construct: method, class, variable, …  One source-code entity can reside in multiple source-code views

50. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.50 Defining Source-code views Structure  Name  Comments  Definition(s)  Default definition Definition can be defined  Extensionally = by explicit enumeration of their elements  Intentionally = by declaratively describing their elements All definitions  Should yield the same extension  This can be checked automatically

51. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.51 Source-code view example view(soulPredicates, ). viewComment(soulPredicates, ['This intentional view contains ALL classes that implement SOUL predicates (i.e., Prolog-like predicates that may use Smalltalk code due to language symbiosis).']). default(soulPredicates,byCategory). intention(soulPredicates,byCategory,?class) if category(?category), name(?category,?name), startsWith(?name,['Soul-Logic']), classInCategory(?class,?category). include(soulPredicates,byCategory,[Soul.TestClassifications]). intention(soulPredicates,byHierarchy,?class) if …

52. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.52 Source-code view maps to source code classifiedAs(method(’interpretation’), Method) :- classifiedAs(class('soul'), Class), interpretingProtocolName(ProtocolName), protocolName(Protocol, ProtocolName), methodInProtocol(Class, Protocol, Method). classifiedAs(method(’interpretation’), Method) :- classifiedAs(class('soul'), Class), interpretingProtocolName(ProtocolName), protocolName(Protocol, ProtocolName), methodInProtocol(Class, Protocol, Method). Implementation qsfdxgf ArchitectureMapping Input Query Interpreter Working Memory Knowledge Base Result s Rule Selection creates uses* uses creates uses* uses              

53. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.53 Software Views Relationships Binary relations between views Two parts:  predicate: the kind of relation that holds between the elements, for example ‘uses’, ‘creates’, ‘accesses’, …  Quantifier: how many elements should satisfy the relation Are mapped to lower-level implementation relationships. Can be simple (e.g. ‘uses’) or complex (e.g. ‘creates’ or ‘usesTrans’). Can be used in multiple ways (verificative, generative)

54. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.54 Relationship Example forall(filteredIsClassifiedAs(ruleInterpreter, methodFilter,X1), exists(filteredIsClassifiedAs(clauseSelector, methodFilter,X2), asks_M_M(X1,X2))) ruleInterpreterclauseSelection forallexists asks_M_M Rule Interpreter Clause Selector r Asks 1 methodFilter 12

55. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.55 Differences with Reflexion Models More complex relationships More complex mapping between architectural components and the implementation Abstraction facilities But — slower:  logic programming slower than regular expressions  Full parser versus lexical approach

56. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.56 Summary: Software Views and Soul Express software architectures at high level of abstraction Supports conformance check between software architecture and source code Uses logic programming language to obtain  Expressiveness  Abstraction facilities

57. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.57 Roadmap Definitions Modeling software architecture with UML Architectural Description Languages Reflexion Models Source-code Views Conclusion and references

58. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.58 Conclusion Do not make meaningless boxes-and- arrows diagrams: add semantics to them. Automated tools and build systems are an essential part of creating large systems. Tools and techniques exist - invest time in using them  UML-based solutions  Architectural description languages  Reverse engineering tools (software reflexion models, views)

59. © S. Demeyer, S. Ducasse, O. Nierstrasz Architecture.59 References & further reading [Shaw&Garlan] M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, 1996. [Garland&Anthony] J. Garland, R. Anthony, Large-Scale Software Architecture - A practical guide using UML, John Wiley, 2003. [Murp95a] G. Murphy, D. Notkin, K. Sullivan, Software Reflexion Models: Bridging the gap between Source and High-Level Models, Proceedings of SIGSOFT'95, 1995. [Mens99a] K. Mens, R. Wuyts, T. D'Hondt, Declaratively Codifying Software Architectures using Virtual Software Classifications, TOOLS-Europe 99, 1999.