Chapter 4
Software Design
Agenda
• Identifying possible components in our system
• Describing designs with UML diagrams
– Class Diagrams
– Modeling classes and Relationships
– Sequence diagrams
– State diagrams
2
Software Development phases
• Phases of software development:
– Analysis phase
• Identify the system we are going to develop, including what it
contains and its business case.
• Model: use-case diagrams
– Design phase:
• Design is about assigning Responsibilities to Classes for how they
collaborate to accomplish a use case
– Define Architecture of the system
• Model: classes, objects, class diagrams, sequence diagram,
collaboration diagrams etc.
– Implementation phase: write software using Java/PHP
• the actual building of the product from the design of the system.
– Testing:
• Make sure that the product does what it is expected to
3
Software Design
• Design: specifying the structure of how a software system
will be written and function, without actually writing the
complete implementation
– The most common design is Object-Oriented
– Therefore structure is usually represented by Classes and
collaboration by Class  Class interactions
• Design: A transition from "what" the system must do, to
"how" the system will do it
– What classes will we need to implement a system that meets our
requirements?
– What fields and methods will each class have?
– How will the classes interact with each other?
4
Design is all about classes
• Identify classes and interactions from use cases:
– Nouns are potential classes, objects, and fields
• E.g student, grade, order, registration form, …
– Verbs are potential methods or responsibilities of a class
• E.g register, encode grade, submit order
– Relationships between nouns are potential interactions
(containment, generalization, dependence, etc.)
• Student registers for Course, customer orders pizza, …
• Design is hard
–
–
–
–
Which nouns should be classes?
Which ones are fields?
What verbs should be methods?
What are potential interactions between your classes?
5
Types of Classes
• We are looking for different types of classes (Specially if you
are working on a three-tier architecture)
– Entity class a.k.a domain class
• A class that exists in the problem domain. E.g student, course,…
(usually persistent data)
• These are the most important classes.
– Boundary class or view class
• a class that exists on a system’s automation boundary, such as an
input window form or Web page
• represent the interactions between the actors and the system
– Control class
• Represent the tasks(operation) that are performed by the user and
supported by the system
• a class that mediates between boundary classes and entity classes,
acting as a switchboard between the view layer and domain layer
• Consider this to be an eventHandler – takes an event from boundary
class and calls the Entity class
6
Example: watch
Use the stereo type for each :
Example: <<control>> stereotype to the ChangeDateControl() object
7
Noun analysis From
Requirements
•
A University record system should keep information about its
students and academic staff.
•
Records for all university members are to include their id
number, surname, given name, email, address, date of birth,
and telephone number.
–
•
Students and academic staff each have their own unique ID
number: studN (students), acadN (academic employee),
where N is an integer (N>0).
In addition to the attributes mentioned above:
–
–
Students will also have a list of subjects they are enrolled in.
A student cannot be enrolled in any more than 10 subjects.
Academic employees will have a salary, and a list of subjects
they teach. An academic can teach no more than 3 subjects
8
Classes
•
Entity classes Identified
–
–
–
–
•
Classes that didn’t make it – University Record System
–
•
Student – have id,
Academic Staff – have salary, id, …
UniversityMembers – id, date of birth, first name, email,…
Subject
We don’t maintain any information, no responsibilities
Where are “your boundary and controller classes”?
–
–
functional requirements may not tell you much about
boundary and controller classes
You need to do the analysis on the use case flow of events to
identify them
9
Describing designs with UML
diagrams
• Class diagram
– Shows classes and relationships among them.
– A static view (static architecture) of the system, displaying what
interacts but not what happens when they do interact.
• Sequence diagram
– A dynamic view of the system, describing how objects
collaborate: what messages are sent and when.
10
What is a UML class diagram?
• A UML class diagram is a picture of
– the classes in an OO system
– their fields and methods
– connections between the classes that interact or inherit from each
other
• Not represented in a UML class diagram:
– details of how the classes interact with each other
– algorithmic details; how a particular behavior is implemented
11
Classes (with no members)
ClassName
Circle
12
Classes (with no members)
• Class
– The rectangle is the icon for the class
– Convention – the name of the class is a word with an initial
uppercase letter.
– It appears near the top of the rectangle.
– If your class name has more than one word name, capitalize the
first letter of the every word.
Circle
13
Classes (with attributes and operations)
ClassName
attr1:type1
attr2:type2=“def”
ClassName
attr1:type1
attr2:type2=“def”
operation1()
operation2(args)
operation3() : ret type
Circle
Circle
centreX:Int
centreY:Int=0
centreX:Int
centreY:Int=0
draw()
move(Int X, Int Y)
14
Classes (with attributes and
operations)
• Attribute
–
–
–
–
is a property of a class (E.g centreX, centreY,…).
A class may have zero or more attributes.
A one-word attribute name is written in lowercase letter.
If the name consists of more than one word each word other than
the first word begins with an uppercase letter.
– The list of attribute names begins below a line separating them
from the class name.
• Operations
– An operation is something that a class
can do, or that you (or another class)
can do to a class.
– Naming – similar to attribute
– The list of operations begins below a
line separating operations from the
attributes.
Circle
centreX:Int
centreY:Int=0
draw(): void
move(Int X, Int Y): void
15
Class Visibility
• Visibility
– specifies the extent to which other classes can use a given class's
attributes or operations.
– applies to attributes or operations
– Three levels of visibility are possible
• public level - usability extends to other classes +
• protected level - usability is open only to classes that inherit from
original class #
• private level - only the original class
Circle
can use the attribute or operation -
- centreX:Int
- centreY:Int=0
+ draw()
# move(Int X, Int Y)16
Class Visibility
• public level
• protected level
• private level
+
#
-
– E.g if we had a property called area
Circle
- centreX:Int
- centreY:Int=0
+ draw()
# move(Int X, Int Y)
17
Class - Implementation
public class Circle {
private int centreX, centreY=0; // centre of the circle
//Methods to return circumference and area
protected double move() {
// Implementation here
}
public void draw() {
// Implementation here
}
}
18
Class Relationships
• Classes can related to each other through different
relationships:
– Association (delegation)
– Generalization (inheritance)
– Realization (interfaces)
19
Association
• Association describes a link, a link being a connection among
objects between classes.
• Association is shown by a solid line between classes.
20
Association - Example
• A Person works for a Company.
Role
employee
employer
Person
Company
works for
Association Name
21
Association - Properties
• Name
– Name of the association
• Role
– The specific role of the association
• Multiplicity
– Indicates the number of objects that are connected
• Type
– Plain association, aggregation, composition
• Direction
– Direction can also be shown for a association
22
Notes
Name : “works for” Is the name of the relationship.
Role : Person plays the role employee and the Company plays
the role employer.
Multiplicity : Many employees to one company.
Type : This shows a plain association (normally referred to as
association)
23
Association - Multiplicity
• Multiplicity on association specify properties of the
number of links that can exist between instances
(objects) of the associated classes.
– That is, it indicates how many objects of one class relate to
one object of another class. It is indicated by a single
number or a range of numbers.
• We can add multiplicity on either end of class
relationship by simply indicating it next to the class
where the relationship enters.
Class1
Association name
multiplicity
multiplicity
Class2
24
Association - Multiplicity
•
•
•
•
A Student can take up to five Courses.
Student has to be enrolled in at least one course.
Up to 300 students can enroll in a course.
A class should have at least 10 students.
Student
10..300
takes
1..5
Course
25
Association
- Multiplicity
Association
– Multiplicity
•
•
•
•
A teacher teaches 1 to 3 courses (subjects)
Each course is taught by only one teacher.
A student can take between 1 to 5 courses.
A course can have 10 to 300 students.
Teacher
1
teaches
1..3
Course
1..5
takes
Student
10..300
26
Association
- Multiplicity
Association
- Multiplicity
• Company can have many employees. An employee can only
work for one company.
Person
employee
*
John: Person
works for
employe
r
1
Company
Microsoft: Company
James: Person
27
Association types
Car
• aggregation: "is part of"
– clear white diamond
1
1
aggregatio
n
Engine
• composition: "is entirely made of"
– stronger version of aggregation
– the parts live and die with the whole
– black diamond
Book
composition
1
*
Page
28
Generalization (Inheritance)
• Child class is a special case of the parent class
SuperClass
SubClass1
–
SubClass2
Omit generalization relationships, such as drawing the Object class
as a parent in Java
2929
Generalization (Inheritance) e.g.
Circle
GraphicCircle
3030
Inheritance - Implementation
public class Circle {
}
public class GraphicCircle extends Circle {
}
3131
Realization- Interface
• Interface is a set of operation the class carries out
– Interface doesn’t have
attributes, only method
signatures
– Classes can implement
the methods
• Signatures serve as a contract
– Relationship Represented
by a dashed, white arrow
3232
Realization - Implementation
public interface Shape{
abstract double getArea();
}
public class RectangularShape implements Shape{
public double getArea(){
return width * height;
}
}
3333
Example: video store
• qq
3434
Class Diagram - Example
• Draw a class diagram for a information modeling
system for a school.
–
–
–
–
–
–
–
–
School has one or more Departments.
Department offers one or more Subjects.
A particular subject will be offered by only one department.
Department has instructors and instructors can work for one
or more departments.
Student can enrol in upto 5 subjects in a School.
Instructors can teach upto 3 subjects.
The same subject can be taught by different instructors.
Students can be enrolled in more than one school.
3535
Class Diagram - Example
– School has one or more Departments.
School
has
1
1..*
Department
Department offers one or more Subjec
 A particular subject will be offered by only o
departme

Department
1
offers
1..*
Subject
3636
Class Diagram - Example
• Department has Instructors and instructors can
work for one or more departments.
Instructor
assigned to
1..*

1..*
Student can enrol in upto 5 Subjects.
Student
*
Department
takes
0..5
Subject
3737
Class Diagram - Example
– Instructors can teach up to 3 subjects.
– The same subject can be taught by different instructors.
Instructor
1..*
Subjects
teaches 1..3
3838
Class Diagram - Example
– Students can be enrolled in more than one school.
Student
*
School
member
1..*
3939
Class Diagram Example
has
School
Department
1
1..*
1…*
1..*
1
offeres
assignedTo
member
Student
1..*
1..*
*
attends
*
Subject
1..5
teaches
Instructor
1..3 1..*
4040
Class diagram, multiplicity and visibility for Hospital
Mgt
41
Class diagram, multiplicity and visibility for Bank
transaction
43
Object Diagram - Example
c1: Company
c1: Company
name=“UniMelb”
d1: Department
d2: Department
name=“Sales”
name=”CSSE”
manager
employee
p1: Persont
p2: Person
name=“Rao”
name=“Raj”
4444
45
Key parts of a Sequence diag.
• participant: object or entity that acts in the diagram
– diagram starts with an unattached "found message" arrow
• message: communication between
participant objects
• the axes in a sequence diagram:
– Horizontal: which object/participant
is acting
– Vertical: time (down = forward
in time)
46
Key parts of a Sequence diag.
• participant: object or entity that acts in the diagram
– diagram starts with an unattached "found message" arrow
• message: communication between
participant objects
• the axes in a sequence diagram:
– Horizontal: which object/participant
is acting
– Vertical: time (down = forward
in time)
47
Sequence diagram from a use case
• The user presses the “check email”.
• The client first sends all unsent
email to the server.
• After receiving an
acknowledgement, the client asks
the server if there is any new
email.
• If so, it downloads the new email.
• Next, it deletes old thrashed email
from the server.
48
Why Sequence Diagrams
• Showing dynamic interactions between objects using sequence
diagrams
• Purpose
– See if our class diagram can satisfy each step of the use case
• Identify more classes that we may have missed in class diagram
• Identify methods of those classes
49
Representing objects
• Squares with object type, optionally preceded by "name :"
– write object's name if it clarifies the diagram
– object's "life line" represented by dashed vert. line
50
Messages between objects
• messages (method calls) indicated by arrow to other object
– write message name and arguments above arrow
51
Messages, continued
• messages (method calls) indicated by arrow to other object
– dashed arrow back indicates return
– different arrowheads for normal / concurrent (asynchronous) calls
52
Lifetime of objects
• creation: arrow with 'new'
written above it
– notice that an object created
after the start of the scenario
appears lower than the others
• deletion: an X at bottom of
object's lifeline
– Java doesn't explicitly delete
objects; they fall out of scope
and are garbage-collected
53
Indicating method calls
• activation: thick box over object's life line; drawn when
object's method is on the stack
– either that object is running its code,
or it is on the stack waiting for another object's method to finish
Activation
Nesting
54
• A sequence diagram displays an interaction as a two-dimensional
chart.
 The vertical dimension is the time axis; time proceeds down the
page.
 The horizontal dimension shows the classifier roles that represent
individual objects in the collaboration
• Each classifier role is represented by a vertical column—the lifeline.
 During the time an object exists, the role is shown by a dashed
line.
 During the time an activation of a procedure on the object is
active, the lifeline is drawn as a double line.
• A message is shown as an arrow from the lifeline of one object to
that of another
55
Course registration Sequence Diagram
56
Course registration….detailed sequence
diagram
57
Example of use case seat reservation
58
59
60
61