Book: B'P' Douglass, Doing Hard Time' Website for VxWorks Operating System: www'windriver'com Grade:

1
Class Diagrams
2
(No Transcript)
3
(No Transcript)
4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16

• There are 5 types of object relationships
• Association revealed in run-time to enable
  messages exchanging, object uses services of
  another object, but doesnt own it
• Aggregation one object logically or physically
  contains another
• Non-sharedstrong aggregation Composition
• Sharedweak aggregation
• Generalization is a kind of
• Dependency all the other, is stereotype of
  relation, for example friend,bind

17
(No Transcript)
18
(No Transcript)
19

• When to use a simple association?
• If on of the following is true
• Object uses services of another object but is not
  aggregate of it.
• The lifecycle of the used class is not in
  responsibility of the user class.
• Association is looser than aggregation
• Association can be characterized as client-server
• Used object is shared and used equally by many
  others.

20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
(No Transcript)
34
(No Transcript)
35
Polygon
36
( int i 0 i lt SIZE i)
private Figure consist_ofSIZE
37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40

• Stereotypes
• Each modeling element is presented as a
  metaclass.
• A stereotypes metaclass is derived from existing
  metaclass, usually it extends or specializes the
  metaclass.
• Stereotypes allow one to classify a model element
  and serve as an extension mechanism in UML.
• Stereotypes apply to almost all model elements.

41
Examples of Stereotypes
42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
(No Transcript)
47
(No Transcript)
48
(No Transcript)
49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
(No Transcript)
56
(No Transcript)
57
(No Transcript)
58
(No Transcript)
59
(No Transcript)
60

• Rules for Good Class Diagrams
• Each diagram has a mission and a single focus (to
  show collaboration or generalization hierarchy).
  It should not try to accomplish too many
  purposes.
• Build a diagram per collaboration or use case.
  Decompose the object space such that each
  important collaboration is in a separate diagram.
• Create a single task diagram if there is
  significant multitasking.
• For rich hierarchies, create diagram per
  generalization hierarchy.
• Dont mix collaboration and generalization unless
  it makes sense.
• Create a master diagram for all classes only for
  small system.
• Dont show attributes and operations on class
  diagram.

61

• Rules for Good Class Diagrams
• Dont cross lines.
• Show multiplicities for all show associations.
• Show role names rather than association labels,
  one role name for unidirectional and two for
  bidirectional.
• Use containment composition notation (nesting
  class boxes). Dont allow contained classes to
  associate with external classes directly.
• Show constrains when appropriate.
• Show stereotypes only if they add value.
• Dont use color to convey information.
• Use a note box to label each diagram.

62
Aircraft Management
63
Aircraft Monitoring
64
Topology
65
Display Flight Path
66
Determine Separation Distance Violation
67
Separation Distance