Sa 006 modifiability


Published on

Software architecture & modifiability: it is about the cost

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Platform: OS, DBMS, Middleware change Environment: Keyboard control to touch screen, sensor input Data representation: binary to ASCII , proprietary to standard (XML), ….
  • Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data. Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
  • Sa 006 modifiability

    1. 1. Software ArchitectureQuality Attributes & Tactics (3)Modifiability Vakgroep Informatietechnologie – IBCN
    2. 2. Modifiability Modifiability is about the cost of changes. Operating Profit (EBIT) = Revenues - ExpensesVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
    3. 3. Modifiability Definition The modifiability of a software system is theease with which it can be modified to changesin the environment, requirements or functional specification. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
    4. 4. Modifiability Aspects What can change ?  Functions, Platform, Environment.  Qualities (performance, reliability,…)  Capacity (number of users,..) When is the change required ?  Development time, build time, configuration, runtime Who will implement the change ?  Software engineers ,users , administrators ? What is the cost of change?  Cost of introducing the mechanism in the architecture  Cost of making the modification using that mechanismVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
    5. 5. Business Concerns (1/2) Extensibility  Adding and enhancing functionality  Effort for the next release Simplification  Complex components are difficult to change  Simplifying functionality for maintainability Restructuring  Modularizing  Creating reusable components  Smaller components are easier to modifyVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
    6. 6. Business Concerns (2/2) Time to deploy  Time for introducing a new feature  Competitiveness Functional scalability  Ability to scale up or down in terms of users, transactions … Functional flexibility  Make existing functionality available to new users, new locations & unforeseen situations.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
    7. 7. Modifiability Generic Scenario (1/3) Source The developer, system administrator or end user, can request or introduce a change to the system. Stimulus A directive to Add/delete/modify functionality; Modify quality attributes Modify platform, technology Operate in a new environment, new users Scale up and scale out Artifact Code, data, interfaces, components, resources, configurations, … Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
    8. 8. Modifiability Generic Scenario (2/3) EnvironmentVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
    9. 9. Modifiability Generic Scenario (3/3) Response Make, test and deploy the modification Response measures  Number of affected artifacts.  Size of the change.  Effort & time  Cost (direct or opportunity cost)  Number of other functions or quality attributes affected by the change  New defects introducesVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
    10. 10. Modifiabililty Generic QAS Artifact Code, Data, Interfaces Components, Resources, Configs ..Source Stimulus Environment Response MeasureDeveloper Modify: - Design - Change, # of artifactsSys - Functions - Build - Test Effortadmin - Deploy - Deploy Time - QualitiesUser - Runtime - Platform Cost - Technology Impact - Scale/Scope New defects p. 10
    11. 11. Example Modifiability Scenario A developer wants to change the UI code (e.g. change an input field to a pick list) at design time; the modification is made without side effects in 3 hours.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11
    12. 12. Example 2: Saas ApplicationsA SaaS application is scalable, multi-tenant, andconfigurable.Scalable application is able to handle and to support therequired quality of service as the system load increases.In a multi-tenancy environment, multiple customers share thesame application, running on the same operating system, on thesame hardware, with the same data storage mechanism. Thedistinction between the customers is achieved during applicationdesign, so that customers do not share or see each others data.Configurable applications allow a certain level of customizationvia metadata services, which are responsible for managingapplication configuration for individual tenants. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
    13. 13. Saas Maturity Model  Lvl I: Ad Hoc/Custom  Each customer has its own customized version  Lvl II: Configurable  Flexibility through configurable metadata: many customers can use separate instances of the same application code.  Lvl III: Configurable, Multi-Tenant-Efficient  Hosting a single instance, which serves all customers. Requires appropriate authorization and security policies.  Lvl IV: Scalable, Configurable, Multi-Tenant-Figure : Four-level SaaS maturity model Efficient Scalability is added through a multitier architecture supporting a load-balanced farm of identical application instances, running on a variable number of servers. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
    14. 14. Understanding ModifiabilityThe modifiability of a system is determined by: Coupling: Modules in systems have different responsibilities. Ifthe responsibilities of modules overlap, a single change requestmay impact multiple modules. The probability that a modification toone module will propagate to another is called coupling. Coupling isan “inter module” characteristic and is the enemy of modifiability:low coupling is good. Cohesion: Cohesion measures how much the responsibilities of amodule are related. The cohesion of a module is the probability thata change request to one responsibility will impact another one.Cohesion is an intramodule characteristic and high cohesion isgood. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14
    15. 15. Modifiability Tactics Tactics to Control Changes made, Change Request Modifiability Tested and Deployed Arrives on Time, within Budget  Reduce Module Size  Increase Cohesion  Reduce Coupling  Defer Binding Time  Commit as late as possibleVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15
    16. 16. Increase Cohesion (1/2) Maintain Semantic Coherence  The responsibilities in a module should serve the same purpose.  Example: Responsibilities that deal with hardware should be allocated to the hardware module and not to the application level. A hardware responsibility typically does not have any semantic coherence with the application responsibilities. Abstract Common Services  In case of similar services they should be implemented only once in a slightly more general form.  Refactoring is an example of this tactic. Refactoring rule involves examining existing responsibilities and factoring out the similar elements. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
    17. 17. Increase Cohesion (2/2) How to test for semantic cohesion?  Anticipate the set of envisioned changes:  Does one specific change impacts a lot of modules ?  Do fundamentally different changes affect the same module ?  If some responsibilities are not affected by a change they should be moved to another module.  If a change impacts multiple modules, responsibilities need to be moved or allocated to new modules. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
    18. 18. Reduce Coupling (1/3) Hide information - Encapsulation  Encapsulation introduces an explicit interface to a module.  Encapsulation acts by enforcing information hiding behind an interface. Maintain existing interfaces – Wrappers  A wrapper is a form of encapsulation. It is an interface for a module that transforms the data or control information for the module.  The wrapper transformations reduce the total cost of a change by reducing the costs associated with propagation Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
    19. 19. Reduce Coupling (2/3) Reduce Communication Paths Use Intermediaries - Break dependencies.  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 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
    20. 20. Reduce Coupling (3/3) 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 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
    21. 21. Defer Binding Time (1/2) Implementation/Design time:  Aspect-Oriented Programming.  Polymorphism.  Parameterize Modules. Build time  Component Replacement.(build scripts, makefiles) Deployment & Initialization time  Configuration-Time Binding.  Resource Files. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21
    22. 22. Defer Binding Time (2/2) Runtime  Use Runtime Registration.  Dynamic Lookup (for services)  Interpret Parameters.  Start-Up Time Binding.  Runtime Binding.  Name Servers.  Plug-Ins.  Publisher-Subscriber Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
    23. 23. Modifiability Tactics: summary Modifiability Reduce Defer Size Binding Time Split Increase Reduce Changes made,Change modules Cohesion CouplingRequest Tested and Deployed Increase EncapsulationArrives Semantic Wrap on Time, Coherence Restrict within Budget Abstract communication paths Common Services Use an intermediary Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
    24. 24. Architectural Patterns & Tactics The Model-View-Controller architectural pattern (MVC) divides an interactive application into three components.  The Model contains the core functionality, data and state.  Views is the user interface component. It produces a representation of the model and can handle input.  Controllers manage the interaction between the model and the view ensures consistency between. Used in :  Java Swing, Adobe Flex, Nokia Qt, Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
    25. 25. The MVC Pattern
    26. 26. MVC Tactics analyzed:The Model-View-Controller pattern implements thefollowing tactics:Maintain Semantic Coherence. According to the definition, themodel component contains the functional core of the application,requiring all the necessary responsibilities for those concepts to belocated within the model.Encapsulation. The model component encapsulates thefunctional core data and functionality.Use an Intermediary. The controller acts as an intermediarybetween the view and the model.Use Runtime Binding. Views can be opened and closeddynamically, and different views can be bound to the data atdifferent times during execution.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
    27. 27. The Layers Pattern The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction The pattern consists of a number of layers. Layers are partially ordered with respect to the uses relationship. A layer may only use lower level layers in the partial order.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27
    28. 28. Layers PatternVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
    29. 29. Layers are used when : Late source code changes should not ripple through the system… Interfaces should be stable, and may even be prescribed by a standards body. Parts of the system should be exchangeable… It may be necessary to build other systems at a later date with the same low-level issues…reuse. Similar responsibilities should be grouped… The system will be built by a team of programmers, and work has to be subdivided along clear boundaries…Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29
    30. 30. Layers Tactics Analyzed (1/2) The Layers pattern can be understood in terms of the following tactics:  Maintain Semantic Coherence. The goal of ensuring that a layer’s responsibilities all work together without excessive reliance on other layers is achieved by choosing responsibilities that have some sort of semantic coherence.  Raise the Abstraction Level. Layers represent an abstract ladder of services. Modules in lower layers may have an abstract (or more general) representation in the upper layers.  Example, there may be concrete device drivers in the lower layer and a more general notion of a virtual device driver in an upper layer.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30
    31. 31. Layers Tactics Analyzed (2/2) Abstract Common Services. Typically the responsibilities of a layer are grouped together into services. Abstract Common Services would place a single copy of the service in a distinct module and have it accessed by the consumers of the replicated service. In the Layers pattern, the common services are abstracted and located in a layer below the consumers of the services. Use Encapsulation. There are two design considerations of the Layers pattern with respect to interfaces: 1. Each layer may have its own interface and 2. Particular layers may act as an interface (e.g., API, façade) for another layer. The first consideration is an instance of the Use Encapsulation tactic; the second is an instance of the Use an Intermediary tactic.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 31
    32. 32. Example 1: ModifiabilityProject: BikePRINT Artifact Code Source Stimulus Environment Response ResponseDeveloper Create Design time Modification measure different is made Integration of visualization without side visualization for analysis effects with system is done within 4 hours Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32
    33. 33. Example 2: InteroperabilityProject: T.U.R.C. Artifact Code Response Source Stimulus Environment Response measureDeveloper Add new Design time Protocol is Only the communicati added communication on protocol without module is affecting adjusted other Integration is functionality possible within 3 hours Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33