Starting%20Point

1
Starting Point

• Identify key domain abstractions classes
  integrating
• Attributes
• Behavior (responsibilities, methods)
• Messaging
• providing logical independence between client and
  object
• Polymorphism
• providing physical independence between client
  and implementation
• Consider relationships integrating classes and
  objects to form higher levels of abstraction
• Association (Uses, Needs)
• Aggregation (Has-A)
• Inheritance (Is-A)

2
Initial Modeling Results

• List of use cases, describing system requirements
• Domain model, capturing your understanding of the
  business process and key domain classes
• Design model, realizing both the information in
  the domain objects and the behavior described in
  the use cases
• Add classes in the design model that actually do
  the work and also provide a reusable architecture
  for future extensions

3
UML Notation Baseline
Diagram Name Type Phase
Use Case Static Analysis
Class Static Analysis
Activity Dynamic Analysis
State-Transition Dynamic Analysis
Event Trace (Interaction) Dynamic Design
Sequence Static Design
Collaboration Dynamic Design
Package Static Delivery
Deployment Dynamic Delivery
Static describes structural system
properties Dynamic describes behavioral system
properties.
4
Static Notation - Classes
Box contains three compartments 1. The name
compartment (required) contains the class name
and other documentation-related information
E.g. Some_class abstract Guillemets identify
stereotypes. E.g. utility, abstract
JavaBean. Can use graphic instead of
word. Access privileges (see below) can precede
name Inner (nested) classes identify outer class
as prefix of class name (Outer.Inner or
OuterInner) 2. The attributes compartment
(optional) During Analysis identify the
attributes (i.e. defining characteristics) of the
object. During Design identify a relationship to
a stock class. 3. The operations compartment
(optional) contains method definitions
message_name( arguments ) return_type If
attributes and operations are both omitted, a
more-complete definition is assumed to be on
another sheet.
This
Not this
5
Static Notation - Associations

• Associated classes are connected by lines.
• The relationship is identified, if necessary,
  with a lt or gt to indicate direction (or use solid
  arrowheads).
• The role that a class plays in the relationship
  is identified on that class's side of the line.
• Stereotypes (like friend) are appropriate.
• Unidirectional message flow can be indicated by
  an arrow (but is implicit in situations where
  there is only one role)
• Cardinality
• 1 - (usually omitted if 11)
• N - (unknown at compile time, but bound)
• 0..1 - (1..2 1..n)
• 1.. - (1 or more)
• - (0 or more)

6
Static Notation - Implementation Inheritance
(Generalize/Specialize)

• Identifies derivation with the derived class as
  the base class and with additional (or modified)
  properties. Derived (sub) class is a
  specialization of (extends) the base (super)
  class.
• Variations include

7
Static Notation - Interface Inheritance
(Specifies/Refines)

• A contract that specifies a set of methods that
  must be implemented by the derived class. In C,
  an interface is a class containing nothing but
  pure virtual methods. Java supports them
  directly. (c.f.. "abstract class," which can
  contain method and field definitions in addition
  to the abstract declarations.)
• Interfaces contain no attributes, so the
  "attributes" compartment is always empty.
• The "inheritance" relationship line is dashed if
  the base class is an interface.

8
Static Notation - Dependency

• User uses Resource, but Resource is not a member
  of the User class. If Resource is modified, some
  method of User might need to be modified.
  Resource is typically a local variable or
  argument of some method in User.

9
Static Notation - Aggregation

• Aggregation (comprises) relationship. Destroying
  the "whole" does not destroy the parts

10
Static Notation - Composition

• Composition (has) relationship. The parts are
  destroyed along with the "whole." Doesn't really
  exist in Java. In C
• class Container
• Item item1 // both of these are
• Item item2 // "composition"
• public
• Container() item2 new Item
• Container() delete item2

11
Static Notation - Navigability

• Messages flow in direction of arrow (only).
  Implicit when no role present if an object
  doesn't have a role in some relationship, then
  there's no way to send messages to it.

12
Static Notation - Constraint

• A constrained relationship requires some rule to
  be applied. (e.g. \ordered) Often combined with
  aggregation, composition, etc.

13
Static Notation -

• In the case of the or, only one of the indicated
  relationships will exist at any given moment (a
  C union).
• Subset does the obvious.
• In official UML, put arbitrary constraints that
  affect more than one relationship in a "comment"
  box, as shown.

14
Static Notation - Qualified Association

• Qualified Association (hash-table, associative
  array, "dictionary").
• class User
• // A Hashtable is an associative array,
• // indexed by some key and containing
• // some value.
• private Hashtable bag new HashTable()
• private void add(String key, Item value)
• bag.put( key, value )

15
Static Notation - Association Class

• Use when a class is required to define a
  relationship.
• Somewhere, an additional relationship is required
  to show ownership. (The one between Person and
  Ticket in the current example.)

16
Static Notation - Summary

• Dependency
• Aggregation
• Composition
• Navigability
• Constraint
• Or
• Subset

17
Dynamic Notation - Objects and Messages

• Vertical lines represent objects, not classes.
  May optionally add a "class" to the box if it
  makes the diagram more readable.
• represents synchronous message.
  (message handler doesn't return until done).
• represents return. (Label arrow with
  name/type of returned object.) Return arrows are
  essential in UML style, otherwise control flow is
  ambiguous
• Sending object's class must have An association
  of some sort with receiving-object's class.
• The receiver-side class's "role" must be the same
  as the name of the receiving object.

18
Dynamic Notation - Object Creation

• Name box appears at point of creation.
• creates form for automatic creation, e.g.. in
  C
• class Creator1
• Object1 the_object // not a reference
• (There is no equivalent operation in Java)
• If message shown instead of creates, then the
  message handler creates the object. Think of new
  Fred() as Fred.new(). Method does not have to be
  new().

19
Dynamic Notation - Conditions, Loops, Grouping

• Message sent only if condition in brackets is
  true.
• An asterisk next to the condition signifies
  iteration.
• An asterisk without a condition means "every,"
  when receiver is an aggregate.
• The box at the bottom of the diagram is UML's
  Grouping notation (awkward when you try to group
  all indirect messages). A indicates a loop.

20
Dynamic Notation - Asynchronous Messages

• Half arrowhead means "asynchronous."
• Widening of line means "activated" (thread is
  running).
• Large X means object deleted (in this case, it's
  self deleting). An external kill is represented
  as

21
Use Case

• A use case is a relatively large end-to-end
  process description that typically includes many
  steps or transactions it is not normally an
  individual step or activity in a process.

22
Use Case Diagrams

• Show the external actors and their connection to
  the functionality (use cases) of the system
• Use cases provide the basis of communication
  among sponsors/customers and implementers in the
  planning of a project
• Capture some user-visible function
• May be small or large
• Achieves a discrete goal for the user

23
Class Diagrams

• Show the static structure of the domain
  abstractions (classes) of the system
• Describe the types of objects in the system and
  the various kinds of static relationships that
  exist among them
• Associations
• Derivations
• Show the attributes and operations of a class and
  the constraints for the way objects collaborate

24
Activity Diagrams

• Show the sequential flow of activities
• typically in an operation
• also in a use case or event trace
• Complement the class diagram by showing the
  workflow of the business (aka Flowchart)
• Encourage discovery of parallel processes which
  helps eliminate unnecessary sequences in business
  processes
• Confirm Availability for each chosen course
• Attend Class

25
Activity Diagrams - Starting and Stopping
26
Activity Diagrams - Synchronization (Fork/Join)

• When several activities can go on in parallel,
  indicates when all activities must be finished in
  order to continue. The heavy bar at the top is a
  fork. After the fork, all activities can (but are
  not required to) go on in parallel. Progress
  cannot continue past the bar on the bottom (a
  join) until all the activities that feed into the
  join complete. A join is an AND operation.

27
Activity Diagrams - Guards (tests)

• This path is used only if the text in the
  brackets is true.

28
Activity Diagrams - Decision (Branch/Merge)

• A decision activity, the guard labels the
  decision that was made. The diamond with outgoing
  arrows (the branch) specifies an OR operation,
  with a condition imposed by the guard. The
  diamond with incoming arrows (a merge) simply
  provides an end to the OR operation. A merge can
  occur without an associated branch if the diagram
  has multiple start states.

29
Activity Diagrams - Swim Lanes

• Activities are arranged into vertical zones
  delimited with dashed lines. Each zone represents
  a broad area of responsibilities, typically
  implemented by a set of classes or objects. For
  example, the swim lane labeled accounting could
  represent objects of several classes (Bookkeeper,
  Clerk, MailRoom, Accountant) working in concert
  to perform the single "cut paycheck" activity.

30
Dynamic Notation - State Transition

• Show all the possible states that objects of the
  class can have and which events cause them to
  change
• Show how the objects state changes as a result
  of events that are handled by the object
• Good to use when a class has complex lifecycle
  behavior