UML for Embedded Systems Development—Extensions; Hardware-Software CoDesign

1. UML for Embedded Systems Development—Extensions; Hardware-Software CoDesign

2. table_05_00 * * * table_05_00 * *

3. Encounters an error condition Arms/disarms system Responds to alarm event Use case: requirements specifications Graphical description:Text description: Use case name Participating actors Flow of events Entry condition(s) Exit condition(s) Quality requirements Homeowner Accesses system via internet Sensors System administrator Reconfigures sensors and related system features (Pressman, p. 163, Figure 7.3)

4. Use case writing guide: --each use case should be traceable to requirements --name should be a verb phrase to indicate user goal --actor names should be noun phrases --system boundary needs to be clearly defined --use active voice to describe flow of events, make clear who does what --make sure the flow of events describes a complete user transaction ---if there is a dependence among steps, this needs to be made clear --describe exceptions separately --DO NOT describe the user interface to the system, only functions --DO NOT make the use case too long—use extends, includes instead --as you develop use cases, develop associated tests

5. Class and object diagrams: Identify Objects from Use Case Specifications: USE ENDUSER’s TERMS AS MUCH AS POSSIBLE Entity objects: “things”, for example: --nouns (customer, hospital, infection) --real-world entities (resource, dispatcher) --real-world activities to be tracked (evacuation_plan) --data sources or sinks (printer) Boundary objects: system interfaces, for example: --controls (report(emergencybutton) --forms (savings_deposit_form) --messages (notify_of_error) Control objects: usually one per use case --coordinate boundary and entity objects in the use case Use the identified objects in a sequence diagram to carry out the use case

6. fig_05_03 Things in the system: classes / objects fig_05_03

7. fig_05_04 Example: classes fig_05_04

8. fig_05_07 Example: classes—container (“has-a”) relation fig_05_07

9. Example: sequence diagram—how classes work together to support a use case goal fig_05_11 fig_05_11

10. fig_05_12 fig_05_12

11. fig_05_13 Example: activity diagram—flow of control fig_05_13

12. fig_05_16 State diagrams--options fig_05_16

13. fig_05_18 Example: state diagrams fig_05_18

14. Note: UML was developed for modeling software. For modeling embedded systems, there are additional behaviors that must be addressed. G. Martin, CADENCE, DATE 2002: --Embedded systems are composed of multiple subsystems or functional units --These components carry out computation and communication tasks using a heterogeneous set of models of computation --Components may be implemented in a variety of ways, combining hardware and software --Mapping of function to architecture is not fixed; “design space exploration” is important for optimization --High-level system modeling and delay of commitment to particular components until late in the design cycle is desirable

15. Embedded systems are heterogeneous: Multiple domains: --signal processing, --wired and wireless communications, traditional data processing Multiple computing models: --continuous time --finite-state-machine --Data flow --Discrete event --Reactive Multiple physical implementations: --Dataflow and control-oriented software --Microprocessors --DSPs --Analog and mixed-signal components --Digital hardware blocks --RF, optical, and MEMS components

16. Embedded systems are “compositional”: Typical embedded system is composed from subsystems which are based on different computational models Both functional and architectural compositions must be carried out Thus validity of how system is composed is as important as whether each module is correct Embedded systems are too complex to design from scratch: Moving from generation N to N+1 typically increases complexity by an order of magnitude Complexity requires more design knowledge than for any one single product Must maximize productivity through use of embedded system platforms, reuse, synthesis based on system-level models

17. System context must also be modeled: Environmental issues: Channel characteristics Noise scenarios Weight Weather Etc. User concerns: Need use cases for multi-function embedded systems

18. Necessary additions: “Platform” model Tools to move from one platform level to another Constraint definition and budgeting methodology to control optimization process in design transformation and synthesis

19. “UML-platform”—components to be added: --“uses” and “needs” relationships to allow platform components to request and receive services from other components --”stack” stereotype to describe hierarchical layered implementations of platform services --”peer” stereotype for components and services at same level --Quality of Service (QoS) tags which can be derived from specifications, mapped into constraints, and used to guide implementation choices [including time deadlines] --defined platform layers for classifying services for deployment: --ASP—application specific programmable --API—application programming interface --ARC—architectural --inclusion of “extension points” for future application requirements and new or variant service offerings

20. Additional issue: Hardware/Software codesign Example system: priority queue example—Hoeg et al, 1994 paper on bbd