System Design and Architecture

Transcription

1 Theory Lecture Plan 2 System Design and Lecture 7 Software Engineering TDDC88/TDDC93 Autumn 2008, David Broman Department of Computer and Information Science Linköping University, Sweden L1 - Course Introduction and Overview L2 - Project Management L3 - Requirements L4 - Acceptance Testing and L5 UML L6 - Design Patterns L7 - System Design design and architecture L8 - Testing Theory L9 - Testing in Practice L10 - Inspection L11 - Software Life Cycles and Configuration Management L12 - Software Management L13 - Course Summary, Exam examples, Questions Software I II V A Software Life-cycle Model Which part will we talk about today? 3 Maintenance Agenda - What will you learn today? 4 Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) Software s I System Design (, High-level Design) Verify System Design System Testing (Integration testing of modules) Module Design (Program Design, Detailed Design) Verify Module Design Verify Implementation Module Testing (Integration testing of units) II V Implementation of Units (classes, procedures, functions) Unit testing Project Management, Software Assurance (SQA), Supporting Tools, Education Software I II V Software I II V 1

2 5 Why should we design a system? 6 Software s Carol the customer Requirements Why not? Harry the hacker Implementation Software I II V Software I II V Constructing a building... 7 Constructing a building... 8 I need a tower, with a big clock... Ulla Ulla The king's requirements Construction The king's requirements Construction Software I II V Software I II V 2

3 Constructing software... 9 Constructing software Carol the customer Requirements Software is different No physical natural order of construction (e.g. start with the foundation of the house) Software is not tangible Harry the hacker Implementation Abstraction Carol the customer Requirements System Design (, High-level Design) Module Design (Program Design, Detailed Design) Fuzzy distinction Sometimes several levels Sometimes only one level Harry the hacker Implementation Software I II V Software I II V Why design and document software architectures? Communication between stakeholders A high-level presentation of the system. Use for understanding, negotiation and communication. Early design decisions Profound effect on the systems quality attributes, e.g. performance, availability, maintainability etc. 11 Beehive Exercise Stakeholder Developers 5 minutes beehive! An architecture document is not written for its own sake. It should be written from the point of its readers. Discuss in pairs Which are the potential stakeholders? In what way will they use the architecture document?. Use of the architect document 12 Large-scale reuse If similar system have common requirements, modules can be identified and reused. (Bass et.al., 2003) Software I II V Software I II V 3

4 Possible Solution? 13 Analyze and Synthesis 14 Stakeholder Use of the architect document Requirements engineers Negotiate and make tradeoffs among requirements Architects/Designers Resolve quality issues (e.g. performance, maintainability etc.) Architects/Designers A tool to structure and analyze the system Designers Design modules according to interfaces Developers Get better understanding of the general product Testers and Integrators Specify black-box behavior for system testing Managers Create teams that can work in parallel with e.g. different modules. Plan and allocate resources. New software engineers To get a quick view of what the system is doing assurance team Make sure that implementation corresponds to architecture. Problem Sub-problem 1 Sub-problem 2 Sub-problem 3 Sub-problem 4 solution 1 solution 2 solution 3 solution 4 Solution The process of Analysis The process of Synthesis Classical Divide and Conquer strategy... Software I II V Software I II V Analyze and Synthesis a system (decompose and compose) 15 Analyze and Synthesis a system (decompose and compose) 16 Requirements System Design (, High-level Design) Imagine a "virtual" System Divide into "virtual" modules a "concrete" System "concrete" modules Acceptance Test (Release testing) System Testing (Integration testing of modules) Imagine a "virtual" System a "concrete" System Requirements Acceptance Test (Release testing) Design is an iterative process! Throw away Prototyping System Design Divide into "virtual" Evolutionary Prototyping System Testing (, "concrete" (Integration testing of modules) modules High-level Design) modules Module Design (Program Design, Detailed Design) Design each module Module Testing (Integration testing of units) Module Design (Program Design, Detailed Design) Design each module Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing Implementation of Units (classes, procedures, functions) Unit testing Software I II V Software I II V 4

5 Box-and-line diagrams What time are we talking about? 18 Encryption / Decryption Logging Module, Subsystem, Element, Entity, Component... (many names) Development time elements Run-time elements Deployment time elements Packet Handler Session Handler Relationship Cryptographic Module Server Interface On different machines? CPUs? Identification & Authentication User Database Classes? Packages? Modules? Functions? Client Different sub-systems? Objects? One machine? Software I II V Software I II V Coupling - dependency between modules 19 Cohesion - relation between internal parts of the module 20 Uncoupled - no dependeces Highly coupled - many dependencies Software I Loosely coupled - few dependencies II What do we want? Low coupling. Why? Replaceable Enable changes Testable - isolate faults Understandable Concurrent design V Low cohesion - the parts e.g. functions have less or nothing in common. High cohesion - does only what it is designed for Software I Medium cohesion - some logically related function. E.g. IO related functions. What do we want? High cohesion. Why? More understandable Easier to maintain II V 5

6 21 Several factors - sometimes overlap 22 Non-functional requirements... I Portability Modifiability Reliability Maintainability Scalability Availability Performance Safety Testability Usability Software I II V Software I II V Performance - timing 23 Safety - absence of critical faults 24 Timing Throughput Response time (interactive system) How can we validate that a safety critical system is correct? Formal validation? Testing? Can our architecture be parallelized? The whole system Scale up... Critical Scale out... Design so that all safety critical operations are located in one or few modules / subsystems. Software I II V Software I II V 6

7 Modifiability - cost of change 25 Testability 26 What can change? Platform? Function? Protocols? Environment? Portability OS (UNIX, Windows, Realtime OS, Mac,... Memory consumption CPU Computation power At least 40% of the cost of well-engineered system is due to testing (Bass et. al., 2003) Control Observe When can change? Source code? Compiler option? Library? Setup config? At runtime? Maintainability Low coupling Consistent with code Enough details Input Internal state Output What about cohesion and coupling? Software I II V Software I II V Some Business Qualities Time-to-market Reuse component and use commercialoff-the-self (COTS) products Cost-and-benefits Use technology that the organization knows II Software I II V Software I II V 7

8 Pipes and Filters 29 Pipes and Filters - Beehive 30 Pipes Input Filters Output Pipes Input Filters Output Examples lexer parser semantic analysis Intermediate Code Generation Optimization ls -R grep ".exe$" sort ls grep sort Pros Understandable, easy to reason about, in-out Extendable - easy to add / remove filters Easy to simulate and analyze properties, e.g. throughput Concurrent execution Cons Limited to batch processing (not good for interactive apps) Duplicated execution, e.g. format checking Error handling Software I II V Software I II V Layers 31 Layers - Beehive 32 layer 1 layer 2 layer 3 Defined Interfaces layer 3 layer 2 layer 1 Increasing Abstraction Encrypted files Authentication Key mgmnt Defined Interfaces layer 3 layer 2 layer 1 Increasing Abstraction Examples Application Presentation Session Transport FTP TCP/UDP Application Transport FTP TCP/UDP Pros Easy reuse of layers Support for standardization Cons Could give performance penalties Network Data link IP Network IP Dependencies are kept local - modification local to a layer Physical OSI -model Ethernet TCP-stack Data link Ethernet Supports incremental development and testing Software I II V Software I II V 8

9 Process control 33 Blackboard 34 A software realisation of an independent control system. The controller maintains a set point for a variable by changing input to a process. Good separation of concerns. Example: Air Condition Needs caution when: selecting variables measuring variables selecting algorithm handling exceptions A development of database repository architecture. Knowledge sources post data in a common repository. The respository processes shared data and can invokate processes in knowledge sources Example: Military intelligence system Advantages: Supports incremental development Easy to change knowledge sources Difficulty: Create a suitable and general knowledge representation. Software I II V Software I II V Example of blackboard datastructure 35 Interpreters 36 Source: Transforms pseudocode into a instructions for a simulator. Example: Simulation of mathematical models. Advantages: Allows users to express themselves in more natural terms. Supports creation of domainspecific languages Problem: Performance Software I II V Software I II V 9

10 Hierarchical Composition of a Modelica Model of an industrial Robot Client-Server k2 i qddref qdref 1 S qref 1 S k1 i r3control r3motor r3drive1 1 cut joint qd tn axis6 axis5 Client Client Client q: angle qdref Kd 0.03 S rel qref psum - Kv sum w Sum - rate1 b(s) a(s) rate2 b(s) a(s) tacho2 b(s) a(s) rate S tacho1 PT1 iref Jmotor=J spring=c fric=rv0 gear=i joint=0 S axis4 axis3 The clients need to be aware of the server. Server Clients initiate communication g5 axis2 q Rd2=100 Srel = n*n' + (identity(3) - n*n')*cos(q) + - skew(n)*sin(q); + diff + pow er wrela = n*qd; OpI zrela = n*qdd; Rd4=100 Sb = Sa*Srel'; emf r0b = r0a; g3 vb = Srel*va; g1 wb = Srel*(wa + wrela); ab = Srel*aa; zb = Srel*(za + zrela + cross(wa, wrela)); hall1 w r I II fa = Srel'*fb; Introduction ta = Srel'*tb; to g4 g2 qd q Software Vs qd Rd3=100 hall2 Rd1=100 - Ri=10 C=0.004*D/w m - Rp2=50 Rp1=200 - Ra=250 La=(250/(2*D*w m)) axis1 y x inertial V Software I II V Client-Server Two-Tier, Thin-client Client Presentation layer Server Business Layer Data management - Heavy load on server - Significant network traffic Two-Tier, Fat-client Client Presentation layer Server Business Layer Data management Three-Tier Client Presentation layer Middle-ware Server Business Layer Data management + Distribute workload on clients - System management + Map each layer on separate problem, update software hardware on clients + Possibility for load-balancing V Software I II V Software I II V 10

11 Not only one way to do it When to document? 42 Write from the point of view of the readers... Stakeholder Use of the architect document Requirements engineers Negotiate and make tradeoffs among requirements Architects/Designers Resolve quality issues (e.g. performance, maintainability etc.) Architects/Designers A tool to structure and analyze the system Designers Design modules according to interfaces Developers Get better understanding of the general product Testers and Integrators Specify black-box behavior for system testing Managers Create teams that can work in parallel with e.g. different modules. Plan and allocate resources. New software engineers To get a quick view of what the system is doing assurance team Make sure that implementation corresponds to architecture. Time Initial design requirements Design iterations design implementation After implementation (consistent with code?) Software I II V Software I II V What to document? 43 What to document? 44 System Overview Different structural Views Development time elements Cryptographic Module Run-time elements Server Deployment time elements System Overview Different structural Views View diagram View description Encryption / Decryption A Packet Handler B Session Handler Catalog with detailed description of all elements (modules, subsystems) Classes? Packages? Modules? Functions? Client Different sub-systems? Objects? On different machines? CPUs? One machine? Mapping between views Description of all relations / dependencies Detailed description of interfaces. Software I II V Software I II V 11

12 What to document? 45 What to document? 46 System Overview Different structural Views View diagram View description Mapping between views Views give structural information Need to describe behavior Sequence Diagram State Charts System Overview Different structural Views View diagram View description Mapping between views Why the architecture is the way it is Rationales for views, interfaces, etc. implication due to certain requirements Expected effect when changing requirements or adding new ones Constraints for the developer when implementing the solution Design alternatives that were rejected and the rational for doing so. Behavior Behavior Rationale In general Why a decision was made What the implication is to change it Software I II V Software I II V Summary - What have we learned today? 47 Further reading 48 Software s I Len Bass, Paul Clements, and Rick Kazman, Software in Practice, Second Edition, ISBN , Pearson Eduction, Inc, Boston, USA, 2003 Frank Buschmann et. al. Pattern-Oriented Software Volume 1: A system of patterns, ISBN , John Wiley & Sons Ltd, England, 1996 II V Ian Sommerville, Software Engineering 8th edition, ISBN , Addison- Wesley, 2006 Shari Lawrence Pfleeger and Joanne M. Atlee, Software Engineering Theory and Practice, 3rd edition, ISBN , Pearson Education International, 2005 Software I II V Software I II V 12