1. Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (4) Modifiability

2. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2 Modifiability What can change ? Functions, Platform, Environment. Data, data representation System Qualities (performance, throughput,…) When is the change required ? Development time, build time,..runtime Who will implement the change ? Software engineers ? Users ? Administrators ? Modifiability is about the cost of changes.

3. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3 Modifiability Scenario “A developer wants to change the UI code at design time; the modification is made without side effects in 3 hours.”

4. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4 Modifiability Tactics Tactics to Control Modifiability Change Request Arrives Changes made, Tested and Deployed on Time, within Budget Localize Modifications Assign responsibilities to modules such that changes are limited in scope. Prevent Ripple Effect A ripple effect from a modification is the necessity of making changes to modules not directly affected by it Defer Binding Time Commit as late as possible

5. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5 Localize Modifications (1/2) General rule : The fewer components to change  less cost to change Goal: Assign functionality to modules so that anticipated changes will be limited in scope Maintain semantic coherence: Responsibilities work together without excessive reliance on other modules  Abstract common services : e.g. timer services, security, encryption, …etc. Anticipate expected changes: Considering the set of envisioned changes, provides a guide to the assignment of responsibilities Do fundamentally different changes affect the same module ?

6. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6 Localize Modifications (2/2) Generalize the module Making the module more general allows it to function for broader range of inputs Think of the input as a language for the module Limit possible options Modifications may have long reaching effects (especially within product lines) Reducing choices can reduce the impact  E.g., changing the OS has substantial ramifications

7. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7 Ripple Effects : Module dependencies Syntax : Data: For B to compile/execute correctly the type of the data produced by A and used by B must be consistent with B’s assumptions Service: For B to compile/execute correctly the signature of services provided by A and invoked by B must be consistent with B’s assumptions Semantics : Data: For B to execute correctly the meaning of the data produced by A and consumed by B must be consistent with B’s assumptions Service: For B to execute correctly the semantics of services provided by A and used by B must be consistent with B’s assumptions

8. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8 Prevent Ripple Effects (2/3) Sequence: Data: For B to execute correctly it must receive data produced by A in a fixed sequence. E.g., protocol headers before body Control: For B to execute correctly A must have executed within certain (time) constraints Identity of an interface of A: A may have multiple interfaces each of which has a definition that must remain consistent with B’s assumptions Location of A at runtime: If A is allowed to migrate B must know where it is.

9. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9 Prevent Ripple Effects (3/3) Quality of service/ data provided by A Data accuracy Existence of A: Routeplanner – existence of GPS module ?  Startup scenario ! Resource behavior of A e.g., A uses the same memory as B Modifiability Tactics cannot avoid ripple effect but limit the effect of changes.

10. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10 Modifiability Tactics Hide information The oldest of our tactics Uses anticipated changes as basis for decomposition Maintain existing interfaces Patterns for implementing this tactic  Adding interfaces  Adding an adapter  Providing a stub (just in case …) Restrict communication paths

11. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11 Use intermediaries (1/2) Examples of Intermediaries Data(syntax):  data repositories (DB and blackboards) act as intermediary between producer and consumer of data Publish/subscribe services Service (syntax)  Patterns: façade, bridge, mediator, proxy, factory all provide intermediaries to convert from one syntax of a service to another

12. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12 Use intermediaries (2/2) More intermediaries... Identity of interface of A:  A broker can be used to find the interface to perform a service, Location of A (runtime)  register with name-server Resource behavior of A or resource controlled by A  Resource manager is intermediary Existence of A:  the factory pattern can construct instances if needed

13. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13 Defer Binding Time Modifiability scenarios include: Time to deploy Allowing non-developers to make changes What is binding time? Static vs dynamic: e.g. name binding in C++ & Java build time, installation, configuration or runtime. Deferring Binding Time supports both of these scenarios

14. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14 Defer Binding Time Tactics Runtime registration supports plug-and-play at expense of registration overhead Configuration files allow set-up parameters to be initialized Polymorphism – late binding of method calls Component replacement allows load time binding Protocol adherence allows runtime binding of independent processes

15. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15 Modifiability Tactics: summary Change Request Arrives Changes made, Tested and Deployed on Time, within Budget Modifiability Localize Changes Prevent Ripple Effect Defer Binding Time Hide Information Maintain existing interfaces Restrict communication paths Use an intermediary Semantic Coherence Anticipate changes Generalize Modules Limit Options Abstract Common Services Runtime Registration Configuration files Polymorphism Component Replacement Adherence to protocols