Architectural Design ResolutionAnalyzedSRSArchitectural Design ProcessDevelop ArchitecturalDesign AlternativesEvaluate ArchitecturalAlternativesSelect ArchitecturalResolutionFinalize Software Architectural DocumentSAD[selected ][else ]

Various Alternatives to Generating Architectural Design Develop Functional ComponentsBased on transforming SRS functions and data requirementsDetermine/Modify Components Based on Quality Attributes: maintainability, reusability, performance, availability & security (non-functional attributes)Based on transforming non-functional SRS requirementsModifying Existing Architecture (for follow-on releases)Based on existing architecture as a starting point and transforming it to satisfy the new systemElaborate an Architecture Style (chapter 15)Based on an existing architectural style and elaborate on that styleTransform a Conceptual Model (chapter 11-Destailed Design)Based on viewing the SRS problem description as a solution description and transforming that to fit the new systemfromscratch

Architectural Design (team or individual activity?) In software engineering, many activities are performed as a team effort --- for

Productivity QualityMorale and General Acceptance

But for Architectural Design:

Better done as an individual firstBring together all the individual architectural design suggestionsEvaluate the alternatives

Determine Functional Components(Using the AquaLush Irrigation System Example in textbook p.82 and p.164)AquaLush Product Vision: The AquaLush Irrigation system will use soil moisture sensors to control irrigation, thus saving money for customers and making better use of water resources.AquaLush Major Product Features (from requirements): - Monitor water usage and limit usage (by moisture level) to amounts set by users - Allow users to specify times when irrigation occurs - Be operated from a simple central control panel - Have a web-based simulator - Allow users to monitor parts and schedule repairsWhat would you list as major functional components ? (e.g.) 1. user interface to initialize, set-up, monitor and control the irrigation system 2. sensor inputs processing 3. water irrigation control 4. web-based simulator 5. parts monitor and repair

Determining Functional Components from SRS(page 289 291textbook solution)1. configure the program at startup2. controlling irrigation (manually and automatically)3. providing a user interface4. allowing users to monitor and repair system

User Interface

Irrigation Control

Monitor and Repair

StartupDo the functional components and the relation lines make sense to you? (Should there be a line between User Interface and Startup ?)From page 180From page 289

Determining Functional Components(page 289 291textbook solution for product)1. configure the program at startup2. controlling irrigation (manually and automatically)3. providing a user interface4. allowing users to monitor and repair system

User Interface

Irrigation Control

Monitor and Repair

StartupAquaLush PartsStatusAquaLush Configuration

>

Note that Monitor and Repair component can usethe Data Store to communicatewith Irrigation Control component, without a line between them.How initialized?

Component ResponsibilitiesThere needs to be some description of each components responsibilities:

User Interface: interacts with control panel hardware and implements control panel interface; obtains data from Monitor and Repair -------Monitor and Repair: Obtains data from Parts Status to pass on to ------ Irrigation Control: Controls valve, reads sensors; reads clock; implements irrigation cycles; ---Startup: reads the configuration data of valves, zones, etc. and send them to Irrigation Control & (also alternatively also include Monitor Repair) ---- Parts Status: a database that keeps track of all failed and repaired parts, etc.Configuration: a database of all the installed parts of valves, sensors, etc. of the customers Aqualush system

Determining Functional Components(page 293 textbook - for adding web- simulator)

Simulating User interaction

Irrigation Control

Monitor and Repair

StartupAquaLush PartsStatusAquaLush Configuration

>

SimulatingValves and sensorsSame initializationproblem?

Determining Components based onnon-Functional or Quality attributes AquaLush has the following non-functional (NF) requirements:Reusability : design must be used in the product, web-simulator, and future versionsHardware adaptability: design should consider adaptability to multiple valve types, sensor types, keypads, and screen display typesReliability: must not fail often in normal usageModifiability: accommodate future changes in irrigation strategy (formula) Note that reliability of not failing often is a nebulous and subjective statement

NonFunctional: Reusability AttributeRequires components to be cohesive and loosely coupled so that they can be reused.Consider each component for these:Would you subdivide User Interface/interaction component into several subcomponents (interface to Irrigation Control and to Monitor and Repair separately)?

Would you separate out Irrigation Control component into a) manual and b) auto subcomponents? - etc.Irrigation ControlManual controlautomatic control

NonFunctional : Hardware Adaptability & ModifiabilityRequires the component to have device adaptability also implies separate cohesive subcomponents low coupling subcomponents, each representing different devicehide the device specific internals and keep the interface unchangingIn AquaLush, the Irrigation Control has interfaces to multiple devices.In AquaLush, Monitor and Repair component and Startup component has interface to a data-storeVirtual Device InterfacevalvesensorkeypaddisplayScreenbuttonsEverything inside the Device Interface components are device dependent, but hiddenfrom outside; all interfaces to outside of the component should stay stable May changealgorithmbased ondifferent sensorsHow would you designa singleread/writeinterface ?

NonFunctional: Reliability and other componentsReliability may be argued many ways:Small cohesive module is by definition more reliableAdd user interface to control irrigation both manually and automatically AND also have direct control of the devices

User InterfaceIrrigation ControlmanualautoVirtual Device InterfacevalveSensor display keypad Screen buttons Agree withall the interactionlines ? Do we needa new component ?EmergencyControlDesigners view of providing reliability ---- not fail often in normal usage

Design AlternativesDesign alternatives are good to have and can improve the design:

Generate and document these alternatives as the design is getting formulated

Combine some of the parts of the generated design alternatives from:Functional ComponentsNon-functional Components

Try to alter and fit to an existing Design Style, if applicable

Architectural Design ResolutionAnalyzedSRSArchitectural Design ProcessDevelop ArchitecturalDesign AlternativesEvaluate ArchitecturalAlternativesSelect ArchitecturalResolutionFinalize Software Architectural DocumentSAD[selected ][else ]

Evaluating Architecture Alternatives What does one look at when evaluating architecture?

Would the architecture result in a system that will satisfy:Functionality requirementsQuality (non-functional) requirementsMaintainabilityReusabilityPerformanceAvailabilityReliabilitySecurityWould the architecture result in a system that will Have great user experience or user interfaceDelight the customer and the users We can not tell what will happen since the architecture is not code, wecan only guess whether the architecture will most likely meet the aboveconditions

An Architecture Evaluating Technique Utilize a profile, which is a set of scenarios generated to fit the characteristics of interest. (e.g.)

Usage profile is a set of scenarios that describes the user requirements (sometimes known as regular business workflow)

Reliability profile is a set of scenarios that portrays the non-functional requirement of how a system behaves under adverse situations

Performance profile is a set of scenarios that portrays the non-functional requirements of how a system behaves under time limit constraints or capacity limit constraints etc.

Each architecture alternative is evaluated by going through the scenarios in the profile and assessing whether the architecture, if implemented, would satisfy the profile.

Developing Profiles with utility treeA utility tree is a tree whose each sub-tree is a profile and the leaves of the sub-tree are the scenarios for that profile Utility treeFunctionalitiesIrrigation control (automatic)Irrigation control (manual)Maintenance repairHardware adaptabilityValve type modificationAdding new valve types1. The profiles are generated, using SRS and some brainstorming2. The scenarios within each profile are also developed using SRS, team brainstorming, and prioritizations.3. Within each profile, keep the number of scenarios to 3 to 104. Each scenario should include: - initial state - activity flow involving actors and the product - post activity state

* * think of special circumstances and non-traditional scenarios, too

Another Architecture Evaluating TechniqueBuild a prototype of part of or the complete software product to evaluate certain aspects (functional and non-functional) of the product.Advantages:Can provide measurementsCan provide experiential feedbacks Disadvantages:Prototypes takes resourcesPrototypes takes time

Much of the prototyping and profiling techniques are aimed at evaluatingthe architecture against the basic design principles (discussed earlier) : - feasibility, - adequacy, - economy, and - changeability

Selecting Alternatives How do we select the architecture from the various alternatives ?Evaluate the Pros and Cons of each of the alternativesBy Number of pros and consBy Weights of pros and cons

Multi-dimensional analysis table (p. 306 of text):A Column of scenariosWeight for each scenario (use normalized weight so each is a fraction of the total and the total is 1)A Column for each architectural alternativeRate all the scenarios for that alternative ( e.g. 1-5)Score the scenario by multiplying the scenario weight and the rateSum the scores for that alternativeCompare the total score for each of the architectural alternatives

Architectural Design ResolutionAnalyzedSRSArchitectural Design ProcessDevelop ArchitecturalDesign AlternativesEvaluate ArchitecturalAlternativesSelect ArchitecturalResolutionFinalize Software Architectural DocumentSAD[selected ][else ]

Finalizing The Architectural DesignThis step ensures that the selected architecture does satisfy the various functional and non-functional requirements (and possibly may delight the users) and is clearly documented.

Architectural design satisfying the basic design principles of:FeasibilityAdequacyEconomyChangeability

Also, The SAD document itself isWell formed (organized)Complete (include all the components/relationships/descriptions)Clear (understandable by others)Consistent (no conflicting information)

(from chapter 8 of text)Think about thesefor your assignment 4

Design Review in Finalizing the SAD A Review is an examination and evaluation of the work by qualified and affected stakeholders There are many different types of reviews:

1. Desk Check by the author 2. Walkthrough informal review by team members 3. Inspection formal review by a trained inspection team with moderator 4. Audit review conducted by experts who are not part of the team 5. Active Review inspection by experts who answer specific aspects of the design (this allows pinpoint reviews and is less costly)A Formal inspection requires 3 formal steps:

- preparation - conducting the inspection - rework and inspection closeout report