Documente Academic
Documente Profesional
Documente Cultură
Modeling
JiHsian Lee
Web:http://202.201.18.40:8080/mas5/labs/home.jsp?id=7
The School of Mathematics, Physics and Software Engineering
Lanzhou Jiaotong University
1 Fundamentals of OOM 7
1.1 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Model Organization . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Structured Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Object Orientation . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Encapsulation of Hardware . . . . . . . . . . . . . . . . . . . . 12
1.7 Encapsulation of Software . . . . . . . . . . . . . . . . . . . . 12
1.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 UML - Part 1 19
2.1 UML - What It Is . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Why Use UML? . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 How UML Started . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 UML Diagram Types . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Business Modelling, Web Applications, and extending UML . 26
2.6 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7.1 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3
4 CONTENTS
2.7.2 Relationships . . . . . . . . . . . . . . . . . . . . . . . 36
2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 UML - Part 2 45
3.1 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Statechart Diagram . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . 53
3.6 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 Modelling Architecture . . . . . . . . . . . . . . . . . . . . . . 56
3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.9 Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A Answers 71
CONTENTS 5
B CRC 73
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.3 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.4 CRC Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B.5 Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6 CONTENTS
Chapter 1
Fundamentals of OOM
This chapter explains the principles behind modeling and abstraction and
shows how they can be applied to object oriented models and systems.
1.1 Abstraction
1.2 Modeling
7
8 CHAPTER 1. FUNDAMENTALS OF OOM
view is an “orthogonal” view, see Figure. 1.1. Each view is needed for a full
understanding of the system. Views are orthogonal when:
• The interaction model is, in turn, derived from the Use Case model
which defines the functionality of the system from a user’s perspective.
• The dynamic model defines the order and conditions under which things
are done and is also mapped onto the object model.
are encapsulated into systems. See Figure. 1.6. If this is done well the result
is:
• Maximal coherence(一致)
• Minimal interconnection
1.8 Summary
• Abstraction is about looking only at the information that is relevant
at the time.
• In object oriented analysis, the object model, or data view, is the pri-
mary, and most stable view of the system.
1.9 Quiz
1. Abstraction is about
(c) It stops you worrying about them when they are not important
4. Model elements
5. In structured analysis
6. In object orientation
(a) The functionality of the object model is derived directly from the
use case model
(c) The object model is the most stable view of the system
7. Encapsulation of hardware
8. Object orientation
UML - Part 1
This chapter explains the origins of UML and some of the different kinds of
diagrams available within it.
19
20 CHAPTER 2. UML - PART 1
遗赠 物,遗
• Appropriate For Both New and Legacy(遗 遗产) Systems.
可描 绘, 可 描 写,可
• Inherent Traceability(可 可追 溯).
The Use Case Driven nature of modelling with UML ensures that all
levels of model trace back to elements of the original functional re-
quirements. This traceability between models comes without the extra
effort creating and maintaining a “traceability matrix” which can be a
complex and time consuming job. The result is that the impact of a
requested change can quickly be estimated. A change in requirements
2.2. WHY USE UML? 23
can be traced though analysis and design models into those components
affected and even lines of code. The code affected can then be traced
back to the requirements and total regression testing(回归测试) effort
calculated.
their relationships. UML does not specify what diagrams should be created
or what they should contain, only what they can contain and the rules for
connecting the elements. the diagram types include:
• 从单独的建模,到设计级代码生成,再到可全面执行的应用程序生成
• 自动或按需而定的Java 同步
• 与领先的IDE 集成
• 基于UML 的数据建模
• 用领先的数据库管理系统进行数据模型同步
• 多用户支持Web 发布和生成报告
2
Jim Conallen is a software engineer in IBM Rational’s Model Driven Development
2.6. USE CASE DIAGRAM 27
about them by following the link. These symbols are also available in cur-
rent versions of Rational Rose.
UML is designed to be extended in this way. Extensions to the syntax are
created by adding “stereotypes(固定形式)” to a model element. The stereo-
type creates a new model element from an existing one with an extended,
user-defined, meaning. User defined symbols, which replace the original UML
symbol for the model element, can then be assigned to the stereotype. UML
itself uses this mechanism, so it is important to know what stereotypes are
predefined in UML in order not to clash with them when creating new one.
Stereotypes allow the UML syntax to be used to model anything.
• Actors (stick men) are anything outside the system that interacts with
the system.
• Use Cases (ovals) are the procedures by which the actors interact with
the system
• Solid lines indicate which actors interact with the system as part of
which procedures
• Dotted lines show dependencies between use cases, where one use case
is “included” in or “extends” another.
Strategy team, where he is actively involved in applying the Object Management Group’s
(OMG) Model Driven Architecture (MDA) initiative to IBM Rational’s model tooling.
28 CHAPTER 2. UML - PART 1
Figure 2.3: The Extend and Include Relationships Among Use Cases
a program proceeds. Class diagrams are, therefore, used more often than
object diagrams to show this view3 .
Classes define the properties of the objects which belong to them. See
Figure. 2.5. These include:
2.7.1 Class
associated with the class are suppressed. The second example illustrates a
class with the attributes and operations represented. In the second example,
the name of the class appears in the top section, the attributes in the middle
section, and the operation in the bottom section.
Attributes are specified according to the following notation:
where,
where,
As was the case with attributes, only the name of the operation must be
specified; the other fields are optional.
Figure. 2.8 illustrates how a constraint can be attached to a class. Any-
thing may appear within the brace identifying the constraint. Most practi-
tioners use a textual description of the constraint.
Figure. 2.9 shows a package diagram. According to the UML specification,
a package is illustrated using a folder-style icon. When the classes contained
within the package are suppressed, the name of the package goes in the center
of the folder. When the classes are present, the name of the package goes in
the tab portion of the folder. Dependencies between packages are illustrated
36 CHAPTER 2. UML - PART 1
2.7.2 Relationships
2.8 Summary
• UML is just a syntax. It says nothing about how too create a model.
at Rational Software.
• A use case diagram show the functionality of the system from the out-
side in.
2.9 Quiz
1. Interaction diagrams include
2. UML is
(d) 2b and 2c
(e) 2a and 2b
(c) Flowcharts are used to show the order in which objects interact
(d) Activity diagrams can be used to show the overall flow of a use
case
(c) 5a and 5b
6. A use case is
(c) The way an actor to achieves the goal that is the name of the use
case
(d) 7a and 7b
(e) 7b and 7c
Chapter 3
UML - Part 2
This chapter explains the rest of the different kinds of diagrams available
within UML.
• Messages — solid lines for calls and dotted lines to data returns, show-
ing the messages that are send between objects. This includes the order
of the messages which is from top of the diagram to the bottom.
45
46 CHAPTER 3. UML - PART 2
• Object lifelines — dotted vertical lines showing the lifetime of the ob-
jects.
operation remains active until all the sequential operations, which it calls,
have completed and returned, thus, allowing it to return control to its caller.
Figure. 3.2 shows a typical sequence diagram for using a microwave oven.
• Object Links — solid lines between the objects. These represent the
references between objects that are needed for them to interact and so
show the static structure at object level. On the links are:
• Messages — arrows with one or more message name that show the
direction and names of the messages sent between objects
• It shows links between objects along which messages can flow whereas
only the messages are shown in a sequence diagram.
item The order of the messages can only be seen in their numbering as
the vertical dimension is used to show static relationships along with
the horizontal dimension.1
use case.2
The concepts and paths in this diagram are
• Relationship role, represents role that the link may play within the
interaction.
where
• States — rounded boxes which indicate the stable states of the object
between events. A state represents a period between events during the
object is stable. If an object has many internal states, the state model
can be simplified by using “nested state” within a simpler state model.
• Events — the text on the transitions before the “/” showing the in-
coming call to the object interface which causes the change of state.
• Actions — the text after the “/” which represents a set of operations
that is done inside of a state or on a transition.
• Transitions — which show the order in which the active states occur
and represent a thread of activity.
3.8 Summary
• Sequence diagrams show potential interactions between objects in the
system in the order in which they normally occur.
3.9 Quiz
1. The activation on a sequence diagram shows
(d) 2a and 2b
(e) 2b and 2c
(d) 3a and 3b
(e) 3b and 3c
(d) 5a and 5b
(e) 5b and 5c
(d) 6a and 6b
(e) 6b and 6c
61
62 CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS
• Slightly different symbols for business actors and business use cases
(also known as business processes).
• The system boundary is now the business or the part of the business
being modelled.
• Defines logical requirements in more detail than the use case model,
rather than a physical solution to the requirements.
The overall process flow must allow for both rework and incremental devel-
opment. See Figure. 4.3.
• Rework — where changes need to be made, the earliest model that the
change affects is changed first and the results flowed forward through
all the other models to keep them up to date.
4.8 Summary
• A software process is needed to make a software development pre-
dictable and repeatable.
• Functional requirements are defined with use cases and use case de-
scriptions.
4.9. QUIZ 67
• The use case model feeds the object, interaction and state models which
are interdependent.
4.9 Quiz
1. Business process modelling of use cases uses
(a) Topology
(b) Technology
(c) Functionality
(d) 3a and 3b
(e) 3b and 3c
(d) 4a and 4b
(e) 4b and 4c
6. An increment starts at
4.9. QUIZ 69
(a) requirements
(b) analysis
(c) design
(d) coding
7. A increment produces
Answers
71
72 APPENDIX A. ANSWERS
Appendix B
CRC
B.1 Introduction
B.2 Problem
73
74 APPENDIX B. CRC
B.3 Perspective
just the right set of words to describe our objects, a set that is internally
consistent and evocative in the context of the larger design environment.
Responsibilities identify problems to be solved. The solutions will exist in
many versions and refinements. A responsibility serves as a handle for dis-
cussing potential solutions. The responsibilities of an object are expressed
by a handful of short verb phrases, each containing an active verb. The more
that can be expressed by these phrases, the more powerful and concise the
design. Again, searching for just the right words is a valuable use of time
while designing. One of the distinguishing features of object design is that no
object is an island. All objects stand in relationship to others, on whom they
rely for services and control. The last dimension we use in characterizing
object designs is the collaborators of an object. We name as collaborators
objects which will send or be sent messages in the course of satisfying re-
sponsibilities. Collaboration is not necessarily a symmetric relation. For
example in Smalltalk- 80, View and Controller operate as near equals (see
example below) while OrderedCollection offers a service with little regard or
even awareness of its client. Throughout this paper we deliberately blur the
distinction between classes and instances. This informality is not as confus-
ing as it might seem because the concreteness of our method substitutes for
naming of instances. This also makes our method for teaching independent
of whether a class or prototype-based language is used.
encourage learners to pick up the card whose role they are assuming while
”executing” a scenario. It is not unusual to see a designer with a card in each
hand, waving them about, making a strong identification with the objects
while describing their collaboration. We stress the importance of creating
objects not to meet mythical future needs, but only under the demands of
the moment. This ensures that a design contains only as much information
as the designer has directly experienced, and avoids premature complexity.
Working in teams helps here because a concerned designer can influence team
members by suggesting scenarios aimed specifically at suspected weaknesses
or omissions.
B.5 Experience
One of the contexts in which we have used CRC cards is a three-hour class
entitled ”Thinking with Objects,” which is intended for computing profes-
sionals who have programmed, but whose jobs do not necessarily involve
programming every day. The class proceeds by introducing a data flow ex-
ample (a school, with processes for teaching and administration) which is
then recast in terms of objects with responsibilities and collaborators (such
as Teacher, Janitor, and Principal). The class then pairs off and spends an
hour designing the objects in an automatic banking machine, an exercise
chosen because of everyone’s familiarity with the application and its ready
breakdown into objects to control the devices, communicate with the central
bank database, and control the user interface. (See the appendix for a sam-
ple solution.) The exercise is followed by a definition of the terms ”class”,
”instance”, ”method”, and ”message”, and the class concludes with a brief
discussion of the history and features of a variety of object- oriented pro-
80 APPENDIX B. CRC
B.6 Conclusion
Taking our perspective as a base we give novices and experienced program-
mers a learning experience which teaches them something valuable about
objects. CRC cards give the learner who has never encountered objects a
physical understanding of object-ness, and prepares them to understand the
vocabulary and details of particular languages. CRC cards also give useful
and convincing experience with objects to those who has learned the mecha-
nisms of objects but do not yet see their value. Ragu Raghavan has said that
in the switch to objects strong programmers become stronger, but weaker
programmers are left behind. Using the cards in group settings we found
that even weaker programmers, without a deep understanding of objects,
could contribute to object designs. We speculate that because the designs
are so much more concrete, and the logical relationship between objects ex-
plicit, it is easier to understand, evaluate, and modify a design. We were
surprised at the value of physically moving the cards around. When learners
pick up an object they seem to more readily identify with it, and are pre-
pared to deal with the remainder of the design from its perspective. It is the
value of this physical interaction that has led us to resist a computerization
of the cards. It is just this problem-integrating the cards with larger design
methodologies and with particular language environments, that we feel holds
the most promise for the future. The need to retain the value of physical
interaction points to the need for a new kind of user interface and program-
ming environment as far beyond what we have today as our current systems
are beyond the tool-oriented environments of the past.