Lecture 38: UML and the Software Development Process
Download
Report
Transcript Lecture 38: UML and the Software Development Process
CS2200 Software Development
Lecture: UML: Use Cases and Class diagrams
A. O’Riordan 2008
Incorporate notes by K. Brown and C. Korbyn
1
A Software Modelling Language
● enables communication between people involved in development is a
modelling language – usually a graphical notation for expressing
design e.g. class designs
● UML (Unified Modeling Language) is a graphical language for
visualising, specifying, constructing and documenting the artefacts of a
software-intensive system.
● It’s a notation – allows flexibility for applying different processes, e.g.
supports iterative, incremental development
● Incorporate industry best practices
● UML has 13 types of diagram, but we will look at just a few
2
UML
•Used for OOA (Object Oriented Analysis) and OOD (Object Oriented
Design)
•Unified older OOA and OOD notations - Booch, OMT, and Objectory
modeling languages
•Supported by CASE tools - enable model interchange between tools
•Originated in 1994 at Rational Corp. - version 0.8 draft released in 1995
•OMG (Object Management Group) consortium took over standardization
in 1997 as UML 1.1
● led by DEC, HP, ILogix, Intellicorp, IBM, ICON Computing, MCI,
Microsoft, Oracle, Rational, TI, and Unisys
● OMG (www.omg.org) also manage specification of related OO
technologies (e.g. CORBA)
● UML 2.0 major revision (2004-2007)
3
Types of Diagram in UML
Structure diagrams emphasize emphasizes the structure of the objects
▪
▪
▪
▪
▪
▪
Class diagram
Component diagram
Composite structure diagram
Deployment diagram
Object diagram
Package diagram
Behaviour diagrams emphasize what happens in the system
▪ Activity diagram
▪ State Machine diagram
▪ Use case diagram
Interaction diagrams, a subset of behaviour diagrams, emphasize the flow
of control and data
▪
▪
▪
▪
Communication diagram
Interaction overview diagram (UML 2.0)
Sequence diagram
UML Timing Diagram (UML 2.0)
4
OOA - Scenario
●
Scenario is one thing that can happen when running the software
●
Example – two scenarios for an online CD store
1. the user logs on to the system, browses a list of CDs, spots the
one she wants, adds it to basket, proceeds to "checkout", enters
her credit card details, confirms the purchase, system checks
authorisation, confirms the sale, queues CD for packing and
dispatch
2. the user logs on to the system, ..., enters credit card details,
confirms the purchase, authorisation fails, user exits the system
5
Analysis: Use case
● a use case is a set of scenarios tied together by a common
user goal
● Example: "buy a CD" use case consists of the two
previous scenarios (success, fail credit card) plus others
● Typically, a use case will have one "as expected" scenario,
plus a number of related scenarios for failures or
alternative paths to success
● You must decide which scenarios fit into a use case, and
which require new use cases
6
Analysis: Use Case text description
Buy a CD
Main Success Scenario
1. Customer logs on
2. Customer browses list
3. Customer selects CD
4. Customer proceeds to checkout
5. Customer enters credit card details
6. Credit company authorises
7. Dispatcher queues for delivery
Extensions
3a Customer quits
6a credit refused
6a1 customer may
re-enter or quit
7
Analysis: Use Case Diagrams
actor
use case
re-stock
maintain
system
engineer
stock
controller
includes
authorisation
buy a CD
deny
credit
customer
dispatch
credit
company
generalisation
dispatcher
8
Analysis using Use Cases
● Use Case diagram is part of UML
● Actor is a role a user plays with respect to the system
● one human user can be multiple actors
● actors can be external systems
● identifying the actors helps decide on the use cases
● Relationships between use cases
● one use case can include another
● one use case can generalise another
● Use cases are useful in analysis, and help to guide the design
● the text descriptions are informal
● you can include many different types of requirement
● the text is more useful than the diagram
9
OOD - Classes
● Design includes specification of classess
● UML class diagrams show software classes and relationships
● a class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
● a software class is an abstraction around data
● state (attributes/instance variables) and behaviour
(operations/instance methods)
● interfaces hide implementation
● Also specify relationships between classes – associations,
generalization
10
Class diagrams
● Structural model – class diagram models part of the structure of your
problem domain or software system
● a class diagram shows classes and their relationships
● Class: Customer, Product
● association: a Customer may have a purchase history
● generalization: a DVD is a type of Product
● you don't have to show all attributes or operations – concentrate on the
important ones that help understanding
● Name of Class
● Attributes – can specify type and visibility
● Operations - can specify type, visibility, parameters and return type
11
Class diagram examples
attributes
class name
CD
CD
getTitle()
getName()
Match()
CD
title
name
getTitle
getName
match
access modifiers
CD
-title: String
-name: String
+getTitle():String
+getName():String
+match(String):boolean
Behaviour (operations)
parameter lists
return types
12
Eliding and Visibility
When drawing a class, you don't have to show every attribute and every
operation at once - you can elide a class, meaning that you can choose to
show only some or none of a class's attributes and operations
The visibility of a feature specifies whether it can be used by other class
● Public Any outside class can use the feature; specified by prepending the
symbol +
● Protected Any descendant of the class can use the feature; specified by
prepending the symbol #
● Private Only the class itself can use the feature; specified by prepending the
symbol -
13
Class diagrams: Association
Association: objects of class A are connected to objects of class B
shown by a solid line between the classes
may have a name
open arrow indicates navigability (A -> B means A "knows" it links to B, but
B doesn't know about A)
can also show multiplicity ( A m -> n B means A links to n Bs, and B links to
m As)
i..j means links to between i and j items
* means links to any number of items
14
Class Diagrams: Generalisation
Generalisation: every B is a special kind of A
● shown by a solid line with a closed white arrow, pointing
from subtype to parent type
● use italics for abstract classes and abstract methods
● also able to show the implements relationship
● shown by a dashed line with a closed white arrow
● interfaces are shown as a circle, or like a class, but with
"<<interface>>" before the class name
15
Class diagram: online store specification
Store
1
1
1
StoreGUI
1
1
Customer
1
*
BasketItem
*
*
Item
CD
DVD
1
Book
16
Alternative store specification
Store
1
1
StoreGUI
1
1
Customer
1
1
1
Basket
1
CD
DVD
1
1
Catalogue
*
Item
1
History
1
1
*
*
BasketItem
1
*
Book
17
detailed specification
1
Store
-catalogue: ArrayList<CatalogueItem>
-customer: Customer
-nextId: int
+Store()
+loginCustomer(Customer): boolean
+logoutCustomer(): void
+getNextIdWithoutIncrementing(): int
+getNextId(): int
+getCatalogue(): List<CatalogueItem>
+getCustomer(): Customer
+getItem(int): CatalogueItem
-readCatalogueFromFile(): void
-readNextUserIDFromFile(): void
+toString(): String
1
1
StoreUDGui
-customer: Customer
-store: Store
-ud: UserDialog
+StoreUDGui(Store)
+displayBasketItems(List<BasketItem>,
String): void
+displayCatalogueItems(List<CatalogueItem>,
String): void
+findInCatalogue(List<CatalogueItem>,
int): CatalogueItem
+findInBasket(List<BasketItem>
int): BasketItem
+addItemToBasket(): void
+changeItemDetails(): void
+removeItemFromBasket(): void
+searchCatalogue(): void
+searchBasketItems(List<BasketItem>):void
+purchaseBasket(): void
+interactWithUser(): void
1
1
1
*
*
CatalogueItem
-title: String
-number: int
-price: double
+CatalogueItem(String,int,double)
+getTitle(): String
+getNumber(): int
+getPrice(): double
+toString(): String
+matches(String):boolean
CD
-artiste: String
-recordLabel: String
+CD(String,int,double,String,String)
+getArtiste(): String
+getRecordLabel(): String
+readFromFile(BufferedReader): CD
Customer
-id: int
-basket: ArrayList<BasketItem>
-history: ArrayList<BasketItem>
+Customer(int)
+getId(): int
+getBasket(): List<BasketItem>
+getHistory(): List<BasketItem>
+readFromFile(Store): void
+saveToFile(): void
+toString(): String
*
1
Book
-author: String
-publisher: String
-isbn: String
+Book(String,int,double,String,String,String)
+getAuthor(): String
+getPublisher(): String
+getIsbn(): String
+readFromFile(BufferedReader): Book
DVD
-director: String
-stars: ArrayList<String>
+DVD(String,int,double,
String,ArrayList<String>)
+getDirector(): String
+getStars(): ArrayList<String>
+readFromFile(BufferedReader): DVD
BasketItem
-item:CatalogueItem
-number: int
+BasketItem(CatalogueItem,int)
+setNumber(int):void
+getItem(): CatalogueItem
+getNumber(): int
+saveToFile(PrintWriter)
+toString(): String
+matches(String): boolean
detailed specification (fragment)
*
1
CatalogueItem
-title: String
-number: int
-price: double
+CatalogueItem(String,int,double)
+getTitle(): String
+getNumber(): int
+getPrice(): double
+toString(): String
+matches(String):boolean
*
*
BasketItem
-item:CatalogueItem
-number: int
+BasketItem(CatalogueItem,int)
+setNumber(int):void
+getItem(): CatalogueItem
+getNumber(): int
+saveToFile(PrintWriter)
+toString(): String
+matches(String): boolean
19