6 Architectural Extraction S Demeyer S Ducasse O

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

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

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 3

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 4

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. • … © S. Demeyer, S. Ducasse, O. Nierstrasz 5

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 6 conventions.

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

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

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 9

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 10

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

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 12

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 13

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 14

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? © S. Demeyer, S. Ducasse, O. Nierstrasz 15

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 16

Conceptual and analysis viewpoints Viewpoint UML diagram Description Analysis Focused Class Describe system entities in response to a scenario. Analysis Interaction diagram between objects for analysis. Analysis Overall Class Combination of all classes from all focused analysis viewpoints. Context Use Case Show the external system actors and the system under design. © S. Demeyer, S. Ducasse, O. Nierstrasz 17

Logical design viewpoints Viewpoint UML diagram Description Component component communications. Component Interaction among components. Component State Component(s) State transitions. Layered Subsystem Package layering and subsystems design. Logical Data Class Critical data views for integration. Subsystem interface dependency Class subsystem dependencies and interfaces. © S. Demeyer, S. Ducasse, O. Nierstrasz 18

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

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

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 21

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

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 23

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 24

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

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 generalpurpose traditional programming language. © S. Demeyer, S. Ducasse, O. Nierstrasz 26

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

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. 28 © S. Demeyer, S. Ducasse, O. Nierstrasz

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. • C 2: 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. © S. Demeyer, S. Ducasse, O. Nierstrasz 29

Example: Wright Configuration Simple. Simulation Component World. Model(map: Function) Port Provide <provide protocol> Computation <provide world model> Component Vehicle. Model Port Environment <value protocol> Computation <Vehicle behavior> Connector Update. Values(n : 1. . ) Role Model 1. . n <1 model’s protocol> Glue <data from one model to another> Instances Envt : World. Model(<map>) V : Vehicle. Model Cn : Update. Values(2) © S. Demeyer, S. Ducasse, O. Nierstrasz Envt V Cn 30

Example: Wright Connector (CSP) Connector Update. Values(n : 1. . ) (open Operate) § Role Model 1. . n = new. Val? y Operate where Operate = request update!x Operate close § Glue = Statev where Statev = [] i: 1. . n Modeli. open Statev [] [] i: 1. . n Modeli. request Modeli. new. Val!v Statev [] [] i: 1. . n Modeli. update? x Statex [] [] i: 1. . n Modeli. close Statev [] § © S. Demeyer, S. Ducasse, O. Nierstrasz 31

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

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

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] © S. Demeyer, S. Ducasse, O. Nierstrasz 34

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? © S. Demeyer, S. Ducasse, O. Nierstrasz 35

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 highlevel model and source model +System computer a software reflexion model +Interpret the software reflexion model. Until ‘happy’ © S. Demeyer, S. Ducasse, O. Nierstrasz 36

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

High-Level Model Describes boxes and arrows model of system. Memory Hardware. Trans Virt. Address. Maint User VMPolicy © S. Demeyer, S. Ducasse, O. Nierstrasz Kernel. Fault. Handler Pager File. System 38

Mapping • Relates source model entities to high-level model entities. • Example: [ file=. *pager. * map. To=Pager ] [ file= vm_map. * map. To=Virt. Address. Maint ] [ file=vm_fault. c map. To=Kernel. Fault. Handler ] [ dir=[un]fs map. To=File. System ] [ dir=sparc/mem. *] map. To=Memory ] [ file=pmap. * map. To=Hardware. Trans ] [ file=vm_pageout. cmap. To=VMPolicy ] © S. Demeyer, S. Ducasse, O. Nierstrasz 39

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 40

Source Model Specification Example • Writing out C calls [ <type> ] <function. Name> ( [ { <formal. Arg> }+ ] ) [ { <type> <arg. Decl> ; }+ ] { <called. Function> @ write ( function. Name, “ calls “, called. Function ) @ ( [ { <parm> }+ ] ) ( ) | ; ) © S. Demeyer, S. Ducasse, O. Nierstrasz 41

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

Software Reflexion Model Example convergence Memory divergence absence Hardware. Trans Virt. Address. Maint User VMPolicy © S. Demeyer, S. Ducasse, O. Nierstrasz Kernel. Fault. Handler Pager File. System 43

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

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

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. © S. Demeyer, S. Ducasse, O. Nierstrasz 46

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

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

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 49

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 50

Source-code view example view(soul. Predicates, <by. Category, by. Hierarchy>). view. Comment(soul. Predicates, ['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(soul. Predicates, by. Category). intention(soul. Predicates, by. Category, ? class) if category(? category), name(? category, ? name), starts. With(? name, ['Soul-Logic']), class. In. Category(? class, ? category). include(soul. Predicates, by. Category, [Soul. Test. Classifications]). intention(soul. Predicates, by. Hierarchy, ? class) if … © S. Demeyer, S. Ducasse, O. Nierstrasz 51

Source-code view maps to source code Implementation Rule Selection Mapping qsfdxgf uses* uses qsfdxgf creates classified. As(method(’interpretation’), Method) : classified. As(class('soul'), Class), interpreting. Protocol. Name(Protocol. Name), protocol. Name(Protocol, Protocol. Name), method. In. Protocol(Class, Protocol, Method). qsfdxgf Result s uses Query Interpreter uses Working Memory Input qsfdxgf creates Knowledge Base uses* Architecture qsfdxgf © S. Demeyer, S. Ducasse, O. Nierstrasz qsfdxgf 52

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 ‘uses. Trans’). • Can be used in multiple ways (verificative, generative) © S. Demeyer, S. Ducasse, O. Nierstrasz 53

Relationship Example Rule Interpreter forall r 1 Asks 1 2 method. Filter rule. Interpreter Clause Selector exists method. Filter asks_M_M clause. Selection forall(filtered. Is. Classified. As(rule. Interpreter, method. Filter, X 1), exists(filtered. Is. Classified. As(clause. Selector, method. Filter, X 2), asks_M_M(X 1, X 2))) © S. Demeyer, S. Ducasse, O. Nierstrasz 54

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 © S. Demeyer, S. Ducasse, O. Nierstrasz 55

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 © S. Demeyer, S. Ducasse, O. Nierstrasz facilities 56

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

Conclusion • Do not make meaningless boxes-andarrows 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) © S. Demeyer, S. Ducasse, O. Nierstrasz 58

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. • [Murp 95 a] G. Murphy, D. Notkin, K. Sullivan, Software Reflexion Models: Bridging the gap between Source and High-Level Models, Proceedings of SIGSOFT'95, 1995. • [Mens 99 a] K. Mens, R. Wuyts, T. D'Hondt, Declaratively Codifying Software Architectures using Virtual Software Classifications, TOOLS-Europe 99, 1999. © S. Demeyer, S. Ducasse, O. Nierstrasz 59