Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Softwarearchitecture in practice unit1 2


Published on

quality and how it is achieved with the contents of the architects tool box

Published in: Software
  • covered all topics in the ppt
    Are you sure you want to  Yes  No
    Your message goes here

Softwarearchitecture in practice unit1 2

  1. 1. Unit 1-2
  2. 2. 1. Understanding quality attributes 2.Achieving qualities 3. Architectural patterns and styles 4.Designing the Architecture 5.Documenting software Architecture 6.Reconstructing software Architecture
  3. 3. 1.1 Functionality and Architecture 1.2 Architecture and Quality Attributes 1.3 System quality Attributes 1.4 Quality Attribute Scenarios in practice 1.5 Business Qualities 1.6 Architecture Qualities
  4. 4. Quality “a characteristic or attribute of something” Attribute of an item , quality refers to measurable characteristics
  5. 5.  Functionality and quality are orthogonal  Functionality-it is the ability of the system to do the work for which it was intended.  It can be achieved through the use of any of a number of possible structures.  Software architecture constraints its allocation to structure when other quality attributes are important.
  6. 6. The message of this section is twofold: 1.Architecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural level. 2.Architecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the details.
  7. 7. Quality attributes are examined in three classes: 1.Qualities of the system. we will focus on availability, modifiability, performance, security, testability and usability. 2.Business qualities(such as time to market) that are affected by the architecture. 3.Qualities such as conceptual integrity, that are about the architecture itself although they indirectly affect other qualities, such as modifiability.
  8. 8. A solution to the problems of the system quality attributes is to use Quality attribute scenarios - as a means of characterizing quality attributes. -a quality attribute is a quality-attribute- specific requirement. -it consists of six parts.
  9. 9. 1)Source of stimulus: this is some entity(a human, a computer system, or any other actuator) that generated the stimulus. 2)Stimulus: the Stimulus is a condition that needs to be considered when it arrives at a system. 3)Environment: the Stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true.
  10. 10. 4) Artifact: some artifact is stimulated. This may be the whole system or some pieces of it. 5)Response: the response is the activity undertaken after the arrival of the stimulus. 6)Response measure: when the response occurs, it should be measurable in some fashion so that the requirement can be tested.
  11. 11. Availability scenario  An example availability scenario is derived from the general scenario of fig 4.2 by instantiating each of the parts, is “an unanticipated external message is received by a process during normal operation. The process informs the operator of the receipt of the message and continues to operate with no downtime.” fig 4.3 shows the pieces of the derived scenario
  12. 12. Modifiability Scenario a sample modifiability scenario is “ A developer wishes to change the user interface to make a screen’s background color blue. This change will be made to the code at design time. It will take less than 3 hrs to make and test the change and no side effects changes will occur in the behavior.” fig 4.4 illustrates this sample scenario(omitting a few minor details for brevity)
  13. 13. Quality Attribute Scenario Generation -To help the architect generate meaningful quality attribute requirements for a system. -in theory this is done in a project’s requirement elicitation, but in practice this is is seldom rigorously enforced.
  14. 14.  To make the general scenarios useful for a particular system, you must make them system specific.  The six most common and important system quality attributes, with the twin goals of identifying the concepts used by the attribute community and providing a way to generate general scenarios for that attribute.
  15. 15.  Availability- is concerned with system failure and its associated consequences.  The availability of a system is the probability that it will be operational when it is needed. This is typically defined as
  16. 16. Modifiability- is about the cost of change. It brings up two concerns. 1. what can change(the artifact)? 2.when is the change made and who makes it (the environment)?
  17. 17.  Performance- is about timing. Events (interrupts, messages, requests from users, or the passage of to time) occur, and the system must respond to them.  A performance scenario begins with a request for some service arriving at the system. Satisfying the request requires resources to be consumed. While this is happening the system may be simultaneously servicing other requests.
  18. 18.  Security- is a measure of the system’s ability to resist unauthorized usage while still providing its services to legitimate users.  Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance and auditing.  Each of these security categories gives rise to a collection of general scenarios.
  19. 19.  Testability – software testability refers to the ease with which software can be made to demonstrate its faults through(typically execution-based) testing.  In particular testability refers to the probability, assuming that the software has at least one fault, that it will fail on its next test execution.
  20. 20.  Usability – is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. it can be broken into following areas:  Learning system features- if the user is unfamiliar with a particular system or a particular aspect of it, what can the system do to make the task of learning easier?  Using a system efficiently- what can the system do to make the user more efficient in its operation.
  21. 21.  Minimizing the impact of errors- what can the system do so that a user error has minimal impact?  Adapting the system to user needs- how can the user(or the system itself) adapt to make the user’s task easier?  Increasing confidence and satisfaction-what does the system do to give the user confidence that the correct action is being taken?
  22. 22. Communicating concepts using general scenarios  One of the uses of general scenarios is to enable stakeholders to communicate.  Table 4.7 gives the stimuli possible for each of the attributes and shows a no.of different concepts.  For example, it may occur with an exchange of several messages b/w a client and server each of which is an atomic event from a performance perspective.
  23. 23.  A no.of other attributes can be found in the attribute taxonomies in the research literature.  For example, scalability is often an important attribute, it is captured by modifying system capacity- the no.of users supported.  Portability is captured as a platform modification.  Interoperability- is important to your organization, it is reasonable to create your own general scenario for it.
  24. 24.  In addition to the qualities that apply directly to a system, a number of business quality goals frequently shape a system’s architecture. These goals center on cost, schedule, market, and marketing considerations.  Time to market: if there is competitive pressure or a short window opportunity for a system or product, development time becomes important.
  25. 25.  Cost and benefit: the development effort will naturally have a budget that must not be exceeded.  Projected lifetime of the system: if the system is intended to have a long lifetime, modifiability, scalability and portability become important.  Targeted market: for general-purpose(mass- market) software, the platforms on which a system runs as well as its features set will determine the size of the potential market. Thus portability and functionality are key to market share.
  26. 26.  Rollout schedule: if a product is to be introduced as base functionality with many features released later, the flexibility and customizability of the architecture are important.  Integration with legacy systems: if the new system has to integrate with existing systems, care must be taken to define appropriate integration mechanisms.
  27. 27.  In addition to qualities of the system and qualities related to the business environment in which the system is being developed, there are also qualities directly related to the architecture itself that are important to achieve.  Conceptual integrity is the underlying theme or vision that unifies the design of the system at all levels.
  28. 28.  Correctness and completeness are essential for the architecture to allow for all the system’s requirements and runtime resource constraints to ne met.  Buildability allows the system to be completed by the available team in a timely manner and to be open to certain changes as development progress.
  29. 29. 2.1 Introducing Tactics 2.2 Availability Tactics 2.3 Modifiability Tactics 2.4 Performance Tactics 2.5 Security Tactics 2.6 Testability Tactics 2.7 Usability Tactics 2.8 Relationship of Tactics to Architectural Patterns
  30. 30.  A Tactic is a design decision that influences the control of a quality attribute response.  We call a collection of tactics an architectural strategy  Each tactic is a design option for the architect  Usually achieving a high availability through redundancy implies a concomitant need for synchronization.  We see two immediate ramifications of this example.
  31. 31. 1. Tactics can refine other tactics 2. pattern package tactics Fig5.1 the tactics are those that architects have been using for years, and we isolate and describe them. we are not inventing tactics here, just capturing what architects do in practice.
  32. 32.  Recovery or repair is an important aspect of availability.  In some cases the monitoring or recovery is automatic and in others it is manual.  We first consider fault detection. We then consider fault recovery and finally fault prevention.  The tactics we discuss in this section will keep faults from becoming failures or at least bound the effects of the fault and make repair possible. This will shown in the foll fig.
  33. 33.  Three widely used tactics for recognizing faults are ping/echo, heartbeat and exceptions.  Ping/echo-one component issues a ping and expects to receive back an echo within a predefined time, from the component under scrutiny.  Heartbeat(dead man timer)- in this case one component emits a heartbeat message periodically and another component listens for it.  Exceptions- one method for recognizing faults is to encounter an exception which is raised when one of the fault classes recognized.
  34. 34.  Fault recovery consists of preparing for recovery and making the system repair. Some preparation and repair tactics follow.  Voting  Active redundancy(hot restrat)  Passive redundancy(warm restrat/dual redundancy/triple redundancy)  Spare  Shadow operation  State resynchronization  Checkpoint/rollback
  35. 35.  The following are some fault prevention tactics  Removal from service- this tactic removes a component of the system from operation undergo some activities to prevent anticipated failures.  Transactions- a transaction is the bundling of several sequential steps such that the entire bundle can be undone at once.  Process monitor- once a fault in a process has been detected, a monitoring process can delete the nonperforming process and create a new instance of it, initialized to some appropriate state as in the spare tactic.
  36. 36.  Tactics to control modifiability have as their goal controlling the time and cost to implement, test and deploy changes.fig 5.4 shows this relationship.
  37. 37.  We organize the tactics for modifiability in sets according to their goals.  One set has as its goal reducing the no.of modules that are directly affected by a change. We call this set “localize modifications.”  a second set has as its goal limiting modifications to the localized modules. We use this set of tactics to “prevent the ripple effect.”  A third set of tactics has its goal controlling deployment time and cost. We call this set “defer binding time.”
  38. 38.  Performance tactics control the time within the which a response is generated. This is shown in fig 5.6
  39. 39.  Tactics for achieving security can be divided into those concerned with resisting attacks, those concerned with detecting attacks, and those concerned with recovering from attacks. All three categories are important.  Fig 5.8 shows the goals of a security tactics
  40. 40.  The goal of tactics for testability is to allow for easier testing when an increment of s/w development is completed.  Fig 5.10 displays the use of tactics for testability.
  41. 41.  Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of support the system provides to the users.  Two types of tactics support usability, each intended for two categories of “users”.  The first category, “runtime” , includes those that support the user during system execution.  The second category is based on the iterative nature of user interface developer at design time.
  42. 42. usability Separate user interface Support user initiative Support system initiative Cancel Undo aggregate User model System model Task model User request User Given appropriate feedback and assistance Fig 5.13 summary of runtime usability tactics
  43. 43.  An architect usually chooses a pattern or a collection of patterns designed to realize one or more tactics.  The pattern consists of six elements.  A proxy which provides an interface that allows clients to invoke publicly accessible methods on an active object  A method request which defines an interface for executing the methods of an active object.
  44. 44.  An activation list which maintains a buffer of pending method requests  A scheduler which decides what method requests to execute next  A servant which defines the behavior and state modeled as an active object  A future which allows the client to obtain the result of the method invocation
  45. 45.  The other tactics this pattern involves  Information hiding(modifiability)- each element chooses the responsibilities it will achieve and hides their achievement behind an interface  Intermediary(modifiability)- the proxy acts as an intermediary that will buffer changes to the method invocation  Binding time(modifiability)- the active object pattern assumes the requests for the object arrive at the object at runtime.  Scheduling policy(performance)- the scheduler implements some scheduling policy
  46. 46.  An architectural pattern in s/w, also known as an architectural style, is analogous to an architectural style in buildings, such as Gothic or Greek Revival or Queen Anne.  It consists of a few key features and rules for combining them so that architectural integrity is preserved.
  47. 47. An architectural pattern is determined by:  A set of element types(such as a data repository or a component that computes a mathematical function).  A topological layout of the elements indicating their interrelationships.  A set of semantic constraints.  A set of interaction mechanisms.
  48. 48.  Mary Shaw and David Garlan’s influential work attempted to catalog a set of architectural patterns that they called architectural Styles or idioms.  This has been evolved by the SEC into what is now more commonly known as architectural patterns, analogous to design patterns and code patterns.
  49. 49. 4.1 Architecture in the life cycle 4.2 Designing the architecture 4.3 Forming the team structure 4.4 Creating a skeletal system
  50. 50.  Any organization that embraces architecture as a foundation for its software development processes needs to understand its place in the life cycle.  The intent of this model is to get user and customer feedback and iterate through several releases before the final release.
  51. 51. Where can I begin designing?  the life-cycle model shows the design of the architecture as iterating with preliminary requirement analysis.  An architecture is “shaped” by some collection of functionality, quality and business requirements. We call these shaping req’s architectural drivers.  Once architectural drivers are known, the architectural design can begin.
  52. 52.  A method for designing an architecture to satisfy both quality req’s and functional req’s. we call this method Attribute Driven Design(ADD)  ADD is an approach to defining a s/w architecture that bases the decomposition process on the quality attributes the s/w has to fulfill.  Sample Input: the input to ADD is a set of req’s.
  53. 53.  Beginning ADD- the process can begin when the driver req’s are known with some assurance  ADD steps 1.Choose the module to decompose 2.A) choose the architectural drivers B)choose an architectural pattern c)Instantiate modules and allocate functionality using multiple views
  54. 54. 2. D)define interfaces of the child modules E)verify and refine use cases and quality scenarios as constraints for the child modules 3. Repeat the steps above for every module that needs further decomposition.
  55. 55.  Once an architecture for the system under construction has been agreed on , teams are allocated to work on the major modules and a work breakdown structure is created that reflects those teams.  Each team then creates its own internal work practices.  The teams within an organization work on modules.
  56. 56.  Once an architecture is sufficiently designed and teams are in place to begin building to it, a skeletal system can be constructed.  The idea at this stage is to provide an underlying capability to implement a system’s functionality in an order advantageous to the project.  Classical S.E practice recommends “stubbing out” sections of code so that portions of the systems can be added separately and tested immediately
  57. 57. 5.1 Uses of Architectural Documentation 5.2 Views 5.3 Choosing the relevant views 5.4 Documenting a View 5.5 Documentation across Views 5.6 Unified Modeling Language
  58. 58.  The architecture for a system depends on the req’s levied on it, so too does the documentation for an architecture depend on the it- i.e., how we expect it will be used.  Architecture documentation is both perspective and descriptive.  All of this tells us that different stakeholders for the documentation have different needs.
  59. 59.  The concept a view, which you can think of as capturing a structure, provides us with the basic principle of documenting software architecture.  Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more than one view.  This principle is useful because it breaks the problem of architecture documentation into more tractable parts.
  60. 60.  Different views support different goals and uses.  Different views will highlight different system elements and/or relationships.  Table shows a representative population of stakeholders and the kind if views they tend to find useful.  Table divided views into these three groups: module, component-and-connector(C&C), and allocation. This 3-way categorization reflects the fact that architects need to think about their s/w in at least 3 ways at once:
  61. 61. 1. how it is structured as a set of implementation units 2. how it is structured as a set of elements that have runtime behavior and interactions 3.How it relates to non-software structures in its environment
  62. 62.  Other views are available  Here is a simple three-step procedure for choosing the views for your project 1.Produce a candidate view 2.Combine views 3.proritize
  63. 63.  There is no industry-standard template for documenting a view, but the seven-part standard organization that we suggest in this section has worked well in practice. 1.Primary presentation 2.Element catalog 3.Context diagram 4.Variability guide 5.Architecture background 6.Glossary of terms 7.Other information
  64. 64. Documenting interfaces: documenting an interface consists of naming and identifying it and documenting its syntactic and semantic information A template for documenting interfaces 1.Interface identity 2.Resources provided 3.Datatype definitions 4.Exception definitions
  65. 65. 5.Variability provided by the interface 6.Quality attribute characteristics of the interface 7.Element requirement 8.Rationale and design issues 9.Usage guide
  66. 66. cross-view documentation consists of just three major aspects, which can summarize as how-what-why: 1.How the documentation is 2.What the architecture is 3.Why the architecture is the way it is
  67. 67.  Uml has emerged as the de-facto standard notation for documenting a software architecture. Module views- is an enumeration of modules together with their interfaces and their relations. -interfaces -modules -aggregation -generalization -dependency
  68. 68.  Component-and-connector views There is no single preferred to document component-and-connector(C&C) views in uml, but a no.of alternatives. -components -interfaces -connectors -systems
  69. 69.  Allocation views in uml, a deployment diagram is a graph of nodes connected by communication associations The nesting of symbols within the node symbol signifies a composition association b/w a node class and constituent classes or a composition link b/w a node object and constituent objects.
  70. 70. 6.1 introduction 6.2 information extraction 6.3 database construction 6.4 view fusion 6.5 reconstruction
  71. 71.  Reconstruction in which the “as-built” architecture of an implemented system is obtained from an existing system.  Reconstruction activities s/w architecture reconstruction comprises the following activities, carried out iteratively: 1.Information extraction 2.Database construction 3.View fusion 4.Reconstruction
  72. 72.  Information extraction involves analyzing a system’s existing design and implementation artifacts to construct a model of it.  Info obtained can be categorized as either static or dynamic.  To extract info a variety of tools are used, including these: -parsers -abstract syntax trees -lexical analyzers -profilers -code instrumentation tools -ad hoc
  73. 73.  Guidelines the following are some practical considerations in applying this step of the method. -use the “least effort” extraction -validate the info you have extracted -extract dynamic info where required
  74. 74. The extracted info is converted into a standard format for storage in a database during database construction. It is necessary to choose a database model. When doing so, consider the following: • It should be a well-known model • It should allow for efficient queries • It should support remote access of the database • It supports view fusion • It supports query language • Check pointing should be supported by implementations
  75. 75.  Guidelines -build database tables from the extracted relations -as with any database construction, carefully consider the database design before you get started -use simple lexical tools like perl and awk
  76. 76.  View fusion involves defining and manipulating extracted info to reconcile, augment, and establish connections b/w the elements.  improving a view  Disambiguating function calls
  77. 77. Guidelines The following are some practical considerations in applying this step of the method: -fuse tables when no single extracted table provides the needed info -fuse tables when there is ambiguity within one of them, and it is not possible to disambiguate using a single table -consider different extraction techniques to extract different info.
  78. 78.  The view info has been extracted, stored, and refined or augmented to improve its quality. The reconstruction operates on view to reveal broad, coarse-grained insights into the architecture  Reconstruction consists of two primary activities: -visualization and interaction -pattern definition and recognization
  79. 79. Guidelines The following are some practical considerations in applying this step of the method: -be prepared to work with the architect closely and to iterate several times on the architectural abstraction that you create -when developing code segments try to build ones that are succinct and that do not list every source element
  80. 80. -code segments can be based on naming conventions -code segments can be based on the directory structure -architecture reconstruction is the effort of redetermining architectural decisions, given only the result of these decisions in the actual artifacts