UML

Terms
Aggregation Represents is part of or contains relationships between two classes or components
Cohesion The degree of relatedness of an encapsulated unit (such as a component or a class)
Composition A strong form of aggregation in which the whole is completely responsible for its parts and each
part object is only associated to the one whole object
Encapsulation The grouping of related concepts into one item, such as a class or component
Inheritance Represents is a, is like, and is kind of relationships. When class B inherits from class A it
automatically has all of the attributes and operations that A implements (or inherits from other classes)
Polymorphism Different objects can respond to the same message in different ways, enable objects to interact with
one another without knowing their exact type
UML Use Case Diagrams
- diagram that shows the relationships among actors and use cases within a system
Used to:
- overview of all or part of the usage requirements for a system
- Communicate the scope of a development project
- Model the analysis of your usage requirements in the form of a system use case model



UML Sequence Diagrams
- a dynamic modeling technique
are typically used to:
- Validate and flesh out the logic of a usage scenario
- Explore your design because they provide a way for you to visually step through invocation of the operations
defined by your classes
- To detect bottlenecks within an object-oriented design
- Give you a feel for which classes in your application are going to be complex, which in turn is an indication
that you may need to draw state chart diagrams for those classes



UML Class Diagrams
- show the classes of the system, their inter-relationships, and the operations and attributes of the classes
are typically used, although not all at once, to:
- Explore domain concepts in the form of a domain mode
- Analyze requirements in the form of a conceptual/analysis model
- Depict the detailed design of object-oriented or object-based software
A class model is comprised of one or more class diagrams and the supporting specifications that describe model
elements including classes, relationships between classes, and interfaces.
Classes are shown as boxes with three sections
the top for the name of the class,
the middle for the attributes, and
the bottom for the operations.
Associations
- depicted as lines between classes.
- Associations should include multiplicity indicators at each end, for example 0..1 representing zero or one
and 1..* representing one or more.


Actors
are external to a system.
interact with the system.
may use the functionality provide by the system, including application functionality and
maintenance functionality.
may provide functionality to the system.
may receive information provided by the system. Actors may provide information to the system.
Actor classes have actors instances or objects that represent specific actors.

Use Cases
- are used to model and represent units of functionality or services provided by a system (or parts of a system:
subsystems or classes) to users.
- are denoted as ellipses or ovals.
- may be enclosed by a system boundary or rectangle labeled with the name of the containing system. They have
the following characteristics:
Use cases are interactions or dialogs between a system and actors, including the messages exchanged and
the actions performed by the system. Use cases may include variants of these sequences, including
alternative and exception sequences.
Use cases are initiated by actors and may involve the participation of numerous other actors. Use cases
should provide value to at least one of the participating actors.
Use cases may have extension points that define specific points within an interaction at which other use
cases may be inserted.
Use case classes have use case instances or objects called scenarios that represent specific interactions.
Scenarios represent a singe sequence of messages and actions.

Relationships
- Association relationships between actor classes and use case classes are used to indicate that the actor classes
participates and communicates with the system containing the use case classes.
- are denoted as solid lines or paths.
- Arrowheads may be used to indicate who initiates communication in the interaction. If an arrowhead points to a
use case, the actor at the other end of the association initiates the interaction with the system. If the arrowhead
points to an actor, the system initiates the interaction with the actor at the other end of the association.

- Extends relationships from extension use case classes to base use case classes are used to indicate that the base
use case classes may be augmented by the extension use case classes; that is, the inclusion use case will
augment the base use case if an extension condition is satisfied.
- A base use case defines the extension point. An extension use case defines the extension condition that must be
satisfied in order to insert the extension use case into the base use case. The insertion of the extension use case
involves the execution of the base use case up to the extension point, testing the extension condition and
inserting and executing the extension use case if the condition is satisfied, and then continuing with the
execution of the base use case.
- Extends relationships are denoted as dashed lines or paths with an open arrow-head pointing at the extension
use case and are labeled with the extension condition in square brackets, the <<extend>> keyword (stereotype),
and the extension point name in parentheses. Extension points are identified in a compartment labeled
"Extension Points" in the base use case.


- Generalization relationships from specialization use case classes to generalized use cases classes are used to
indicate the specialization use case classes are consistent with the generalized use case classes and may add
additional information.
- A specialization use case may be used in place of a generalized use case and may use any portions of the
interaction of the generalized use case.
- Generalization relationships are denoted as solid lines or paths with a hollow arrow-head pointing at the
generalized use case.

- Generalization relationships from specialization actor classes to generalized actor classes are used to indicate the
specialization actor classes are consistent with the generalized actor classes and may add additional information.
- A specialization actor may be used in place of a generalized actor and receives the characteristics of the
generalized actor. Generalization relationships between actors are denoted similarly to generalization
relationships between use cases.