1

CMPT 275

High Level Design Phase Modularization

Janice Regan, 2008 2

Objectives of Design The design phase takes the results of the requirements

analysis phase and evolves these results further

Use cases and use case diagrams

Context diagram, requirements, class diagrams, state diagrams …

The results of the design phase feeds directly into the implementation phase

Requirements analysis → WHAT the system must do

Next Goal: determine HOW the software system is to accomplish what it must do

Janice Regan, 2008 3

Map of design phaseDESIGN

HIGH LEVELDESIGN

Modularization

User Interface

Module Interfaces

Data PersistanceSubsystem

User Manual

architecture

LOW LEVELDESIGN

ClassesClass Interfaces

Interaction Diagrams

Implementation

Janice Regan, 2008 4

Example Repository: CASE Tools

Project Repository

Design EditorCode

Generator

Design

Translator

Design

Analyser

Program

editor

Report

Generator

From figure 11.2 Sommerville 2004

CASE: Computer Aided Software Engineering

Janice Regan, 2008 5

Example Repository: CASE Tools

Project Repository

Design EditorCode

Generator

Design

Translator

Design

Analyser

Program

editor

Report

Generator

From figure 11.2 Sommerville 2004

CASE: Computer Aided Software Engineering

Janice Regan, 2008 6

Client-server

GameClient

GameClient

GameClient

GameServerInternet

Janice Regan, 2008 7

The OSI Layers: Layered Model

Expanded from Figure 1.10 Stallings (2000)

Ethernet

TCP/IP

CORBA

Janice Regan, 2008 8

Model/View/Controller

Model: maintains all domain knowledge

Controller, manages sequence of interaction with the user

View: Display model to user

Controller

Model

View

initiatorrepository

Subscriber

*

1 Notifier

Janice Regan, 2008 9

Map of design phaseDESIGN

HIGH LEVELDESIGN

Modularization

User Interface

Module Interfaces

Data PersistanceSubsystem

User Manual

architecture

LOW LEVELDESIGN

ClassesClass Interfaces

Interaction Diagrams

Implementation

System design or

object design or

Janice Regan, 2008 10

System design activities

Analysis

System design

Object design

Functional requirements

Non Functional requirements

Analysis object model

Analysis dynamic model

Design goals

Subsystem decomposition

Janice Regan, 2008 11

Objectives of system design Transforms analysis model (from

requirements analysis) into a system design model

System decomposition Identify design goals (choose aspects of the system to

be optimized)

Develop and refine a subsystem decomposition that satisfies the maximum number of design goals and or the most critical design goals

Identify, model system architecture

Janice Regan, 2008 12

Software Modularization Software system modularization

(module decomposition) decompose software system into subsystems

Subsystems interface (communication) description define which subsystems communicate with

one another and describe how this communication is accomplished

Janice Regan, 2008 13

Modularization Goals Good modularity eases

Simplicity: Makes it easy to understand, implement and test

Extension: Facilitates the addition of features

Change: Facilitates the modification of requirements

A module can be replaced with minimal effects on the rest of the software system

Janice Regan, 2008 14

Building on the Context DiagramNow we are interested with the architecture of the software inside the central software system, its modularization and

how the modules work and interact with outside agents

Patron

Resources

(Books, CDs ..)

Web

Student Information

Repository (DB)

Employee

Information

Repository (DB)

Online Journals

Folder is UML notation for a

package

Librarian

GUI

Janice Regan, 2008 15

Software Architecture Software system modularization

(module decomposition)

Decompose software system into subsystems and modules

Different levels of decomposition system-subsystem, subsystem-module (may have more levels)

Janice Regan, 2008 16

Software Architecture Subsystems interface descriptions

define which subsystems communicate with one another and describe how this communication is accomplished

Different types of system architectures or decomposition styles lead to different approaches to modularization

Janice Regan, 2008 17

Modularization Goals Good modularity promotes

Simplicity: Make it easy to understand, implement and test

Effective inter-system/module communication (internally and with external environment)

Encapsulation (Information hiding)

Janice Regan, 2008 18

Modularization Goals

Encapsulation (Information hiding) promotes ease of

Extension: Facilitates the addition of features

Change: Facilitates the modification of requirements

Replacement of single modules when needed

Janice Regan, 2008 19

Modularization Guidelines Coupling: degree to which subsystems

are dependent on each other. This is sometimes illustrated by the number of relations (communications) between subsystems or (or on the module level between modules within subsystems).

Desirable: low coupling amongst subsystems -> minimize interfaces between subsystems -> make interfaces between subsystems as simple as possible

Janice Regan, 2008 20

Modularization Guidelines Cohesion: degree to which a subsystems’

modules, or a modules classes depend on each other. Sometimes indicated by the number of dependencies between modules in subsystems.

Desirable: high cohesion within a subsystem -> localize all elements responsible for performing related functions in one subsystem or module

Janice Regan, 2008 21

Low Coupling

Janice Regan, 2008 22

High Coupling

Janice Regan, 2008 23

High Cohesion within a module Responsibilities of module or subsystem are

cohesive when

Elements related to one concept or resource are grouped to hide the detailed function of that concept or device from other modules, no side effects (informational)

Elements contribute to a single well defined task (functional)

Elements operate on the same input or produce the same output (communicational, not usually OO except perhaps within objects)

better

Janice Regan, 2008 24

High Cohesion within module Responsibilities of module or subsystem are

cohesive when

Elements occur in sequence input of one to output of another, a series of procedures that occur in a fixed sequence (procedural or sequential)

Elements occur together in time e.g. startup (temporal)

Elements perform related tasks, one of which is selected on each call to the module (logical) for example related utilities

better

Janice Regan, 2008 25

Lower Cohesion

Janice Regan, 2008 26

Higher Cohesion

Janice Regan, 2008 27

Why low coupling is desirable Simplifies interfaces between subsystems/modules

Reduces the number of interfaces between subsystems

Reduces dependency between modules of a subsystem or subsystems of a system

Encapsulation (information hiding)

Localization of functions

Why high cohesion is desirable

Janice Regan, 2008 28

Objectives of system design Transforms analysis model (from

requirements analysis) into a system design model

Identify, model system architecture

Develop an efficient system decomposition

Identify boundary use cases describing configuration, startup, shutdown, exceptional conditions.

Janice Regan, 2008 29

Design goals, System decomposition

Identify design goals (choose aspects of the system to be optimized) Design goals are often derived from non-functional requirements. Guide designers in assessing trade offs

Develop and refine a subsystem decomposition that satisfies the maximum number of design goals and or the most critical design goals

Refine the decomposition to better satisfy the design goals

Janice Regan, 2008 30

Design goals When assessing design goals consider

Selection of existing components (off the shelf modules or components )

Hardware / software mapping, Are there multiple nodes or systems

What is each node responsible for

selecting solutions for managing persistent data

Access control policies

Control flow on a solution wide basis

Boundary conditions (startup, error, shutdown)

Janice Regan, 2008 31

How to modularize - 1 Start with the big picture

(conceptualization of your software system)

Consider its functions (use cases)Functional partitioning is useful for dividing a software system into smaller pieces (use case -> subset of functionality)or Division of responsibility

Look at data access

It may help to choose an already existing architecture style

Janice Regan, 2008 32

How to modularize - 2 Subsystems waiting for data then execute?

Soln: Pipes-and-filters architectural style

An application centered on a data store? Soln: Repository

A process supplying the needs of user processes? Soln: Client-server

Few subsystems arranged in layers? Soln: Layered

Janice Regan, 2008 33

How to modularize - 3 Once you have a set of subsystems, go

through the goals and guidelines and see if your subsystems make sense

Janice Regan, 2008 34

Format for Subsystem Diagram

Folder -> subsystem/module

Line -> communication between two subsystems/modules

Name of SubSystem

Janice Regan, 2008 35

Possible Architecture for LMS Want concurrent access for multiple clients (accessing from

a network) to centrally stored data

Want an Data server module that will interact with Database, then database can be changed without changing the data server module

This suggests a client server architecture

DBMSDB server

module

Client 2Client 1 Client 4Client 3Client 5

Network

Janice Regan, 2008 36

Possible Architecture for LMS

DBMS

DB server

module

Client 2Client 1 Client 4Client 3 Client 5

Remember for client server architecture client means a process requesting services. This is not the same as our client, the user or source of the project!!!

Patron 1 Librarian 1 Patron 2 Patron 3 Librarian 2

Janice Regan, 2008 37

When ModularizingBrowseResource

ReserveResource

DetermineOverdueCharge

Check out resource

Verify Patron

<<include>>

<<include>>

Module B

Module A

Janice Regan, 2008 38

Tricks Do not over- or under-modularize

If over-modularize (lots of modules)then lots of interfaces to define

If under-modularize (few modules)complexity of module great

Complexity of each module (subsystem) should be the maximum that still provides a simple and understandable module

1 use case is not usually one subsystem