1 / 14

Overview: Software System Architecture Software System Test

Overview: Software System Architecture Software System Test. Mike O’Dell Based on an earlier presentation by Bill Farrior , UTA, modified by Mike O’Dell. What is System Design?. A progressive definition of how a system will be constructed:

taya
Télécharger la présentation

Overview: Software System Architecture Software System Test

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Overview:Software System ArchitectureSoftware System Test Mike O’Dell Based on an earlier presentation by Bill Farrior, UTA, modified by Mike O’Dell

  2. What is System Design? • A progressive definition of how a system will be constructed: • Guiding principles/rules for design (Meta-architecture) • Top-level structure, design abstraction (Architecture Design) • Details of all lowest-level design elements (Detailed Design) CSE 4317

  3. What is Software Architecture? • A critical bridge between what a system will do/look like, and how it will be constructed • A blueprint for a software system and howit will be built • An abstraction: a conceptual model of what must be done to construct the software system • It is NOT a specification of the details of the construction CSE 4317

  4. What is Software Architecture? • The top-level breakdown of how a system will be constructed: • design principles/rules • high-level structural components • high-level data elements (external/internal) • high-level data flows (external/internal) • Discussion: Architectural elements of the new ERB CSE 4317

  5. System Architecture Design Process • Define guiding principles/rules for design • Define top-level components of the system structure (“architectural layers”) • Define top-level data elements/flows (external and between layers) • Deconstruct layers into major functional units (“subsystems”) • Translate top-level data elements/flows to subsystems CSE 4317

  6. Layers/Services: application: supporting network applications ftp, smtp, http transport: host-host data transfer tcp, udp network: routing of datagrams from source to destination ip, routing protocols link: data transfer between neighboring network elements E.g., Ethernet, 802.11 WLAN physical: bits “on the wire” application transport network link physical Layer Example: The Internet Protocol Stack Architecture 1: Introduction

  7. ICMP protocol • error reporting • router “signaling” • IP protocol • addressing conventions • datagram format • packet handling conventions • Routing protocols • path selection • RIP, OSPF, BGP routing table Subsystem Example: The Internet Network Layer Transport layer: TCP, UDP Network layer Link layer Physical layer 4: Network Layer

  8. (PCF) (DCF) 1-2 Mbps Infrared, or 2.4-2.5 GHz Freq. hopping or DSSS (1997) 54 Mbps 5-6 GHz OFDM 802.11a (1999) 11 Mbps 2.4-2.5 GHz DSSS 802.11b (2000) 54/108 Mbps 2.4-2.5 GHz OFDM 802.11g/g+ (2003) 248 Mbps (2x2) 2.4/5 GHz MIMO w/ spacial mpx 802.11n (2008) Subsystem Example: IEEE 802.11 Architecture (Link Layer) Polling mode CSMA/CA mode 6: Wireless and Mobile Networks

  9. duration depends on MAC load type duration depends on network condition MAC frame: Control, management , data + headers(size depends on frame load and type) PCF: Point Coordination Function (asynchronous, connectionless access) DCF: Distributed Coordination Function (connection oriented access) DIFS: DCF Inter Frame Space (minimum delay for asynchronous frame access) PIFS: PCF Inter Frame Space (minimum poll timing interval) SIFS: Short IFS (minimum timing for high priority frame access as ACK, CTS, MSDU…) MSDU: MAC Service Data Unit Reference: W. Stallings: Data and Computer Communications, 7th ed IEEE 802.11 MAC (Detailed Design) Timing in Basic Access 6: Wireless and Mobile Networks

  10. Criteria for a Good Architecture(The Four I’s) • Independence – the layers are independent of each other and each layer’s functions are internally-specific and have little reliance on other layers. Changes in the implementation of one layer should not impact other layers. • Interfaces/Interactions – the interfaces and interactions between layers are complete and well-defined, with explicit data flows. • Integrity – the whole thing “hangs together”. It’s complete, consistent, accurate… it works. • Implementable – the approach is feasible, and the specified system can actually be designed and built using this architecture. CSE 4317

  11. How do you Document a Software Architecture? • Describe the “rules” : meta-architecture • guiding principles, vision, concepts • key decision criteria • Describe the layers • what they do, how they interact with other layers • what are they composed of (subsystems) CSE 4317

  12. How do you Document a Software Architecture? • Describe the data flows between layers • what are the critical data elements • provider subsystems (sources) and consumer subsystems (sinks) • Describe the subsystems within each layer • what does it do • what are its critical interfaces of the subsystem, within and external to its layer • what are its critical interfaces outside the system CSE 4317

  13. Final Thoughts – Verification System Definition DDS: Detailed Design Specification SRD: System Requirements ADS: Architecture Specification Implementation MAP: All Module Interfaces & Interactions MAP: All Subsystem & Layer Interfaces & Interactions MAP: All Specified Requirements MAP: All Modules System Validation Test Integration Test Unit Test Component Test (a.k.a. Function Test) System Verification CSE 4317

  14. Final Thoughts – Verification • Unit Test: verifies that EVERY module (HW/SW) specified in the DDS operates as specified. • Component/Function Test: verifies integrity of ALL inter-module interfaces and interactions. • Integration Test:verifies integrity of ALL inter-subsystem interfaces and interactions. • System Verification Test: verifies ALL requirements are met. CSE 4317

More Related