Scribd
Upload
4 views

Lecture 7 - Modularity + Sequence Diagram

The document discusses modular software design, emphasizing the importance of modularity to manage complexity in large software systems. Key concepts include coupling and cohesion, which aim to reduce dependencies between modules and ensure they serve a single purpose. Additionally, it introduces UML sequence diagrams to illustrate object interactions over time, highlighting elements such as lifelines, messages, and activation periods.

Uploaded by

kle27512
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

Lecture 7 - Modularity + Sequence Diagram

The document discusses modular software design, emphasizing the importance of modularity to manage complexity in large software systems. Key concepts include coupling and cohesion, which aim to reduce dependencies between modules and ensure they serve a single purpose. Additionally, it introduces UML sequence diagrams to illustrate object interactions over time, highlighting elements such as lifelines, messages, and activation periods.

Uploaded by

kle27512
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

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


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”
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”
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 documentation
public class HinhTron {
/** (Internal)
* Demo sự giống nhau giữa Thuộc tính và Biến
* nếu như không có thành phần khả_năng_truy_cập trước
* các thuộc tính
*/
// Thuộc tính (Internal)
final float PI = 3.14f;
float r;
float cv;
float dt;
void tinhChuVi() {
// Thuộc tính
float banKinh = 10;
cv = 2 * PI * banKinh;
}
}
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

• 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

You might also like