7KHIRXUIDFHVRI80/ Trygve Reenskaug 80/RIIHUVGLIIHUHQWSHUVSHFWLYHV XVHIXOIRUGLIIHUHQWSXUSRVHV

advertisement
7KHIRXUIDFHVRI80/
(Version of May 18, 1998)
Trygve Reenskaug
80/RIIHUVGLIIHUHQWSHUVSHFWLYHV
XVHIXOIRUGLIIHUHQWSXUSRVHV
• 'RZHQHHGWKHP"
• :KDWGRWKH\KLJKOLJKWDQG
KLGH"
• 6RZKDW"
©1998 Trygve Reenskaug
Four Faces, SDJH
UML offers a varied and powerful language for describing object
oriented systems.
We like to view the UML perspectives as belonging on four different
axis.
We will explore these perspectives: What are they and why do we
need them?
©1998 Trygve Reenskaug
Four Faces, SDJH
%RWWRP8S3UHVHQWDWLRQ
22UDP5ROH0RGHO
80/&ROODERUDWLRQSHUVSHFWLYH
80/,QWHUIDFHSHUVSHFWLYH
80/$VVRFLDWLRQ(5SHUVSHFWLYH
80/&ODVVSHUVSHFWLYH
6WXG\DK\SHUWH[WGRFXPHQWDWLRQ
,QWHUDFWWKURXJK,%09LVXDO$JH
(GLWWKH-DYDOLVWLQJ
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
We will discuss UML in the context of a concrete example
•Run the example
•Look at the code. Programming environment important because it is
ONE representation.
•Add modeling if above is insufficient. Select modeling concepts that
highlight problem areas that are still unclear.
©1998 Trygve Reenskaug
Four Faces, SDJH
6FKHGXOLQJZLWK'HIDXOW5HVRXUFH
Model
Code
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
This toy sample user interface is a Java Applet that is run from a web
browser. The interface interacts with a background service that is
also written in Java.
The top bars in the bar chart shows the earliest times when the
activities can be performed. The bottom bars show when the activities
all have to be done by the same resource, and this resource can only
serve one activity at the time.
©1998 Trygve Reenskaug
Four Faces, SDJH
6FKHGXOLQJZLWK*DQWU\&UDQH
Model
Code
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
An example of specialization: Some activities use a Gantry crane.
This crane has two independent hooks: One can lift a light load and
the other can lift any load.
Activity B is to lift a light load. It can be performed concurrently with
activity C, which is a heavy load. Activities D and E are both heavy
loads, they have to be performed in sequence. Activities A and F use
the old resource that can serve one at the time.
©1998 Trygve Reenskaug
Four Faces, SDJH
2XU6LPSOHDQG&RQFUHWH2EMHFW0RGHO
2EMHFWVGHVFULEHFRPSOH[V\VWHPV
2EMHFW%
2EMHFW$
0HVVDJH
3RUW
,1
287&
287%
,1
287&
Methods Data
2EMHFW&
Methods Data
,1
Methods
Data
Model
Code
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
Traditional activity planning systems are programmed with a
centralized logic working on standardized activity records. The
current demo replaces activity records with objects so that different
activities and resources can behave differently according to their
nature.
Thinking about this activity scheduling system implies thinking about
interacting objects. What is our strategy for performing the
scheduling. What are the objects and what are their responsibilities?
©1998 Trygve Reenskaug
Four Faces, SDJH
2XU6LPSOHDQG&RQFUHWH2EMHFW0RGHO
6RPHUHOHYDQWVKLS\DUGREMHFWV
Object representing
the Shipyard
Object representing a
ship’s schedule
Object representing
the shipyard resources
Object representing
a single resource
Object representing
a construction activity
Object representing
a ship’s part
Mode
Code
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
Our example is taken from a shipyard. We represent important
aspects by objects and let scheduling be performed through
negotiation between these objects.
©1998 Trygve Reenskaug
Four Faces, SDJH
:RUNLQJZLWKWKHFRGH
22UDP5ROH0RGHO
80/&ROODERUDWLRQSHUVSHFWLYH
80/,QWHUIDFHSHUVSHFWLYH
80/$VVRFLDWLRQ(5SHUVSHFWLYH
80/&ODVVSHUVSHFWLYH
6WXG\DK\SHUWH[WGRFXPHQWDWLRQ
,QWHUDFWWKURXJK,%09LVXDO$JH
(GLWWKH-DYDOLVWLQJ
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
Given this solution: In which ways can we create and study the
underlying program?
An important goal for all programming languages is to bridge the gap
between the programmer’s understanding of the solution and the
actual code.
We will here look at three contexts for presenting the Java code of
our example.
©1998 Trygve Reenskaug
Four Faces, SDJH
3DUWRI$FWLYLW\-DYDVRXUFH
/** Activity frontloading operation
* Reports earliest completion of a predecessor
*/
public void frontload (int time ) {
earlyStart = Math.max (earlyStart, time);
if ((counter += 1) >= predecessors.length) {
int fin = getEarlyFinish();
for (int i=0; i<successors.length; i++) {
successors[i].frontload(fin);
}
}
}
~13 classes ~102 methods ~1500 lines
Model
(GLW-DYDOLVWLQJ
Run an Application
©1998 Trygve Reenskaug
Four Faces, SDJH
The simplest is to use straight text files and a text editor such as
EMACS. In Java, convention is that each class is stored in its own
file. We use the directory structure of the file system to manage
concepts such as projects, packages and class libraries.
©1998 Trygve Reenskaug
Four Faces, SDJH
,%09LVXDO$JHŠ:RUNVSDFH
Model
(GLW9LVXDO$JH
Run an Application
©1998 Trygve Reenskaug
Four Faces, SDJH
IBM VisualAge for Java is an example of a higher-level environment
for writing and exploring Java code. The environment manages the
code and can be considered to be an extension of the programming
language.
This view is a browser for the tree consisting of projects, packages,
classes and methods.
©1998 Trygve Reenskaug
Four Faces, SDJH
,%09LVXDO$JHŠ&ODVV+LHUDUFK\
Mode
(GLW9LVXDO$JH
Run an Application
©1998 Trygve Reenskaug
Four Faces, SDJH
Here is another perspective on the code, showing the class hierarchy
and the methods that will be parts of all instances. Filters permit
flattening of the code so that DOOmethods can be visible even if
implemented in a superclass.
©1998 Trygve Reenskaug
Four Faces, SDJH
,%09LVXDO$JHŠ9LVXDO&RPSRVLWLRQ
Model
(GLW9LVXDO$JH
Run an Application
©1998 Trygve Reenskaug
Four Faces, SDJH
Here is a powerful code generator for user interfaces. The
programmer paints the appearance of the interface, adding buttons,
text fields, menus, etc. (VisualAge has a capability for defining
actions. (Not illustrated here).
Many (most) programming environments provide something similar to
this.
©1998 Trygve Reenskaug
Four Faces, SDJH
,%09LVXDO$JHŠ9HUVLRQ0DQDJHPHQW
Model class
(GLW9LVXDO$JH
Run an Application
©1998 Trygve Reenskaug
Four Faces, SDJH
Another extension of the programming environment is a version
management system that appears as a seamless extension of the
programming language.
©1998 Trygve Reenskaug
Four Faces, SDJH
+\SHUWH[WGRFXPHQW$FWLYLW\FODVV
Model class
6WXG\+\SHUWH[W
Run an Application
©1998 Trygve Reenskaug
Four Faces, SDJH
Comments are in Java enclosed by a special construct:FRPPHQW
By convention this variant is defined to be part of the
documentation: GRFXPHQWDWLRQFRPPHQW
The programming environment uses this information to produce a
richly connected hypertext document. This slide shows a small part.
We have now left the programming environment; we cannot edit and
compile from the hypertext version. But the document is a YLHZ of the
code since it is produced completely automatically from the code.
©1998 Trygve Reenskaug
Four Faces, SDJH
+\SHUWH[WGRFXPHQW&ODVVKLHUDUFK\
&ODVV+LHUDUFK\
class java.lang.Object
class scheduling.Activity
class scheduling.ActivityGantry
interface scheduling.ActivityIntf
class java.awt.Component
class java.awt.Canvas
class editor1.ActivityGraph1
class editor1.BarChart1
class editor1.ResourceGraph1
class java.awt.Container
class java.awt.Panel
class java.applet.Applet
class editor1.NetworkEditor1
class editor1.ButtonStrip1
©1998 Trygve Reenskaug
Model
6WXG\+\SHUWH[W
Run an Application
Four Faces, SDJH
This is another of the automatically produced hypertext reports, it
shows the class inheritance hierarchy and can be used to navigate in
the documentation.
©1998 Trygve Reenskaug
Four Faces, SDJH
$%RWWRP8S$SSURDFK
22UDP5ROH0RGHO
80/&ROODERUDWLRQSHUVSHFWLYH
80/,QWHUIDFHSHUVSHFWLYH
80/$VVRFLDWLRQ(5SHUVSHFWLYH
80/&ODVVSHUVSHFWLYH
6WXG\DK\SHUWH[WGRFXPHQWDWLRQ
,QWHUDFWWKURXJK,%09LVXDO$JH
(GLWWKH-DYDOLVWLQJ
5XQDQ$SSOLFDWLRQ
©1998 Trygve Reenskaug
Four Faces, SDJH
Given what we can get from the code and the programming
environment, we now finally come to UML. What does it give us that
we haven’t got already and do we need it?
UML’s offerings have better be important to us, because we now
need to create and maintain a separate description outside the
program itself.
Clearly, the weaker our programming environment, the more
important will be the separate program models.
©1998 Trygve Reenskaug
Four Faces, SDJH
)RXUSHUVSHFWLYHV
,QWHUIDFHSHUVSHFWLYH
Focus on a
uni-directional
communication path
5ROH
&ROODERUDWLRQ
SHUVSHFWLYH
Focus on objects
and interactions.
:KDWDUHWKH
REMHFWVDQGKRZ
GRWKH\
FROODERUDWH"
S y ste m o f
c o lla b o ra tin g
o b je c ts
Focus on the class,
its specification
and implementation.
'DWDSHUVSHFWLYH
Focus on data entities
and their relationships
©1998 Trygve Reenskaug
&ODVVSHUVSHFWLYH
0RGHO
Code level
Run an Application
Four Faces, SDJH
UML is a very rich modeling language, encompassing most important
object oriented modeling paradigms that have been proposed over
the past years.
We will focus on the four important perspectives that are illustrated in
the slide.
©1998 Trygve Reenskaug
Four Faces, SDJH
80/&ODVVSHUVSHFWLYH
Canvas
(from java.awt)
Applet
(from java.applet)
Panel
(from java.awt)
Object
(from java.lang)
ActivityGraph1
(from editor1)
YardProxy
Resource
ResourceManager
(from editor1) (from resources) (from resources)
ResourceGantry
(from resources)
BarChart1
(from editor1)
NetworkEditor1
(from editor1)
ButtonStrip1
(from editor1)
Project
Activity
(from scheduling) (from scheduling)
ActivityGantry
(from scheduling)
UML
©1998 Trygve Reenskaug
Four Faces, SDJH
The class perspective shows the classes and their inheritance
relationships.
The class perspective can also show class attributes and method
interfaces. We have not illustrated this capability in this slide because
of space limitations.
©1998 Trygve Reenskaug
Four Faces, SDJH
80/GDWDSHUVSHFWLYH
1
tool 1
tool NetworkEditor1
(from editor1)
127(
7KLVGLDJUDPUHIOHFWVDQ
HDUOLHUYHUVLRQRIWKHSURJUDP
ButtonStrip1
(from editor1)
BarChart1
(from editor1)
barChart
1
ActivityGraph1
(from editor1)
1 projectGraph
1 buttonStrip
tool
1
1
project
1
resource
Resource
(from kernel)
Project
(from kernel)
project
1
activities
0..*
0..*
ResourceGantry
endActivities
Activity
(from kernel)
SUHGHFHVVRUV
(from kernel)
startActivities
0..*
VXFFHVVRUV
ActivityGantry
(from kernel)
©1998 Trygve Reenskaug
UML
Four Faces, SDJH
A UML association shows a relationship between classes. This is
exactly analogous to the Entity-Relationship modeling used for
modeling relational databases. As in E-R modeling, each class
represents the set of all instances of that class.
The logic of this diagram was generated automatically from the Java
code with the Rational Rose® reverse engineering tool. An exception
is that Rose did not find the DJJUHJDWLRQmodifier that says that
Acitivities are aggregated in the Project.
A more important exception is that Rose did not find the association
between Activity and Resource. In the program, this essential
association is implemented indirectly; the Activity knows the name of
the resource and asks the Project for its reference whenever it needs
it. (It can of course be added manually as we have done here. In fact,
there is no strict relationship between UML DVVRFLDWLRQV and Java
program UHIHUHQFHV).
Notice that the Activity class is associated with itself through the
VXFFHVVRUV and SUHGHFHVVRUV associations. These associations do
not identify the predecessor and successor objects, but merely state
that an Activity object is associated with some other Activity objects.
Specifically, the diagram does not say that the successors of one
Activity objects count this object among their predecessors.
©1998 Trygve Reenskaug
Four Faces, SDJH
&ROODERUDWLRQZLWKPHVVDJHVHTXHQFH
3URMHFW
3URMHFW
SUHSDUH)URQWORDG
IURQWORDGWLPH
3UHGHFHVVRU
$FWLYLW\3URMHFW
IURQWORDGWLPH
$FWLYLW\
$FWLYLW\
6XFFHVVRU
$FWLYLW\3URMHFW
UML
©1998 Trygve Reenskaug
Four Faces, SDJH
We change our perspective from classes to objects; from sets to
individuals. This permits us to study patterns of interacting objects:
What are the objects, what are their responsibilities, and how do their
collaborate to achieve the system functionality.
The (classifier) UROH represents the object’s position in the structure.
We see that instances of the Activity class play different roles:
3UHGHFHVVRU, $FWLYLW\, and 6XFFHVVRU. Instances of the 3URMHFW class
are also 3UHGHFHVVRUV, in this way a 3URMHFW can start the frontloading
operation. The 3URMHFW also plays the 6XFFHVVRU role so that it can
receive the final scheduling messages.
We achieve a VHSDUDWLRQRIFRQFHUQ a collaboration describes the
objects involved in one or more functions, focusing on the objects
involved and describing the relevant object properties.
©1998 Trygve Reenskaug
Four Faces, SDJH
&ROODERUDWLRQLQ22UDPQRWDWLRQ
P rojec t :
P rojec t
P red ec es s or :
Activity, P rojec t
A c tivity :
Activity
S u cc es so r :
Activity,
rojec t
(P
ro je ct, APctivity)
UML
©1998 Trygve Reenskaug
Four Faces, SDJH
An important UML extension mechanism is the VWHUHRW\SHwhich
adds more semantics to the basic modeling elements. A stereotype
may introduce additional values, additional constraints and a new
graphical representation.
We here illustrate the OOram extension to the UML collaboration.
The semantics of the OOram role model is more precisely defined
than the UML collaboration. The most important practical
consequences are VHSDUDWLRQRIFRQFHUQ and model refinements
through V\QWKHVLV (to be discussed later).
©1998 Trygve Reenskaug
Four Faces, SDJH
&ROODERUDWLRQ6FHQDULR22UDP
P re d e c e s s o r:
(A c tiv ity,
P ro je c t)
A ctiv ity :
A ctiv ity
S u c c e s s o r:
(A c tiv ity,
P ro je c t)
fro n tlo a d in g
(tim e)
fro n tlo a d in g
(tim e)
UML
©1998 Trygve Reenskaug
Four Faces, SDJH
A collaboration (role model) represents a pattern of objects that
interact to perform a given XVHFDVH in order to reach a specified
goal.
The scenario is one way of describing the dynamics of interacting
objects.
Note that the nodes of a scenario cannot be classes, because the
classes hide object identity and we cannot know which object sends
and which object receives the messages.
©1998 Trygve Reenskaug
Four Faces, SDJH
&ROODERUDWLRQLQ22UDPQRWDWLRQ
P rojec t :
P rojec t
A c tM an ag em entIntf
p re pa re B a ckloa d
p re pa re Fron tloa d
P red ec es s or :
Activity, P rojec t
Frontload Intf
fro ntlo ad
©1998 Trygve Reenskaug
B a ck load In tf
b acklo ad
A c tivity :
Activity
S u cc es so r :
Activity,
rojec t
(P
ro je ct, APctivity)
UML
Four Faces, SDJH
We see the ClassifierRoles as super-ellipses and the
AssociationEnds as small circles, called SRUWV. A port represents an
object’s UHIHUHQFHto a collaborator, it is implemented as a variable or
a function or some kind of constant. Java permits the typing of
references with LQWHUIDFHVwe have illustrated some interfaces in this
slide.
©1998 Trygve Reenskaug
Four Faces, SDJH
7RS/HYHO&ROODERUDWLRQ
<DUG
3URMHFW
5HVRXUFH
0DQDJHU
$FWLYLW\
5HVRXUFH
UML
©1998 Trygve Reenskaug
Four Faces, SDJH
This is an illustration of the OOram VHSDUDWLRQRIFRQFHUQWe have
previously studied the details of the scheduling operation. We now
take a wider view and model the overall system architecture.
Compare to figure 6. We see that the current version of the program
reflects our initial intuition fairly well. The exception is that we do not
model the product; this has been postponed to a future version.
©1998 Trygve Reenskaug
Four Faces, SDJH
5HVRXUFH$OORFDWLRQ22UDP
A c tiv ity :
A ctivity
R e s o u rc e :
R e source
©1998 Trygve Reenskaug
UML
Four Faces, SDJH
We again change Area Of Concern, this time to model the negotiation
between an Activity and its Resource for allocating access.
We do not give the details here, but note that we model and program
each Activity-Resource pair to reflect their special characteristics. The
Gantry craneResource can, for example, ask the lifting Activity for
the weight of the load before it makes the appropriate allocation.
©1998 Trygve Reenskaug
Four Faces, SDJH
22UDP5ROH0RGHO6\QWKHVLV
P ro ject :
A ctivity :
A ctivity :
P red ec es s or :
R eso u rce :
S u cce sso r :
P ro ject :
R eso u rce :
SUHSDUH)URQWORDG
P red ecesso r :
A ctivity :
A ctivity:
IURQWORDGWLPH
©1998 Trygve Reenskaug
H
HUY
UHV
S u cce sso r :
IURQWORDGWLPH
UML
Four Faces, SDJH
We now use V\QWKHVLVto create a composite model that shows the
scheduling process combined with the resource allocation process.
The resulting GHULYHGPRGHO is linked to two EDVHPRGHOV and reflect
the static and dynamic properties of these models. So the use cases
of the base models are all included in the derived model, either as
explicit use cases or as subordinate use cases that become part of
other functions.
Technically, every role in every base model is mapped onto some
role in the derived model. The ports (association ends) of the derived
model includes the combined interfaces of all the corresponding base
ports. And the behavior of the derived model as described by its
scenarios includes all the behaviors of the base models.
©1998 Trygve Reenskaug
Four Faces, SDJH
,QWHUIDFHVSHFLILFDWLRQ22UDP
SDFNDJH VFKHGXOLQJ;
SXEOLFLQWHUIDFH )URQWORDG,QWI {
5HSRUWVHDUOLHVWFRPSOHWLRQ
SXEOLFYRLG IURQWORDG (int time );
'RWKHUHVRXUFHDOORFDWLRQ
void UHVHUYH5HVRXUFH();
}
UML
©1998 Trygve Reenskaug
Four Faces, SDJH
We finally show theLQWHUIDFHSHUVSHFWLYH. Interfaces can be used to
define the external properties of a class. In collaboration modeling we
are using them to specify the messages that may flow along the
different collaboration paths.
We here show the OOram and Java perspectives on the same
interface. The OOram interface can be specified informally or formally
according to what is most convenient.
©1998 Trygve Reenskaug
Four Faces, SDJH
6RZKDW"
•
6HOHFW\RXUSURJUDPPLQJHQYLURQPHQW
WKDWVXLWV\RXUQHHGV
• Use UML class perspective to design class
hierarchies
• UML data (E-R) perspective may be
superseded by collaborations
• 8VHLQWHUIDFHPRGHOLQJIRUGLVWULEXWLRQ
•
•
DQGUHXVDEOHFRPSRQHQWV
8VH80/FROODERUDWLRQV22UDPUROH
PRGHOVZKHQZRUNLQJZLWKLQWHUDFWLQJ
REMHFWV
8VH22UDPV\QWKHVLVIRUUHXVDEOH
SDWWHUQV
©1998 Trygve Reenskaug
Four Faces, SDJH
Our advice must necessarily be subjective, based on our own
preferences and experience.
We find that a powerful programming environment covers most of our
needs. Its main weakness is that it neither isolates the different
functions (use cases, subjects), nor shows how they are
accomplished in the object structure. We therefore add collaborations
(role models) for designing and documenting critical functions.
On a more advanced level, OOram synthesis is very powerful for
designing, documenting and applying reusable patterns and
frameworks.
©1998 Trygve Reenskaug
Four Faces, SDJH
5HIHUHQFHV
• http://www.ifi.uio.no/~trygve
http://www.numerica-taskon.no
:RUNLQJ:LWK2EMHFWV
• Reenskaug, Wold, Lehne:
Manning/Prentice Hall 1996. ISBN 0-13-452930-8
•
8QLILHG0RGHOLQJ/DQJXDJH80/ Proposal to the Object
Management Group. Version 1.1, September 1, 1997.
Documents can be retrieved from the OMG at
ftp://ftp.omg.org/pub/docs/ad. Document numbers 97-0802 through 97-08-05 define the standard.
&RQFHSWXDO0RGHOLQJRI2EMHFWV$5ROH
0RGHOLQJ$SSURDFK Dr Scient theses. Dept. of
• Egil P. Andersen:
Informatics, University of Oslo. 4 November 1997.
:RUNLQJZLWKREMHFWV$WKUHHPRGHO
DUFKLWHFWXUHIRUWKHDQDO\VLVRILQIRUPDWLRQV\VWHPV JOOP
• Trygve Reenskaug :
May 1997.
©1998 Trygve Reenskaug
©1998 Trygve Reenskaug
Four Faces, SDJH
Four Faces, SDJH
Download