Architectural Design: Software Design and Architecture

Architectural Design SWE 3633-Software Design & Architecture  Architecture Design Architecture design is a problem- solving activity whose input is the SRS document and whose output is the “abstract” specification of a software which realizes the desired characteristics ...

Architectural Design SWE 3633-Software Design & Architecture  Architecture Design Architecture design is a problem- solving activity whose input is the SRS document and whose output is the “abstract” specification of a software which realizes the desired characteristics  Architecture Design – cont. Architecture design is a specification of the solution’s major components, their responsibilities and properties, and the relationship and collaboration among the major components.  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 design principles: – Feasibility – Adequacy – Changeability – Economy Requirements (Product Design) Architectural Design Detail Design – Feasibility: During Product Design, we may need to understand the feasibility of some specific architecture – 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  Variations in Architectural Design Not all architectural designs are the same in terms of their level of abstraction: 1. number of components (main components), 2. description of each component 3. relationships among components Deciding on the “right” level of architectural depth has always been a problem.  Two important Considerations: 1. Problem context: the larger the problem the more levels of abstraction, # of components, # of relationships among components 2. Organizational context: more experienced and sophisticated organizations would have more standards, tools, guidelines, and skills invested --- thus may have more pre- determined preference or constraints on the architectural design  Introduction To Architectural Design Architectural Design Process Swft Engr. Design Analyzed Develop Architectural SRS Alternatives SRS Design Analysis Evaluate Architectural Architectural Alternatives Design Select Architectural Detail Design Resolution Design Doc. [else ] [selected ] Finalize Software SAD Architectural Document  Software Architecture Document (SAD) Template 1. Product Overview 2. Architectural Models 3. Mapping between Models 4. Architectural Design Rationale  Software Architecture Document (SAD) 1. Product Overview: summarizes the overall product description, stakeholders and target market descriptions, assumptions and constraints, and the basic business requirements (refer to SRS)  Software Architecture Document (SAD) 2. Architectural Models: presents the architecture in terms of models of data, functional decomposition and functional activities, and system states and transitions (representing different aspects or views (use DeSCRIPTR as a guide).  Software Architecture Document (SAD) 3. Mapping between Models: presents and explains how the different models are related  Software Architecture Document (SAD) 4. 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)  Design of Non-Functional Requirements Major Functional Requirements can be directly mapped into key architectural components, but how about “non- Functional requirements (or attributes)”?  Quality Attributes Operational Attributes Development Attributes  Operational Attributes Performance: time limits, space capacity, transaction limits Operational Attributes – cont. Availability: readiness for use (borders on performance) Operational Attributes – cont. Security: resistance or protection from harm Operational Attributes – cont. Reliability: error resistance and performing to requirements Operational Attributes – cont. Usability: easy to understand and navigate  Developmental attributes Maintainability: easy to understand and modify Developmental attributes –cont. Reusability: portable, easy to modify, loose coupling, etc.  An Example Page 258 - “Finger Print Matching” A program responsible for matching fingerprints read from scanners against a database to allow people into and out of a secure facility.  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.  Fingerprint Matching Software “Design” Fingerprint Reading “matching --- device against a database” Input Fingerprint validation validation “fingerprints read from scanners” Finger Print DB  Fingerprint Matching Software “Design” Example Using Activity Diagram notation Fingerprint Matching Architecture fingerprint input Input validation [bad input] error message [good input] Fingerprint Reading device fingerprint validation Finger Print pass/ Set-up / send message DB no-pass message What about these?  Fingerprint Matching Software “Design” Example Using Activity Diagram Input validation Fing_prt validate Fingerprint input input Reading device [else] Error Error process message [good print] Evoke Digitized F-prt-dig Fing prt Fingerprint validation Digitized Fing prt Pass/No-pass Finger validate Fing_prt F-print message Print table DB Compare this with box-and line diagram on page 265 of text  What about these “non-functional” attributes? 1. “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? What about these “non-functional” attributes? 2. “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? What about these “non-functional” attributes? 3. “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? What about these “non-functional” attributes? 4. “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 to activity diagram  What about Cohesion? Would we have some issues related to “cohesion?” – Input validation: a single related function – Fingerprint validation: a single related function Questions