# 4. Basic Structural Modeling

Τεχνίτη Νοημοσύνη και Ρομποτική

15 Νοε 2013 (πριν από 4 χρόνια και 7 μήνες)

68 εμφανίσεις

4. Basic Structural Modeling

Relationships

Sung Kim

CS6359

Slide
2

Overview

Relationships

Dependency

Generalization

Association

Modeling techniques

Building webs of relationships

Sung Kim

CS6359

Slide
3

Relationships

Window

open()

close()

ConsoleWindow

DialogBox

Control

Event

association

dependency

generalization

Sung Kim

CS6359

Slide
4

Dependency

Dependency

a change in specification of
one thing may affect another.

“Uses” relationship.

May have a name, but not common.

FilmClip

playOn(c:Channel)

start()

stop()

Channel

dependency

name

Sung Kim

CS6359

Slide
5

Generalization

Generalization

relationship between general
thing (parent) and specific kind of thing (child)

Child “is
-
a
-
kind
-
of” parent.

Child inherits attributes and operations of parent.

generalization

Rectangle

Square

Polygon

Circle

Shape

base class

leaf class

Sung Kim

CS6359

Slide
6

Generalization (cont’d)

May have a name, but not common.

Polymorphism

multiple objects can respond
to the same message in different ways.

Achieved through generalization and interfaces.

Children of the same parent are polymorphic.

Sung Kim

CS6359

Slide
7

Association

Association

structural relationship where
objects of one class are connected to objects
of another class.

-
directional by default.

Binary association connects exactly two
classes. N
-
ary connects many classes.

Sung Kim

CS6359

Slide
8

Name

descriptive term for the association.

Role

persona the class at the near end of the
association presents to the class at the other end of
the association.

Multiplicity

defines the number of objects
associated with an instance of the association.

Default of 1

Zero or more (*)

n..m; range from n to m inclusive

Aggregation

structural association representing
“whole/part” relationship; “has
-
a” relationship.

Sung Kim

CS6359

Slide
9

Association Representation

Company

Person

employee

employer

works for

1..*

*

association

roles

association name

multiplicity

Sung Kim

CS6359

Slide
10

Aggregation Representation

Company

Department

1..*

association

multiplicity

aggregation

part

whole

Sung Kim

CS6359

Slide
11

Modeling Techniques

Simple dependencies

Single inheritance

Structural relationships

Sung Kim

CS6359

Slide
12

Modeling Simple Dependencies

One class uses another as a parameter to an
operation.

Create dependency pointing from class with
operation to parameter.

CourseSchedule

remove(c:Course)

Course

Sung Kim

CS6359

Slide
13

Modeling Single Inheritance

Be careful! Inheritance is too often abused.

Look for common responsibilities, attributes,
and operations.

If necessary, create a new class to assign
commonalities.

Specify that the more
-
specific classes inherit
from the more
-
general.

Sung Kim

CS6359

Slide
14

Modeling Inheritance (cont’d)

Abstract

Abstraction

the essential characteristics of a thing.

Abstract class

cannot be instantiated.

Abstract method

has no implementation defined.

Depicted in italics or with stereotypes.

Concrete

Not abstract.

Can have instances.

Sung Kim

CS6359

Slide
15

Modeling Inheritance (cont’d)

CashAccount

presentValue()

interestRate

Security

presentValue
()

history()

Bond

presentValue()

Stock

presentValue()

PreferredStock

CommonStock

abstract

Sung Kim

CS6359

Slide
16

Modeling Structural Relationships

Specify an association to create a navigation path
between two objects.

Specify an association if two objects interact with
each other beyond operation arguments.

Specify multiplicity; 1 is assumed.

Error in text on implicit default.

Specify aggregation when one of the classes
represents a whole over the other classes.

Sung Kim

CS6359

Slide
17

Web of Relationships Example

School
Instructor
Course
Department
Student
*
1..*
1..*
1
has

member
*
*
member

*
1..*

teaches
1..*
1..*
1..*
1..*
0..1
1
chairperson

assigned to
Sung Kim

CS6359

Slide
18

Hints & Tips

Modeling relationships

Use dependencies when relationship is not structural.

Use generalization with “is
-
a” relationship.

Don’t introduce cyclical generalizations.

Balance generalizations

Not too deep

Not too wide

Use associations where structural relationships exist.

Sung Kim

CS6359

Slide
19

Hints & Tips (cont.)

Drawing a UML relationship

Use rectilinear or oblique lines consistently.

Avoid lines that cross.

Show only relationships necessary to understand a
particular grouping of things.

Elide redundant associations.

Sung Kim

CS6359

Slide
20

Summary

Relationships

Dependency

Generalization

Association

Modeling techniques

Relationships

Sung Kim

CS6359

Chapter 10

Slide
22

Overview

Dependency

Generalization

Association

Realization

Sung Kim

CS6359

Chapter 10

Slide
23

SetTopController

authorizationLevel

startUp()

shutDown()

Connect()

<<interface>>

URLStreamHandler

openConnection()

parseURL()

setURL()

toExternalForm()

PowerManager

ChannelIterator

Controller

EmbeddedAgent

<<friend>>

multiple inheritance

stereotyped dependency

realization

Sung Kim

CS6359

Chapter 10

Slide
24

Dependency

Eight Stereotypes of Dependency Among Classes

bind: the source instantiates the target template using
the given actual parameters

derive: the source may be computed from the target

friend: the source is given special visibility into the
target

instanceOf: the source object is an instance of the
target classifier

instantiate: the source creates instances of the target

Sung Kim

CS6359

Chapter 10

Slide
25

Dependency (cont’d)

Eight Stereotypes of Dependency Among
Classes (cont’d)

powertype: the target is a powertype of the
source; a powertype is a classifier whose
objects are all the children of a given parent

refine: the source is at a finer degree of
abstraction than the target

use: the semantics of the source element
depends on the semantics of the public part of
the target

Sung Kim

CS6359

Chapter 10

Slide
26

Dependency (cont’d)

Two Stereotypes of Dependency Among
Packages:

access: the source package is granted the right
to reference the elements of the target
package

import: a kind of access; the public contents of
the target package enter the flat namespace of
the source as if they had been declared in the
source

Sung Kim

CS6359

Chapter 10

Slide
27

Dependency (cont’d)

Two Stereotypes of Dependency Among
Use Cases:

extend: the target use case extends the
behavior of the source

include: the source use case explicitly
incorporates the behavior of another use case
at a location specified by the source

Sung Kim

CS6359

Chapter 10

Slide
28

Dependency (cont’d)

Three Stereotypes of Dependency in Interactions
among Objects:

become: the target is the same object as the source
but at a later point in time and with possibly different
values, state, or roles

call: the source operation invokes the target operation

Copy: the target object is an exact, but independent,
copy of the source

Sung Kim

CS6359

Chapter 10

Slide
29

Generalization

One stereotype

implementation
: the child
inherits the implementation of the parent but
does not make public nor support its interfaces

Four Standard Constraints

complete: all children in the generalization have been
specified; no more children are permitted

incomplete: not all children have been specified;

disjoint: objects of the parent have no more than one
of the children as a type

overlapping: objects of the parent may have more than
one of the children as a type

Sung Kim

CS6359

Chapter 10

Slide
30

Association

name, role, multiplicity, & aggregation

Other Properties:

Composition

Association
Classes

Constraints

Visibility

Qualification

Interface Specifier

Sung Kim

CS6359

Chapter 10

Slide
31

Realization

A realization is a semantic relationship between
classifiers in which one classifier specifies a
contract that another classifier guarantees to
carry out.

Realization is sufficiently different from
dependency, generalization, and association
relationships that it is treated as a separate kind
of relationship.

Semantically, realization is somewhat of a cross
between dependency and generalization, and its
notation is a combination of the notation for
dependency and generalization.

Sung Kim

CS6359

Chapter 10

Slide
32

Summary