Architecture Design

1. Architecture Design Chapter 9

2. Architecture Design • Architecture design ---- used in verb form Architecture design is a problem-solving activity whose input is the SRS document and whose outputis the “abstract” specification of a software solution which realizes the desired characteristics Rephrased from page 254 of text What does “abstract specification” really mean ----? Does it have anything to do with the problem solving technique of abstraction – where only the “major” components , their “major” responsibilities and characteristics, and their “major” relationships are described ?

3. Architecture Design • Architecture design - - - used in a noun form Architecture design is a specification (document) of the solution’s major components, their responsibilities and properties, and the relationship and collaboration among the major components. Also, rephrased from page 254 of text

4. Architectural Design Activity Overlaps • Architecture Design Activity can not be cleanly separated from SRS Analysis (Product Design) and Detail Design Activities because of the 4 “basic” design principles: • (Feasibility): During Product Design, we may need to understand the feasibility of some specific architecture by creating a “prototype” • (Adequacy): May need to “prove” the sufficiency of the solution and need to create an architectural prototype during Product Design or Design Analysis time • (Changeability): May need to make trade-offs of requirements based on the design architecture • (Economy): May need to explore schedule, cost, and resource impact based on the design/architecture AND some detail design Requirements (Product Design) Architectural Design Detail Design

5. Variations in Architectural Design • Not all architectural designs are the same in terms of their levelof abstraction: • number of components (main components), • description of each component • relationships among components • Two important Considerations: • Problem context: the larger the problem the more levels of abstraction, # of components, # of relationships among components • Organizational context: the more experienced and sophisticated organizations would have more standards, tools, guidelines, and skills invested --- thus may have more pre-determinedpreference or constraints on the architectural design Deciding on the “right” level of architectural depth has always been a problem!

6. Introduction To Architectural Design Architectural Design Process Swft Engr. Design Develop Architectural Alternatives Analyzed SRS SRS Design Analysis Evaluate Architectural Alternatives Architectural Design Select Architectural Resolution Detail Design Design Doc. [else ] [selected ] Finalize Software Architectural Document SAD

7. Software Architecture Document (SAD)Content • Product Overview: summarizes the overall product description, stakeholders and target market descriptions, key assumptions and constraints, and the basic business requirements (or refer to SRS document) • Architectural Models: presents the architecture in terms of models of data, functional decomposition and functionalactivities, and system states and transitions (representing different aspects or views – use DeSCRIPTRas a guide). • Mapping between Models: presents and explains how the different models are related • Architectural Rationale: explains the main criteria considered for design decisions, alternatives that were investigated, and why the particular architectural choice was made. (choosing which design decisions to discuss is important) The “meat’ of the document are the sections that describe the different models and the relationship among the models; but don’t forget the rationale

8. Design of Non-Functional Requirements • MajorFunctional Requirements can be directly mapped into key architectural components, but how about “non-Functional requirements (or attributes)”? • Operational Attributes (for users): • Performance: time limits, space capacity, transaction limits • Availability: readiness for use (borders on performance) • Security: resistance or protection from harm • Reliability: error resistance and performing to requirements • Usability: easy to understand and navigate • Developmental attributes (for software engineers): • Maintainability: easy to understand (cohesive) and modify • Reusability: portable, easy to modify, loose coupling, etc. Note: Your text calls these “quality” attributes (p.257) - Architectural Design of Functional requirements is much more straightforward. - The non-Functional requirements puts constraints and forces one to look for alternatives in architecture; some nonfunctional requirements turn into functional solution (e.g. security)

9. Non-Functional Considerations for Architects For class discussion ---- not in text book • Performance: number of transactions per second ---- how would we assess this ? • (# of instructions per transaction) x (time/instruction) = time/transaction • Availability: percentage of system up-time ---- how would you assess this? • # of hours up/ total hours ----- architect needs to think about what brings the down time. (include design for performance scalability and redundancy?) • Security:percentage of non-compromised data ---- how would you assess this? • # of non-compromised tables/total number of tables per year ---- what could cause table compromise (bad or improper inputs)? • Reliability: number of defects in the product ----- how would you assess this? • # of problems/10,000 usage-hour ----- defect causes? (input processing, algorithm, output processing, interface, etc.) • Usability: customer satisfaction ----- how do we assess this as architects? • # of discrete steps to functional completeness (worst case number versus human psychological bounds?)

10. (from P.258 of text) “Finger Print Matching” • Functionalities: A “program” responsible for matching fingerprints read from scanners against a database to allow people into and out of a secure facility. • Non-Functional: There are also some other characteristics that are important: (1) must respond quickly, (2) must be available the entire time, (3) must be able to perform matching at a reliable rate, (4) and must resist attackers. (note: mostly usage/operationally oriented as opposed to software engineering oriented --- e.g. nothing about how to build this or maintain this))

11. Fingerprint Matching “Design” via DecompositionExample Using “cooked up” box and line notation(p 258 –text) Fingerprint Reading device “matching --- against a database” Input validation Fingerprint validation validating “fingerprints” read from scanners Finger Print DB

12. Fingerprint Matching Software “Initial Design”Example Using Activity Diagram notation(p 258 –text) Fingerprint Matching Architecture fingerprint input Input validation error message [bad input] [good input] Fingerprint Reading device fingerprint validation Finger Print DB Set-up / send message pass/ no-pass message What about these?

13. Fingerprint Matching “Design Refinement”Example Using Activity Diagram+(p 258 –text) Input validation Fing_prt input Fingerprint Reading device validate input [else] Error process Error message 1.Easier tohandle functions. 2. BUT what about ? : - performance - reliability - security - availability 3. Do we need to depend on experience and insights to design these non-functional requirements? - how about design pattern? [good print] Evoke F-prt-digi Digitized Fing prt Fingerprint validation Digitized Fing prt Finger Print DB Pass/No-pass message validate F-print Fing_prt table Compare this with box-and line diagram on page 265 of text – it’s “broader”

14. What about these “non-functional” attributes? • “respond quickly” - Performance • Which functionality: a) input validation or b) fingerprint validation or both needs to be looked at? • Is the scanner system or the db system a potential bottleneck? • How do we specify the speed criteria on the activity diagram? • “must be available the entire time - - -” - Availability • Scanner system must have a back-up scanner to switch to? • Do we need a redundant db or some other file? • Similarly do we need to have a redundant processor ? • How do we specify the redundancy on the activity diagram? • “must perform matching at a reliable rate” – Reliability • Input checking must not accept incomplete or smeared finger print • Algorithms for digitizing finger prints must be accurate – (error rate?) • Algorithm for data base compare must be accurate – (error rate?) • How do we specify these on the activity diagram? • “must resist attacker” – Security • What does this mean? The whole system must be physically protected and there should not be any “connection” to any other system. • The system must have a security check functionality for start-up, shut-down, and access. • We can do the security checking by adding another set of functionality for system maintenance to activity diagram • How do we show physical protection on the activity diagram?

15. What about Cohesion and Coupling? • Had we put input validation and fingerprint validation together as “validation”---- would we have some issue related to “cohesion?” • Input validation: a single related function • Fingerprint validation: a single related function • Now that we have separated these two, what is the issue on “coupling?” • Digitized fingerprint passed from input validation to fingerprint validation ( one finger print at a time --- or can we batch the fingerprints for performance reason?) Is there some other way to“cohesively” Decomposeand Integrate with “minimal coupling”?

16. Affinity of Data and Processing • Recall our earlier discussion of (Cohesion) “processing where the data is kept” concept? • How does that apply to the fingerprint processing software ? • Where is the input data? --- processed at input validation “module” • Where is the fingerprint data? --- processed at the fingerprint validation “module” For OO aficionados: Should these be two different Methods within the same FingerPrint Class or possibly two different Classes, :ScannerValidator and IdentityValidator ?

17. Specifying Architecture Design • There are both static structure and dynamic behavior models to specify. • There are various notations that may be used: • UML • Activity Diagram √ • Use Case diagram √ • Class diagram √ • Interaction diagrams : sequence, communication, timing, overview • State diagram • Package, component, and deployment diagrams (in this lecture note) • Box-and-Line diagram(in these lecture notes) • Text

18. A Table of Notations and their usage for DeSCRIPTR

19. Box-and-Line Diagrams • This is a notation of boxes (figures) and lines which connect the figures that represent “components.” • Has no specific notation besides box and line • May be used to represent either static or dynamic modeling, used mostly for static modeling • There are some guidelines: • Use box-and-line only when there is no standard notation that can meet the needs • Make boxes for different items look different • Be consistent in using the symbols and figures • Use noun-phrase to name things and verb-phrase to name actions • Don’t mix static and dynamic elements Box-and-Line chart should employ alegend to help clarify the symbols.

20. Textual Notation • Text is very useful in specifying items that are not easy to describewith graphical notations such as: • Responsibilities (details of) • Relationships (details of) • System/Program Interfaces (not just user interface) • Properties(especially non-functional properties such as availability) • Some guidelines on using Text: • Write good technical prose using meaningful names when specifying responsibilities and relationships in an architecture • Use a template to specify interfaces: • Services provided • Syntax • Semantics • Pragmatics • Services required • Usage guide • Design rationale • Use pre-condition & post-condition to help describe semantics and pragmatics of interfaces • Specify properties and attributes with the help of scenarios clarity See page 264 of text for an example of a template usage

21. A Simple example of syntax, semantics & pragmatics • Syntax Example: • IO_Routine (IOCntrl: integer) : return_type • The parameter IOCntrl may take on the integer values of 0,1,2, or 3 • Semantics: • This method provides the service of performing different I/O functions based on the IOCntrl parameter • IOCntrl values: 0 – do nothing 1 – read information 2 – write information 3 – update information • Pragmatics: • The passed integer type IOCntrl parameter is not to be operatedon as an integer, but just as a control information that can be evaluated. • For example, IOCntrl of 3 does not mean 1 + 2, even though 1+2 =3 and read followed by write may be the same as update. (But think of 2+1 = 3)

22. What’s pre-condition and post-condition? • Pre-condition : state of the system or the component or the entity that must be true prior to the “operation” of interest. • Only consider the attribute (or “state”) that matters • e.g. The input coming in from the fingerprint scanner is indeed “valid” [e.g. meaning “input is “90% digitizable”] prior to evoking the fingerprint digitizer function. • Post-Condition: state of the system or the component or the entity that must be true at the conclusion of the “operation” of interest. • Only the consider the attribute (or state) that matters • e.g. digitized fingerprint is produced In stating the pre and post condition, we have also been forced to think of error or alternative conditions --- if the input is valid, the digitizer will NOT fail ----- regardless of any other reason?

23. How do we attach many of the “textual” information to the graphical design notation? • For UML use: • Notes • Extensions

24. Some “COMMON” UML concepts/notations for design • Note: any explanation, in text form, attached to a model element; this is helpful in explaining the design, especially the design for non-functional requirements • UML notation is a “dog-eared” box connected to the model element by a dashed line • Extensions: a mechanism to extend the notations of UML elements to further characterize the design of the element • Constraint is a restriction on the design element written as text inside {- - - } in UML. • Properties is an attribute of a design element written as tagged values inside { tag = value} in UML. If tag has a Boolean value of true, then just the tag without the value can suffice. (e.g. {constant}) • Stereotype is an additional explanation about the modeled element to give more meaning. It is written in text form as keywords in side <<keyword>> in UML notation. (Some use this to explain the level of perspective of the design element) Constraints, Properties, and Stereotype extensions may be placed next to the applicable element. If it applies to multiple design elements, then a dashed line may be used to connect the extension to multiple elements

25. More “COMMON” concept/notation : Dependency • A Dependency: is a binary relationship between 2 elements such that changes to one (independent) element may cause changes to the other (dependent) element. (e.g.) • A uses B • A compiles with B • A imports data from B • A dashed arrow is used to portray dependencies in UML (points from the dependent to the independent entity) {regional} {regional} sales expenses <<imports>> <<imports>> {HQ} • - {regional} and {HQ} are properties • - <<imports>> is a stereotype • - {net =*.xx} is a constraint/property • dog-eared explanation is a note • about the algorithm( ) accounting net: real {net = *.xx} Adds all sales and subtracts all expenses algorithm( ) Note: { - - -} used for both property and constraint

26. Logical and Physical Architecture • In the example of fingerprint matching architectural design, both logical and physicalentities were mixed in the diagram. • To be clearer, we sometimes differentiate the two as: • Logical Architecture • A configuration of the major components and their relationships to one another at the abstract level • Physical Architecture • A configuration of the components and their relationships to each other at the realization level (as code and data residing on and executing on physical computational resources).

27. Logical Architecture Represented with Package and Component Diagrams • A Package is a collection of model elements that represent a grouping of logical constructs (components) where • the elements of a Package (logical grouping) should be “related” • the relationships among the elements should be shown • A Component is a reusable & replaceableconstruct which is used as a member of a package or as a self standing entity by itself. As such it has the following characteristics • The details of its internals are often hidden • ** The interfaces must be “extremely” clear (well defined) This is key

28. UML Diagrams of Package Designfor grouping of related entities A Financial app Basic Package symbol, with a tab A Package A composed of Package B and Package C, each with its elements - note the difference in representing composition in Package B and Package C B C A relationship of Package A uses Package K A K <<uses>> financial regulatory

29. UML Diagram of Component Designfor Reusable and/or Replaceable Component <<component>> MathPack MathPack Two ways to denote component <<component>> StatsPack Provided interface to be “called” by others <<component>> MathPack Required interface to “call” others component MathPack uses the required interface to access the provided interface of StatsPack component <<component>> MathPack <<component>> StatsPack

30. Modeling the constituents of a Component <<component>> DrawFigures <<delegate>> Draw2D Draw3D ScreenDisplay <<delegate>> UnZipData ZippedData The delegate connectorties the component interface to one or more internal Components (in this case --- to UnZipData internal component)

31. interface Drawfigures { public unZipData( ); public pict draw_meth ( ) ; } class Draw2D implements Drawfigures { . . . } Class Draw3D implements Drawfigures { . . . } class Drawfigures { . . protected unzipd data . public void unzip (zipd x, int cntrl ) ; protected Draw2D ( ); protected Draw3D ( ); . } Component Design can/may already influence implementation ( B – more likely single Class implementation) ( A – java language interface implementation )

32. Alternative ways to Specify Component << component>> OrderProc << provided interf.>> OrderEntry << required interf.>> InventoryProc InventoryProc OrderEntry << component>> OrderProc These 2 diagrams portray the same concept OrderProc component provides the interface for OrderEntry and requires the interface to InventoryProc by some other component.

33. Component Interface “forms” • What forms do these interface come in? • Transfer of control • Transfer of information • More specifically? • Protocol (e.g. network) • Database linkage (e.g. SQL link between app and db) • Procedure calls (e.g. invoking a method) • Shared variable access (e.g. “global” variable) • Buffers (e.g. I/O buffers, paging) • Table entries (e.g. shared db table) Are we constrained by the “implementation” language and “middleware” language ?

34. More items to consider for Component Interface • How do we specify certain properties about the component interfaces ? • Is the communications always one way from component A to component B; what do we do if we care about two way communications? • What do we do about synching--- if component A wants to send data to component B but B isnot ready; do we have to define a “buffer’ for resend? • What if the material component A sends to component B is not understood by component B; should there be error messages and retry - - - and how many retries? • ** What do we do about the “required” interface if there needs to be more than one or if it changes** ? If more interested in this topic ---- search on the topic “software connectors” Also, think about “coupling” both static and dynamic cases

35. Physical Architecture • Physical architecture is a representation of the design entities in terms of artifacts residing on nodeswhere: • Artifacts are physical representation of logical entities produced – documents, code, messages, database tables, screens, etc. • Nodes are computational resources such as a device or an execution environment: • Devices may be printers, cpu, controller, etc. • Execution environment may be a db system, os, etc. This definition makes sense to you ? <<db artifact>> AccntTable Artifact notation for an AccntTable, a db table <<device>> HP100:printer Node notation for a device named HP100 of type printer

36. UML Deployment Diagram to RepresentPhysical Architecture • A Deployment Diagram shows: • Computational resource (nodes) • Communication path between computational resources • Artifacts that reside and execute on the computational resources <<device>> HP3100:ServerPC <<CPU device>> IBM201: Server <<TCP/IP>> <<artifact>> AppCode << data base syst.>> Oracle12:db <<artifact>> AppData <<artifact>> DataTable <<TCP/IP>> <<device>> ClientPC <<artifact>> ScreenBrowser