1. 1 Embedded Systems Software: Modeling and Programming-- The Object-oriented Paradigm and The Unified Modeling Language (UML); Extensions to HW / SW Systems

2. 2 "problems" of software development: **conceptual integrity **incremental build, progressive refinement **large projects "differ" from small ones programming paradigms (1950’s-present): attempts to deal effectively with these problems, make software easier to develop and to maintain Problems of software development

3. 3 1950's:unstructured, no information hiding-- ”spaghetti” code, GOTO, flowcharts --machine code --assembly lang. --FORTRAN, LISP (Algol; COBOL) 1970s,1980s: structured, top-down design (“3 basic control structures, no GOTO”), modularity --Pascal, C, PL/I, Ada 1990’s: encapsulation, information-hiding, reuse, hardware/software codesign (from simulation languages developed much earlier, e.g., Modula, simula) --C++, Java 2000’s: info hiding; web languages; environments encapsulating multiple languages, styles --.NET, C#, Python, Perl, MATLAB, Mathematica, Labview, … A Brief History: Computer Hardware, Computer Languages, Design Techniques Early machines—large, central (Eniac) Supercomputers, “Minicomputers”, PCs, multiuser machines, PICs Beowulf clusters, Spread of the Internet “Ubiquitous computing”, laptops,. Personal communication devices, multicore processors, GPUs wpclipart.com chilton-computing.org.uk techxav.com http://en.wikipedia.org/wiki/PIC _microcontroller#History cse.mtu.edu visual.merriam- webster.com http://t0.gstatic.com/images?q=tbn:ANd9GcS3J9yAV0YibC4keB8M_6hc0xh3sZYbbGKZUK-pHLzx7Lkek74w http://www.amd.com/us-en/assets/content_type/Additional/ 43494A_QuadCore_Opt_Die_BLK_HRes.jpg43494A_QuadCore_Opt_Die_BLK_HRes.jpg textually.org

4. 4 Important basic OO concepts: class: encapsulates data structure (object) and associated methods (functions) these may be declared public / private / protected appropriate uses: public: pass info to object or request info about object (use "messages") (can be used by anyone) private: modify object (can be used in class or by “friends”) protected: for descendants (in class or by derived class and “friends”) OO class

5. 5 traditional: record (struct): functions to use or modify this record can be anywhere in the program OO: class concept supports encapsulation, information hiding Record/class DATA Procedural Prog. OO Prog.

6. 6 Useful OO techniques: Inheritance: ex: in a program modeling an ecosystem, we might have the relationships: wolf is carnivore; sheep is herbivore; grass is plant carnivore is animal; herbivore is animal animal is organism; plant is organism here the base class “organism” holds data fields which apply to all organisms, e.g., amount of water needed to survive two derived classes, plant and animal, hold information specific to each of these types of organisms, e.g., kind of soil preferred by plant the animal class also has two derived classes, wolf and sheep Inheritance allows the collection of common attributes and methods in "base" class and inclusion of more specific attributes and methods in derived classes Inheritance A.A. B.B. Ex: Object data structures: A. Base class B. Derived class XYZXYZ XYZWXYZW

7. 7 Polymorphism: base class can define a “virtual” function; appropriate versions of this function can be instantiated in each derived class (e.g., "draw" in the base class of graphical objects can have its own specific meaning for rectangles, lines, ellipses) Overloading: ex: cin >> num1; >> is overloaded "shift” ex: “+” can be overloaded to allow the addition of two vectors ex: a function name can be overloaded to apply to more than one situation; e.g., a constructor can be defined one way if initial values are given and a different way if initial values are not given Polymorphism and overloading

8. 8 Templates: example: template T method1 (T x) ….. can be specialized:int method1 (int x) float method1 (float y) usertype method1 (usertype a) templates promote reuse Templates

9. 9 Separate compilation: Typically, an object-oriented program can be broken into three sets of components:  definitions and prototypes (text files, “header files”)  implementations (compiled--source code need not be available to user)  application program--uses the classes defined in header files and supported by the implementation files This strategy promotes reuse and information hiding Separate compilation

10. 10 1.Note that no paradigm is misuse-proof 2.DISCUSSION: Is the OO paradigm useful for mixed hardware / software systems? Use / Misuse of object-oriented paradigm

11. 11 Design: “top-down”; Test: “bottom-up” : “Design for testability” determine specifications: use cases system tests determine classes [modules] and connections (static behavior): ER or class diagrams; CRC cards module (“black box”) tests model dynamic behavior: interaction (object message) diagrams activity diagrams state diagrams (fsm’s) sequence diagrams [ individual class methods “white box” or “glass box” tests] Using OO & (a subset of) UML in a project: design; design for testability dynamic module interactions / “boundary” behavior

12. 12 UML: a language for specifying and designing an OO project UML: stands for "unified modeling language” unifies methods of Booch, Rumbaugh (OMT or Object Modeling Technique), and Jacobson (OOSE or Object-Oriented Software Engineering) mainly a modeling language, not a complete development method Early versions -- second half of the 90's Not all methods we will use are officially part of the UML description

13. 13 USE CASES: a part of the ”Unified Modeling Language" (UML) which we will use for requirements analysis and specification each identifies a way the system will be used and the "actors" (people or devices) that will use it (an interaction between the user and the system) each use case should capture some user-visible function and achieve some discrete goal for the user an actual user can have many actor roles in these use cases an instance of a use case is usually called a "scenario” Use case will typically have graphical & verbal forms Use cases

14. 14 Example: cellular network place and receive calls use case (based on Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide) Example use case System boundary Text description --Use case name (cellular network place and receive calls) --Participating actors (cellular network and human user) --Flow of events (network or user accesses network to use its functionality) --Entry condition(s) (user accesses network using device or password) --Exit condition(s) (call completed lost or network busy) --Quality requirements (speed, service quality) Text description—gives important details Use case diagram—summarizes, provides system overview

15. 15 use case Text description: Use case name Participating actors Flow of events Entry condition(s) Exit condition(s) Quality requirements

16. 16 Use case—detailed example (Pressman) Example: “SAFEHOME” system (Pressman) Use case: InitiateMonitoring Participating actors:_______ Flow of events:_______ Entry condition(s):_______ Exit condition(s):_______ Quality requirements:_______ (What is in HW, what is SW?) Arms/disarms system Accesses system via internet Responds to alarm event Encounters an error condition Reconfigures sensors and related system features Homeowner System administrator Sensors Pressman, p. 163, Figure 7.3

17. 17 Use case additions—simplifications of use case descriptions A. Include: one use case includes another in its flow of events (cases A and B both include case C) B.Extend: extend one use case to include additional behavior (cases D and E are extensions of case F) A B C > F E D

18. 18 Use case additions C. Inheritance: one use case specializes the more general behavior of another G and H specialize behavior of J) H J authenticate Authenticate with card Authenticate with password G

19. 19 Use case continued Examples: what would be a hardware use case for the following? What might be a software use case? vending machine traffic light Use case name Participating actors Flow of events Entry condition Exit condition Quality requirements

20. 20 Note: Use cases can form a basis for system acceptance tests For each use case: Develop one or more system tests to confirm that the use case requirements will be satisfied Add explicit test values as soon as possible during design phase These tests are now specifically tied to the use case and will be used as the top level acceptance tests Do not forget use cases / tests for performance and usability requirements (these may be qualitative as well as quantitative) System Tests

21. 21 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 in describing flow of events, to 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

22. 22 Analysis model (UML version): --functional model (use cases and scenarios) --analysis object model (static: class and object diagrams) --dynamic model (state and sequence diagrams) As system is analyzed, specifications are refined and made more explicit; if necessary, requirements are also updated

23. 23 Example: an activity diagram for analyzing a system you are building:

24. 24 Class (modules) 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

25. 25 Common classes Other common types of classes which the developer can look for include: tangible things, e.g., Mailbox, Document system interfaces and devices, e.g., DisplayWindow, Input Reader agents, e.g., Paginator, which computes document page breaks, or InputReader events and transactions, e.g., MouseEvent,CustomerArrival users and roles, e.g., Administrator, User systems, e.g., mailsystem (overall), InitializationSystem (initializes) containers, e.g., Mailbox, Invoice, Event foundation classes, e.g., String, Date, Vector, etc.

26. 26 Sequence Diagram Sequence Diagram: a sequence diagram also models dynamic behavior typically a sequence diagram shows how objects act together to implement a single use case messages passed between the objects are also shown sequence diagrams help to show the overall flow of control in the part of the program being modeled they can also be used to show: concurrent processes asynchronous behavior

27. 27 Sequence Diagram--Syntax Objects in the sequence diagram are shown as boxes at the top below each object is a dashed vertical line--the object’s “lifeline” an arrow between two lifelines represents each message arrows are labeled with message names and can also include information on arguments and control information two types of control: condition, e.g., [is greaterthan zero] iteration, e.g., *[for all array items] “return” arrows can also be included

28. 28 Sequence Diagram Example

29. 29 ER diagrams Useful object relationships These diagrams represent the relationships between the classes in the system. These represent a static view of the system. There are three basic types of relationship: inheritance ("is-a") aggregation ("has-a”) association ("uses") These are commonly diagrammed as follows:

30. 30 ER diagram: is-a is-a: draw an arrow from the derived to the base class: manager employee

31. 31 ER diagram--has-a has-a: draw a line with a diamond on the end at the "container" class. Cardinalities may also be shown (1:1, 1:n, 1:0…m; 1:*, i.e., any number > 0, 1:1…*, i.e., any number > 1): car tire 1 4 tire & car can exist independently —shared aggregation person arm 1 2 arm is part of the person– composition aggregation

32. 32 ER diagram--uses uses or association: there are many ways to represent this relationship, e.g., cargasstation company employee employs works for * 1 * n 1 *

33. 33 CRC cards CRC cards: class--responsibilities--collaborators cards "responsibilities" = operators, methods "collaborators" = related classes (for a particular operator or method) Make one actual card for each discovered class, with responsibilities and collaborators on the front, data fields on the back. CRC cards are not really part of UML, but are often used in conjunction with it.

34. 34 CRC card--example Example (based on Horstmann, Practical Object-Oriented Development in C++ and Java): frontback Class Mailbox OperationsRelationships (Responsibilities)(Collaborators) get current messageMessage, Messagequeue play greeting ----------- Queue of new messages Queue of kept messages Greeting Extension number Passcode Class Mailbox

35. 35 State Diagram State Diagram (~ FSM): another way of adding detail to the design--models dynamic behavior describes all the possible states a particular object can be in and how that object's state changes as a result of events that affect that object usually drawn for a single class to show behavior of a single object used to clarify dynamic behavior within the system, as needed

36. 36 State Diagram--Properties A state diagram contains a "start" point, states, and transitions from one state to another. Each state is labeled by its name and by the activities which occur when in that state. Transitions can have three optional labels: Event [Guard] / Action. A transition is triggered by an Event. If there is no Event, then the transition is triggered as soon as the state activities are completed. A Guard can be true or false. If the Guard is false, the transition is not taken. An Action is completed during the transition.

37. 37 State Diagram--Example Example: this state diagram example for an "order" in an order- processing system is from Fowler and Scott, UML Distilled (Addison-Wesley, 1997): Checking check item Dispatching initiate delivery Waiting Delivered start /get first item [not all items checked] /get next item [all items checked && all items available] [all items checked && some items not in stock] item received [some items not in stock] item received [all items in stock] delivered

38. 38 Example—bank simulation (Horstmann) Teller 1 Teller 2 Teller 3 Teller 4 Customer 1Customer 3Customer 2 Horstmann, Mastering Object- Oriented Design in C++, Wiley, 1995

39. 39 Example—bank simulation (Horstmann), cont. An initial solution (Horstmann, p. 388): Event Departure Arrival Customer Bank EventQueue Application Bank Statistics

40. 40 Example—bank simulation (Horstmann), cont. An improved solution (Horstmann, p. 391): Event Departure Arrival Customer Bank EventQueue Simulation Bank Statistics

41. 41 Comparison What simplifications have been made? Why? Event Departure Arrival Customer Bank EventQueue Application Bank Statistics Event Departure Arrival Customer Bank EventQueue Simulation Bank Statistics

42. 42 Example: How would we use the tools described so far to design a “smart” vending machine? How would we develop test cases at each stage? Use cases? Class diagram? Sequence diagram? Classes / CRC cards?

43. 43 Software modeling for embedded systems: static and dynamic behavior

44. 44 Important concepts in embedded systems: --concurrency: the system can handle multiple active independent or cooperating objects at the same time --thread [of control]—models sequential execution of a set of instructions; embedded system may have several concurrent threads operating simultaneously --persistence—how long does a software object last? Examples: Temporary variable Global variable Software module

45. 45 table_05_00 Note that “UML” syntax can vary among implementations; Previously we looked at one implementation, here we consider examples from the text

46. 46 fig_05_01 UML Use case diagram—example-note that this author omits “system boundary”-

47. 47 fig_05_02 UML: Use case diagram (text); note exceptions

48. 48 UML—static modeling

49. 49 fig_05_03 UML: Class diagram (“CRC card”) Class name data Methods (responsibilities and collaborators) (+ collaborators)

50. 50 fig_05_04 UML: class relationships: inheritance

51. 51 fig_05_05 UML: “interface”—similar to inheritance but different public appearance Hidden operation

52. 52 fig_05_06 UML: containment of one class within another Type 1: aggregation—statistical analysis has a number of algorithm “parts”

53. 53 fig_05_07 UML: containment of one class within another Type 2: composition—here the intervals are meaningless outside the schedule (~ “local variables”)

54. 54 UML—dynamic modeling

55. 55 fig_05_08 UML: interaction diagram—call and return (can also be used in software modeling)

56. 56 fig_05_09 UML: interaction diagram—create and destroy

57. 57 fig_05_10 UML: interaction diagram—send (no response expected)

58. 58 fig_05_11 UML: sequence diagram: sequence of actions; carries out a use case

59. 59 fig_05_12 UML sequence diagram--example

60. 60 fig_05_13 UML: concurrent behavior. Example: fork and join

61. 61 fig_05_14 UML: concurrent behavior. Example: branch and merge

62. 62 fig_05_15 UML activity diagram—captures all actions and control flows within a task

63. 63 fig_05_16 UML state machine models--4 types of events: UML state chart is a directed graph

64. 64 fig_05_18 UML state chart: types of transitions initial state final state

65. 65 fig_05_19 UML state chart: actions and guard conditions If guard condition is false, transition does not happen

66. 66 fig_05_20 UML: can decompose state into sequential substates

67. 67 fig_05_21 UML: can define a “history” state (e.g., for an interrupt)— system will probably eventually return to this state

68. 68 fig_05_22 UML: can have concurrent substates

69. 69 UML is a tool for a structured design methodology It helps manage the design and development process We can also look at modifying / refining the PROCESS itself CMM : capability maturity model-- defines level of the development process itself 1. Initial: ad hoc 2. Repeatable: basic project management processes in place 3. Defined: documented process integrated into an organization-wide software process 4. Managed: detailed measures are collected 5. Optimizing--desired level: Continuous process improvement from quantitative feedback

70. 70 UML is a tool for a structured design methodology It helps manage the design and development process We can also look at modifying / refining the PROCESS itself CMM : capability maturity model-- defines level of the development process itself 1. Initial: ad hoc 2. Repeatable: basic project management processes in place 3. Defined: documented process integrated into an organization-wide software process 4. Managed: detailed measures are collected 5. Optimizing--desired level: Continuous process improvement from quantitative feedback

71. UML for embedded systems How to deal with parallelism? How to deal with all constraints (e.g., “business” constraints)? How to deal with hardware / software co-design? How to deal with timing and real-time constraints? 71

72. 72 fig_05_23 Alternative methodology: control flow and data flow diagrams (Note: in a processor we usually have a data path and a control path)

73. 73 fig_05_24 Control and data flow diagrams: tasks (with hierarchy levels)

74. 74 fig_05_25 Control and data flow diagrams: Data sources and sinks

75. 75 fig_05_26 Control and data flow diagrams: Data stores

76. 76 fig_05_27 Control and data flow diagrams: Example

77. 77 fig_05_28 Control and data flow diagrams: Hierarchical view of an input / output task