A Software Engineering Lecture by Steven Choy
Lecture Overview: The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. This lecture first gives you an overview of UML. It then describes two fundamental notations of UML: use case diagrams, and class diagrams. For each of them, it describes the basic semantics, provides examples for explanation, and goes into a deeper view of them.
Reading: Chapter 2 of the textbook: Modeling with UML
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."
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
UML Diagram Family
- Use Case Diagram
- Class Diagram
- Interaction Diagram
- State Diagram
- Activity Diagram
- Component Diagram
- Deployment Diagram
- (more...)
What you will learn
- Use case diagram (this lecture)
- Class & Object diagram (this lecture)
- Interaction diagram (next lecture)
- State diagram (next lecture)
- Activity diagram (next lecture)
What UML tries 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
- Functional Model
- Describe the functionality of the system from user's 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
Use Case
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
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!
Example
I want an Online WEB STORE
- Client:
"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."
- Developer:
"Can you elaborate more about how a customer purchase a product online? It's great if you can give me an example."
- Client (describing the feature)
"The customer (let's call him "Peter") browses the product catalog and finds an iPod Nano. That's great. He then adds the iPod into the shopping cart and proceeds to payment. The system asks for Peter's 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."
Buy "iPod Nano" Scenario
| Scenario name
| BuyiPodNano
|
| Participating actors
| Peter:Customer
|
| Flow of events
|
- Peter browses through product catalog and finds an iPod Nano.
- He then adds the iPod into the shopping cart and proceeds to payment.
- The system asks for Peter's 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.
|
What's a Use Case?
- A key behaviour of the system, as seen from an actor's point of view
- Each use case describes a function that the system must provide and that produces a result
What's an Actor?
- Actors are external entities that interact with the system
- Actor can be a role like a customer, system manager, teacher
- Actor don't need to be human. It can also be a device or another system such as central database
Use Case Model
- Use Case Diagram
- Use Case Description
Example: Use Case Diagram
Example: Use Case Description
| Use case name
| BuyProduct
|
| Participating actors
| Initiated by Customer
|
| Flow of events
|
- The Customer browses through product catalog and select items into shopping cart.
- The Customer performs a "Checkout" on the shopping cart.
- The system responds with a blank form, requesting for customer's shipping information.
- The Customer fills the form with his/her address and proceeds.
- The system responds with the full pricing information (including shipping cost) and a form for credit card information.
- The customer fills in the credit card information and confirms the payment.
- The system authorizes the payment.
- The system presents an acknowledge and sends a confirmation to the customer's 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 requirements
| The Customer is acknowledged within 10 seconds.
|
(One more example is in pages 44-45 of the textbook.)
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!
Use Case Relationships
- Communication Relationships
- Include Relationships
- Extend Relationships
- Inheritance Relationships
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
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
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
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
Class Diagram
Overview
- Describe the structure of the system in terms of
- Objects/classes,
- Attributes, operations, and
- Their associations
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
Association
- Represent relationships between instances of classes
- Depicted by a solid line
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
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.
- 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
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.
Basic Aggregation
- Is-part-of relationship
- Example: Think of an address book. Contact is part of a Contact Group.
Composite Aggregation
- A stronger form of aggregation
- The child class's instance lifecycle is dependent on the parent class's instance lifecycle
- Example: When AddressBook instance is destroyed, the Contact/ContactGroup instance will also be destroyed
Summary
(The above image is hosted in flickr.com)
Extra materials for studying Unified Modeling Language (UML)
UML Tools
- UMLet 7.1 - Free UML Tool for Fast UML Diagrams: UMLet is an open-source UML tool: draw UML diagrams, export diagrams to eps, pdf, jpg, svg, and clipboard, share diagrams using Eclipse, and create new, custom UML elements. It runs stand-alone or as Eclipse plug-in on Windows, OS X and Linux.
- Visual Paradigm for UML: Visual Paradigm for UML (VP-UML) is a powerful, cross-platform and yet the most easy-to-use visual UML modeling and CASE tool. VP-UML provides software developers the cutting edge development platform to build quality applications faster, better and cheaper!
- StarUML - The Open Source UML/MDA Platform: It is an open source project to develop fast, flexible, extensible, featureful, and freely-available UML/MDA platform running on Win32 platform.
- ArgoUML: It is the open source UML modeling tool and includes support for all standard UML 1.4 diagrams. It runs on any Java platform and is available in ten languages.
- UMLGraph - Declarative Drawing of UML Diagrams: UMLGraph allows the declarative specification and drawing of UML class and sequence diagrams.
Thanks for Reading
If you would rather like to have this lecture note in printed format, please click the print action link in the top right corner.
If you find any problem in this lecture note, please feel free to tell Steven by steven@findaway.hk
