A Partnership for Performance

Partnership for PerformanceHow to hear this lectureClick on the icon: to hear the narration for each slide.

#1Partnership for Performancefisher.osu.eduFisher logoLecture 7 - ArchitectureDr. Rajiv RamnathDirectorCollaborative for Enterprise Transformation and Innovation (CETI)Department of Computer Science and Engineering, College of EngineeringThe Ohio State UniversityRamnath.6@osu.eduhttp://www.ceti.cse.ohio-state.edu

Partnership for Performance

#2How we got here: Business analysis identified a problem to be solved and an application to be built.Domain, Problem and Solution analysis helped identify what was to be builtRequirements were captured about this application in terms of functional and non-functional requirementsNow we have to design the application, starting from a high-level. This is architecture

Partnership for PerformanceSoftware ArchitectureThe software architecture of a computing system is the structure(s) of the system, which comprise software elements, the externally visible properties of these elements, and the relationships between them.Courtesy: SEIRef: Software Architecture In Practice, Len Bass et. al., Safari

#3What is architecture?An EXTERNALLY visible component, its structure, property or its relationship with other externally visible componentsWhy externally visible? So that one can reason about how the system meets its requirements.Certainly, functional requirementsMore importantly, architecture is what determines how (or whether) a system meets non-functional requirementsInformally: The things that matter to the systemInformally: Things that are hard to change, once the system has been partially builtSo, software architecture => the components, properties and relationships are software relationships

Partnership for PerformanceThings Common to All ArchitecturesGoals that lead to quality attributes Performance, Availability etc.Modules and layersNeeding multiple views to describeStatic structure and dynamic behaviorTradeoffs

Leading to common ways of defining, describing, creating, analyzing, evaluating, and documenting.

#4Requirements lead to goals that must be met, which may be described in terms of attributes or properties Performance, Scalability, Modifiability, etc.All architectures have modules and layers i.e. componentsThey need multiple views to describe and understand it.For example: A University has an organizational hierarchy Departments->Colleges->University. Also has a physical hierarchy of classrooms and buildings. Each is a view that describes some aspect of the Universitys architecture. Each view is relevant to understanding a different aspect of the architecture All architectures have tradeoffs: For Universities Dept. hierarchy allows deep research in an area. However, hard to address interdisciplinary problems such as global warming.For software systems: Security vs. performance, Security vs. usability

Partnership for PerformanceStyles of Architectural ViewsModule:Decomposition = containsUses = DEPENDS on the CORRECT execution ofLayered = constrains what calls whatComponent-and-Connector:Process, concurrency, shared data (flow), client-serverAllocation:Deployment to infrastructureImplementation to file structureWork-assignment to teamsReason for Views? To systematically understand the functioning of the system and how it implements its quality attributesRef: Software Architecture In Practice, Len Bass et. al., Safari

#5Architectural views can be categorized into 3 styles of views:Module how the architecture is structured as a set of unitsComponent-and-connector: As a set of elements that have runtime behavior and interactionsAllocation: How the software architecture relates to NON-SOFTWARE structures (such as the hardware) in the environment.Partnership for Performance4+1 View Model of Software Architecture

#6Logical view : The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagram, Communication diagram, Sequence diagramDevelopment view : The development view illustrates a system from a programmer's perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagramProcess view : The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagramPhysical view : The physical view depicts the system from a system engineer's point-of-view. It is concerned with the topology of software components on the physical layer, as well as communication between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagramUse Cases/Scenarios : The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. UML Diagram(s) used to represent the scenario view include the Use case diagramDesigning ArchitectureCollege of EngineeringThe Ohio State University

#Partnership for PerformanceAttribute Driven Design a Recursive Decomposition ProcessStart with a module (in the beginning, the system) and refine it, as follows:Create a prioritization of the architectural requirements functional and NFR (most relevant) quantified into Quality AttributesStarting with the 1st requirement, design the architecture using architectural tacticsDecompose into child modules and interfaces as necessaryVerify using use cases and quality scenariosDocument this design using views

#Note: Try this in your project. Continue this until you see tradeoffs emerging.8Partnership for PerformanceQuality AttributesSystem quality:AvailabilityModifiability (includes scalability, portability)PerformanceSecurityUsabilityTestability

Business qualities:Time to market, cost/benefit, lifetime, target market, schedule, integrationRef: Software Architecture In Practice, Len Bass et. al., Safari

#9Quality attributes = Measurable non-functional requirements

(Remember Acceptance Plan?)Partnership for PerformanceTactics for implementing Quality Attributes - 1Availability:Fault detection: Ping, heartbeat, exception Recovery: Redundancy (active, passive), reboot Prevention: Demand management, transactionsModifiability (including Extensibility and ScalabilityLocalize, prevent ripple effects, defer binding time, limit allowable modificationsEssentially: Reduce coupling and increase cohesionPerformanceReduce resource use (memory, communications, data) Reduce switchingIncrease resourcesIncrease parallelismControl demand

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#10Look up the these tactics to see what they mean:

Partnership for PerformanceTactics for implementing Quality Attributes - 2UsabilityRuntime: Feedback, use task, user and system modelsDesign time: Separate UI (modifiability tactic)TestabilityGoal: Show the PRESENCE of faultsRecord/playback, Stub interface from implementationSpecialized testing interfaceUse internal monitoringSecurityDetect: Monitor and compare access patterns, store and analyze dataResist: Authentication, levels of authorization to , limit exposure by limiting access, encryption, preservation of integrity through checksumsRecover: availability tactics, audit trails for identification and investigation

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#11Analyzing and Validating Architecture using The Architectural Tradeoff Analysis Method (ATAM)

College of EngineeringThe Ohio State University

#Partnership for PerformanceATAM Component - ScenariosScenarios are used toUnderstand quality attributes

Scenarios should cover a range ofAnticipated uses of (use case scenarios),Anticipated changes to (growth scenarios), orUnanticipated stresses (exploratory scenarios) to the system.

A good scenario makes clear what the stimulus is that causes it and what responses are of interest.

Where have you seen this before? Acceptance Tests!!Ref: Software Architecture In Practice, Len Bass et. al., Safari

#Partnership for PerformanceATAM Component - Utility Tree

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#This is a simpler way of defining the architectural scenarios.14Partnership for PerformanceATAM Scenario ExamplesUse case scenarioRemote user requests a database report via the Web during peak period and receives it within 5 seconds.

Growth scenarioAdd a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week.

Exploratory scenarioHalf of the servers go down during normal operation without affecting overall system availability.

Scenarios should be as specific as possible.

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#Partnership for PerformanceATAM - Analyze Architectural ApproachesScenariosUsed to Pose ArchitectureQuestions

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#Here the scenario is used to probe the architecture to see how it does (or does not) support the scenario,16Partnership for PerformanceATAM - Analysis ExamplesScenario-based questions elicit the architectural decisions made.

ExamplesPerformance How are priorities assigned to processes? What are the message arrival rates? What are transaction processing times?ModifiabilityAre there any places where layers/facades are circumvented ?What components rely on detailed knowledge of message formats? What components are connected asynchronously?

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#Partnership for PerformanceATAM - Sensitivity, Tradeoffs and RisksSensitivity A property of a component that is critical to success of system.The number of simultaneous database clients will affect the number of transaction a database can process per second. This assignment is a sensitivity point for the performanceKeeping a backup database affects reliabilityPower of encryption (Security) sensitive to number of bits of the keyTradeoff point- A property that affects more than one attribute or sensitivity point.In order to achieve the required level of performance in the discrete event generation component, assembly language had to be used thereby reducing the portability of this component.Keeping the backup database affects performance also so its a trade-off between reliability and performanceRisk point - If a sensitivity or tradeoff point is close to limits, this is a risk pointRef: Software Architecture In Practice, Len Bass et. al., Safari

#Partnership for PerformanceHow Much Architecting Is Needed?

Ref: Software Architecture In Practice, Len Bass et. al., Safari

#Grey graph change to scehduleBlack graph shows time added due to rework19Architecture Work-ProductsCollege of EngineeringThe Ohio State University

#Partnership for PerformanceArchitecture Work-ProductsTarget environment= 4+1 Deployment viewSubsystem model= 4+1 Conceptual viewSystem ArchitectureOther views

#Process:Look up Work-product in handoutComplete in reverse order subsystem model, target environment, system architecture.Think of each subsystem as a single class. Give it methods that define the contract with its usersTarget Environment should show the actual technology used.System Architecture describes how the functionality is implemented. Also shows how the NFR are met. It is the Design view of the Acceptance Plan.21Partnership for PerformanceTarget environmentHardware, OS and runtime environmentPurpose is to document deployment environmentParticipants - customer and system architectsTiming - along with NFRs and then elaborated at designTechnique - start with NFRsNotation: Free format text with appropriate diagrams.

#Partnership for PerformanceSubsystem modelDelegation of system responsibilities into subsystems Clearly define interfacesParticipantsArchitects, project managerTimingAlong with system architectureTechniqueIf possible start with analysisUse facades

#Partnership for PerformanceSystem ArchitectureGlobal, project-wide design decisions on:Layering, communication patterns, distribution, persistence, security, error-handling and recovery, debugging, reuseApplication, application support and utility sub-domainsUsually done by one personTechnique:Start with prioritized NFRs with global impact (performance, error handling, UI etc.)If an NFR does not exist, create appropriate ones at this stage!Make architectural decisions to meet theseTransform a set of Analysis Sequence Diagrams to validate these decisions

#Partnership for PerformanceThe End

#Logical View

End userFunctionality

Development View

Process View

Physical View

Use Case View

ProgrammersSoftware Management

IntegratorsPerformanceScalability

System EngineersTopologyCommunications

4+1" View Model

Conceptual

Physical