Object%20Model:%20Four%20main%20system%20objects%20or%20classes - PowerPoint PPT Presentation

About This Presentation
Title:

Object%20Model:%20Four%20main%20system%20objects%20or%20classes

Description:

Object Model: Four main system objects or classes – PowerPoint PPT presentation

Number of Views:38
Avg rating:3.0/5.0
Slides: 56
Provided by: cse6
Learn more at: http://www.cse.msu.edu
Category:

less

Transcript and Presenter's Notes

Title: Object%20Model:%20Four%20main%20system%20objects%20or%20classes


1
Object Model Four main system objects or classes
  • Controller object
  • might be made up of several controllers
  • is the brains of the system.
  • Takes input from the sensors and gives
    instructions to the actuators.
  • Sensor object
  • environmental objects that gives information to
    controller.
  • Can be passive (thermometer) or active (button).

2
Object Model Four main system objects (continued)
  • Actuator object
  • Environmental objects that are controlled by the
    controller.
  • Can be turned on or influenced by controller.
  • Examples User indicator lights, motors, burners.
  • User Interface object
  • A display for the user.
  • Can be made up of both sensors and actuators.
  • Example machine control panel

3
Step One Develop a high-level object model
Embedded System
0..
0..
0..
Controller
Actuator
User-Interface
Sensor
Button
Pedal
Inheritance
Class Name
Class
Zero or more
0..
Attribute()
Association
Aggregation
Operation()
4
Review of Dynamic Model
  • A dynamic model is a type of state machine.
  • System can only be in one state at a time.
  • Arrows Transitions
  • from one state to another happen
  • when events happen.
  • Events are labeled on the transitions.
  • Guards are conditions that keep a transition from
    happen, such as is in neutral or park

5
Step Two Develop a system-level dynamic model
On button pushed in neutral or park
Idle or off state
Running state
Off button pushed
State
Transition
condition Guard
6
Example Automotive Door Control
  • The system controls the windows and door locking
    functions.
  • All doors have window roll up and down controls.
  • Drivers door has window lock feature.
  • Driver and front passenger have door lock and
    unlock toggle.
  • Fob unit for locking and unlocking doors, with
    driver notification (horn honk and lights flash.)
  • Three concurrent systems identified.

7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
Summary of development process
  • The object model shows the real world objects
    grouped in classes with attributes and operations
    and associations.
  • The dynamic model shows the control aspects with
    superstates refined into substates.

15
Review of Embedded Systems
  • Software controller that is interacting with its
    hardware environment through sensors and
    activators.
  • Concurrency and real time issues.
  • Safety critical nature of many of these systems.
  • Increased demand for these systems to be designed
    well.

16
High level design Initial thoughts for embedded
systems.
  • Assume there is a hardware environment.
  • Assume that somehow the needed signals are coming
    from the environment (sensors.)
  • Assume the needed hardware is there to respond to
    your signals (actuators.)

17
Object Model
Class
attribute
operation
  • In OMT the object model is the starting place for
    the modeling process.
  • The object model will include objects and their
    relationships.
  • The Object Model will be the static, structural
    aspect of the system.

18
Identify Real World Objects
  • Read over the problem description and find the
    nouns in the text.
  • These nouns are candidates for objects in your
    object model.
  • Discard unnecessary and incorrect classes.
  • Object classes will include the controller
    (software unit that will be built), sensors, and
    activators.

19
Data Dictionary needs to be written
  • A written paragraph describing each modeling
    entity.
  • Needed so that names are non-ambiguous.

20
Class Sensor
  • Because of the common properties of all sensors,
    this can be a class of objects, called a
    superclass.
  • Generalization - this superclass can be
    generalized into subclasses.
  • Inheritance - each subclass will inherit the
    properties or features from the superclass.
  • Examples user interface (buttons etc),
    thermometers, hardware sensors.

21
Class Actuator
  • Similarly the activators will probably become a
    superclass.
  • Generalization - The various activators can be
    generalized into subclasses.
  • Inheritance - each activator subclass will
    inherit properties or features from the
    superclass.
  • Examples LEDs, motor controls, etc.

22
The Controller
  • At an abstract level, this would be only one
    object in most embedded systems.
  • This object would be refined at lower levels of
    the modeling process into subsystems or
    sub-objects.
  • Aggregation could be used to show the parts of
    the controller.

23
Model itself
Class
attribute
operation
  • Graphically a class is shown as a box with the
    name on top.
  • Attributes (middle third) and operations (bottom
    third) added eventually.
  • Attributes and operations are not needed for
    high-level object model.

24
Find the Associations
  • Interaction between objects must be shown by
    associations or lines draw with labels.
  • ex line between user button and associated LED.
  • Many times these associations will be a physical
    connection between objects in an embedded system.
  • Help in Rumbaugh. (section 8.4.4 8.4.5)
  • Multiplicity must be shown eventually.

25
Example
Controller
turned on by
reads
Actuators
Sensors
0..
0..
Water level
Motor
LED
User buttons
26
Conclusion about Object Model
  • Look at Dr. Chengs Creation Tips.
  • Not very complex at first.
  • More details will come as designer proceeds from
    abstraction to more and more concreteness.
  • controller will be divided into more objects
  • attributes and operations are identified and
    included.
  • Starting place for OMT. Sets the stage.

27
Next step Dynamic Model
  • The dynamic model shows the control aspect of the
    system.
  • Because embedded systems are mainly controllers,
    the dynamic model is the key model for embedded
    systems.
  • This model can show the timing aspects.
  • Shows sequence of operations in response to
    external stimuli.

28
Getting started on a Dynamic Model
  • Helpful to make a scenario
  • sequence of events that happens in one execution
    of a system.
  • Example insert coins, make selection, pop
    dispensed.
  • Interface (high-level prototyping)
  • a rough draft of user interface will help
    thinking about the events in an embedded system.

29
Interface (type of rapid prototyping)
0
4
3
2
1
6
7
8
8
5
clear
enter
cancel
receipts
cash slot
ATM interface from Figure 8.17 by Rumbaugh
30
continue getting started.
  • Next make an event trace.
  • each object is a vertical line.
  • events as horizontal arrow.
  • time goes from top to bottom.
  • Use Dr. Cheng's creation tips.
  • Follow the steps in Rumbaugh 8.5.

31
Example of an Event Trace
User
ATM
Consortium
Bank
insert card
request password
enter password
verify account
verify card with bank
bank account OK
account OK
request kind
enter kind
request amount
enter amount
process transaction
process bank transactions
bank transaction succeeds
Event trace for ATM scenario
Example from Figure 8.18 of Rumbaugh
32
More Dynamic Modeling
33
Dynamic Model - State Diagram
  • Graphical representation of a finite state
    machine.
  • Each state represents all the values of the
    objects in the system.
  • Changing states - transitioning on events.
  • Events - external stimuli
  • ex. button pushed timer complete tub full.

34
Review of getting started
  • Scenario making gets us started thinking about
    events.
  • Interface (high-level prototyping) helps us to
    think about order of things. (happening in
    projects)
  • Event trace helps to know what object is doing
    what action.
  • Dr. Chengs creation tips.
  • Use Rumbaughs 8.5 section.

35
Dynamic Models for E.S.
button
  • Dynamic Model for user buttons would be
    simplistic modeling might not be needed.
  • Some environmental units might have behavior that
    should be modeled. (like an engine shifting
    through speeds)
  • For embedded systems - might only need one
    significant behavior model (for controller.)
  • Complex models will be decomposed into more
    detailed behavioral models.
  • Concurrency could be present within a model.

pushed
on
off
button
pushed
36
How dynamic model relates to object model
  • One state diagram for each class (with important
    behavior.)
  • Each class has concurrent behavior.
  • Aggregation in the Object Model implies
    concurrency in the Dynamic Model.

37
Examples of Aggregation (5.17)
  • Object model

Car
Ignition
Transmission
Brake
Accelerator
Each class will need a concurrent state diagram
38
turn key to start
Ignition
release key
Transmission
in Neutral
Off
Starting
On
turn key off
Transmission
push R
push N
Reverse
Neutral
push F
push N
Forward
upshift
upshift
stop
First
Second
Third
downshift
downshift
Accelerator
Brake
depress accelerator
depress brake
Off
On
release accelerator
On
Off
release brake
39
How to model concurrency within an object
Car
40
How to hide complexity
  • Not have a flat state diagram
  • Start abstract and then do subdiagrams.
  • use bulls eye
  • Take one abstract state and expand it with state
    generalization.

41
Example of nesting(and other syntax as well)
coins in(amount) / set balance
Collecting money coins in(amount) / add to balance
Idle
cancel / refund coins
select(item)
changelt0
item empty
do test item and compute change
change0
changegt0
do make change
do dispense item
do move arm
do move arm
do push item
to correct row
to correct column
off shelf
Example lower-level state diagram for Dispense
item activity
42
State Generalization
push R
push N
Reverse
Neutral
push F
push N
ex. level 0 Dynamic Model for a
transmission.
Forward
Transmission
push R
push N
Reverse
Neutral
push F
push N
Forward
upshift
upshift
stop
First
Second
Third
downshift
downshift
ex. level 1 Dynamic Model for a transmission.
43
Notation on Transitions and in States
event1 (attribs) condition1/ action1
  • do activity
  • takes some time.
  • associated with a state.
  • Guards
  • conditions - boolean
  • guard
  • Actions
  • instantaneous
  • associated with an event.
  • /action

State1 do activity 1
State2
You might need any or all of these for your
project!
44
Checking for completeness and consistency
  • Formal specifications do this better!
  • The mathematical format can allow automation of
    these types of checks.
  • Every state should have a way in and out.
  • unless starting point or ending point.
  • Look for one objects Dynamic Model sending an
    event that doesnt have any receiving transition
    in another objects DM.

45
Things to watch out for
  • Think about input from concurrent objects at
    unexpected times.
  • ex. If more than one ATM machine is trying to
    access the same account at the same time.
  • User input when not planned. (OK to ignore, but
    make sure that is what is really wanted.)
  • Take your scenarios and see if they work!
  • Walk through seeing that all the objects FM has
    all the needed transitions.

46
Topics Covered
  • Dynamic Model
  • Synchronization schemes
  • Exception Handling
  • Timing including safety critical issues.

47
Synchronization
  • In concurrent processing, the actions of the
    objects are rarely independent of each other.
  • One may need to stop and wait for another process
    to catch up or get to a certain state.
  • Example In a nuclear power plant, the model
    would need to reflect waiting for rods to be in
    place before generating power.

48
Synchronization of Statesby status detection
B
A
A1
B1
event
A is in state A2
A2
B2
Transition between B1 and B2 will not fire until
object A has entered state A2.
49
Synchronization of Statesby a common event
A
B
StateA1
StateB1
event1
event1
StateB2
StateA2
Firing of the two transitions in the two models
will happen at the same time.
50
Synchronization of Statesby common data
A
B
StateA1 do x0
StateB1
event
x1
StateA2 do x 1
StateB2
Transition from StateB1 to StateB2 will not fire
till StateA2 has been done. (This assumes
shared memory.)
51
Exception Handling
  • Events such as resets and hardware interrupts
    must be handled.
  • These are called Exceptions.
  • Crucial to terminate the behavior of an object.
  • Needed if user can exit a sequence of states at
    anytime.

52
Examples of exception handling
  • Possible to modeling exiting all the substates of
    a superstate in OMT.
  • Ex. Pushing the N (neutral button) in any of the
    forward states of a transmission.
  • 2 ways to exit normal completion and exception.

Superstate
event1
substate1
substate2
normal exiting by completion
exception event
53
Timing Issues in Dynamic Model
  • Sometime the firing of a transition is time
    dependent, especially in embedded systems.
  • Real-time systems might have transitions that are
    tied to a real-time clock.
  • States might time-out after a certain length of
    time.
  • Transitions might need to be stalled for a
    certain length of time.

54
Timing (Safety critical)
  • Safety critical real-time solutions
  • example
  • transition out of boiler on state after being
    in this state for 1 hour, even if one expects a
    transition on temperaturegtexpected.

Boiler
temperature gt expected
On
Off
in boiler on state gt 1 hour
(Event on transition could just be labeled 1
hour)
55
Delays in Dynamic Model
  • Sometimes a transition should not be fired for a
    certain amount of time.
  • This timing constraint can be modeled as a guard
    on transition
  • ex.
  • 10 seconds since the exit from state A
  • This will delay the firing of the transition for
    10 seconds.

56
More Timing Issues in D. M.
  • For a real-time system, the guard might refer to
    a real-time clock
  • example
  • changing a traffic signal from day operation to
    night operation at 10 p.m.
  • because there is no event on transition ready to
    fire when the guard is true.

time 2200 hours
Day superstate
Night superstate
time 0600 hours
57
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com