1 CMPT 275 High Level Design Phase Modularization.
-
Upload
margaretmargaret-mclaughlin -
Category
Documents
-
view
213 -
download
0
Transcript of 1 CMPT 275 High Level Design Phase Modularization.
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