61FIT3SQA – Software Quality Assurance
Lecture 7
Software Design - Modularity
UML Sequence Diagram
Faculty of Information Technology
Hanoi University
Introduction to
MODULAR SOFTWARE DESIGN
Software scalability problem
• What if software becomes very big?
– It becomes very difficult to understand
– Dependencies among software components make it hard
to modify software
• The question
– How to design large software that is easy to understand?
• Today’s approach: modularity
– Breaking software into pieces that can be understood
(and built) separately
Modular software characteristics
• Decomposable
– Can be broken down to pieces (modules)
– Reduce complexity and allow teamwork
• Composable
– Modules can be combined to form bigger parts
(like Lego pieces)
• Changes in the requirements should affect a small
number of modules
• Errors in one module are (mostly) contained within it
Important design issues
• Coupling
– How much dependency there is between components
– Objective: understand each component without (much)
understanding of the others
• Cohesion
– How well parts of a component fit and work together
– Objective: a component should be self-contained,
independent, and has a single, well-defined purpose
 Goals: decrease coupling, increase cohesion
Cohesion
• Separation of concerns
– A module should represent a single concept (e.g. ADT)
– The common design objective
• A module should provide a single abstraction
– i.e. it should be about one “thing”
Coupling
• How are modules dependent on one
another?
– Statically (in the code)
– Dynamically (at run-time)
• Sign of coupling
– Do we need to understand one to understand the
other?
Coupling leads to Spaghetti Code
• Coupling causes more
and more coupling
– Eventually turning your
code into ”spaghetti
code”
– It is usually easier to
throw the code away
and start over
Reducing coupling
• Separation of concerns
– A module should represent a single concept (e.g. ADT)
– The common design objective
• A module should provide a single abstraction
– i.e. it should be about one “thing”
Discussions on
OOP DESIGN
Class design
• Separation of concerns
– A class should represent a single concept
(i.e. it should provide a single abstraction)
• Completeness
– For YOUR code, avoid unnecessary work
(you aren’t gonna need it)
– Leave TODOs for what you want to add later
• Consistency
– Consistency in names, param/returns, ordering, and
behavior
Class documentation
• Keep internal and external documentation
separate
• External (design specification): /** ... */
– What clients need to know about your class
– e.g. pre/postconditons, side effects, warnings & notices
• Internal (implementation notes): //
– What programmers (incl. yourself) need to know
– Tricky parts of the code
– Loop invariants, mid conditions...
Class cohesion
• Do one thing
– Observe or mutate, but not both!
• Compute a value but let client decide what
to do with it
– Don’t print in the same method that generates data
(This locks your code into a text representation)
– Return the data and let the views display it
(flexibility, reusability and separation of concerns, again)
• Separate UI from the rest
– Allows multiple platforms (mobile, web, desktop...)
Method design tips
• Avoid long parameter lists
• Avoid methods that take lots of “flag”
parameters
– Flags often mean the method is doing
multiple things
• Methods should have consistent names,
parameters order, way of returning
Examples
1. Which of the following is better?
public void printMyself()
public String toString()
2. Inconsistency
setFirst(int index, String value)
setLast(String value, int index)
Introduction to
UML SEQUENCE DIAGRAM
Sequence Diagrams
• A sequence diagram depicts the interactions
among objects during a certain period of time.
– May be presented either in a generic form or in an
instance form.
– Generic form shows all possible sequences of
interactions – sequences corresponding to all the
scenarios of a use case.
– Instance form shows the sequence for only one
scenario.
Sequence Diagram Basics
• The vertical axis of represents time.
• The horizontal axis represents the
participating objects
Object
Lifeline
Message
Activation
Elements of a sequence diagram (1)
• Objects: represented by boxes at top of
diagram
• Lifeline: the time during which an object exists
• Messages: means by which objects
communicate with each other
Elements of a sequence diagram (1)
• Activation: the time period during which an
object performs an operation
• Synchronous message: a type of message in
which the caller has to wait for the receiving
object to finish executing the called operation
before it can resume execution itself
Elements of a sequence diagram (3)
• Simple message: a message that transfers
control from the sender to the recipient
without describing the details of the
communication
• Asynchronous message: a message in which
the sender does not have to wait for the
recipient to handle the message
Use case diagram of a school registration system
Written use case «Register for classes»
Normal flow:
an open course
with prerequisites
Alternative flow:
an open course
without prerequisites
Sequence Diagram
in Generic Form