Modeling with UMLPart 1

1
Modeling with UMLPart 1

• Lecture 03
• Software Engineering and
• Project Management
• Instructed by Steven Choy on Oct 9, 2006

2
UML Overview

• The OMG specification states

"The Unified Modeling Language (UML) is a
graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a
software-intensive system. The UML offers a
standard way to write a system's blueprints,
including conceptual things such as business
processes and system functions as well as
concrete things such as programming language
statements, database schemas, and reusable
software components.
3
Why UML?

• Better communication with user
• A language that is understandable by people from
  different technical backgrounds
• Accurate communication between developers
• A language with standard notation to model
  Object-oriented software system
• Give developer an overview of the whole system

4
UML Diagram Family

• Use Case Diagram
• Class Diagram
• Interaction Diagram
• State Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram
• (more)

5
What you will learn

• Unified Modeling Language (UML)
• Use case diagram
• Class Object diagram
• Interaction diagram
• State diagram
• Activity diagram

6
The Need to Model
When we began to craft the Unified Modeling
Language, we hoped that we could produce a
standard means of expressing design that would
not only reflect the best practices of industry,
but would also help demystify of a standard
modeling language would encourage more developers
to model their software systems before building
them. Grady Booch Ivar Jacobson James
Rumbaugh
7
What UML tries to model?

• Functional Model
• Describe the functionality of the system from
  users point of view
• Object Model
• Describe the structure of the system in terms of
  objects, attributes and operations.
• Describe the relationship between objects
• Dynamic Model
• Describe the internal behaviour of the system

8
Use Case
9
Understand Users World

• Building the RIGHT system involves a good
  communication and understanding of users
  requirement
• Question, Question, Questions
• What features do we need to provide?
• Who will use/interact the system?
• How does the system relate to other systems?
• User does not speak technical jargon
• ? Use Case

10
Use Case Model

• Provide a simple way for clients and developers
  to communicate view the requirements
• Represent the functionalities of the expected
  system
• Focus on the behaviour from an external
  viewpoint. Not implementation!

11

• I WANT AN
• ONLINE WEB STORE!!!

12
I want an Online WEB STORE!!!

• Client
• Developer

I want you to build an online web store for
selling product. The web store should allow
customers to buy product online with their credit
cards
Can you elaborate more about how a customer
purchase a product online? Its great if you can
give me an example.
13
A Good Client describing the Feature

• Client

The customer (lets call him Peter) browses the
product catalog and finds an iPod Nano. Thats
great. He then adds the iPod into the shopping
cart and proceeds to payment. The system asks for
Peters credit card shipping information. Peter
follows the instructions and type in the
corresponding information. The system checks the
authorization on the credit card and confirms the
sales, followed by a confirmation e-mail.
14
Buy iPod Nano Scenario

• Scenario name BuyiPodNano
• Participating actors PeterCustomer
• Flow of events 1. Peter browses through product
  catalog and finds an iPod Nano.
• 2. He then adds the iPod into the shopping
  cart and proceeds to payment.
• 3. The system asks for Peters credit card
  shipping information.
• 4. Peter follows the instructions and type in
  the corresponding information.
• 5. The system checks the authorization on the
  credit card and confirms the sales,
  followed by a confirmation e-mail.

15
Whats a Use Case?

• A key behaviour of the system, as seen from an
  actors point of view
• Each use case describes a function that the
  system must provide and that produces a result

16
Whats an Actor?

• Actors are external entities that interact with
  the system
• Actor can be a role like a customer, system
  manager, teacher
• Actor dont need to be human. It can also be a
  device or another system such as central database

17
Use Case Model
Use case name Participating actors Flow of
events Entry condition Exit condition Quality
Requirement
Use Case Diagram
Use Case Description
18
Use Case Diagram Example
19
Use Case Description

• Use case name BuyProduct
• Participating actors Initiated by Customer
• Flow of events 1. The Customer browses through
  product catalog and select items into shopping
  cart.
• 2. The Customer performs a Checkout on the
  shopping cart.
• 3. The system responds with a blank form,
  requesting for customers shipping information.
• 4. The Customer fills the form with his/her
  address and proceeds.
• 5. The system responds with the full pricing
  information (including shipping cost) and a
  form for credit card information.
• 6. The customer fills in the credit card
  information and confirms the payment.
• 7. The system authorizes the payment.
• 8. The system presents an
  acknowledge and sends a confirmation to the
  customers e-mail address.
• Entry condition The Customer is logged into the
  online web store
• Exit condition The Customer has received an
  acknowledgement and confirmation email
• Quality The Customer is acknowledged within 10
  seconds.
• requirements

Fig. 2-14 of textbook
20
Use Case Description

• Use case name ReportEmergency
• Participating actors Initiated by FieldOfficer
• Communicates with Dispatcher
• Flow of events 1. The FieldOfficer activates the
  Report Emergency function of her terminal.
• 2. FRIEND responds by presenting a form to the
  FieldOfficer
• 3. The FieldOfficer fills out the form by
  selecting the emergency level, type, location
  and brief description of the situation
• 4. FRIEND receives the form and notifies the
  Dispatcher
• 5. The Dispatcher reviews the submitted
  information and creates an Incident in the
  database by invoking the OpenIncident use case.
  The Dispatcher selects a response and
  acknowledges the report.
• 6. FRIEND displays the acknowledgement and the
  selected response to the FieldOfficer.
• Entry condition The FieldOfficer is logged into
  FRIEND
• Exit condition The FieldOfficer has received an
  acknowledgement and the selected response from
  the Dispatcher
• Quality The FieldOfficers report is
  acknowledged within 30 seconds.
• requirements

Fig. 2-14 of textbook
21
Use Case Consideration

• What behaviour are considered as a Use Case?
• Only those behavioral features that can be seen
  by an actor
• Remember use case does not describe the internal
  implementation!

22
Use Case Relationships

• Communication Relationships
• Include Relationships
• Extend Relationships
• Inheritance Relationships

23
Communication Relationships

• When an actor and use case exchanges information,
  it is said they communicate
• A solid line is used in use case diagram to
  represent communication relationship

24
Include Relationships

• You have more than one use case that share a
  common behaviour (use case)
• To reduce redundancy, use include to share
  common use case
• A dashed open arrow is used to depict include
  relationship

25
Extend Relationship

• You have an use case and you want to create
  another one but add additional events (extension
  point) to the base use case
• A dashed open arrow is used to depict include
  relationship

26
Inheritance Relationships

• You have one general use case and you want to
  create another one to specialize it
• A solid line with an open triangle is used to
  depict inheritance relationship

27
Class Diagram
28
Overview

• Describe the structure of the system in terms of
• Objects/classes,
• Attributes, operations, and
• Their associations

29
A Simple Example
30
Basics

• Classes abstractions that specify the attributes
  and behavior of a set of objects
• Objects
• entities that encapsulate state and behavior
• each object has an identity
• Object names are underlined and start with a
  lowercase letter
• Class names start with an uppercase letter

31
Class Diagram An Example
32
Object Diagram An Example
33
Association

• Represent relationships between instances of
  classes
• Depicted by a solid line

34
Navigability

• Association can be bidirectional or
  unidirectional
• A bidirectional association can be navigated in
  both directions (or unknown)
• A unidirectional association can only be
  navigated in one direction, indicated by the
  arrow

35
Multiplicity

• Each end of the association is labeled with a set
  of integers
• The set of integers is known as multiplicity of
  the association end.

36
Multiplicity (continue)

• Multiplicity represents the lower and upper bound
  of the participating objects.
• represent the range 0 to infinity.
• 3 common types of associations
• One-to-one
• One-to-many
• Many-to-many

37
Multiplicity (continue)
38
Inheritance

• Inheritance is a relationship between a
  generalized class and one or more specialized
  classes
• Inheritance is depicted using a solid line with
  an empty triangle at the line end.

39
Inheritance (continue)
40
Basic Aggregation

• Is-part-of relationship
• Example Think of an address book. Contact is
  part of a Contact Group.

41
Aggregation (continue)
is composed of relationships
42
Composite Aggregation

• A stronger form of aggregation
• The child classs instance lifecycle is dependent
  on the parent classs instance lifecycle
• Example When AddressBook instance is destroyed,
  the Contact/ContactGroup instance will also be
  destroyed

43

• Acknowledgement
• Part of the slides
• were originally authored
• by Simon Ng.