Stereotype

1
(No Transcript)
2
Stereotype

• Adornment in a class
• Used in two different ways
• As a metatype, e.g., ltltsubsystemgtgt
• To tailor UML to meet a specific need or purpose

3
Dependency

• In UML modeling, a dependency relationship is a
  relationship in which changes to one model
  element (the supplier) impact another model
  element (the client).
• You can use dependency relationships in class
  diagrams, component diagrams, deployment
  diagrams, and use case diagrams.
• You can also use a dependency relationship to
  represent precedence, where one model element
  must precede another.
• Dependency relationships usually do not have
  names.

4
Dependency
As the following figure illustrates, a dependency
is displayed in the diagram as a dashed line
with an open arrow that points from the client
model element to the supplier model element.
5
Types of dependency relationships

• Because a dependency relationship can represent
  several different types of relationships,
  keywords or stereotypes are used to show the
  precise nature of the dependency.

6
Abstraction

• abstraction, derive, refine, or trace
• Relates two model elements, or sets of model
  elements, that represent the same concept at
  different levels of abstraction, or from
  different viewpoints.

7
Binding

• bind
• Connects template arguments to template
  parameters to create model elements from
  templates.

8
Realization

• realize
• Indicates that the client model element is an
  implementation of the supplier model element, and
  the supplier model element is the specification.

9
Substitution

• substitute
• Indicates that the client model element takes the
  place of the supplier.
• The client model element must conform to the
  contract or interface that the supplier model
  element establishes.

10
Usage

• use, call, create, instantiate, or send
• Indicates that one model element requires another
  model element for its full implementation or
  operation.

11
Using Dependency Relationships

• You can add dependency relationships to your
  model to accomplish the following goals
• Connect two packages to indicate that at least
  one model element in the consumer package is
  dependent on one model element in the supplier
  package. The dependency relationship does not
  indicate that all model elements in the consumer
  package are dependent.
• Connect two classes to indicate that the
  connection between them is at a higher level of
  abstraction than an association relationship. The
  dependency relationship indicates that the
  consumer class performs one of the following
  functions
• Temporarily uses a supplier class that has global
  scope
• Temporarily uses a supplier class as a parameter
  for one of its operations
• Temporarily uses a supplier class as a local
  variable for one of its operations
• Sends a message to a supplier class

12
Using Dependency Relationships

• Connect components to interfaces or other
  components to indicate that they use one or more
  of the operations that the interface specifies or
  that they depend on the other component during
  compilation.

13
Example

• In an e-commerce application, a Cart class
  depends on a Product class because the Cart class
  uses the Product class as a parameter for an add
  operation.
• In a class diagram, a dependency relationship
  points from the Cart class to the Product class.
  The Cart class is, therefore, the client model
  element, and the Product class is the supplier
  model element.
• This relationship indicates that a change to the
  Product class might require a change to the Cart
  class.

14
Example
15
Packages

• Packages are UML constructs that enable you to
  organize model elements into groups, making your
  UML diagrams simpler and easier to understand.
• Packages are depicted as file folders and can be
  used on any of the UML diagrams, although they
  are most common on use-case diagrams and class
  diagrams because these models have a tendency to
  grow.  

16
Package
17
Component Diagram

• The component diagram's main purpose is to show
  the structural relationships between the
  components of a system. In UML 1.1, a component
  represented implementation items, such as files
  and executables.
• Unfortunately, this conflicted with the more
  common use of the term component," which refers
  to things such as COM components. Over time and
  across successive releases of UML, the original
  UML meaning of components was mostly lost.
• UML 2 officially changes the essential meaning of
  the component concept in UML 2, components are
  considered autonomous, encapsulated units within
  a system or subsystem that provide one or more
  interfaces.
• Although the UML 2 specification does not
  strictly state it, components are larger design
  units that represent things that will typically
  be implemented using replaceable" modules.
• But, unlike UML 1.x, components are now strictly
  logical, design-time constructs. The idea is that
  you can easily reuse and/or substitute a
  different component