Flying Cucumber

#  author: dwet(骁尧)

# This article is brief summary of the <Object Oriented Software Development> course.

Use Case Model

• describes what the user expects the system to do
            —-functional requirements
• generally described using an activity diagram (to be discussed later)
• example:

Activity Diagram

• an activity diagram can be used to
     — describe a use case
     — describe a method in a collaboration diagram
     — describe an action associated with a transition in a state diagram, or the entry action or the exit action of a state diagram
• every activity diagram must have only one initial state and one or more final states
• a merger is also represented by a diamond
     — two or three incoming transitions and one outgoing transition
     — the outgoing transition will be fired only when both the incoming transitions are fired
• example:

Class and Object Diagram

• How to find classes?
   - nouns in requirements document or use case descriptions do not provide adequate solutions
   - each class should contain a distinct set of operations relevant to the system under consideration
   - do not include implementation-oriented classes in the analysis model
        * may be introduced later during design and/or implementation
        * examples: array, tree, list
• every association is expected to be labeled, direction of an association, cardinality, role name are all optional
      — UML does not require a name for an association
• representations of cardinality
    — 0, 1, * (zero or more), n..m (values in the range between n and m both inclusive)
• example:

• a piece of information that belongs to both classes in an association is put into a separate class called “association class”
    — association class is a dependent class that depends on the other two classes in the association
    — cannot exist independently
    — object of an association class must refer to objects of the other two classes in the association
    — Example: A “Transaction” object depends on a “User” object and on an “Account” object.

State Diagrams

• one state diagram per class in the class diagram
• one logical state diagram may be spread out into one or more physical diagrams for space considerations

• every state may have
    – an entry action – executed as soon as the state is entered
    – an exit action – executed just before leaving the state
    – a “do” action – executed while the object is in this state; may be ongoing until the object leaves the state