COMP 3111

SOFTWARE ENGINEERING

LECTURE 21
SYSTEM ANALYSIS AND DESIGN

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 1
 6-10

SYSTEM DESIGN OUTLINE

 System Design Overview
– Life Cycle Role
– The Purpose and Importance of System Design
– Realizing Design Goals
– Dealing with the Implementation Environment

 System Analysis and Design Activities

✓ Architectural Analysis and Design
✓ Use-case Analysis
✓ Class Design
✓ Object Behaviour Analysis: State Machine Diagrams
☞Design Patterns
– Anti Patterns

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 2
 Behavioural patterns are concerned
DESIGN PATTERNS with how classes and objects interact
and distribute responsibility.

Creational patterns involve object instantiation

and all provide a way to decouple a client from
the objects it needs to instantiate. Behavioural Mediator

Template Method Command

Memento
Creational Observer
Visitor Iterator
Singleton Builder Interpreter
Prototype Chain of responsibility
Abstract Factory State
Factory Strategy

Concurrency Structural
Proxy
Active object Balking Decorator
Façade
Read write lock
Bridge Composite
Monitor object Reactor
Flyweight Adapter
Thread pool Scheduler

Structural patterns compose classes

Concurrency patterns manage concurrent
or objects into larger structures.
interactions among multiple objects.
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 3
 Mediator pattern 允许了each colleague to communicate with each other directly

BOB’S HOUSE OF THE FUTURE

但是each colleague has to keep track some rules for doing something，就是下⾯的各种check
但是我们不知道exactly where the rule exists,例如startCoffee event，我们不知道是exist in alarm, calendar o
sprinkler Bob’s house is Java-enabled!
因此这些rules很难maintain&keep track of
Alarm
onEvent() { CoffeePot
checkCalendar() Alarm
checkSprinkler() onEvent() {
startCoffeePot() CoffeePot checkCalendar()
// do more stuff checkAlarm()
} // do more stuff
}

Calendar Sprinkler
onEvent() { onEvent() {
checkDayOfWeek() checkCalendar()
Calendar
doSprinkler() Sprinkler checkShower()
doCoffeePot() checkTemp()
doAlarm() checkWeather()
// do more stuff // do more stuff
} }

HouseOfTheFuture's dilemma???

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 5
 MEDIATOR PATTERN
当event happened, mediator会notify some other colleagues to do something
It's such a relief not
having to figure out
Alarm
that alarm clock's
 All appliances picky rules!
CoffeePot
now only need to
interact with the Mediator
Mediator:
类似于centralized controller if(alarmEvent) {
checkCalendar()
– tell the Mediator Mediator checkShower()
when their state checkTemp()
changes. }
if(weekend){
– respond to checkWeather()
requests from // do more stuff
the Mediator. }
Calendar if(trashDay){
Sprinkler
resetAlarm()
// do more stuff
checkAlarm()
// do more stuff
}

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 7
 MEDIATOR PATTERN: CLASS DIAGRAM

The Mediator class defines an The Colleague class defines the

interface for communicating interface for ConcreteColleague classes.
with Colleague objects.

colleague has a reference to the mediator interface

«interface» «interface»
Mediator Colleague

ConcreteMediator ConcreteColleague1 ConcreteColleague2

ConcreteMediator knows the

ConcreteColleague classes Each ConcreteColleague knows its
and keeps a reference to each ConcreteMediator object and communicates with
ConcreteColleague object. the ConcreteMediator whenever it would have
communicated with another ConcreteColleague.

The MEDIATOR pattern is commonly used

to coordinate related GUI components.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 8
 MEDIATOR PATTERN
Advantages
decouple意思就是colleagues no longer communicate with each other directly
 Decoupled Colleagues: The colleague classes are totally decoupled.
Adding a new or reusing a colleague class is very easy.

 Comprehension: Simplifies understanding and maintenance since the

mediator centralizes and encapsulates the control logic.

 Simplified Object Protocols: The colleague objects need to

communicate only with the mediator object (reduces communication
from many-to-many to one-to-many).

 Limits Subclassing: Only need to extend the mediator class when the
logic needs to be extended.

Disadvantages
 Complexity: The Mediator object can become overly complex.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 10
 Behavioural patterns are concerned
DESIGN PATTERNS with how classes and objects interact
and distribute responsibility.

Creational patterns involve object instantiation

and all provide a way to decouple a client from
the objects it needs to instantiate. Behavioural Mediator

Template Method Command

Memento
Creational Observer Visitor Iterator
Singleton Builder Interpreter
Prototype Chain of responsibility
Abstract Factory State
Factory Strategy

Concurrency Structural
Proxy
Active object Balking Decorator
Façade
Read write lock
Bridge Composite
Monitor object Reactor
Flyweight Adapter
Thread pool Scheduler

Structural patterns compose classes

Concurrency patterns manage concurrent
or objects into larger structures.
interactions among multiple objects.
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 11
 7.4.1 7.4.3 10.4.1 A.8

PROXY PATTERN
Problem
We don’t open the multimedia content until we really want to see the content
Sometimes we want to defer the full cost of creating and initializing an object
until we actually need to use it.

Example

 In a document editor that can embed graphical objects in a document,

objects like large raster images can be expensive to create.

 However, opening a document should be fast. Thus, we should avoid

creating expensive objects all at once when the document is opened.
Moreover, usually not all objects are visible at the same time anyway.

☞ Expensive objects should be created on demand.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 12
 PROXY PATTERN: SOLUTION
Use an image proxy that acts as a stand-in (surrogate) for the real image
(i.e., a virtual proxy).
The proxy acts just like the image, instantiates it when needed and
forwards request to it after creating it.
«interface»
DocumentEditor Graphic aTextDocument
anImageProxy
image anImage
draw() fileName
data
getExtent()
store() in memory on disk
load()
if (image == 0)
{
image = loadImage(fileName);
}
image image → draw()
Image ImageProxy
imageImp fileName
if (image == 0)
extent extent
{
draw() draw() return extent;
getExtent() getExtent() }
store() store() else
load() load() {
return image → getExtent();
If you want to get image, you need to }
COMP 3111 use image proxy©2018
1 September L21: SYSTEM ANALYSIS & DESIGN 13
 PROXY PATTERN: CLASS DIAGRAM

client例如document editor Subject is an abstract class that defines

the common interface for RealSubject
«interface»
Client Subject and Proxy so that Proxy can be used
anywhere RealSubject is expected.
request()
..
.

realSubject
RealSubject defines RealSubject Proxy
the real object that
Proxy represents. request() request() realSubject → request();
.. ..
. .

The Proxy class maintains a reference that

lets it access RealSubject. Proxy provides an
get things through the proxy interface identical to Subject's so that Proxy
can be substituted for RealSubject. Proxy
controls access to RealSubject and may be
responsible for creating and deleting it.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 14
 Behavioural patterns are concerned
DESIGN PATTERNS with how classes and objects interact
and distribute responsibility.

Creational patterns involve object instantiation

and all provide a way to decouple a client from
the objects it needs to instantiate. Behavioural Mediator

Template Method Command

Memento
Creational Observer Visitor Iterator
Singleton Builder Interpreter
Prototype Chain of responsibility
Abstract Factory State
Factory Strategy

Concurrency Structural
Proxy
Active object Balking Decorator
Façade
Read write lock
Bridge Composite
Monitor object Reactor
Flyweight Adapter
Thread pool Scheduler

Structural patterns compose classes

Concurrency patterns manage concurrent
or objects into larger structures.
interactions among multiple objects.
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 16
 8.4.1 A.3

BRIDGE PATTERN
假设我们有different windows under different OS
Problem: When an abstraction can have several possible
implementations, inheritance is usually used to handle
this. However, this binds an implementation to an
abstraction permanently making it difficult to modify,
extend and reuse abstractions and implementations
independently.
E.g., implementation of a portable Window abstraction in a
user interface toolkit.

«interface» «interface»
Window Window

MSWindow MacWindow MSWindow MacWindow IconWindow

Problem: We are mixing design (abstractions) and

MSWindow MacWindow
implementation inheritance hierarchies.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 17
 BRIDGE PATTERN: SOLUTION
Separate the window abstraction and implementation class
hierarchies and connect them using a bridge.
bridge This window has a reference to the window
«interface» implementation interface imp «interface»
Window WindowImp

drawText() devDrawText()
drawRect() devDrawLine()

We have an interface for imp → devDrawLine()

imp → devDrawLine() 通过这样，we separate abstraction supertype
window,and under this interface imp → devDrawLine() and subtypes with different implementations
we have different types of imp → devDrawLine()
windows 有implementation for MacOS, implementation for
windows，然后connect them together using a bridge

IconWindow ApplicationWindow MSWindowImp MacWindowImp

drawBorder() drawCloseBox() devDrawText() devDrawText()

devDrawLine() devDrawLine()

drawRect(); drawRect(); msDrawLine(); msDrawString();

drawText()

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 18
 Behavioural patterns are concerned
DESIGN PATTERNS with how classes and objects interact
and distribute responsibility.

Creational patterns involve object instantiation

and all provide a way to decouple a client from
the objects it needs to instantiate. Behavioural Mediator

Template Method Command

Memento
Creational Observer Visitor Iterator
Singleton Builder Interpreter
Prototype Chain of responsibility
Abstract Factory
State
Factory Strategy

Concurrency Structural
Proxy
Active object Balking Decorator
Façade
Read write lock
Bridge Composite
Monitor object Reactor
Flyweight Adapter
Thread pool Scheduler

Structural patterns compose classes

Concurrency patterns manage concurrent
or objects into larger structures.
interactions among multiple objects.
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 21
 SINGLETON PATTERN
⼀种keep track of exactly one instance of something的design

Problem: It is important for some classes to have exactly one

instance. How to ensure that a class has only one
instance and that the instance is easily accessible?
A global variable can make an object accessible, but how
to prohibit instantiation of multiple instances?

Why would we need only one instance of an object?

• Thread pools
• Caches
• Dialog boxes
• Objects used for logging
• Objects that handle graphics cards?
• System.out?

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 22
 SINGLETON PATTERN: CLASS DIAGRAM
Make the singleton class itself responsible for
– keeping track of its sole instance,
– ensuring that no other instance can be created, and
– providing a way to access the instance.

The uniqueInstance class variable

Singleton holds the reference to the one and
only instance of Singleton.
uniqueInstance : Singleton
// other Singleton data
if (uniqueInstance == NULL)
getInstance() uniqueInstance = new Singleton;
// other Singelton methods return uniqueInstance;

The getInstance operation is a class operation,

so it can be accessed from anywhere in the
code using Singleton.getInstance(). It is as easy
as accessing a global variable, but provides
benefits like lazy instantiation.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 23
 Behavioural patterns are concerned
DESIGN PATTERNS with how classes and objects interact
and distribute responsibility.

Creational patterns involve object instantiation

and all provide a way to decouple a client from
the objects it needs to instantiate. Behavioural Mediator

Template Method Command

Memento
Creational Observer Visitor Iterator
Singleton Builder Interpreter
Prototype Chain of responsibility
Abstract Factory
State
Factory Strategy

Concurrency Structural
Proxy
Active object Balking Decorator
Façade
Read write lock
Bridge Composite
Monitor object Reactor
Flyweight Adapter
Thread pool Scheduler

Structural patterns compose classes

Concurrency patterns manage concurrent
or objects into larger structures.
interactions among multiple objects.
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 25
 SIMPLE FACTORY PATTERN
 To use classes, they need to be instantiated (using new
operator).

 Often, we need to decide at runtime what specific subclass to

instantiate.
Duck duck;
if (picnic) { duck = new MallardDuck(); }
else if (hunting) { duck = new DecoyDuck; }
else if (inBathTub) { duck = new RubberDuck(); }

 This kind of code is not closed for modification.

– To extend this code with new concrete types, it will have to be
reopened.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 26
 THE OPEN-CLOSED PRINCIPLE

Design Principle
Classes should be open for extension,
but closed for modification.

We should allow a design to incorporate new

behaviour without modifying existing code.

How best to achieve it?

☞ Adhere to good OO practice!
Design Principle
 Single responsibility principle
Identify the aspects of your application that vary and
 Liskov
separate them substitution principle
from what stays the same.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 27
 SIMPLE FACTORY PATTERN: MAKING PIZZA

Pizza orderPizza() {
Pizza pizza = new Pizza();

pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
We want to be able to make different types
return pizza; of pizza.
}
So, for flexibility, we really want this to be
an abstract class or interface, but we
cannot directly instantiate either of those.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 28
 SIMPLE FACTORY PATTERN: MAKING PIZZA
Pizza orderPizza(string type) {
Pizza pizza; We are now passing in the type
of pizza to orderPizza.
if (type.equals(“cheese”)) {
pizza = new CheesePizza(); Based on the type of pizza, we
} else if (type.equals(“greek”) { instantiate the correct concrete
class and assign it to the pizza
pizza = new GreekPizza();
instance variable. Note that each
} else if (type.equals(“pepperoni”) { pizza here has to implement the
pizza = new PepperoniPizza(); Pizza interface.
} 可以initialize成不同类型的pizza，后⾯的操作都⼀样

pizza.prepare();
Once we have a Pizza, we prepare it (you know, roll
pizza.bake(); the dough, put on the sauce and add the toppings &
pizza.cut(); cheese), then we bake it, cut it and box it!
pizza.box(); Each Pizza subtype (CheesePizza, GreekPizza, etc.
return pizza; knows how to prepare itself.
}

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 29
 SIMPLE FACTORY PATTERN:
ADDING MORE PIZZA TYPES
Pizza orderPizza(string type) {
Pizza pizza;
This code is NOT closed 这⾥vary了，不应该，只应该extend
for modification. If the
Pizza Shop always if (type.equals(“cheese”)) {
changes its pizza pizza = new CheesePizza();
offering, we have to get This is what varies.
} else if (type.equals(“greek”) {
into this code and As the pizza
modify it.
pizza = new GreekPizza(); selection changes
} else if (type.equals(“pepperoni”) { over time, you will
pizza = new PepperoniPizza(); have to modify this
} else if (type.equals(“clam”) { code over and over.
pizza = new ClamPizza();
} else if (type.equals(“veggie”) {
pizza = new VeggiePizza();
}

pizza.prepare(); This is what we expect to stay the same. For

pizza.bake(); the most part, preparing, baking and
pizza.cut(); packaging a pizza has remained the same for
years and years. So, we do not expect this
pizza.box();
code to change, just the pizza it operates on.
return pizza;
}
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 30
 SIMPLE FACTORY PATTERN:
ENCAPSULATING OBJECT CREATION
if (type.equals(“cheese”)) {
我们把不应该修改的代码extract out，然后put it pizza = new CheesePizza();
somewhere else，这⾥我们put within a factory } else if (type.equals(“pepperoni”) {
pizza = new PepperoniPizza();
} else if (type.equals(“clam”) {
pizza = new ClamPizza();
} else if (type.equals(“veggie”) {
pizza = new VeggiePizza();
}
Pizza orderPizza(string type) {
Pizza pizza;

First we pull the object Then we place that code in an

creation code out of the object that is only going to
orderPizza operation. create pizzas. If any other
object needs a pizza created,
pizza.prepare(); this is the object to come to.
pizza.bake();
pizza.cut();
pizza.box(); What’s going to go here?
return pizza;
}

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 31
 SIMPLE FACTORY PATTERN:
A SIMPLE PIZZA FACTORY
Here is our new class, the SimplePizzaFactory. It has one job First we define a createPizza()
in life: creating pizzas for its clients. operation in the factory. This is the
operation all clients will use to
instantiate new objects.
public class SimplePizzaFactory {
public Pizza createPizza(string type) {
Pizza pizza = null;

if (type.equals(“cheese”)) { we pulled out this part of code and then

pizza = new CheesePizza(); put it in the factory
} else if (type.equals(“pepperoni”) {
Here is the code we pulled
pizza = new PepperoniPizza(); out of the orderPizza()
} else if (type.equals(“clam”) { operation.
pizza = new ClamPizza();
} else if (type.equals(“veggie”) {
pizza = new VeggiePizza();
}
return pizza;
} This code is still parameterized by the
} type of the pizza, just like our original
orderPizza() operation was.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 32
 SIMPLE FACTORY PATTERN:
REWORKING THE PIZZA STORE
Now we give PizzaStore a reference to a SimplePizzaFactory.

public class PizzaStore {

SimplePizzaFactory factory;

public PizzaStore(SimplePizzaFactory factory) { PizzaStore gets the

this.factory = factory factory passed to it in
} the constructor.

public Pizza orderPizza(string type) {

Pizza pizza
We create pizza through a factory
pizza = factory.createPizza(type);
And the orderPizza() operation uses
pizza.prepare(); the factory to create its pizzas by
pizza.bake(); simply passing on the type of the
pizza.cut(); order.
pizza.box();
return pizza; Notice that we have replaced the new operator
} with a create operation on the factory object.
// other operations here No more concrete instantiation here!
}

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 33
 SIMPLE FACTORY PATTERN: CLASS DIAGRAM
The Creator class declares the factory
operation, which returns an object of type
Product. Creator may also define a default
implementation of the factory operation that
Product defines the returns a default ConcreteProduct object.
interface of objects
FactoryOperation creates.

«interface» use factory to create

Creator different types of products
«interface»
Product
FactoryOperation() …
AnOperation() product = FactoryOperation()
…
different concrete
implementations of
the products
ConcreteProduct ConcreteCreator

FactoryOperation() return new ConcreteProduct

ConcreteProduct implements ConcreteCreator overrides the

the Product interface. factory operation to return an
instance of a ConcreteProduct.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 34
 WHEN TO USE DESIGN PATTERNS
1. Solutions to problems that recur with variations
– No need for reuse if the problem only arises in one context!

2. Solutions that require several steps

– Not all problems need all steps.
– Design patterns can be overkill if the solution is a simple linear set of
instructions.

3. Solutions where the solver is more interested in the

existence of the solution than its complete derivation
– Design patterns leave out too much to be useful to someone who
really wants to understand.
– BUT, they can be a temporary bridge …

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 36
 BENEFITS OF DESIGN PATTERNS
 Design patterns enable large-scale reuse of software designs.
– They also help document systems to enhance understanding.

 Design patterns explicitly capture expert knowledge and design

tradeoffs and make this expertise more widely available.
behave more like an expert

 Design patterns help improve developer communication.

– Design pattern names form a vocabulary among the developers.

 Design patterns help ease the transition to object-oriented

technology.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 37
 DRAWBACKS OF DESIGN PATTERNS
 Design patterns do not lead to direct code reuse.

 Design patterns are deceptively simple.

 Development teams may suffer from design pattern overload.

 Design patterns are validated by experience and discussion

rather than by automated testing.

 Integrating design patterns into a software development process

is a human-intensive activity.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 38
 6-10

SYSTEM DESIGN OUTLINE

 System Design Overview
– Life Cycle Role
– The Purpose and Importance of System Design
– Realizing Design Goals
– Dealing with the Implementation Environment

 System Analysis and Design Activities

– Architectural Analysis and Design
– Use-case Analysis
– Class Design
– Object Behaviour Analysis: State Machine Diagrams
– Design Patterns
☞Anti Patterns

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 39
 ANTI PATTERNS
something that you don’t want to follow
 An anti pattern tells you what is a bad solution.
– Why a bad solution is attractive.
– Why the solution is bad (in the long term).
– What alternatives (good solutions) you have.

 There are many types of anti patterns

– development
– object-oriented
– organizational
– domain specific

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 40
 WELL-KNOWN ANTI PATTERNS
 Anti patterns are all around us. They are often used as tools for
social control.

Social Anti Patterns Software Anti Patterns

• Criminal • Spaghetti Code

• Terrorist • Stovepipe System
• Drug Addict/Dealer • Analysis Paralysis
• Heretic/Witch • Design By Committee
• Dilbert’s Pointy-haired Manager • God Class
• Mythical Man Month
• Death March Project

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 41
 DEVELOPMENT ANTI PATTERN:
SPAGHETTI CODE
 spaghetti code [Slang] an undocumented piece of software code that
cannot be extended or modified without extreme difficulty due to its
convoluted structure.

Un-structured Well structured code

code is a liability is an investment
COMP 3111 1 September
©2018 L21: SYSTEM ANALYSIS & DESIGN 42
 DEVELOPMENT ANTI PATTERN:
SPAGHETTI CODE
Symptoms
 Quick demonstration code (prototype) that becomes
operational.
 “Lone Ranger” programmer (who was that masked man)?
 Obsolete or scanty documentation.
 50% of maintenance is spent on system rediscovery.
 Hesitant Programmer Syndrome
– More likely to break it than extend it.
– Easier to just rewrite it.
 Cannot be reused
– System software and COTS packages can’t be upgraded.
– Performance cannot be optimized.
 User work arounds.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 43
 DEVELOPMENT ANTI PATTERN:
SPAGHETTI CODE
Object-Oriented Spaghetti Code
 Many object methods with no parameters.
 Suspicious class or global variables.
 Intertwined and unforeseen relationships between objects.
 Procedure-oriented methods, objects with procedure-oriented
names.
 OO advantage lost — inheritance cannot be used to extend the
system, polymorphism is not effective either.

Bottom Line
The software has reached a point of diminishing returns
where the effort involved to maintain existing code exceeds
the cost of developing a new “ground up” solution.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 44
 DEVELOPMENT ANTI PATTERN:
THE BLOB/GOD CLASS
Symptoms Too many responsibilities for one single class

 A single class with many attributes and/or operations

(i.e., a class that knows too much or does too much).

 Violates the cohesion (single

responsibility) property of OO
design.

 A nightmare to maintain
(changes or bug fixes
introduce new bugs).

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 45
 DEVELOPMENT ANTI PATTERN:
THE BLOB/GOD CLASS
Typical Causes

 Inappropriate requirements specification

 Lack of an object-oriented architecture

 Lack of (any) architecture

 Lack of architecture enforcement

 Too limited intervention

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 46
 DEVELOPMENT ANTI PATTERN:
THE BLOB/GOD CLASS
Consequences

 Lost OO advantage.

 Too complex to reuse or test.

 Unnecessary code

 Expensive to load.

Refactor the code!

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 47
 SYSTEM Analysis and DESIGN: RETROSPECTIVE
Architectural design
– Outlines the overall software structure of the system in terms of
cohesive, loosely-coupled subsystems.
– Makes use of architectural patterns to organize subsystems.

Class Analysis
– Structures the system by partitioning use cases into boundary,
control and entity classes.
– Assigns responsibilities to classes.

Class Design
– Completes the specification of each class (attributes, operations).
– Restructures and optimizes classes.
– Makes use of design patterns to handle commonly occurring design
requirements, particularly nonfunctional requirements.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 48
 7.5

SYSTEM DESIGN: SUMMARY

The Analysis and Design Model contains:

Subsystems, their dependencies and their interfaces.

☞ Implemented by implementation subsystems containing
source code, scripts, binaries, executables, etc.

Analysis classes and their responsibilities.

☞ Localizes changes to boundary, entity or control classes.

Design classes, their operations, attributes, relationships and

implementation requirements.
☞ Implemented by files containing source code.

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 49
 COMP 3111 SYLLABUS
 1. Introduction
 2. Modeling Software Systems using UML
 3. Software Development
 4. System Requirements Capture
 5. Implementation
 6. Testing
 7. System Analysis and Design
8. Software Quality Assurance
9. Managing Software Development

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 50
 SYSTEM ANALYSIS & DESIGN
EXERCISE

COMP 3111 1 September

©2018 L21: SYSTEM ANALYSIS & DESIGN 51