Software Architecture PDF

Software Architecture © S. Somé  Architecture is... “the decisions that you wish you could get right early in a project... the important stuff. Whatever that is” – R. Johnson “things that people perceive as hard to change” – M. Fowler “the set of significant design decisions about...

Software Architecture © S. Somé  Architecture is... “the decisions that you wish you could get right early in a project... the important stuff. Whatever that is” – R. Johnson “things that people perceive as hard to change” – M. Fowler “the set of significant design decisions about how the software is organized to promote desired quality attributes and other properties” – M. Keeling “the set of design decisions which, if made incorrectly, may cause your project to be cancelled” – E. Woods © S. Somé © S. Somé  Why Software Architecture? The goal of software architecture is to minimize the human resources required to build and maintain the required system (Robert C. Martin) Engineering Staff over Time Product Size in KLOC Intense refactoring needed Technical debt © S. Somé  IEEE Definition “Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” (ISO/IEC/IEEE 42010) abstraction of elements key to always present includes basis for its the system development © S. Somé Importance of Software Architecture Inhibits/enables quality attributes Influences the organizational structure Helps reasoning about/managing Enables evolutionary prototyping change Helps with cost and schedule estimates Helps predict system qualities Transferable, reusable model Allows communication among Stakeholders Allows the assembly of independent Carries early design decisions components Channels the creativity of developers Defines constraints on implementation Foundation for training © S. Somé  Software Architect “If architecture is the important stuff, then the architect is the person (or people) who worries about the important stuff” – M. Fowler Defines the Problem from an Engineering Perspective Partitions the System and Assign Responsibilities Decides Trade-offs among Quality Attributes Manages Technical Debt Grows the Team’s Architecture Skills © S. Somé As a Software Architect, you will: ⚫ Produce software designs using ⚫ Present key aspects of the architecture existing Architecture patterns. and its vision to managers within IT. ⚫ Define new architecture ⚫ Define, implement and enforce patterns for use by developers processes to ensure the appropriate implementing projects. implementation of architectural patterns. ⚫ Research/identify prototypes evaluating new software ⚫ Educate the development team on technologies and platforms. standards, architectural directions and system integration directions. ⚫ Enforce software best practices ⚫ Proactively identify and work to through code reviews, ensuring resolve software issues arising during balance of software project implementation. © S.performance/maintainability. Somé  Architecture in Context System has Architecture has described by Rationale 1..* 1..* identifies important to Architecture Stakeholder 1..* provides 1..* Description is addressed to Justifications, recorded with 1..* the architecture has organized identifies by 1..* 1..* 1..* Facet of architecture, targets Concern Viewpoint conforms to View specific concerns used to cover participates in 1..* 1..* consists 1..* of 1..* Conventions (languages, Model establishes methods for Model notations, methods, Kind templates, patterns, model 1..* kinds) for building and ISO/IEC/IEEE 42010 © S. Somé using a view  Architecture Frameworks Establish a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular domain of application or stakeholder community (ISO/IEC/IEEE 42010) Zachman’s information systems architecture framework Open Group’s Architecture Framework (TOGAF) “4+1” view model http://www.iso-architecture.org/42010/afs/frameworks-table.html © S. Somé  Views Representation of an architecture from the perspective of a related set of concerns Modules View Addresses specific stakeholders Concurrency View Interrelated Various numbers and types Deployment View according to the architectural framework © S. Somé  Module View Developers, Managers concerns Modifiability, Testability, Schedule,... Helps answer: What is the primary functional responsibility assigned to a module? What other software elements is a module allowed to use? What other software elements does a module uses/ depends on? © S. Somé  Concurrency View Integrators, Operators Integrity, Fault-tolerance, Performance,... Helps answer: What are the major executing components and how do they interact at runtime? Which parts of the system can be replicated? Which parts of the system can run in parallel? How does data flows through the system? © S. Somé  Deployment View System Engineers, Operators Availability, Reliability, Performance, Scalability,... Helps answer: What processor does each software element execute on? What are opportunities for redundancy? © S. Somé  Architecture Process Set of activities conducted by Architects Architecture to develop an architecture Requirements Selection Architecture Structuring Architecture Validation © S. Somé  Attribute-Driven Design (ADD) Iterative Architecture Design Approach from the SEI Series of Design Rounds divided in Iterations Focuses on achievement of Quality Attributes Selects and represents structures in views https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=436536 © S. Somé  Architecture Design Process © S. Somé © S. Somé  Step 1: Review Inputs Ensures inputs availability and correctness Clear design purpose Primary functionality Prioritized Quality Attributes/ Constraints © S. Somé Select subset of drivers focus of Step 2: Establish the Iteration Goal the iteration Goal of the iteration: create the necessary architecture elements to satisfy these drivers © S. Somé Identify the architecture elements that impact the Drivers Step 3: Choose Elements to Refine To be refined using a design strategy © S. Somé Select Design Concepts (Architectural Pattern, Tactic, Reference Architecture, Framework Component) that satisfy the Driver. Step 4: Choose Design Concepts Choice restricted by Constraints Based on Tradeoffs Prototyping may be used © S. Somé Instantiate elements from Design Concept, their Relationships and Interfaces Step 5: Instantiate elements © S. Somé Documentation of Architecture, Design decisions, Rationales, discarded Alternatives Models for the architecture Step 6: Sketch views, record decisions © S. Somé Ensures created design satisfies the goals Review of the sketches of the views and design decisions Can add new concerns to be addressed Subsequent iterations when there are still unsatisfied drivers or design purpose is not satisfied based on an assessment Step 7: Analysis and Review of risks © S. Somé  Architectural Requirements - Drivers Design Context and Purpose Quality Attributes Primary Functionality Constraints Architectural Concerns © S. Somé  Design Context and Purpose Nature of Development Greenfield Mature Existing experience to rely on Greenfield Novel Needs exploration (e.g. prototyping) Brownfield Needs existing architecture Business Goal Estimation Rough architecture Exploration Prototyping for better insight Development Enough detail to support product, development team © S. Somé  Example: FCAPS System Business Case Large communications company wanted to expand its Internet Protocol (IP) network to support “carrier-class services”, and more specifically high- quality voice over IP (VOIP) system Needs synchronization of VOIP servers and other equipment FCAPS System: to monitor and manage a time synchronization network © S. Somé  FCAPS Standard model for network management Fault management Configuration management Accounting Performance management Security management Greenfield Mature Development © S. Somé  Primary Functionality Ability of a system to fulfill its intended tasks Critical to Business Goals Main Motivation of project Core Use Cases/ Features Architecture affects ease of Changes © S. Somé  Use Case Model © S. Somé Use case Description UC-1: Monitor network status A user monitors the time servers in a hierarchical representation of the whole network. Problematic devices are highlighted, along with the logical regions where they are grouped. The user can expand and collapse the network representation. This representation is updated continuously as faults are detected or repaired UC-2: Detect fault Periodically the management system contacts the time servers to see if they are “alive”. If a time server does not respond or if a trap that signals a problem or a return to a normal state of operation is received, the event is stored and the network representation observed by the users is updated accordingly UC-3: Display event history Stored events associated with a particular time server or group of time servers are displayed. These can be filtered by various criteria such as type or severity UC-4: Manage time servers The administrator adds a time server to, or removes a time server from, the network © S. Somé Use case Description UC-5: Configure time server An administrator changes configuration parameters associated with a particular time server. The parameters are sent to the device and are also stored locally UC-6: Restore configuration A locally stored configuration is sent to one or more time servers UC-7: Collect performance data Network performance data (delay, offset, and jitter) is collected periodically from the time servers UC-8: Display information The user displays stored information about the time server- configuration values and other parameters such as the server name UC-9: Visualize performance data The user displays network performance measures (delay, offset, jitter) in a graphical way to view and analyze network performance UC-10: Log in A user logs into the system through a login/password screen. Upon successful login, the user is presented with different options according to their role UC-11: Manage users The administrator adds or removes a user or modifies user permissions © S. Somé  Quality Attributes Measurable properties of a system Fitness of a product for its intended use How well the system satisfies its stakeholders needs Should be measurable © S. Somé  Performance Usability communication, parallelism,... availability, responsiveness, common style Security specialized components Modifiability Availability modularization redundancy, interaction Reusability Portability dependency abstraction Testability Integrability abstraction modularization © S. Somé  Quality Attribute Scenarios ID Quality attribute Scenario Associated use case QA-1 Performance Several time servers send traps to the UC-2 management system at peak load: 100% of the traps are successfully processed and stored QA-2 Modifiability A new time server management protocol is UC-5 introduced to the system as part of an update. The protocol is added successfully without any changes to the core components of the systems QA-3 Availability A failure occurs in the management system during All normal operation. The management systems resumes operation in less than 30 seconds QA-4 Performance The management system collects performance data from a time server during peak load. The management system collects all performance data within 5 minutes, while processing all user requests, to ensure no loss of data due to CON-5 © S. Somé ID Quality attribute Scenario Associated use case QA-5 Performance A user displays the event history of a particular UC-3 time server during normal operation. The list events from the last 24 hours is displayed within 1 second QA-6 Security A user performs a change in the system during All normal operation. It is possible to know who performed the operation and when it was performed 100% of the time © S. Somé  Constraints Predetermined Decisions Technologies Inter-operating Systems Laws, Standards Developers abilities Strict deadlines... © S. Somé  Constraints ID Constraint CON-1 A minimum of 50 simultaneous users must be supported CON-2 The system must be accessed through a web browser (Chrome V3.0+, Firefox V4+, IE8+) in different platforms: Windows, OSX and Linux CON-3 An existing relational database server most be used. This server cannot be used for other purposes than hosting the database CON-4 The network connection to user workstations can have low bandwidth but is generally reliable CON-5 Performance data needs to be collected in intervals of no more than 5 minutes, as higher intervals result in time servers discarding data CON-6 Events from the last 30 days must be stored © S. Somé  Architectural Concerns May not be included in the requirements but need to be considered in the design General architecture Concerns: broad architectural issues (e.g. creating components, allocating functionality) Specific Concerns for the project: system-internal issues (e.g. logging, exception handling) Internal Requirements related to development: derived requirements (e.g. facilitate development, deployment, operation) Architectural Issues from previous architecture reviews © S. Somé  Architectural Concerns ID Concern CRN-1 Establishing an overall initial system structure CRN-2 Leverage the team’s knowledge about Java technologies, including Spring, JSF, Swing, Hibernate, Java Web Start and JMS frameworks and the Java language CRN-3 Allocate work to members of the development team © S. Somé  Architecture Roadmap Greenfield Project project Vision & Scope Establish Design Initial Concepts Architecture Architecture Viewpoints Description Architectural Architecture Requirements Brownfield Development project Iterations © S. Somé  FCAPS Design Step 1: Review Inputs Category Details Design purpose This is a greenfield system from a mature domain. The purpose is to produce a sufficiently detailed design to support the construction of the system Primary functional The primary use cases were determined to be: requirements UC-1: Because it directly supports the core business UC-2: Because it directly supports the core business UC-7: Because of the technical issues associated with it UC-1: Monitor network status UC-2: Detect fault UC-7: Collect performance data © S. Somé  FCAPS Design Step 1: Review Inputs Category Details Quality attribute The quality attribute scenarios have been prioritized are as scenario follow: Scenario ID Importance to the customer Difficulty of implementation according to the architect QA-1 High High QA-2 High Medium QA-3 High High QA-4 High High QA-5 Medium Medium QA-6 Medium Low © S. Somé QA-1, QA-4, QA-5: Performance QA-2: Modifiability QA-4: Availability QA-6: Security  FCAPS Design Step 1: Review Inputs Category Details Constraints All of the constraints are included as drivers Architectural All of the architectural concerns are included as drivers concerns © S. Somé  FCAPS Design – Iteration 1 Step 2: Establish Iteration Goal by Selecting Drivers Achieve architectural concern CNR-1: establish an overall system structure Must be mindful of ⚫ QA-1: Performance ⚫ QA-2: Modifiability ⚫ QA-3: Availability ⚫ QA-4: Performance ⚫ CON-2: System must be accessed through a web browser in different platforms (i.e. Windows, OSX, and Linux) ⚫ CON-3: A relational database server must be used ⚫ CON-4: Network connection to users workstations can have low bandwidth and be unreliable ⚫ CRN-2: Leverage team’s knowledge about Java technologies © S. Somé  Step 3: Choose one or more elements of the system to refine User’s Time Server workstation Legend: FCAPS System System under development External system Context Diagram Data flow Element to refine: Entire FCAPS Database Server system Strategy: Decomposition © S. Somé Step 4: Choose one or more design concepts that satisfy the selected drivers © S. Somé  Architectural Design Concepts Tools that facilitate architecture design Building blocs Re-usable realizations of Design Principles Reference architectures Patterns Tactics Frameworks © S. Somé  Architectural Patterns/Styles Conceptual solutions to recurring design problems in a defined context Influences satisfaction architectural drivers Specify architectural structures Generally abstract © S. Somé  Data Flow Sample Data flowing between functional elements Categories Independent Components Concurrent Components, occasionally communicating Virtual Machines Interpreter + program in special-purpose language Data Centered Primarily built around large data collection Layered Subsystems that depend on each other in a very specific order © S. Somé  Architectural Tactics Fundamental design technique Design decision known to influence the achievement of a given quality attribute Tactics to control Stimulus Response response Architectural pattern/style typically “packages” a set of tactics © S. Somé  Example: Security Tactics © S. Somé  Reference Architectures Blueprint, provides overall logical structure for a type of applications Reference Model for applications in a specific domain Typically incorporates & constraints architectural patterns/styles © S. Somé Example: reference architecture web applications From Microsoft Application Architecture Guide ⚫ Incorporates: Layers, Application Facade, Data Access Components © S. Somé  Frameworks Concrete reusable realization of architecture elements From patterns, tactics, reference architectures Generic functionality addressing a recurring domain and quality attribute concerns Full-stack framework Covers whole reference architecture Non-Full-stack framework © S. Somé Covers specific concerns Step 4: Choose one or more design concepts that satisfy the selected drivers Selected Design Concepts Design decisions & location Rationale Logically structure the client Discarded alternatives part of the system using Rich Client Application reference Alternative Reason for discarding architecture Rich Internet This reference architecture is oriented toward application the development of applications with a rich (RIA) user interfce that runs inside a web browser Web This reference architecture is oriented toward applications the development of applications that are accessed fro a web browser Mobile This reference architecture is oriented toward application the development of applications that are deployed in hadheld devices © S. Somé  Reference architecture for the development Rich Client applications ⚫ Incorporates the Layers, Application Facade, Data Access Components patterns © S. Somé  Mobile Applications © S. Somé  Selected Design Concepts Design decisions & location Rationale Logically structure the server part Service applications do not provide a user interface but rather of the system using the Service expose services that are consumed by other applications Application reference architecture Physically structure the Since the system must be accessed from a web-browser (CON-2) application using the three-tier and an existing database server must also be used (CON-3), a deployment pattern three-tier deployment is appropriate Build the user interface of the The standard framework for building Java Rich Clients ensures client application using the Swing portability (CON-2) and it is what the developers were already Java framework and other Java familiar with (CRN-3) technologies Deploy the application using the Access the application is obtained via web browser, which Java Web Start Technology launches the installer (CON-2) © S. Somé  Service Applications © S. Somé  Three-Tier Deployment © S. Somé Step 5: Instantiate architectural elements, allocate responsibilities and define interfaces Adapts selected generic concepts by instantiation Design decision & location Rationale Remove local data sources in It is believed that there is no need to store data locally, as the the rich client application network connection is generally reliable Also, communication with the server is handled in the data layer. Internal communication between components in the client is managed through local methods calls and does not need particular support Create a module dedicated to The service agents component from the reference architecture is access the time servers in the adapted to abstract the access to the time servers. This will data layer of the Service further facilitate the achievement of QA-2 and will play a critical Application reference role in the archievement of UC-2 and UC-7 architecture © S. Somé  Step 6: Sketch views and record design decisions * Layer * * Layer * Presentation CS Cross-cutting CS * Swing * UI Process Modules Security module CS UI Modules * Layer * Business logic CS Op. Mgnt. Module CS Business module CS Business entities CS * Layer * Data CS Client Side * Module * Communication modules © S. Somé  Server Side * Layer * * Layer * Service SS Cross-cutting SS Service Interface Security module SS * Layer * Business logic CS Op. Mgnt. Module SS Business module SS Business entities SS * Layer * Data CS Communication module SS DB Access Module Time Server Access Module © S. Somé Element Responsibility Presentation This layer contains modules that control user interaction and use case control flow client side (CS) Business logic This layer contains modules that perform business logic operations that can be CS executed locally on the client side Data CS This layer contains modules that are responsible for communication with the server Cross-Cutting CS This layer includes modules with functionality that goes across different layers, such as security, logging and I/O. This is helpful in achieving QA-6, even it is not one the drivers © S. Somé Element Responsibility UI modules These modules render the user interface and receive user inputs UI process modules These modules are responsible for control flow of all the system use cases (including navigation between screens) Business process CS These modules either implement business operations that can be performed locally or expose business functionality from the server side Business entities CS These entities make up the domain model. They may be less detailed than those on the server side Communication These modules consume the services provided by the application running on modules CS the server side Services server side This layer contains modules that expose services that are consumed by the (SS) clients Business logic SS This layer contains modules that perform business logic operations that require processing on the server side © S. Somé Element Responsibility Data SS This layer contains modules that are responsible for data persistence and for communication with the time servers Cross-Cutting SS These modules have functionality that goes across different layers, such as security, logging and I/O Service Interfaces These modules expose services that are consumed by the clients SS Business Modules SS These modules implement business operations Business Entities SS These entities make up the domain model DB Access Module This modules is responsible for persistence of business entities (objects) into the relational database. It performs object-oriented to relational mapping and shields the rest of the application from persistence details Time server access This module is responsible for communication with the time servers. It isolates module and abstracts operations with the time servers to support communication with different type of time server © S. Somé  Initial deployment diagram for the FCAPS system © S. Somé  Element Responsiblity User workstation The user’s PC, which hosts the client side logic of the application Application server The server that hosts server side logic of the application and also servers web pages Database server The server that hosts the legacy relational database Time server The set of (external) time servers Relationship Description Between web/app server and Communication with the database will be done database server using the JDBC protocol Between web/app server and The SNMP protocol is used (at least initially) time server © S. Somé  Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose Not Partially Completed Design Decision Made during the Iteration Addressed Addressed Addressed UC-1 Selected reference architecture establishes the modules that will support this functionality UC-2 Selected reference architecture establishes the modules that will support this functionality UC-7 Selected reference architecture establishes the modules that will support this functionality QA-1 Not relevant decisions made, as it is neccessary to identify the elements that participate in the use case that is associated with the scenario © S. Somé Not Partially Completed Design Decision Made during the Iteration Addressed Addressed Addressed QA-2 Introduction of a time server access module in the data layer on the server application that encapsulates communication with the time servers. QA-3 Identification of the elements derived from the deployment pattern that will need to be replicated QA-4 No relevant decisions made, as it is neccessary to identify the elements that participate in the use case that is associated with the scenario CON-1 Structuring the system using 3 tiers will allow multiple clients to connect to the application server. Decisions regarding concurrent access have not been made yet © S. Somé Not Partially Completed Design Decision Made during the Iteration Addressed Addressed Addressed CON-2 Use of Java Start technology allows access through a web browser to download the Rich Client. Since the Rich Client is being programmed in Java, this supports execution under Windows, OSX, and Linux CON-3 Physically structure the application using 3-tier deployment pattern, and isolate the database by providing database access components in the data layer of the application server CON-4 Use of Java Web Start technology requires the client to be downloaded only the first time, and then when upgrades occur. This is helpful to support limited- bandwidth connections © S. Somé Not Partially Completed Design Decision Made during the Iteration Addressed Addressed Addressed CON-5 No relevant decisions made CON-6 No relevant decision made CRN-1 Selection of reference architectures and deployment pattern CRN-2 Technologies that have been considered up to this point take into account the knowledge of the developers. Other technologies still need to be selected (e.g. Communication with the time servers) CRN-3 No relevant decision made © S. Somé  FCAPS Design – Iteration 2 To reason about the units of implementation, which affect team formation, interfaces, and the means by which development tasks may be distributed, outsourced, and implemented in sprints © S. Somé Step 2: Establish Iteration Goal by Selecting Drivers Addresses the general architecture concern of identifying structures to support primary functionality For ⚫ understanding how functionality is supported (CRN-3) ⚫ allocation of work to members of development team Must be mindful of ⚫ CRN-3 Allocate work to members of the development team ⚫ UC-1 Monitor network status ⚫ UC-2 Detect fault ⚫ UC-3 Display event history © S. Somé  Step 3: Choose one or more elements of the system to refine Modules in layers identified in iteration 1 Collaboration of components in modules is needed to support functionality © S. Somé Step 4: Choose one or more design concepts that satisfy the selected drivers Design decisions and location Rationale & Assumptions Create a Domain Model for the Before start a functional decomposition, it is necessary to application create an initial domain model for the system, identifying the major entities in the domain, along with their relationship Identify Domain Objects that map to Each distinct functional element of the application needs to functional requirements be encapsulated in a self-contained building block – a domain object © S. Somé Design decisions and location Rationale & Assumptions Decomposition Domain Objects into Domain objects represent complete sets of functionality, but general and specialized Components this functionality is supported by finer-grained elements located within the layers. The “components” in this pattern are what we have referred to as module Use spring framework and hibernate Spring is widely used framework to support enterprise application development. Hibernate is an object to relational mapping (ORM) framework that integrates well with spring © S. Somé Step 5: Instantiate architectural elements, allocate responsibilities and define interfaces Design decisions and location Rationale Create only an initial domain model The entities that participate in the primary use cases model to be identified and modeled but only an initial model is created, to accelerate this phase of design Map the system use cases to domain An initial identification of domain objects can be made by objects analyzing the system’s use cases. To address CRN-3, domain objects are identified for all of the use cases © S. Somé Design decisions and location Rationale Decompose the domain objects across This technique ensures that modules that support all of the the layers to identify layer specific functionalities are identified modules with an explicit interface CRN-4: A majority of modules shall be unit tested Connect components associated with This framework uses an inversion of control approach that allows modules using Spring different aspects to be supported and the modules to be unit- tested (CRN-4) Associate frameworks with a module in ORM mapping is encapsulated in the modules that are contained the data layer in the data layer. The Hibernate framework previously selected is associated with these modules © S. Somé Step 6: Sketch views and record design decisions Initial domain model 0. * generates Event Time Server Region 0. * 1 - date - deviceName - name - ipAddress - payload parent - model - severity - type 1. * 0. * acknowledges 1 1 Configuration Performance Data User - configurationParameters - delay: DataSet - login - jitter: DataSet - password - offset: DataSet - permissions - type © S. Somé Domain objects associated With the use case model Network Status Monitoring Fault Detection Event History Responsibilities Responsibilities Responsibilities UC-1 UC-2 UC-3 Time Server Management Time Server Management System Access Responsibilities Responsibilities UC-5 Responsibilities UC-4 UC-6 UC-10 Performance Data & Info. Display Performance & Data Collection User Management Responsibilities UC-8 Responsibilities Responsibilities UC-9 UC-7 UC-11 © S. Somé  Client Side Presentation CS NetworkStatusMonitoringView Business Logic CS NetworkStatusMonitoringController Data CS RequestManager © S. Somé Modules that support the primary use cases Server Side Service SS RequestService Business Logic SS TopologyController DomainEntities TimeServerEventsController DataCollectionController Data SS RegionDataMapper TimeServerDataMapper EventDataMapper TimeServerController © S. Somé Element Responsibility NetworkStatusMonitoringView Displays the network representation and updates it when events are received. This component and UI process components from the reference architecture NetworkStatusMonitoringController Responsible for providing the necessary information to the presentation layer for displaying the network representation RequestManager Responsible a facade that receives requests from the clients TopologyController Contains business logic related to the topology information DomainEntities Contains the entities from the domain model (server side) TimeServerController Contains business logic related to the managements of events DataCollectionController Contains logic to perform data collection and storage RegionDataMapper Responsible for persistence operations (CRUD) related to the regions TimeServerDataMapper © S. Somé Element Responsibility TimeServerDataMapper Responsible for persistence operations (CRUD) related to the time servers EventDataMapper Responsible for persistence operations (CRUD) related to the events TimeServerConnector Responsible for communication with the time servers. It isolates and abstracts operations with the time servers to support communication with different types of time servers © S. Somé Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose Not Partially Completely Design Decision Made during the Iteration Addressed Addressed Addressed UC-1 Modules across the layers & preliminary interfaces to support this use case have been identified UC-2 Modules across the layers & preliminary interfaces to support this use case have been identified UC-7 Modules across the layers & preliminary interfaces to support this use case have been identified QA-1 The elements that support the associated use case (UC-2) have been identified QA-2 The elements that support the associated use case (UC-5) have been identified QA-3 No relevant decisions made QA-4 The elements that support the associated use case (UC-7) have © S. Somé been identified Not Partially Completely Design Decision Made during the Iteration Addressed Addressed Addressed CON-1 No relevant decisions made CON-4 No relevant decisions made CON-5 Module responsible for collecting data have been identified CON-6 Module responsible for collecting data have been identified CRN-2 Additional technologies were identified and selected considering the team’s knowledge CRN-3 Modules associated with all of the use cases have been identified and a work assignment matrix has been created CRN-4 The architectural concern of unit-testing modules, which was introduced in this new iteration, is partially solved through the use of an inversion of control approach to connect the components associated with the modules © S. Somé  FCAPS Design – Iteration 3 Focuses on just one of the quality attributes scenarios (QA-3) © S. Somé Step 2: Establish Iteration Goal by Selecting Drivers Address QA-3 quality attribute scenario: “A failure occurs in management system during operation. The management system resumes operation in less than 30 seconds” © S. Somé  Step 3: Choose one or more elements of the system to refine Physical nodes identified in iteration 1 Application server Database server © S. Somé Step 4: Choose one or more design concepts that satisfy the selected drivers © S. Somé Step 4: Choose one or more design concepts that satisfy the selected drivers Design Decision & Location Relationale & Assumptions Introduce the active redundancy tactic by By replicating the critical elements, the system can replicating the application server and withstand the failure of one the replicated elements other critical components such as the without affecting functionality database Introduce an element from the message Traps received from the time server are placed in the queue technology family message queue and then retrieved by the application. Use of a queue will guarantee that traps are processed and delivered in order (QA-1) © S. Somé  Step 5: Instantiate architectural elements, allocate responsibilities and define interfaces Design Decision & Location Relationale Deploy message queue on a separate Deploying the message server on a separate node will guarantee node that no traps are lost in case of application failure Use active redundancy Because replicas of the application server are active at any time, it makes sense to distribute and balance the load among the replicas Implement load balancing & Many technological options for load balancing & redundancy can be redundancy using technology support implemented without having to develop an ad hoc solution that would be less mature and harder to support © S. Somé Step 6: Sketch views and record design decisions Refined deployment diagram Server1: ApplicationServer LoadBalancer Pc: Workstation Database Server Server2: ApplicationServer Device1: Relocatable IP :TrapReceiver TimeServer address © S. Somé Element Responsibility LoadBalancer Dispatches (and balances the load of) requests coming from clients to the application servers. The load balancer also presents a unique IP address to the clients TrapReceiver Receives traps from network devices, converts them into events, and puts these events into a persistent message queue © S. Somé Scenario: TrapReceiver exchanges messages with other elements from the deployment diagram to support UC-2 (detect fault) Associated with QA-3 (availability) and QA-1 (performance) :NetworkDevice :TrapReceiver :ApplicationServer Pc: UserWorkstation trap() transformAndEnqueue(Event) consume() publish() event() updateView() © S. Somé  Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose Not Partially Completely Design Decision Made during the Iteration Addressed Addressed Addressed QA-1 The introduction of a separate replicated trap receiver node can help ensure 100% of the traps are processed, even in the case of a failure of the application server. Furthermore, becuase trap reception is performed in a separate node, this approach reduces application server processing load, thereby helping performance QA-2 No relevant decisions made © S. Somé Not Partially Completely Design Decision Made during the Iteration Addressed Addressed Addressed QA-3 By making the application server redundant, we reduce the probability of failure of the system. Furthermore, if the load balancer fails, a passive replica is activated within the required time period Becuase specific technologies have not been chosen, this driver is marked as “partially addressed” QA-4 No relevant decisions made CON-1 Replication of the application server and the use of a load balancer will help in supporting multiple user requests CON-4 No relevant decisions made CON-5 No relevant decisions made CON-6 No relevant decisions made © S. Somé Not Partially Completely Design Decision Made during the Iteration Addressed Addressed Addressed CRN-2 No relevant decisions made CRN-4 No relevant decisions made CRN-5 This new architectural concern is introduced in this iteration: manage state in replicas. At this point, no relevant decisions have been made © S. Somé  Architecture Validation To ensure correctness of an architecture Architecture review Scenario-based evaluation Quantitative evaluation (metrics) Prototype development © S. Somé  Architecture Review Manual inspection of an architectural document Conducted by a group of reviewers (architects, developers, clients) Supported by review checklists Verifies the completeness and correctness of the architecture Produces a report that needs follow-up © S. Somé  Scenario-based evaluation Scenario: illustrates a Quality Attribute Simulation to ensure that the design supports the scenarios Examples of approaches Software Architecture Analysis Method (SAAM) Architecture Trade-off Analysis Method (ATAM) © S. Somé  Architecture Degradation Prescriptive Architecture Architecture as “designed” Design decisions Source for implementation Descriptive architecture Architecture as “implemented” Concrete mapping of design decision to code and related © S. Soméartifacts  Architecture Degradation Prescriptive Architecture Descriptive Architecture Implementation intent Architecture Drift Architecture Erosion Degradation: divergence of Prescriptive and Descriptive Architectures Usually from changes not reflected in Prescriptive Architecture © S. Somé  Architectural Drift Introduction of architectural design decisions in descriptive architecture that are: 1.not included in, encompassed by, or implied by prescriptive architecture 2.but do not violate any of the prescriptive architecture's design decisions © S. Somé  Architectural Drift Prescriptive Architecture Descriptive Architecture Layer A Layer A Layer B Layer B Layer C Layer X Layer C © S. Somé  Architectural Erosion Introduction of architectural design decisions in descriptive architecture that violate the principles of prescriptive architecture © S. Somé  Architectural Erosion © S. Somé