© 2000 Morgan Kaufman Overheads for Computers as Components System design techniques zDesign methodologies. zRequirements and specification.

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

© 2000 Morgan Kaufman Overheads for Computers as Components Product metrics zTime-to-market: ybeat competitors to market; ymeet marketing window (back-to-school). zDesign cost. zManufacturing cost. zQuality.

© 2000 Morgan Kaufman Overheads for Computers as Components Mars Climate Observer zLost on Mars in September zRequirements problem: yRequirements did not specify units. yLockheed Martin used English; JPL wanted metric. zNot caught by manual inspections.

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

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

© 2000 Morgan Kaufman Overheads for Computers as Components Waterfall model steps zRequirements: determine basic characteristics. zArchitecture: decompose into basic modules. zCoding: implement and integrate. zTesting: exercise and uncover bugs. zMaintenance: deploy, fix bugs, upgrade.

© 2000 Morgan Kaufman Overheads for Computers as Components Waterfall model critique zOnly local feedback---may need iterations between coding and requirements, for example. zDoesn’t integrate top-down and bottom- up design. zAssumes hardware is given.

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

© 2000 Morgan Kaufman Overheads for Computers as Components Spiral model critique zSuccessive refinement of system. yStart with mock-ups, move through simple systems to full-scale systems. zProvides bottom-up feedback from previous stages. zWorking 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 specify architect design build test refined system

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

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

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

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

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

© 2000 Morgan Kaufman Overheads for Computers as Components Concurrent engineering techniques zCross-functional teams. zConcurrent product realization. zIncremental information sharing. zIntegrated product management. zSupplier involvement. zCustomer focus.

© 2000 Morgan Kaufman Overheads for Computers as Components AT&T PBX concurrent engineering zBenchmark against competitors. zIdentify breakthrough improvements. zCharacterize current process. zCreate new process. zVerify new process. zImplement. zMeasure and improve.

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

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

© 2000 Morgan Kaufman Overheads for Computers as Components Good requirements zCorrect. zUnambiguous. zComplete. zVerifiable: is each requirement satisfied in the final system? zConsistent: requirements do not contradict each other.

© 2000 Morgan Kaufman Overheads for Computers as Components Good requirements, cont’d. zModifiable: can update requirements easily. zTraceable: 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 zCustomer interviews. zComparison with competitors. zSales feedback. zMock-ups, prototypes. zNext-bench syndrome (HP): design a product for someone like you.

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

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

© 2000 Morgan Kaufman Overheads for Computers as Components Statecharts zAncestor of UML state diagrams. zProvided composite states: yOR states; yAND states. zComposite states reduce the size of the state transition graph.

© 2000 Morgan Kaufman Overheads for Computers as Components Statechart OR state S1 S2 S3 S4 i1 i2 traditional S1 S2 S3 S4 i1 i2 OR state s123

© 2000 Morgan Kaufman Overheads for Computers as Components Statechart AND state S1-3S1-4 S2-3S2-4 S5 traditional c d b a r c d b a S1S3 S2S4 S5 AND state c d r b a sab r

© 2000 Morgan Kaufman Overheads for Computers as Components AND-OR tables zAlternate way of specifying complex conditions: cond1 or (cond2 and !cond3) cond1T- cond2-T cond3-F AND OR

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

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

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

© 2000 Morgan Kaufman Overheads for Computers as Components Own-Aircraft AND state CAS Inputs: own-alt-radio: integer standby-discrete-input: {true,false} own-alt-barometric:integer, etc. Effective-SLAlt-SLAlt-layer Climb-inibitDescend-inibit Increase-climb-inibit Increase-Descend-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 zWell-known method for analyzing a system and developing an architecture. zCRC: yclasses; yresponsibilities of each class; ycollaborators are other classes that work with a class. zTeam-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: frontback

© 2000 Morgan Kaufman Overheads for Computers as Components CRC methodology zDevelop an initial list of classes. ySimple description is OK. yTeam members should discuss their choices. zWrite initial responsibilities/collaborators. yHelps to define the classes. zCreate some usage scenarios. yMajor uses of system and classes.

© 2000 Morgan Kaufman Overheads for Computers as Components CRC methodology, cont’d. zWalk through scenarios. ySee what works and doesn’t work. zRefine the classes, responsibilities, and collaborators. zAdd class relatoinships: ysuperclass, subclass.

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

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