1. COMP2110 Software Design in 2004 lecture 09 High level design
about assignment 2
high level design
example: Encounter

2. About assignment 2
deliverables
quality
presentation week 7
working in small teams
Details will be published later today.

3. Software Engineering Roadmap
Develop Architecture/ High level design
Identify
corporate
practices
Develop Detailed Design
Plan
project
Analyze
requirements
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Begin Selecting a Basic Architecture
One way to ...
1. Develop a mental model of the application at a high level – creative invention
as if it were a small application
e.g., personal finance application ...
… “works by receiving money or paying out money, in any order, controlled through a user interface”.
2. Decompose into the required components
look for high cohesion & low coupling
… decomposes into Assets, Suppliers, & Interface.
3. Repeat this process for the components
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5. Cohesion and coupling a principle of quality design
how to divide systems into modules
modules should have strong cohesion:
“hang together” logically,
have a common theme,
have more interaction (associations, uses relationships) between things within the same module than with things outside
and there should be weak coupling between modules
small interfaces
thin interfaces
few dependencies – easy to separate, reuse, replace

6. Cohesion and Coupling   Bridge High cohesion Low coupling component1 2 3 4
component
Bridge 5 6
High cohesion
Low coupling  
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. High level design: module example
BusCatcher
route
and
service
manager
message
stream
handler
user
interface
manager
buttons
display
system
clock
alarm
control
audible
alarm
wireless interface

8. High level design: module example (2)
askRoute
askService
askDelay
route and service manager
ETAlist ?
promptSelect
message
stream
handler *
busETA
userSetting
user
interface
manager
routeNo
estTime
getTimeOfDay
setAlarmDelay
clearAlarm
display
buttons
wireless interface
alarm
control
audible
alarm
system
clock

9. UML Notation … and … Typical Implementation
package MyPackage;
abstract class AbstractClass
class DerivedClass extends AbstractClass {
int att;
void myFunction( ReferencedClass r )
{ . .. } }
package of classes
MyPackage
abstract class
AbstractClass
inheritance
DerivedClass
att: int
myFunction()
attribute
operation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. Modules, packages & high level design
what Parnas refers to as “abstract modules” and design standards call “modules” may be seen in OO languages as
“packages” - Java
“clusters” – Eiffel
packages – UML
or they may be groupings in the design document and in the file system, with no language structure
route and service manager
This package contains 3 classes named
busETA
ETAlist
userStates
routeNo
setTime
busETA
ETAlist
userSetting

11. Architecture and Modularization of Encounter Role-playing Game
EncounterGame
EncounterGame
EncounterCharacters
EncounterCast
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. Framework and architecture
The designers of the Encounter game program saw an opportunity for a creative abstract framework:
a layer of general role-playing game packages supporting a layer of specific Encounter packages
They decided to use 3 modules, each of 2 layers
cast (characters)
game (events and rules of engagements)
environment (areas and connections)

13. RPG Video Game Layering
Characters
Framework layer
«framework package»
«uses»
EncounterCharacters
«application package»
EncounterCharacter
Application layer
PlayerCharacter
ForeignCharacter
PlayerQualityWindow
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

14. Role-Playing Game, and Encounter Packages -- showing domain classes
Framework layer
GameEnvironment
This is a messy diagram
«framework package»
Characters
RolePlayingGame
«framework package»
«framework package»
«uses»
Application layer
EncounterGame
EncounterCharacters
«application package»
«application package»
EncounterGame
Engagement
EncounterCharacter
EngagementDisplay
EncounterEnvironment
PlayerCharacter
«application package»
ForeignCharacter
Area
EncounterAreaConnection
PlayerQualityWindow
ConnectionHyperlink
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. One Way to Obtain The Class Model
2. Create and/or use
framework classes
-- for architecture
More
general
3. Create design classes
-- specific to this
application
-- to complete the
class model
1. Create domain classes
-- from requirements
analysis
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

16. 1. Decompose into self-contained modules.
2. Compare with a standard architecture (e.g. Garlan and Shaw’s classification – previous lectures). Improve decomposition.
Data flowing in batches between processing stations?
batch sequential dataflow
Processing stations waiting for data, then executing?
pipe-and-filter dataflow
A process supplying the needs of user processes?
client-server
A process only reacting to events occurring upon it?
event systems
An application centered on a data store?
repository
Arranged in layers?
layered
Try to develop at least two alternative architectures.
One way to ...
Select an Architecture 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. Select an Architecture 2
One way to ...
Select an Architecture 2
2. Select among the alternatives identified.
3. Add utility classes to those from requirements analysis, to accommodate the architecture selected
e.g., data flow: … to control flow among the elements
e.g., event systems: … to control transitions among states
4. Apply an existing framework and/or design pattern.
if a helpful one can be identified
5. Partition the collection of classes into packages
ideally, 4-8 (nest packages for larger applications)
each package should make sense in the language of the application (e.g., “videos” OK; “bigClasses” not OK)
6. Verify high cohesion within parts; low coupling among parts -- otherwise, adjust choice of modular splits.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. A Typical Repository Architecture
GUI
Analysis
process 1
Analysis
process n
Control
…...
…...
DBMS
Database
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.