System Design and Architecture

Transcription

1 System Design and Lecture 7 Software Engineering TDDC88/TDDC93 Autumn 2008, David Broman Department of Computer and Information Science Linköping University, Sweden

2 Theory Lecture Plan 2 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

3 A Software Life-cycle Model Which part will we talk about today? Maintenance 3 Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) 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) Implementation of Units (classes, procedures, functions) Unit testing Project Management, Software Assurance (SQA), Supporting Tools, Education Software I II V

4 Agenda - What will you learn today? 4 Software s I II V Software I II V

5 5 Software s Software I II V

6 Why should we design a system? 6 Carol the customer Requirements Why not? Harry the hacker Implementation Software I II V

7 Constructing a building... 7 I need a tower, with a big clock... Ulla The king's requirements Construction Software I II V

8 Constructing a building... 8 Ulla The king's requirements Construction Software I II V

9 Constructing software... 9 Software is different No physical natural order of construction (e.g. start with the foundation of the house) Software is not tangible Carol the customer Requirements Harry the hacker Implementation Software I II V

10 Constructing software Abstraction System Design (, High-level Design) Fuzzy distinction Sometimes several levels Sometimes only one level Module Design (Program Design, Detailed Design) Carol the customer Requirements Harry the hacker Implementation Software I II V

11 Why design and document software architectures? 11 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. Large-scale reuse If similar system have common requirements, modules can be identified and reused. (Bass et.al., 2003) Software I II V

12 Beehive Exercise 5 minutes beehive! An architecture document is not written for its own sake. It should be written from the point of its readers. 12 Stakeholder Developers Discuss in pairs Which are the potential stakeholders? In what way will they use the architecture document?. Use of the architect document Software I II V

13 Possible Solution? 13 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. Software I II V

14 Analyze and Synthesis 14 Problem The process of Analysis Sub-problem 1 Sub-problem 2 Sub-problem 3 Sub-problem 4 solution 1 solution 2 solution 3 solution 4 The process of Synthesis Solution Classical Divide and Conquer strategy... Software I II V

15 Analyze and Synthesis a system (decompose and compose) 15 Imagine a "virtual" System a "concrete" System Requirements Acceptance Test (Release testing) System Design (, High-level Design) Divide into "virtual" modules "concrete" modules System Testing (Integration testing of modules) Module Design (Program Design, Detailed Design) Design each module Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing Software I II V

16 Analyze and Synthesis a system (decompose and compose) 16 Requirements System Design (, High-level Design) Imagine a "virtual" System a "concrete" System Acceptance Test (Release testing) Design is an iterative process! Throw away Prototyping Divide into "virtual" Evolutionary Prototyping "concrete" modules modules System Testing (Integration testing of modules) Module Design (Program Design, Detailed Design) Design each module Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing Software I II V

17 Box-and-line diagrams Encryption / Decryption Logging Module, Subsystem, Element, Entity, Component... (many names) Packet Handler Session Handler Relationship Interface Identification & Authentication User Database Software I II V

18 What time are we talking about? 18 Development time elements Run-time elements Deployment time elements Cryptographic Module Server On different machines? CPUs? Client Classes? Packages? Modules? Functions? Different sub-systems? Objects? One machine? Software I II V

19 Coupling - dependency between modules 19 Uncoupled - no dependeces Loosely coupled - few dependencies Highly coupled - many dependencies What do we want? Low coupling. Why? Replaceable Enable changes Testable - isolate faults Understandable Concurrent design Software I II V

20 Cohesion - relation between internal parts of the module 20 Low cohesion - the parts e.g. functions have less or nothing in common. Medium cohesion - some logically related function. E.g. IO related functions. What do we want? High cohesion. Why? More understandable Easier to maintain High cohesion - does only what it is designed for Software I II V

21 21 I Software I II V

22 Several factors - sometimes overlap 22 Non-functional requirements... Portability Modifiability Reliability Maintainability Scalability Availability Performance Safety Testability Usability Software I II V

23 Performance - timing 23 Timing Throughput Response time (interactive system) Can our architecture be parallelized? Scale up... Scale out... Software I II V

24 Safety - absence of critical faults 24 How can we validate that a safety critical system is correct? Formal validation? Testing? The whole system Critical Design so that all safety critical operations are located in one or few modules / subsystems. Software I II V

25 Modifiability - cost of change 25 What can change? Platform? Function? Protocols? Environment? Portability OS (UNIX, Windows, Realtime OS, Mac,... Memory consumption CPU Computation power When can change? Source code? Compiler option? Library? Setup config? At runtime? Maintainability Low coupling Consistent with code Enough details Software I II V

26 Testability 26 At least 40% of the cost of well-engineered system is due to testing (Bass et. al., 2003) Control Observe Input Output Internal state What about cohesion and coupling? Software I II V

27 Some Business Qualities 27 Time-to-market Cost-and-benefits Reuse component and use commercialoff-the-self (COTS) products Use technology that the organization knows Software I II V

28 28 II Software I II V

29 Pipes and Filters 29 Pipes Input Filters Output Examples lexer parser semantic analysis Intermediate Code Generation Optimization ls -R grep ".exe$" sort ls grep sort Software I II V

30 Pipes and Filters - Beehive 30 Pipes Input Filters Output 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

31 Layers 31 layer 3 layer 3 layer 1 layer 2 Defined layer 2 Increasing Interfaces layer 1 Abstraction Examples Application Presentation FTP Application FTP Session Transport TCP/UDP Transport TCP/UDP Network IP Network IP Data link Physical Ethernet Data link Ethernet OSI -model TCP-stack Software I II V

32 Layers - Beehive 32 Encrypted files Authentication Key mgmnt Defined layer 3 layer 2 Increasing Interfaces layer 1 Abstraction Pros Easy reuse of layers Support for standardization Dependencies are kept local - modification local to a layer Supports incremental development and testing Cons Could give performance penalties Software I II V

33 Process control 33 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 Software I II V

34 Blackboard 34 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

35 Example of blackboard datastructure 35 Source: Software I II V

36 Interpreters 36 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

37 Hierarchical Composition of a Modelica Model of an industrial Robot k2 37 i qddref qdref 1 S qref 1 S k1 i r3control r3motor r3drive1 1 cut joint qd tn axis6 axis5 q: angle qdref Kd 0.03 S rel qref psum - Kv sum w Sum - rate2 b(s) a(s) rate S iref Jmotor=J spring=c fric=rv0 gear=i joint=0 S axis4 axis3 q Rd2=100 Ri= Srel = n*n' + (identity(3) - n*n')*cos(q) + - skew(n)*sin(q); + diff + pow er OpI fa = Srel'*fb; Introduction ta = Srel'*tb; to Software rate1 b(s) a(s) tacho2 b(s) a(s) tacho1 PT1 Vs qd Rd3=100 hall2 I g2 Rd1=100 wrela = n*qd; zrela = n*qdd; Rd4=100 Sb = Sa*Srel'; r0b = r0a; g3 vb = Srel*va; g1 wb = Srel*(wa + wrela); ab = Srel*aa; zb = Srel*(za + zrela + cross(wa, wrela)); qd Rp2=50 C=0.004*D/w m g5 Rp1=200 Ra=250 La=(250/(2*D*w m)) emf w r II q hall1 g4 axis2 axis1 y x inertial V

38 Client-Server 38 Client Client Client The clients need to be aware of the server. Server Clients initiate communication I II V Software

39 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 + Distribute workload on clients - System management problem, update software on clients Three-Tier Client Presentation layer Middle-ware Server Business Layer Data management 39 + Map each layer on separate hardware + Possibility for load-balancing Software I II V

40 40 V I II V Software

41 Not only one way to do it 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. I II V Software

42 When to document? 42 Initial design Design iterations After implementation (consistent with code?) design Time implementation requirements I II V Software

43 What to document? 43 System Overview Different structural Views Development time elements Run-time elements Deployment time elements Cryptographic Module Server On different machines? Client CPUs? Classes? Packages? Modules? Functions? Different sub-systems? Objects? One machine? I II V Software

44 What to document? 44 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) Mapping between views Description of all relations / dependencies Detailed description of interfaces. I II V Software

45 What to document? 45 System Overview Different structural Views Views give structural information Need to describe behavior View diagram View description Sequence Diagram State Charts Mapping between views Behavior I II V Software

46 What to document? 46 System Overview Different structural Views View diagram View description Mapping between views Behavior Rationale 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. In general Why a decision was made What the implication is to change it I II V Software

47 Summary - What have we learned today? 47 Software s I II V I II V Software

48 Further reading 48 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 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 I II V Software