System design techniques z Design methodologies z Requirements

System design techniques z. Design methodologies. z. Requirements and specification. © 2000 Morgan Kaufman Overheads for Computers as Components

Design methodologies z. Process for creating a system. z. Many systems are complex: ylarge specifications; ymultiple designers; yinterface to manufacturing. z. Proper processes improve: yquality; ycost of design and manufacture. © 2000 Morgan Kaufman Overheads for Computers as Components

Product metrics z. Time-to-market: ybeat competitors to market; ymeet marketing window (back-to-school). z. Design cost. z. Manufacturing cost. z. Quality. © 2000 Morgan Kaufman Overheads for Computers as Components

Mars Climate Observer z. Lost on Mars in September 1999. z. Requirements problem: y. Requirements did not specify units. y. Lockheed Martin used English; JPL wanted metric. z. Not caught by manual inspections. © 2000 Morgan Kaufman Overheads for Computers as Components

Design flow z. Design flow: sequence of steps in a design methodology. z. May be partially or fully automated. y. Use tools to transform, verify design. z. Design flow is one component of methodology. Methodology also includes management organization, etc. © 2000 Morgan Kaufman Overheads for Computers as Components

Waterfall model z. Early model for software development: requirements architecture coding testing maintenance © 2000 Morgan Kaufman Overheads for Computers as Components

Waterfall model steps z. Requirements: determine basic characteristics. z. Architecture: decompose into basic modules. z. Coding: implement and integrate. z. Testing: exercise and uncover bugs. z. Maintenance: deploy, fix bugs, upgrade. © 2000 Morgan Kaufman Overheads for Computers as Components

Waterfall model critique z. Only local feedback---may need iterations between coding and requirements, for example. z. Doesn’t integrate top-down and bottomup design. z. Assumes hardware is given. © 2000 Morgan Kaufman Overheads for Computers as Components

Spiral model system feasibility specification prototype initial system enhanced system design requirements test © 2000 Morgan Kaufman Overheads for Computers as Components

Spiral model critique z. Successive refinement of system. y. Start with mock-ups, move through simple systems to full-scale systems. z. Provides bottom-up feedback from previous stages. z. Working through stages may take too much time. © 2000 Morgan Kaufman Overheads for Computers as Components

Successive refinement model specify architect design build test initial system © 2000 Morgan Kaufman test refined system Overheads for Computers as Components

Hardware/software design flow requirements and specification architecture software design hardware design integration testing © 2000 Morgan Kaufman Overheads for Computers as Components

Co-design methodology z. Must architect hardware and software together: yprovide sufficient resources; yavoid software bottlenecks. z. Can build pieces somewhat independently, but integration is major step. z. Also requires bottom-up feedback. © 2000 Morgan Kaufman Overheads for Computers as Components

Hierarchical design flow z. Embedded systems must be designed across multiple levels of abstraction: ysystem architecture; yhardware and software systems; yhardware and software components. z. Often need design flows within design flows. © 2000 Morgan Kaufman Overheads for Computers as Components

Hierarchical HW/SW flow spec architecture HWSW architecture HW SW detailed design integrate integration testtest system © 2000 Morgan Kaufman hardware software Overheads for Computers as Components

Concurrent engineering z. Large projects use many people from multiple disciplines. z. Work on several tasks at once to reduce design time. z. Feedback between tasks helps improve quality, reduce number of later design problems. © 2000 Morgan Kaufman Overheads for Computers as Components

Concurrent engineering techniques z. Cross-functional teams. z. Concurrent product realization. z. Incremental information sharing. z. Integrated product management. z. Supplier involvement. z. Customer focus. © 2000 Morgan Kaufman Overheads for Computers as Components

AT&T PBX concurrent engineering z. Benchmark against competitors. z. Identify breakthrough improvements. z. Characterize current process. z. Create new process. z. Verify new process. z. Implement. z. Measure and improve. © 2000 Morgan Kaufman Overheads for Computers as Components

Requirements analysis z. Requirements: informal description of what customer wants. z. Specification: precise description of what design team should deliver. z. Requirements phase links customers with designers. © 2000 Morgan Kaufman Overheads for Computers as Components

Types of requirements z. Functional: input/output relationships. z. Non-functional: ytiming; ypower consumption; ymanufacturing cost; yphysical size; ytime-to-market; yreliability. © 2000 Morgan Kaufman Overheads for Computers as Components

Good requirements z. Correct. z. Unambiguous. z. Complete. z. Verifiable: is each requirement satisfied in the final system? z. Consistent: requirements do not contradict each other. © 2000 Morgan Kaufman Overheads for Computers as Components

Good requirements, cont’d. z. Modifiable: can update requirements easily. z. Traceable: yknow why each requirement exists; ygo from source documents to requirements; ygo from requirement to implementation; yback from implementation to requirement. © 2000 Morgan Kaufman Overheads for Computers as Components

Setting requirements z. Customer interviews. z. Comparison with competitors. z. Sales feedback. z. Mock-ups, prototypes. z. Next-bench syndrome (HP): design a product for someone like you. © 2000 Morgan Kaufman Overheads for Computers as Components

Specifications z. Capture functional and non-functional properties: yverify correctness of spec; ycompare spec to implementation. z. Many specification styles: ycontrol-oriented vs. data-oriented; ytextual vs. graphical. z. UML is one specification/design language. © 2000 Morgan Kaufman Overheads for Computers as Components

SDL z Used in telecommunications protocol design. z Event-oriented state machine model. telephone on-hook caller goes off-hook dial tone caller gets dial tone © 2000 Morgan Kaufman Overheads for Computers as Components

Statecharts z. Ancestor of UML state diagrams. z. Provided composite states: y. OR states; y. AND states. z. Composite states reduce the size of the state transition graph. © 2000 Morgan Kaufman Overheads for Computers as Components

Statechart OR state s 123 i 1 S 1 i 1 S 2 S 1 i 2 i 1 S 4 S 2 i 2 S 3 traditional © 2000 Morgan Kaufman S 3 Overheads for Computers as Components OR state i 2 S 4

Statechart AND state sab c S 1 -3 S 1 -4 S 3 d a b b c S 2 -3 r r S 5 AND state Overheads for Computers as Components d S 4 r traditional © 2000 Morgan Kaufman c S 2 -4 d a b a S 5

AND-OR tables z. Alternate way of specifying complex conditions: cond 1 or (cond 2 and !cond 3) OR AND cond 1 cond 2 cond 3 © 2000 Morgan Kaufman T - T F Overheads for Computers as Components

TCAS II specification z. TCAS II: aircraft collision avoidance system. z. Monitors aircraft and air traffic info. z. Provides audio warnings and directives to avoid collisions. z. Leveson et al used RMSL language to capture the TCAS specification. © 2000 Morgan Kaufman Overheads for Computers as Components

RMSL z State description: state 1 z Transition bus for transitions between many states: inputs a state description b c outputs © 2000 Morgan Kaufman d Overheads for Computers as Components

TCAS top-level description CAS power-on Inputs: power-off TCAS-operational-status {operational, not-operational} fully-operational own-aircraft other-aircraft i: [1. . 30] mode-s-ground-station i: [1. . 15] © 2000 Morgan Kaufman Overheads for Computers as Components C standby

Own-Aircraft AND state CAS Inputs: own-alt-radio: integer standby-discrete-input: {true, false} own-alt-barometric: integer, etc. Effective-SL Alt-SL 1 1 2 2 . . . 7 7 Alt-layer Climb-inibit. . . Descend-inibit. . . Increase-Descend-inibit. . . Increase-climb-inibit . . . Advisory-Status Outputs: sound-aural-alarm: {true, false} aural-alarm-inhibit: {true, false} combined-control-out: enumerated, etc. © 2000 Morgan Kaufman Overheads for Computers as Components . . .

CRC cards z. Well-known method for analyzing a system and developing an architecture. z. CRC: yclasses; yresponsibilities of each class; ycollaborators are other classes that work with a class. z. Team-oriented methodology. © 2000 Morgan Kaufman Overheads for Computers as Components

CRC card format Class name: Superclasses: Subclasses: Responsibilities: Collaborators: Class name: Class’s function: Attributes: front © 2000 Morgan Kaufman back Overheads for Computers as Components

CRC methodology z. Develop an initial list of classes. y. Simple description is OK. y. Team members should discuss their choices. z. Write initial responsibilities/collaborators. y. Helps to define the classes. z. Create some usage scenarios. y. Major uses of system and classes. © 2000 Morgan Kaufman Overheads for Computers as Components

CRC methodology, cont’d. z. Walk through scenarios. y. See what works and doesn’t work. z. Refine the classes, responsibilities, and collaborators. z. Add class relatoinships: ysuperclass, subclass. © 2000 Morgan Kaufman Overheads for Computers as Components

CRC cards for elevator z. Real-world classes: yelevator car, passenger, floor control, car sensor. z. Architectural classes: car state, floor control reader, car control sender, scheduler. © 2000 Morgan Kaufman Overheads for Computers as Components

Elevator responsibilities and collaborators © 2000 Morgan Kaufman Overheads for Computers as Components