Course material from my Object-Oriented Development course. This presentation introduces models, diagrams, and the UML.

1. MODELING
3 AND UML
OVERVIEW

2. 1 INTRODUCTION
2 METHODOLOGIES
3 MODELS AND UML
4 OBJECT CONCEPTS
5 ANALYSIS
2
6 SOFTWARE DESIGN

3. Goal of Presentation
3
 This presentation will
 Define model and diagrams and explain importance of
them to system development.
 Introduce UML

4. Definitions
4
 A model is a simplified representation of
something in the real world, usually for the purpose
of understanding that reality, and having all the
features of that reality necessary for the current
task or problem.
 Like a map, a model represents something else.
 Thus modeling is a form of abstraction, that is, the
process of focusing only on features essential to the
problem at hand.
Source: David William Brown, An Intro to Object-Oriented Analysis (Wiley, 2002), p. 30

5. What Are Models For?
5
 Models are used for:
 To capture and precisely state requirements and domain
knowledge so that all stakeholders may understand and
agree on them.
 To think about the design of a system.
 To capture design decisions in a mutable form separate
from the requirements.
 To generate usable work products.
 To organize, retrieve and edit info about large systems.
 To explore multiple solutions economically.
 To master complex systems.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 13-4

6. Levels of Models
6
 Models take on different forms and appear at
different levels of abstraction.
 A useful model has the right level of detail and represents
only what is important for the task in hand.
 The amount of detail in the model is adapted to one of
the following purposes:
 Guides to the thought process.
 Abstract specifications of the essential structure of a system.
 Full specification of a final system.
 Exemplars of typical or possible systems.
 Complete or partial descriptions of systems.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 15-6

7. Many Matching Models
7
 Each model emphasizes some aspect of the real-
world thing.
 Thus, many models are required to reveal all the
important details of that thing.
 Yet, these matching models must eventually fit
together.
 What is represented in one model must be consistent
with what is represented in another model.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 51

8. 8

9. Diagrams
9
 Diagrams are abstract shapes that are used to
represent things or actions from the real world
 Diagrams follow rules or standards
 The standards make sure that different people will
interpret the diagram in the same way
40°
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 98-9.

10. Author Reviewer Typesetter Printer
An Example
of a Diagram
Write Chapter
10
Review Chapter
 An activity Revise Chapter
[book not
diagram of the complete]
[book complete]
tasks involved in
producing a book. Typeset Book
Correct Proofs
Reset Book
Print Book
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design presentation.

11. Hiding Detail Write Chapter
Plan Chapter
11 Author Reviewer Typesetter Printer
Produce
First Draft
Write Chapter
Revise Draft
Review Chapter
[not satisfied]
[satisfied]
Revise Chapter
Add Exercises
[book not
complete]
[book
Add References
complete]
to Bibliography
Typeset Book
Correct Proofs
Reset Book
Print Book
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design presentation.

12. Diagrams versus Models
12
 A diagram illustrates some aspect of a system.
 A model provides a complete view of a system at a
particular stage and from a particular perspective.
 A model may consist of a single diagram, but most
consist of many related diagrams and supporting
data and documentation.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 100-1.

13. Models in Systems Development
13
 To understand the user’s world we need:
 People sensitivity (interviewing and listening skills) for
gathering relevant and accurate information.
 Modeling diagrams to document and communicate
what we’ve learned from the users.
 We are using UML as our modeling notation.
 Modeling techniques to ensure these notations produce
an accurate picture of the user’s business.
 These are partly defined by:
 the modeling notation itself, as well as
 the software process/methodology.
Source: David William Brown, An Intro to Object-oriented (Wiley, 2002), p. 38

14. Developing Models
14
 The models that we produce during the development of
a system change as the project progresses.
 They change by degree of:
 Abstraction
 Model will become less abstract and more concrete.
 Formality
 Degree of formality in which methods, attributes, and constraints
are defined will increase as project progress.
 Level of detail
 More potential detail in every model as project progresses.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 103-5.

15. Development of Use Case Model through successive iterations
Staff Management
Iteration 1
Add a new staff
member
Staff Management
Add a new staff
member
Add a new staff
grade
Add a new staff
grade
Change the
rate for a
staff grade
Obvious use cases.
Ac countant Change the
rate for a
staff grade Change the
grade for a
staff member
Ac countant
Change the
grade for a
staff member
Calculate staff
bonuses
Simple use case descriptions.
Calculate staff
bonuses
Staff Management
Add a new staff
member
Staff Management
Iteration 2
Add a new staff
member
Staff Management
Add a new staff
grade
Add a new staff Campaign Selection
member
Add a new staff
grade
Change the
Campaign Selection
rate for a
staff grade Client: Holborn Motors
Add a new staff Campaign Selection Lynch Properties
grade
Ac countant Change the
rate for a Client: Holborn Motors
Yellow Partridge
Yellow Partridge
staff grade Change the Lynch Properties
Zeta Systems
Additional use cases.
grade for a
Change the
staff member
Client: Holborn Motors
Yellow Partridge
Yellow Partridge
Ac countant
Spring Jewellery Campaign 1997
Campaign:Lynch Properties
Zeta Systems
rate for a
staff grade Change the
grade for a Spring Jewellery Campaign 2001
Yellow Partridge
staff member
Spring Jewellery Campaign 1997
Zeta Systems Jewellery Campaign 2002
Spring
Ac countant Calculate staff
Campaign:
Change the
bonuses
Spring Jewellery Campaign 2001
Summer Collection 1998
grade for a Spring Jewellery Campaign 2002
Spring Jewellery Campaign
staff member Campaign:
Calculate staff
Summer Collection 1998
2002
bonuses
OK Quit
Simple use case descriptions.
Calculate staff
bonuses
OK Quit
OK Quit
Prototypes.
Iteration 3
Campaign Management
Assign staff
to work on
a campaign «include»
Campaign Management Find campaign
Assign staff «include»
to work on
a campaign
Add a new
«include» ert to
adv Campaign Selection
a campaign
«include»
Find campaign
Campaign Management
Assign staff
to work on
Campaign
Manager
Add a new
«include»
Campaign Selection
a campaign «include» ert to
adv
a campaign
Check campaign
«include»
Find campaign budget Client: Holborn Motors
Campaign «include»
Campaign Selection Lynch Properties
Manager
Add a new
adv ert to «extend» «extend»
Client: Holborn Motors
Yellow Partridge
Yellow Partridge
Structured use cases.
Check campaign
a campaign
«include»
budget Lynch Properties
Zeta Systems
Campaign
Manager
Print campaign
summary
Print campaign
invoice
Client: Holborn Motors
Yellow Partridge
Yellow Partridge
Spring Jewellery Campaign 1997
Campaign:Lynch Properties
«extend» «extend»
Check campaign
budget
Zeta Systems
Spring Jewellery Campaign 2001
A ccountant
Print campaign Print campaign Yellow Partridge
summary invoice
Spring Jewellery Campaign 1997
Zeta Systems Jewellery Campaign 2002
Spring
«extend» «extend»
Campaign:
A ccountant
Spring Jewellery Campaign 2001
Summer Collection 1998
Print campaign Print campaign
Spring Jewellery Campaign 2002
Spring Jewellery Campaign
summary invoice
Campaign:
Summer Collection 1998
2002
Structured use case descriptions.
A ccountant
OK Quit
OK Quit
OK Quit
Prototypes.
15
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 104.

16. Earlier Models and Diagrams
16
 A variety of modeling notations have developed
over the years. These include:
 Process
models (data flow diagrams)
 Data models (ERDs)

17. Process Models: Data Flow
17
Diagrams
 Focus not just on operations but on who does what with
whom. That is, the focus is on data and how it processes
through an organization.
 Used Data Flow Diagrams (DFDs) as a way to model
the activities, functions, and processes that make up a
users’ business.
Student Details Registration
Validated Student Student
Details Records
Acknowledgement
of Registration
Student
Enrollment
Confirmation
Confirmation of
Enrollment Request Enrollment Enrollment
Confirmed
Vacancies Courses
Enrollments Enrollments

18. Data Models: ERDs
18
 Focus on data modeling rather than on process
modeling.
 Entity Relationship Diagrams (ERDs) used as analysis
tool as well as a database design tool.

19. OO Diagramming
19
 There are all sorts of different OO diagrams:
 e.g., Booch OOD, Rumbaugh OMT, Yourdon & Coad, etc.
 UML (Unified Modeling Language) has become the
standard notation for OO diagramming and modeling.
 The modeling notation defined by UML does not define a
modeling technique
 These are defined by the software process/methodology.
 UML is not a methodology or process; rather it is a universal
modeling notation.

20. UML Defined
20
 The Unified Modeling Language (UML) is a general
purpose visual modeling language that is used to
specify, visualize, construct, and document the
artifacts of a software system.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

21. UML Defined
21
 It captures decisions and understanding about
systems that must be constructed.
 It is used to understand, design, browse, configure,
maintain, and control information about systems.
 It is intended to be used with all development
methods, lifecycle stages, application domains, and
media.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

22. Not A Programming Language!
22
 The UML is not a programming language !
 The UML is a general-purpose modeling notation
for discrete systems such as software.

23. Goals of UML
23
 There were a number of goals behind the development of UML:
 UML is a general-purpose modeling language that all modelers can use.
 It is meant to include the concepts of the leading methods so that it can
be used as their modeling language.
 It was intended to be as familiar as possible.
 It is meant to support good practices for design such as encapsulation,
separation of concerns, and capture of the intent of a model construct.
 It is intended to address current software development issues, such as
large scale, distribution, concurrency, patterns and team development.
 It was to be as simple as possible while still being capable of modeling
the full range of practical systems that need to be built.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 8-9

24. What Does Unified Mean?
24
 The word unified has the following relevant
meanings for UML:
 Across historical methods and notations.
 Across the development lifecycle
 Across application domains
 Across implementation languages and platforms
 Across development processes
 Across internal concepts
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 7-8

25. UML Building Blocks
25
 UML is composed of three building blocks:
 Things
 These are the modeling elements
 Relationships
 These tie things together
 Diagrams
 These are views into UML models
Source: Booch, The Unified Modeling Language User Guide (Addison-Wesley, 1998), p. 2.

26. UML Things
26
 UML thing may be partitioned into:
 Structural things
 Represent the nouns of a UML model such as class, component, use
case, etc
 Behavioral things
 Represent the verbs of a UML model such as interactions, states,
etc.
 Grouping things
 Represent things that group elements together such as the
package.
 Annotational things
 The note
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 9.

27. UML Relationships
27
 Used to show how two or more things
relate to each other.
generalization association
dependency realization
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 10.

28. Diagrams in UML
28
 UML diagrams consist of: Write Chapter
 icons Plan Chapter
 two-dimensional symbols Produce
First Draft
 paths
Revise Draft
 Strings
[not satisfied]
 UML diagrams are views into the model. [satisfied]
 They are not the model itself Add Exercises
Add References
to Bibliography
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design presentation.

29. UML Diagrams
29
Static Model Dynamic Model
class diagram object diagram
component diagram use case diagram
deployment diagram sequence diagram
collaboration diagram
statechart diagram
activity diagram
Source: Arlow and Neustadt, UML and the Unified Process (Addison-Wesley, 2002), p. 11.

30. UML Parts
30
 A system is modeled as a collection of discrete
objects that interact to perform work that ultimately
benefits an outside user.
 UML has:
 static
and,
 dynamic parts.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

31. Static and Dynamic Information
31
 In particular UML captures information about the static structure and the dynamic
behavior of a system.
 The static structure defines the kinds of objects important to a system and to its
implementation, as well as the relationships among the objects.
 The dynamic behavior defines the history of objects over time and the communications
among objects to accomplish goals.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3

32. Organization
32
 The UML also contains organization constructs for
arranging models into packages that permit software
teams to:
 partition large systems into workable pieces.
 understand and control dependencies among the packages,
and
 manage the versioning of model units in a complex
development environment.
 The UML contains constructs for representing
implementation decisions and for organizing run-time
elements into components.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 3-4

33. UML Concepts
33
 system
 The overall thing that is being modeled.
 sub-system
 Part of the system.
 model
 An abstraction of system or subsystem from a particular
perspective or view.
 Different models present different views of the system.
 diagram
 A graphic representation of a set of elements in the model.
Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 102.

34. Static Structure
34
 Any precise model must first define the universe of
discourse.
 That is, the key concepts from the application, their internal
properties, and their relationships to each other.
 This set of constructs is the static view of the system.
 The static view is notated by class diagrams (also called
class static structure diagrams).
 That is, the application concepts are modeled as classes,
each of which describes a set of discrete objects that hold
information and communicate to implement behavior.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 9

35. Class static structure diagrams
35
BankAccount Customer
-customerName
-accountNum
-balance
+getCustomerName()
+getAccountNum()
+getBalance()
+setBalance()
Loan CheckingAccount
-interestRate -serviceCharge
+makePayment() +deposit()
+addInterest() +withdrawal()

36. Dynamic Behavior
36
 There are two ways to model behavior:
 One is the communication patterns of a set of
connected objects as they interact to implement
behavior.
 This is modeled using use case diagrams, sequence
diagrams, collaboration diagrams, and activity diagrams.
 The other is the evolution of an object’s state over time
as it interacts with the rest of the world.
 State change refers to possible changes in object’s attributes
and associations with other objects.
 This is modeled as a statechart.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 9-10

37. Use Cases
37
 When we analyze a system we try to identify the
main functionality that the system will have and the
main ways it will be used.
 Each of these ways the system is going to be used is
called a use case.
A use case is a sequence of actions a system performs
that yields an observable result of value to a particular
actor.
 An actor is either a person (user) interacting with the system
or, in some cases, another system interacting with the system.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 53

38. Using Use Cases
38
 A use case captures the main functionality of the
system from a user or actor’s perspective.
 It also serves as a vehicle to divide the system into
parts that can be implemented somewhat
separately.
 For any given system, we will usually develop and
implement the most important use cases first.
 Establishing which use cases are important often follows
from looking at the main events in the problem domain.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 54

39. Use Case Diagram
39
 We can model use cases in a use case diagram.
 Stickfigures represent actors.
 Ovals represent the use case.
 The arrows show interactions.
Video Store System
Rent Videos
Video Store Clerk Add New Videos

40. Activity Diagrams
40
 Used to model business activities/tasks in the very
early stages of a project.
 Also used to describe a system function described
by a use case.
 They are analogous to standard flowcharts.

41. Activity Diagrams
41
activities Add a New
Client
transitions
Assign Staff
Contact
[new campaign]
decisions
[campaign to add]
object flow
Add New
Campaign
object
:Campaign

42. Activity Diagrams
42
 Swimlanes Campaign
Manager
Accountant Client
 vertical columns
Record Completion
 labelled with the of a campaign
person, organisation
Issue invoice
or department
responsible for the
Pay invoice
activities in that
column Record client
payment

43. Sequence Diagrams
43
 The class diagram is limited in that it does not
represent time-dependent behaviors.
 Sequence diagrams present object interactions
arranged in time sequence.
 Itshows the actors or objects participating in an
interaction and the events they generate arranged in a
time sequence.
 Often, a sequence diagram shows the events that result
from a particular instance of a use case but a sequence
diagram can also exist in a more generic form.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 62

44. Sequence Diagrams
44
Patron Librarian System
SubmitResources()
Rectangles represent objects.
Stick figures represent actors.
Vertical lines represent the lifeline of the object or actor.
SubmitLibraryCard()
Horizontal arrows indicate messages.
RecordID()
CheckStatus()
status()
RecordCallNumber()
CalcDueDate()
RecordLoan()
dueDate()

45. Collaboration Diagram
45
 A collaboration diagram shows interactions
organized around the objects and their messages to
each other.
 Collaboration diagrams and sequence diagrams are
used interchangeably.
 Unlike a sequence diagram, a collaboration
diagram shows relationships among object roles
and it does not express time as a separate
dimension.
Message1()
2: Message2()
3: Message3()
ClassAInstance ClassBInstance

46. Statechart Diagram
46
 The statechart diagram shows the states an object
might be in and the actions or conditions that cause an
object to make a transition from one state to another.
 By documenting events and transitions, a statechart
diagram shows the sequence of states an object goes
through during its life.
 Statecharts are extensions of the class diagram and
you could create one statechart for each class.
 In practice, you will only create a statechart for those
classes that exhibit especially interesting or complex time-
dependent behavior.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 60

47. Statechart Diagram
47
Retrieving Books Packaging
setFulfilledFlag
Shipped Shipping
Boxes represent states.
Arrows represent transitions between states.
Solid dots represent start and end states.

48. Model Organization
48
 Computers can deal with large flat models, but
humans cannot.
 In a large system, modeling information must be
divided into coherent pieces so that teams can work
on different parts concurrently.
 Packages are general-purpose hierarchical
organizational units of UML models.
 Packages can be used for storage, access control,
configuration management, and constructing libraries
that contain reusable model fragments.
Source: Rumbaugh, Jacobson, Booch, Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 10

49. Packages
49
 If the class diagram becomes large, it will become
quite difficult to use for an overview of the system.
 In such cases we create a high-level view of the system,
using some kind of partitioning or cluster scheme.
 UML calls these clusters packages and provides
modeling notation called a package diagram.
Sales Human Resources