1. CIS224 Software Projects: Software Engineering and Research Methods
Lecture 2b
Introducing the Unified Modeling Language (UML)
(Based on Fowler (2004, Chapter 1) and Stevens and Pooley (2006, Preface & Chapter 3))
David Meredith
CIS224 Software Projects: Software Engineering and Research Methods

2. What is UML and why should we bother with it?
UML is a graphical notation system for designing and describing component-based and object-oriented software
graphical modeling languages for software development have been around for a long time
textual programming languages not abstract enough for discussing high-level design
diagrams good at communicating design without lots of detail
not a replacement for a textual programming language
UML is an open standard controlled by the Object Management Group (OMG)
OMG set up to build standards to support interoperability of object-oriented systems
This course will focus on the current standard which is UML 2.0
Familiarity with UML has become a core skill for software engineers

3. Modes of using UML Sketch mode Blueprint mode
most common
forward engineering: make UML diagram then write code
reverse engineering: derive UML diagram from code
focus on important features and leave out detail
Blueprint mode
emphasis on completeness
forward engineering: build detailed design for programmers to implement
like architect designing a building which is built by construction company
Programming language mode
draw UML diagrams that are automatically compiled into executable code
Model Driven Architecture (MDA) (Kleppe et al., 2003)
standard approach to using UML as a programming language
Three stages
PIM - platform-independent model (in UML)
PSM - platform-specific model (e.g., different for .NET or Java, probably also in UML)
executable code
Executable UML (Mellor and Balcer, 2002)
Model compiler compiles UML directly into executable code without passing through PSM stage
Uses a subset of full UML
is it more productive than using a textual programming language?

4. Using UML from two perspectives
Software perspective
Using UML to model software systems
Direct mapping from UML elements to software elements
Two levels of abstraction (but not clear-cut demarcation between them)
Interface
Specification
how an object behaves (i.e., what it does)
how we interact with an object
Implementation
how an object achieves its behaviour (i.e., how exactly it does what it does)
Conceptual perspective
Using UML to represent concepts in some non-software domain (e.g., business processes)

5. We will be using UML… …from a software perspective
…at the interface level of abstraction
…in sketch and blueprint mode

6. Views on a design
When we want to express a design, we do not try to express all aspects of it at once
Build different models to describe different aspects
Express models as diagrams in a modelling language like UML

7. Three basic types of model
Use case model
describes system from the point of view of the users
Static structural model
describes elements of the system and the relationships between them
Dynamic behavioural model
describes behaviour of the system over time

8. UML 2.0 diagrams 13 official diagram types in UML 2.0
Box represents a diagram type
Open-headed arrow indicates generalization
Will only cover a small fraction of the complete UML in this course, concentrating on the more commonly used diagram types

9. Legal UML normative UML conforms to the standard specification
conventional UML may not conform to standard (i.e., may be non-normative) but commonly used in practice
UML rules are treated as descriptive, not prescriptive
but must have well-defined meaning, even if not strictly legal UML
otherwise the diagrams cannot be interpreted reliably

10. Suppression in UML Anything may be suppressed in a UML diagram
Therefore cannot assume that something is not in the system simply because it is not in the diagram!
Unless it conflicts with what is in the diagram

11. Using non-UML diagrams
Don’t need to use UML all the time!
Sometimes non-UML diagrams are useful
Screen flow diagrams
Flow charts
Decision tables
Class-Responsibility-Collaboration (CRC) cards

12. Using UML in requirements analysis
Use case diagram to describe how people interact with the system
Class diagram for building up vocabulary of domain
Activity diagram to describe how humans interact with software in the organisation
State diagram for describing complex life cycle of a concept
Have to communicate with users and customers who may not be experts in software engineering
Keep notation to a minimum
Avoid implementational details
Domain experts (users) must understand your diagrams

13. Using UML in design Class diagrams from a software perspective
Sequence diagrams and CRC cards for common scenarios
Package diagrams for large-scale structure of software
State diagrams for classes with complex life-cycles
Deployment diagrams to show physical layout of software

14. Using UML in documentation
Use UML diagrams in sketch mode to highlight and illustrate interesting features
Remember:
“Comprehensiveness is the enemy of comprehensibility”

15. Using UML to study other people’s code
Use UML in sketch mode to make graphical notes about the structure and behaviour of a piece of software or code that you are studying

16. Introductory case study: Initial problem statement
“You have been contracted to develop a computer system for a university library. The library currently uses a 1960s program, written in an obsolete language, for some simple bookkeeping tasks, and a card index for user browsing. You are asked to build an interactive system which handles both of these aspects online.” (Stevens and Pooley, 2006, p. 27)

17. Clarifying the requirements
Initial problem statement is vague
Need a more detailed analysis before agreeing to tackle the problem
Requirements engineering is difficult because
Different users have different priorities
Users are not good at imagining or expressing what an ideal system would be like
Managers who talk to developers might not be users and so might not have experience of doing the jobs that the system is supposed to help with

18. Requirements in more detail
Books and journals
Library contains books and journals
May have several copies of a given book
Some books are for short-term loan
Other books can be borrowed by any library member for 3 weeks
Only members of staff may borrow journals
Ordinary library members may borrow up to 6 items at a time
Members of staff may borrow up to 12 items at a time
New books and journals are added to the library and old ones are sometimes disposed of
Current year’s journals are sent away to be bound into hardback volumes at the end of each year

19. Requirements in more detail
Borrowing
System must keep track of when books and journals are borrowed and returned
System should produce reminders when a book is overdue
In the future, users may need to be able to extend a loan if the item is not reserved

20. Requirements in more detail
Browsing
Users should be able to search for a book on a particular topic, by a particular author, etc. in order to
Check if a copy of the book is available
Reserve a copy if it is not
Anyone can browse in the library

21. Users and tasks High quality system must meet its users’ needs
Need to identify users of a system
Need to identify tasks each user must carry out with the system
Need to prioritise tasks in order of importance
So that we can plan development

22. Actors and use cases In UML Actor Use case
User is modelled by an actor
Task is modelled by a use case
Actor
User of a system in a particular role
e.g., library member as book borrower
External system which interacts with our system
E.g., bar-code reading machine
Use case
Task that actor needs to perform with the help of our system
E.g., borrow a copy of a book
May involve a complex process
E.g.
Checking that the library member has not borrowed the maximum number of books
Checking that the book can be borrowed
May include two or more scenarios, each with a different type of outcome
User allowed to borrow book
User refused permission to borrow book
Name use case after what happens in “normal” or main success scenario
E.g., “Borrow copy of book”

23. Documenting a use case
Document each use case in third person, active voice, e.g.
“Borrow copy of book A BookBorrower presents a book. The system checks that the potential borrower is a member of the library, and does not already have the maximum permitted number of books on loan. This maximum is 6 unless the member is a staff member, in which case it is 12. If both checks succeed, the system records that this library member has this copy of the book on loan. Otherwise, the system refuses the loan.”
In use case description, say what system must achieve, not exactly how it should achieve it
E.g., don’t say exactly how system stores information about a loan

24. Use case diagram
Avoid adding use cases that the customer or users haven’t told you to include!

25. Using use cases to determine goals of iterations
Decide what most important use cases are and provide these in early iterations
For example
in library case study, most important use cases might be
Borrow copy of book
Return copy of book
Borrow journal
Return journal
So aim to provide these at end of first iteration

26. Limited use case analysis for first iteration
Books and Journals: The library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only staff members may borrow journals.
Borrowing: The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above.

27. Identifying classes Classes correspond to key domain abstractions
Domain is application area that we’re working in (e.g., the library)
Abstraction represents only relevant important properties of a domain concept or thing
Can use noun identification technique to help with identifying appropriate classes

28. Noun identification technique
Take a clear concise statement of requirements or use case descriptions
Underline all nouns and noun phrases
This gives us candidate classes
Remove inappropriate classes to get initial class list for the system

29. Example of noun identification technique
Books and Journals: The library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals.
Borrowing: The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above.
Initial class list:
Book, Journal, Copy, LibraryMember, (Item?), StaffMember

30. Objects representing actors
There isn’t always an object in a system representing each actor (e.g., StaffMember or LibraryMember objects)
Can make objects representing actors responsible for carrying out actions on behalf of those actors
E.g., send message borrow(theCopy) to LibraryMember object representing Jo Bloggs when Jo borrows a copy of a book
In library system, need to know how many books each member has on loan, so makes sense to have a LibraryMember object for each member

31. Associations between classes
Having identified initial class list, then identify important real-world relationships or associations between the classes
Clarifies understanding of domain
Reveals coupling in the system
OK for closely-related domain objects to be associated since expect one class to depend on the other
Examples of real-world associations in the library system
a copy is a copy of a book
a library member borrows or returns a copy
a member of staff borrows or returns a copy
a member of staff borrows or returns a journal

32. Class model for the library system

33. Class model for library system (improved version)

34. Dynamic behavioral models
Class model describes static structure of system
Also need to describe dynamic behaviour of system
How classes work together to provide the behaviour required by the use cases
Interaction diagrams show how messages pass between objects to realize a use case

35. Library member borrows a book
Human library member (BookBorrower actor) comes to issue desk with physical copy of book (represented by theCopy: Copy).
Library member (represented by theLibraryMember : LibraryMember) and copy of book identified
borrow(theCopy) message sent to theLibraryMember.
theLibraryMember checks that the library member is permitted to borrow the book (might send an okToBorrow() message to itself).
If theLibraryMember can borrow the copy of the book, then a beBorrowed(theLibraryMember) message is sent to theCopy which updates itself with the information that it has been borrowed by theLibraryMember.
It may also be necessary for the theCopy to send a copyBorrowed(theCopy) message to an object, theBook: Book, which represents the book of which theCopy is a copy.

36. Sequence diagram of “Borrow copy of book” use case

37. State machine diagram of Book

38. Going further
Having worked out sequence diagram and state machine diagram, can go back to class model and add attributes and operations to some of the classes
Once identified how all use cases are realized, down to level of which messages are passed, can then implement the classes and complete the first iteration

39. Summary
UML is a graphical notation system for designing and describing component-based and object-oriented software
can be used in sketch mode, blueprint mode or programming language mode
can be used from a software perspective or a conceptual perspective
three basic types of model
use case models
static structural models
dynamic behavioural models
UML standard is descriptive not prescriptive
but must be comprehensible with well-defined meaning
almost anything can be suppressed in a UML diagram
UML can be used in requirements analysis, design, documentation and for studying legacy code
considered a simple case study which involved designing a library system
Requirements analysis using UML use case diagrams
Using the use case analysis to determine goals of iterations
Identifying classes using noun identification technique
Using class model to represent classes and associations between them
Using a sequence diagram to represent the dynamic behaviour of the system when it realizes a use case
Using a state machine diagram to represent how the state of a class changes when it receives messages