1. Software Design Models UML
Software Engineering
Software Design Models UML

2. Where are we? Phase Actions Outcome Initiation Requirements
Raising a business need
Business documents
Requirements
Interviewing stakeholders, exploring the system environment
Organized documentation
Specification
Analyze the engineering aspect of the system, building system concepts
Formal specification
Design
Define architecture, components, data types, algorithms
Formal Specification
Implementation
Program, build, unit-testing, integrate, documentation
Testable system
Testing & Integration
Integrate all components, verification, validation, installation, guidance
Testing results, Working sys
Maintenance
Bug fixes, modifications, adaptation
System versions

3. Requirements vs. Design
What the system should do
More abstract
Design:
How the system should do it
More detailed

4. Object Oriented Modeling
Evolution of analysis and design techniques
Transition from structured programming to object oriented programming

5. The Unified Modelling Language
The Unified Modelling Language is a standard graphical language for modelling object oriented software
At the end of the 1980s and the beginning of 1990s, the first object-oriented development processes appeared
In 1995, another methodologist, Jacobson, joined the team
His work focused on use cases
In 1997 the Object Management Group (OMG) started the process of UML standardization

6. History of UML

7. Overview of UML Diagrams
Behavioral
: behavioral features of a system / business process
Activity
State machine
Use case
Interaction
Structural
: element of spec. irrespective of time
Class
Component
Deployment
Object
Composite structure
Package
Interaction
: emphasize object interaction
Communication(collaberation)
Sequence
Interaction overview
Timing

8. 13 (!!) Kinds of UML Diagrams
Activity
Class
Communication
Component
Component structure
Deployment
Interaction
Object
Package
Sequence
State machine
Timing
Use case

9. Diagrams in UML
A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships).
• Class diagram shows a set of classes, interfaces, and collaborations with their relationships.
• Object diagram shows a set of objects and their relationships.
• Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

10. Diagrams in UML (continued)
• Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them.
=> A sequence diagram emphasizes the time ordering.
=> A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.

11. Diagrams in UML (continued)
• Statechart diagram shows a state machine consisting of states, transitions, events, and activities.
• Activity diagram is a statechart diagram that shows the flow from activity to activity within a system.
• Component diagram shows the organization and dependencies among a set of components.
• Deployment diagram shows the configuration of processing nodes and the components that live on them.

12. Class Diagrams

13. UML Class Diagrams The main symbols shown on class diagrams are:
Classes
represent the types of data themselves
Associations
represent linkages between instances of classes
Attributes
are simple data found in classes and their instances
Operations
represent the functions performed by the classes and their instances
Generalizations
group classes into inheritance hierarchies

14. Notation: Classes Window name origin attributes size open() operations
close()
move()
display()
name
attributes
operations
A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

15. Class Class Name Attribute : type Operation (arg list) : return type
Abstract operation
Various parts are optional

16. Classes
A class is simply represented as a box with the name of the class inside
The diagram may also show the attributes and operations
The complete signature of an operation is:
operationName(parameterName: parameterType …): returnType

17. Employee class (UML)

18. Example UML Class Diagram

19. Kinds of Edges There are other kinds of edges Class A Class B Source
Association
Role of B
Class A
Class B
Role of A
Navigability
Role name
Role name
Source
Target
Dependency
Client
Supplier
There are other kinds of edges

20. Multiplicities on Edges (Cardinalities)
1 Exactly one
* Many (any number)
0..1 Optional (zero or one)
m..n Specified range
{ordered}* Ordered

21. Multiplicity of associations
one-to-one
each student must carry exactly one ID card
one-to-many
one rectangle list can contain many rectangles

22. Association types aggregation: "is part of"
Car
Association types 1
aggregation 1
aggregation: "is part of"
symbolized by a clear white diamond
composition: "is entirely made of"
stronger version of aggregation
the parts live and die with the whole
symbolized by a black diamond
dependency: "uses temporarily"
symbolized by dotted line
often is an implementation detail, not an intrinsic part of that object's state
Engine
Page
Book
composition * 1
Lottery Ticket
Random
dependency

23. Composition A composition is a strong kind of aggregation
if the aggregate is destroyed, then the parts are destroyed as well
Two alternatives for addresses * * * * *
Building
Room

25. An association model

26. Labelling associations
Each association can be labelled, to make explicit the nature of the association

27. Analyzing and validating associations
One-to-one
For each company, there is exactly one board of directors
A board is the board of only one company
A company must always have a board
A board must always be of some company

28. Analyzing and validating associations
Many-to-many
A secretary can work for many managers
A manager can have many secretaries
Secretaries can work in pools
Managers can have a group of secretaries
Some managers might have zero secretaries.
Is it possible for a secretary to have, perhaps temporarily, zero managers?

29. A more complex example A booking is always for exactly one passenger
no booking with zero passengers
a booking could never involve more than one passenger.
A Passenger can have any number of Bookings
a passenger could have no bookings at all
a passenger could have more than one booking

30. Class diagram example StudentBody Student Address 1 100
- firstName : String
- lastName : String
- homeAddress : Address
- schoolAddress : Address
+ main (args : String[])
+ toString() : String
Address
- streetAddress : String
- city : String
- state : String
- zipCode : long
+ toString() : String

31. Reflexive associations
It is possible for an association to connect a class to itself
successor *
Course
isMutuallyExclusiveWith * * *
prerequisite

32. Detailed Example: A Class Diagram for Genealogy
Problems
A person must have two parents
Marriages not properly accounted for

33. Genealogy example: Possible solutions
Person
Person
name
name
sex
placeOfBirth
placeOfBirth
dateOfBirth
dateOfBirth
placeOfDeath
child
placeOfDeath
child
dateOfDeath *
dateOfDeath *
{partner->forAll(p1,p2 |
partner * * * *
0..2
p1 <> p2
implies p1.sex <> p2.sex)} *
Woman
Man
Union
femalePartner
child
0..1 * * * *
0..1
child
malePartner
0..1
placeOfMarriage
parents * *
dateOfMarriage
dateOfDivorce
Union
0..1
placeOfMarriage
parents
dateOfMarriage
dateOfDivorce

35. Note (Comment)
Some item eg class
Comment about an item

36. Generalization (Inheritance)
Supertype
Subtype 1
Subtype 2

37. Generalisation and inheritance
Objects are members of classes which define attribute types and operations
Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes)
A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own
Generalisation in the UML is implemented as inheritance in OO programming languages

38. Generalization Specializing a superclass into two or more subclasses
The discriminator is a label that describes the criteria used in the specialization

40. A generalisation hierarchy

41. Multiple inheritance

42. Class diagram example 1..* 1 0..1 DVD Movie VHS Movie Video Game
Rental Item
Rental Invoice
1..* 1
Customer
Checkout Screen
0..1
Simple
Association
Class
Abstract
Aggregation
Generalization
Composition
Multiplicity

43. An example (generalization)
Person
0..2
0..2
0..2
0..2
0..2
0..2
PersonRole
name
idNumber
RegularFlight *
EmployeeRole
time
PassengerRole
flightNumber
jobFunction
supervisor * * * * * * * * * * * * * * * * * * *
Booking * * * * * *
SpecificFlight
seatNumber
date

44. Class attributes attributes (fields, instance variables)
visibility name : type [count] = default_value
visibility: + public # protected - private ~ package (default) / derived
underline static attributes
derived attribute: not stored, but can be computed from other attribute values
attribute example: - balance : double = 0.00

45. Association classes
Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes
The following are equivalent
Registration
grade
Student
CourseSection *
Registration
grade
Student
CourseSection *

46. An example (attributes and associations)
Employee
RegularFlight
Passenger
name *
name
time
employeeNumber
number
flightNumber
jobFunction
supervisor * * * * * * * * * * * * * * * * * * *
Booking * * * * * *
SpecificFlight
seatNumber
date

47. Instance Specification (Object)
ObjectName: Class Name
Attribute : type
Operation (arg list) : return type
Abstract operation
Various parts are optional

48. Object diagram

49. Object aggregation

54. Noun Identification: A Library Example
The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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.
The system must keep track of when books and journals are borrowed and returned and enforce the rules.

55. Noun Identification: A Library Example
The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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.
The system must keep track of when books and journals are borrowed and returned and enforce the rules.

56. Candidate Classes Library the name of the system Book Journal Copy
ShortTermLoan event
LibraryMember
Week measure
MemberOfLibrary repeat
Item book or journal
Time abstract term
MemberOfStaff
System general term
Rule general term

57. Relations between Classes
Book is an Item
Journal is an Item
Copy is a copy of a Book
LibraryMember
Item
MemberOfStaff is a LibraryMember
Is Item needed?

58. Operations LibraryMember borrows Copy LibraryMember returns Copy
MemberOfStaff borrows Journal
MemberOfStaff returns Journal
Item not needed yet.

59. Class Diagram MemberOfStaff LibraryMember 1 1 on loan on loan 0..*
0..12
Journal
Copy
is a copy of
1..*
Book

60. Representing Architecture: The 4+1 View Model
It is important to keep the discussion of this slide at a very high level. Examples of the 5 views are not provided. You may wish to go to the white board and show some examples. Several examples from earlier in this module can be used. For example, The sample use case diagram can illustrate the use-case view. The sample class diagram can illustrate the logical view.
Also mention that the UML provides the notation we use to visualize these views.
Logical View
Implementation View
Analysts/ Designers
End-user
Programmers
Software management
Structure
Functionality
Use-Case View
Many different parties are interested in the architecture (e.g., the system analyst, the designers, the end uses, etc.). To allow these parties or stakeholders to communicate, discuss and reason about architecture, we need to have an architectural representation that they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns,and omitting entities that are not relevant to this perspective.
While many views of architecture can be useful, the Rational Unified Process identifies 4+1 views as a standard set:
The logical view addresses the functional requirements of the system. It is an abstraction of the design model, identifying major design packages, subsystems and classes.
The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management.
The process view addresses the concurrent aspect of the system at run-time: tasks, threads or processes, and their interactions.
The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes.
The use-case view contains a few key scenarios or use cases that are used to drive the architecture and to validate it.
Process View
Deployment View
System Integrators
System Engineering
Performance
Scalability
Throughput
System topology
Delivery, installation
communication

61. Major Workflows Produce Models
You can relate this back to previous slides that describe the system model and the many diagrams needed to fully communicate its content. One can consider all of the models listed here, taken together, to be “the system model.”
The only model that is a little different is the business model. It describes the business at large, not just the automated part. The other models describe the information system that supports the business model.
It is a good idea to point out that each of these models is incrementally developed across many iterations.
Analysis & Design
Design Model
Implementation Model
Test Model
realized by
implemented by
verified by
Requirements
Implementation
Test
Use-Case Model
Business Modeling
Business Model
supported by
The Rational Unified Process is a model-driven approach. Several models are needed to fully describe the evolving system. Each major workflow produces one of those models. The models are developed incrementally across iterations.
The Business Model is a model of what the business processes are and the business environment. It can be used to generate requirements on supporting information systems.
The Use-Case Model is a model of what the system is supposed to do and the system environment.
The Design Model is an object model describing the realization of use cases. It serves as an abstraction of the implementation model and its source code.
The Implementation Model is a collection of components, and the implementation subsystems that contain them.
The Test Model encompasses all of the test cases and procedures required to test the system.