Design Principles

Design Principles and Guidelines Overview

MIDDLEWARE SERVICES
 Design Principles
Software Design Principles and Guidelines (SECURITY, EVENT NOTIFICATION, TRANSACTIONS, PERSISTENCE, LOAD BALANCING,
FAULT TOLERANCE, A/V STREAMING, DYNAMIC RESOURCE MANAGEMENT, SCHEDULING,
NAMING, TRADING, LOGGING, ETC...)

HOME – Important design concepts

operation() – Useful design principles
Douglas C. Schmidt CLIENT COMPONENT
EXECUTOR CALL
BACKS
 Development Methodologies
d.schmidt@vanderbilt.edu STUBS
CONTAINER
MIDDLEWARE – Traditional approaches
Vanderbilt University, St. Louis INTERFACE SKELETONS
OBJECT
– Agile programming
www.cs.wustl.edu/schmidt/
ADAPTER

MESSAGE-PASSING
MIDDLEWARE  Design Guidelines
May 25, 2003 OS KERNEL OS KERNEL
NETWORK NETWORK
PROTOCOLS
– Motivation
PROTOCOLS
NETWORK NETWORK – Common Design Mistakes
INTERFACE INTERFACE
NETWORK
– Design Rules

Design Principles Design Principles

Motivation: Goals of the Design Phase (1/2) Motivation: Goals of the Design Phase (2/2)
SUPER
SUPER
VISOR SUPER  Decompose system into  Specify component interfaces
VISOR VISOR
STREAM
components

DOWNSTREAM
Head

UPSTREAM
– Interfaces should be well-defined
– i.e., identify the software  Facilitates component testing
CCM Session Router
Stream Module architecture and team communication
Event Filter
Module
 Determine relationships open()=0  Describe component functionality
close()=0
MIB Event Analyzer
between components put()=0
Module svc()=0 – e.g., informally or formally
– e.g., identify component
ACE Switch Adapter
Module  Identify opportunities for systematic
RUN-TIME dependencies
reuse
TELECOM  Determine intercomponent STREAM
SWITCHES EVENT Tail – Both top-down and bottom-up
SERVER communication mechanisms
– e.g., globals, function calls,
shared memory, IPC/RPC

2 3
 specification and apply above process to each
– Make decisions that apply to whole program
Design Principles

– contain easily comprehensible components

1. List the hard decisions and decisions likely to

– provide individual, independent, low-level

Macro Steps in the Design Process

Micro Steps in the Design Process

– Design the uses hierarchy as you do this

decisions and decisions likely to change

4. Continue refining until all design decisions

2. Design a component specification to hide
iterative decision process with the following

3. Treat each higher-level component as a

 Given a requirements spec, design is an

– Modularize most likely changes first

– Then modularize remaining difficult
 In the design process the orientation moves from
– Customer to developer

implementation assignments
– What to how

(include reuse decisions)

 Macro steps include:

– hidden in a component
1. Preliminary Design

each such decision

– External design describes the real-world model
– Architectural design decomposes the requirement specification
into software subsystems

family first
general steps:
2. Detailed Design
– Specify each subsystem

change
Design Principles
– Further decomposed subsystems, if necessary

are:
4

5
Design Principles Design Principles

Example: Designing a Web Server Key Design Concepts and Principles

WWW
1: GET ~schmidt
HTTP/1.0 WWW
 Web server design
CLIENT SERVER decisions Key design concepts and design Main goal of these
2: index.html
principles include: concepts and principles is
PROTOCOL
HANDLERS
– Portability issues to:
HTML
PARSER
– I/O demuxing and 1. Decomposition
GUI
DISPATCHER concurrency 2. Abstraction and information hiding  Manage software
REQUESTER
– HTTP protocol system complexity
processing 3. Component modularity
 Improve software quality
COMMUNICATION PROTOCOL – File access
GRAPHICS
ADAPTER (E.G., HTTP) 4. Extensibility factors
 Web server 5. Virtual machine architectures  Facilitate systematic
OS KERNEL OS KERNEL components
OS I/O SUBSYSTEM OS I/O SUBSYSTEM 6. Hierarchical relationships reuse
NETWORK ADAPTERS NETWORK ADAPTERS
– Event dispatcher  Resolve common design
NETWORK 7. Program families and subsets
– Protocol handler challenges
www.cs.wustl.edu/˜jxh/ – Cached virtual
research/ filesystem

6 7
Design Principles Design Principles

Challenge 1: Determining the Web Server Architecture Solution: Decomposition

 Context: A large and complex production web server  Decomposition handles complexity by splitting large problems into
smaller problems
 Problems:
 This “divide and conquer” concept is common to all life-cycle
– Designing the web server as a large monolithic entity is tedious processes and design techniques
and error-prone
– Web server developers must work concurrently to improve  Basic methodology:
productivity 1. Select a piece of the problem (initially, the whole problem)
– Portability and resuability are important quality factors 2. Determine the components in this piece using a design paradigm,
e.g., functional, structured, object-oriented, generic, etc.
3. Describe the components interactions
4. Repeat steps 1 through 3 until some termination criteria is met
– e.g., customer is satisfied, run out of time/money, etc. ;-)

8 9

Design Principles Design Principles

Decomposition Example: Web Server Framework Object-Oriented Decomposition Principles

 Features
Reactor/Proactor Strategy Singleton
I/O strategy Cached virtual
State
Memento

framework filesystem
1. Don’t design components to correspond to execution steps
– High-performance
Asynchronous completion token Tilde ~ – Flexible concurrency,  Since design decisions usually transcend execution time
expander
Component configurator

/home/...
Protocol
Event dispatcher demuxing, and caching 2. Decompose so as to limit the effect of any one design decision on
Acceptor

handler

Protocol
mechanisms the rest of the system
filter
– Uses frameworks based
Pipes and filters
on ACE  Anything that permeates the system will be expensive to change
Adapter

Concurrency
3. Components should be specified by all information needed to use
State

Protocol pipeline strategy

framework framework

Component configurator Active object Strategy the component

www.cs.wustl.edu/schmidt/PDF/JAWS.pdf  and nothing more!

10 11
Design Principles Design Principles

Challenge 2: Implementing a Flexible Web Server Solution: Abstraction

 Abstraction manages complexity
 Context: The requirements that a production web server must meet ESSENTIAL
by emphasizing essential
INTERFACE CHARACTERISTICS
will change over time, e.g.: characteristics and suppressing
– New platforms UNESSENTIAL implementation details
DETAILS
– New compilers  Allows postponement of certain
– New functionality
– New performance goals design decisions that occur at
various levels of analysis, e.g.,
 Problems:
– Representational and
– If the web server is “hard coded” using low-level system calls it will algorithmic considerations
IMPLEMENTATION
be hard to port – Architectural and structural
– If web server developers write software that’s tightly coupled with considerations
internal implementation details the software will be hard to evolve – External environment and
platform considerations

12 13
 e.g., loops, iterators, frameworks, and multitasking

Design Principles
ACE Information Hiding
EVENT
LOOP
 e.g., ADT classes and component models

Streams
Common Types of Abstraction

 Information hiding is an important means of achieving abstraction

BACKS
CALL
EVENT

EVENT
LOOP

LOOP

– i.e., design decisions that are subject to change should be hidden

SPECIFIC EVENT HANDLER

behind abstract interfaces

CALLBACKS

FUNCTIONALITY
APPLICATION-

 Application software should communicate only through well-defined

ACE Reactor
ACE Task
 e.g., closed subroutines

interfaces
CALLBACKS
1. Procedural abstraction

 Each interface should be specified by as little information as possible

3. Control abstraction

 If internal details change, clients should be minimally affected

2. Data abstraction

– May not even require recompilation and relinking...

INVOCATIONS
Design Principles

LOCAL
CLASSES

CLASSES
ADT

IPC

14

15
 16
Design Principles

The ACE_Message_Block Class

ACE_Message_Block

# rd_ptr_ : size_t
# wr_ptr_ : size_t
Design Principles

# cont_ : ACE_Message_Block *
# next_ : ACE_Message_Block *

Formats
# prev_ : ACE_Message_Block *
# data_block_ : ACE_Data_Block *

 Algorithms

– Machine
data types
+ init (size : size_t) : int
+ msg_type (type : ACE_Message_Type) ACE_Data_Block
+ msg_type () : ACE_Message_Type

byte-ordering,
+ msg_priority (prio : u_long) # base_ : char *

 Input and Output

– e.g., sorting or
+ msg_priority () : u_long # refcnt_ : int
* 1

character codes
+ clone () : ACE_Message_Block *
+ duplicate () : ACE_Message_Block *
– i.e., using abstract
 Data representations

+ release () : ACE_Message_Block *

dependencies, e.g.,
+ set_flags (flags : u_long) : u_long
searching techniques
+ clr_flags (flags : u_long) : u_long
+ copy (buf : const char *,n : size_t) : int
+ rd_ptr (n : size_t)
+ rd_ptr () : char *
+ wr_ptr (n : size_t)
+ wr_ptr () : char *
+ length () : size_t
+ total_length () : size_t
+ size () : size_t

Class characteristics
protocols
 Hide messaging implementations from clients
ACE_Message ACE_Message ACE_Message
_Block _Block _Block
memory paging

cont() cont() cont()

data_block() data_block() data_block()
 Lower-level interfaces

wr_ptr() wr_ptr() rd_ptr()

Typical Information to be Hidden

rd_ptr() rd_ptr() wr_ptr()

multiple mechanisms
by same mechanisms
i.e., process sequence

ACE_Data
_Block ACE_Data_Block
PAYLOAD reference_count() = 2

(1) SIMPLE MESSAGE STRUCTURE (2) COMPOSITE MESSAGE STRUCTURE

 e.g., reliable communication
 Separating policy and mechanism

 e.g., OS scheduling and virtual

18
– Same policy can be implemented by
– e.g., ordering of low-level operations,

– Multiple policies can be implemented

service can be provided by multiple

17

Design Principles

The ACE_Message_Queue Class

tail_

next()
prev()
cont()
head_

SYNCH_STRATEGY
ACE_Message_Queue
Block
Queue

# head_ : ACE_Message_Block *
Message

Message
Design Principles

# tail_ : ACE_Message_Block *
# high_water_mark_ : size_t
SYNCH

# low_water_mark_ : size_t
Data_Block
STRATEGY

+ ACE_Message_Queue (high_water_mark : size_t = DEFAULT_HWM,

low_water_mark : size_t = DEFAULT_LWM,
notify : ACE_Notification_Strategy * = 0)
next()
prev()
cont()

+ open (high_water_mark : size_t = DEFAULT_HWM,

low_water_mark : size_t = DEFAULT_LWM,
Block

notify : ACE_Notification_Strategy * = 0) : int

Message

+ flush () : int
next()
prev()
cont()

+ notification_strategy (s : ACE_Notification_Strategy *) : void

next()
prev()
cont()

+ is_empty () : int
Block

+ is_full () : int
Message
Data_Block
Block

+ enqueue_tail (item : ACE_Message_Block *,

timeout : ACE_Time_Value * = 0) : int
Message

+ enqueue_head (item : ACE_Message_Block *,

Data_Block

timeout : ACE_Time_Value * = 0) : int

+ enqueue_prio (item : ACE_Message_Block *,
Data_Block

timeout : ACE_Time_Value * = 0) : int

+ dequeue_head (item : ACE_Message_Block *&,
timeout : ACE_Time_Value * = 0) : int
+ dequeue_tail (item : ACE_Message_Block *&,
timeout : ACE_Time_Value * = 0) : int
+ high_water_mark (new_hwm : size_t) : void
+ high_water_mark (void) : size_t
+ low_water_mark (new_lwm : size_t) : void
+ low_water_mark (void) : size_t
+ close () : int
+ deactivate () : int
+ activate () : int
payloads

+ pulse () : int
+ state () : int
transparently

Class characteristics
– Efficiently handles

 Note how the synchronization aspect can be

ACE_Message_Blocks

counting can be added

 Design encapsulates and

strategized!
allocators, and reference
arbitrarily-large message
Information Hiding Example: Message Queueing
 A Message_Queue is a list of

parameterizes various aspects

– e.g., synchronization, memory

19
Design Principles Design Principles

Challenge 3: Determining the Units of Web Server Solution: Component Modularity

Decomposition  A modular system is one that’s structured
APPLICATION-
EVENT SPECIFIC
LOOP GLUE CODE
into identifiable abstractions called
 Context: A production web server that uses abstraction and components
TIME
information hiding NAMING – A software entity that represents an
 Problems: LOCKING abstraction
– A “work” assignment for developers
– Need to determine the appropriate units of decomposition, which TRADING – A unit of code that
LOGGING
should  has one or more names
 Possess well-specified abstract interfaces and  has identifiable boundaries
 Have high cohesion and low coupling  can be (re-)used by other components
 encapsulates data
 hides unnecessary details
 can be separately compiled

20 21

Design Principles Design Principles

Designing Component Interfaces Component Modularity Example: Stream Processing

APPLICATION APPLICATION  A Stream allows flexible
 A component interface consists of HOME RECEPTACLES
Stream Stream
configuration of layered
FACETS
several types of ports: STREAM processing modules
COMPONENT Head
– Exports EXECUTOR CALL  A Stream component contains
 Services provided to other BACKS
a stack of Module components
components, e.g., facets and
 Each Module contains two
DOWNSTREAM

event sources CONTAINER

Task components

UPSTREAM
– Imports EVENT SINK EVENT SOURCE
Multiplexor
 Services requested from STREAM
open()=0 – i.e., read and write Tasks
close()=0
other components, e.g.,  Define components that Tail put()=0
svc()=0  Each Task contains a
receptacles and event sinks provide multiple interfaces NETWORK INTERFACE

– Access Control OR PSEUDO-DEVICES Message Queue component

and implementations
 Not all clients are equal, e.g., and a Thread Manager
protected/private/public  Anticipate change MESSAGE MODULE WRITE
TASK
READ
TASK
component

22 23
Design Principles Design Principles

Benefits of Component Modularity Criteria for Evaluating Modular Designs

Modularity facilitates software Modularity is important for Component decomposability Component continuity
quality factors, e.g.,: good designs since it:
 Are larger components  Do small changes to the
 Extensibility ! well-defined,  Enhances for separation of decomposed into smaller specification affect a
abstract interfaces concerns components? localized and limited number
of components?
 Reusability ! low-coupling,  Enables developers to Component composability
high-cohesion reduce overall system Component protection
complexity via decentralized  Are larger components
 Compatibility ! design composed from existing  Are the effects of run-time
software architectures
“bridging” interfaces smaller components? abnormalities confined to a
 Increases scalability by
 Portability ! hide machine small number of related
supporting independent and Component understandability
dependencies components?
concurrent development by  Are components separately
multiple personnel understandable?

24 25

Design Principles Design Principles

Principles for Ensuring Modular Designs Challenge 4: “Future Proofing” the Web Server
Language support for components Explicit Interfaces
 Context: A production web server whose requirements will change
 Components should correspond to  Whenever two over time
syntactic units in the language components A and B
communicate, this must  Problems:
Few interfaces
be obvious from the text – Certain design aspects seem constant until they are examined in
 Every component should of A or B or both the overall structure of an application
communicate with as few others as – Developers must be able to easily refactor the web server to
Information Hiding
possible account for new sources of variation
 All information about a
Small interfaces (weak coupling)
component should be
 If any two components communicate private unless it’s
at all, they should exchange as little specifically declared
information as possible public

26 27
Design Principles Design Principles

Solution: Extensibility Extensibility Example: Active Object Tasks

 Features
 Extensible software is important to support successions of quick SYNCH_STRATEGY
PEER_STREAM
SYNCH
updates and additions to address new requirements and take Svc Task STRATEGY – Tasks can register with a
Handler open()=0
advantage of emerging opportunities/markets close()=0
Reactor
put()=0
APPLICATION-
svc()=0 A – They can be dynamically
SPECIFIC
APPLICATION-
 Extensible components must be both open and closed, i.e., the INDEPENDENT
linked
SYNCH
“open/closed” principle: Service STRATEGY – They can queue data
Message
Event Object Queue
– They can run as “active
– Open component ! still available for extension Handler suspend()=0 objects”
resume()=0
 This is necessary since the requirements and specifications are handle_input()
handle_output() A Shared
rarely completely understood from the system’s inception handle_exception() Object  JAWS uses inheritance and
handle_signal()
– Closed component ! available for use by other components handle_timeout () init()=0
fini ()=0
dynamic binding to produce
handle_close()
get_handle()=0 info()=0 task components that are
 This is necessary since code sharing becomes unmanageable A A

when reopening a component triggers many changes both open and closed

28 29

Solution: Virtual Machine Architectures

Design Principles

operations that are useful in developing a family

– Extensions provide additional data types and
Challenge 5: Separating Concerns for Layered

primitives that work on a limited set of data

PRESENTATION
PRESENTATION
APPLICATION
APPLICATION
Systems

TRANSPORT

LINK
TRANSPORT

DATA LINK
NETWORK

PHYSICAL
NETWORK

PHYSICAL
– Modeled after hardware instruction set

HOST B

SESSION
SESSION
 A virtual machine layer provides a set of
 A virtual machine provides an extended

DATA
 Context: A production web server whose requirements will change

associated “software instructions”

over time

GATEWAY B

LINK
DATA LINK
NETWORK

PHYSICAL
 Problems:

NETWORK

PHYSICAL
DATA
– To enhance reuse and flexibility, it is often necessary to

PHYSICAL
“software instruction set”

VIRTUAL

LINK
LINK
decompose a web server into smaller, more manageable units

GATEWAY A

LINK
that are layered in order to

DATA LINK
NETWORK

PHYSICAL
NETWORK

PHYSICAL
 Enhance reuse, e.g., multiple higher-layer services can share

of similar systems

DATA
lower-layer services
 Transparently and incrementally enhancement functionality

PRESENTATION
 Improve performance by allowing the selective omission of

PRESENTATION
APPLICATION
APPLICATION

TRANSPORT

LINK
TRANSPORT

DATA LINK
NETWORK

PHYSICAL
NETWORK

PHYSICAL
HOST A

SESSION
SESSION
Design Principles

unnecessary service functionality

types

DATA
 Improve implementations, testing, and maintenance

31
30
  Abstracts away from details of the underlying OS
Design Principles

Other Examples of Virtual Machines

Virtual Machine Layers for the ACE Toolkit

Software Virtual Machine

microcode ! gates, transistors, signals, etc.
NETWORKED
JAWS ADAPTIVE STANDARDS- BASED MIDDLEWARE

 e.g., compiler ! assembler ! obj code !

restartable system calls

WEB SERVER THE ACE ORB
SERVICE
TOKEN GATEWAY
COMPONENTS (TAO)
SERVER SERVER

set of system calls

LAYER

masking signals
LOGGING NAME TIME

signal handlers
SERVER SERVER SERVER

signal stack
SERVICE CORBA
FRAMEWORK ACCEPTOR CONNECTOR
HANDLER HANDLER

signals
LAYER

Java Virtual Machine (JVM)

PROCESS/ STREAMS
C++ THREAD LOG SHARED
SERVICE
WRAPPER MANAGERS MSG CONFIG- MALLOC
REACTOR/

Computer architectures
FACADE

restartable instructions
URATOR

interrupt/trap handlers
PROACTOR
LAYER SYNCH SPIPE SOCK SAP/ FIFO MEM FILE

Hardware Machine
WRAPPERS SAP TLI SAP SAP MAP SAP

blocking interrupts
Operating systems
OS ADAPTATION LAYER
C PROCESSES/ SELECT/

interrupts/traps
WIN32 NAMED SOCKETS/ UNIX DYNAMIC SHARED FILE SYS

interrupt stack
instruction set
PIPES & UNIX
APIS THREADS STREAM PIPES TLI FIFOS IO COMP LINKING MEMORY APIS

 e.g., Linux
Design Principles
PROCESS/THREAD COMMUNICATION VIRTUAL MEMORY & FILE
SUBSYSTEM SUBSYSTEM SUBSYSTEM

GENERAL OPERATING SYSTEM SERVICES

www.cs.wustl.edu/ schmidt/ACE.html 

33
32

Design Principles Design Principles

Challenge 6: Separating Concerns for Hierarchical Solution: Hierarchical Relationships

Systems
 Hierarchies reduce component interactions by restricting the
 Context: A production web server whose requirements will change topology of relationships
over time  A relation defines a hierarchy if it partitions units into levels (note
 Problems: connection to virtual machine architectures)
– Level 0 is the set of all units that use no other units
– Level i is the set of all units that use at least one unit at level < i
– Developers need to program components at different levels of
and no unit at level  i.
abstraction independently
– Changes to one set of components should be isolated as much
as possible from other components  Hierarchies form the basis of architectures and designs
– Need to be able to “visualize” the structure of the web server
design – Facilitates independent development
– Isolates ramifications of change
– Allows rapid prototyping

34 35
38

Design Principles
Design Principles

Hierarchy Example: JAWS Architecture

Class X
Class Y
REQUEST PROCESSING LAYER

svc_run
svc_run svc_run
 A uses relation does not necessarily yield a

 Note, uses is not necessarily the same as invokes:

 X Uses Y if the correct functioning of X depends on

svc_run
hierarchy (avoid cycles...)

the availability of a correct implementation of Y

– Some uses don’t involve invocations

– Some invocations are not uses

The Uses Relation (1/3)

 e.g., message passing, interrupts, shared

 e.g., error logging

memory access

QUEUEING HTTP Msg

Queue Options
LAYER Processor s
s
HTTP HTTP HTTP
Handler Handler Handler

I/O DEMUXING HTTP

Reactor Acceptor
LAYER

36

Design Principles Design Principles

The Uses Relation (2/3) Defining Hierarchies

 Allow X to use Y when:  Relations that define hierarchies include:

– X is simpler because it uses Y – Uses
 e.g., Standard C++ library classes – Is-Composed-Of
– Y is not substantially more complex because – Is-A
it is not allowed to use X – Has-A
– There is a useful subset containing Y and not
 The first two are general to all design methods,
X
the latter two are more particular to OO design
 i.e., allows sharing and reuse of Y
– There is no conceivably useful subset and programming
containing X but not Y
 i.e., Y is necessary for X to function ACE_IPC_SAP ACE_Addr

correctly
 Uses relationships can exist between classes, ACE_SOCK_IO ACE_SOCK

frameworks, subsystems, etc.

ACE_SOCK_Acceptor ACE_INET_Addr

Acceptor-
Reactor Proactor
Connector

ACE_SOCK_Stream ACE_SOCK_Connector

Service
Streams Task
Configurator

39 37
Design Principles
 The is-composed-of relationship shows how the

The Uses Relation (3/3)  The following diagram illustrates some of the

Acceptor

Acceptor
The Is-Composed-Of Relation

components xi that share some common

HTTP

Sock
 X is-composed-of fxig if X is a group of
 A hierarchy in the uses relation is essential for designing reusable
system is broken down in components

is-composed-of relationships in JAWS

software systems

Handler
 However, certain software systems require controlled violation of a

Stream
HTTP

Sock
uses hierarchy

Reactor
– e.g., asynchronous communication protocols, OO callbacks in
frameworks, signal handling, etc.

Handler

Stream
HTTP
– Upcalls are one way to control these non-hierarchical

Sock
dependencies
 Rule of thumb:

Design Principles

Handler
– Start with an invocation hierarchy and eliminate those invocations

Stream
purpose

HTTP

Sock
(i.e., “calls”) that are not uses relationships

41
40

if instances of class X are specialization of class

 class X possesses Is-A relationship with class Y
Design Principles

ACE_Event_Handler that is specialized for

The Is-Composed-Of Relation

associated with object-oriented design and

 This “ancestor/descendant” relationship is
 Many programming languages support the is-composed-of relation

programming languages that possess

HTTP_1_1
– e.g., an HTTP_1_0_Handler Is-A

Handler
via some higher-level component or record structuring technique

ACE_Event_Handler
The Is-A Relation

processing HTTP 1.0 requests

 However, the following are not equivalent:

inheritance and dynamic binding

– level (virtual machine)

handle_input()
get_handle()
– component (an entity that hides one or more “secrets”)
– a subprogram (a code unit)

HTTP_1_0
 Components and levels need not be identical, as a component may

Handler
appear in several levels of a uses hierarchy

Design Principles

Y.

43
42
46
Design Principles

The Has-A Relation

Design Principles
 This “client” relationship is associated with
object-oriented design and programming
languages that possess classes and objects
 class X possesses a Has-A relationship with
class Y if instances of class X contain an
instance(s) of class Y.

– e.g., JAWS, ACE, etc.

middleware infrastructure
– e.g., the JAWS web server Has-A Reactor,

– Promotes system reusability

HTTP_Acceptor, and CV_Filesytem

– Anticipates potential changes

 Heuristics for identifying subsets:
Reactor
JAWS HTTP
Web Acceptor

– Minimize footprints for embedded systems

– Also identify minimal increments to subsets

Server
CV_Filesystem

 This principle should be applied to facilitate extension and

Solution: Program Families and Subsets

– Analyze requirements to identify minimally useful subsets

contraction of large-scale software systems, particularly reusable

 Program families are natural way to detect and implement subsets

44
45

Design Principles

Example of Program Families: JAWS

and TAO
over time

in args
Design Principles

 Problems:

Reactor/Proactor Strategy Singleton

OBJ operation () OBJECT
CLIENT REF (SERVANT) I/O Strategy Cached Virtual
out args + return value
Framework Filesystem
State

Memento

IDL
SKELETON
REAL-TIME Tilde
ORB RUN-TIME OBJECT Asynchronous Completon Token Expander ~
IDL SCHEDULER
STUBS ADAPTER
/home/...
Protocol Event Dispatcher
REAL-TIME ORB CORE Handler
Acceptor

Protocol
IOP IOP
Service Configurator

Filter
PLUGGABLE PLUGGABLE
ORB & XPORT ORB & XPORT
PROTOCOLS PROTOCOLS
Service Configurator
OS KERNEL ACE components OS KERNEL

REAL-TIME I/O REAL-TIME I/O

SUBSYSTEM SUBSYSTEM Concurrency
Adapter

Protocol Pipeline Strategy

State

HIGH-SPEED HIGH-SPEED
NETWORK INTERFACE NETWORK INTERFACE Framework Framework

NETWORK Pipes and Filters Active Object Strategy

(1) THE ACE ORB (TAO) (2) The JAWS Web Server Framework
Software

 TAO is a high-performance, real-time

implementation of the CORBA specification
 JAWS is a high-performance, adaptive Web
server that implements the HTTP specification
release the server without all the features enabled
server to run in resource-constrained environments

 JAWS and TAO were developed using the

wrapper facades and frameworks provided by
the ACE toolkit
– It may be necessary to reduce the overall functionality of the

– To meet externally imposed schedules, it may be necessary to

 Context: A production web server whose requirements will change
Challenge 7: Enabling Expansion and Contraction of

47
 Design Principles

– e.g., sometimes it is important to retain bugs!

Other Examples of Program Families Conventional Development Processes

– e.g., different alphabets, different vertical

– e.g., shared data structures and library

 Waterfall Model

 Different hardware or software platforms

 Different services for different markets – Specify, analyze, implement, test (in sequence)

applications, different I/O formats

– Assumes that requirements can be specified up front

– e.g., UNIX I/O device interface

and Subsets

 Spiral Model

 Different resource trade-offs

 Different internal resources

– Supports iterative development

– e.g., compilers or OSs

 Different external events

– Attempts to assess risks of changes

– e.g., speed vs space

 Backward compatibility
 Rapid Application Development
– Build a prototype
– Ship it :-)

routines
Design Principles

48
49

Design Principles Design Principles

Agile Processes eXtreme Programming: Planning

 Start with user stories
 Stresses customer satisfaction, and therefore, involvement – Written by customers, to
– Provide what the customer wants, as quickly as possible
User Change in Requirements, Risk, specify system
Story or Developement Environment
– Provide only what the customer wants requirements
– Minimal detail, typically
 Encourages changes in requirements Requirements just a few sentences on a
 Relies on testing Planning Commitment
System Time Schedule Iteration – card
Expected development
 For example, eXtreme Programming practices Prototype Game
time: 1 to 3 weeks each,
– Planning, designing, coding, testing roughly
Risk Estimates  Planning game creates
Technology commitment schedule for
Spike entire project
 Each iteration should take
based on http://www.extremeprogramming.org/rules/planninggame.html
2-3 weeks

50 51
Design Principles Design Principles

eXtreme Programming: Designing eXtreme Programming: Coding

 Defer design decisions as long as possible  Pair programming
 Advantages:
– Always code with a partner
– Simplifies current task (just build what is needed) – Always test as you code
– You don’t need to maintain what you haven’t built  Pair programming pays off by supporting good implementation,
– Time is on your side: you’re likely to learn something useful by the
reducing mistakes, and exposing more than one programmer to the
time you need to decide
– Tomorrow may never come: if a feature isn’t needed now, it might design/implementation
never be needed  If any deficiencies in existing implementation are noticed, either fix
 Disadvantages: them or note that they need to be fixed

– Future design decisions may require rework of existing

implementation
– Ramp-up time will probably be longer later
 Therefore, always try to keep designs as simple as possible

52 53

Design Principles Design Principles

eXtreme Programming: Testing Agile Processes: Information Sources

 Unit tests are written before code
 Code must pass both its unit test and all regression tests before
committing
 In effect, the test suite defines the system requirements
– Significant difference from other development approaches
– If a bug is found, a test for it must be added
– If a feature isn’t tested, it can be removed
 Kent Beck, Extreme Programming Explained: Embrace Change,
Addison-Wesley, ISBN 0201616416, 1999
 Kent Beck, “Extreme Programming”, C++ Report 11:5, May 1999,
pp. 26–29+
 John Vlissides, “XP”, interview with Kent Beck in the Pattern
Hatching Column, C++ Report 11:6, June 1999, pp. 44-52+
 Kent Beck, “Embracing Change with Extreme Programming”, IEEE
Computer 32:10, October 1999, pp. 70-77
 http://www.extremeprogramming.org/
 http://www.xprogramming.com/
 http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

54 55
Design Principles Design Principles

Design Guidelines: Motivation Common Design Mistakes (1/2)

 Design is the process of organizing structured solutions to tasks  Depth-first design

from a problem domain
 This process is carried out in many disciplines, in many ways
– There are many similarities and commonalities among design
processes
– There are also many common design mistakes . . .
 The following pages provide a number of “design rules.”
– Remember, these rules are simply suggestions on how to better
organize your design process, not a recipe for success!
– only partially satisfy the requirements
– experience is best cure for this problem . . .
 Directly refining requirements specification
– leads to overly constrained, inefficient designs
 Failure to consider potential changes
– always design for extension and contraction
 Making the design too detailed
– this overconstrains the implementation

56 57

Design Principles Design Principles

Common Design Mistakes (2/2) Rules of Design (1/8)

 Ambiguously stated design  Make sure that the problem is well-defined

– misinterpreted at implementation – All design criteria, requirements, and constraints, should be

 Undocumented design decisions
– designers become essential to implementation
 Inconsistent design
– results in a non-integratable system, because separately
developed modules don’t fit together
enumerated before a design is started
– This may require a “spiral model” approach
 What comes before how
– i.e., define the service to be performed at every level of
abstraction before deciding which structures should be used to
realize the services
 Separate orthogonal concerns
– Do not connect what is independent
– Important at many levels and phases . . .

58 59
Design Principles
Rules of Design (2/8)
 Design external functionality before internal functionality.
– First consider the solution as a black-box and decide how it
should interact with its environment
– Then decide how the black-box can be internally organized. Likely
it consists of smaller black-boxes that can be refined in a similar
fashion
 Keep it simple.
– Fancy designs are buggier than simple ones; they are harder to
implement, harder to verify, and often less efficient
– Problems that appear complex are often just simple problems
huddled together
– Our job as designers is to identify the simpler problems, separate
them, and then solve them individually
60
Design Principles
Rules of Design (4/8)
 Details should depend upon abstractions
– Abstractions should not depend upon details
– Principle of Dependency Inversion
 The granule of reuse is the same as the granule of release
– Only components that are released through a tracking system can
be effectively reused
 Classes within a released component should share common closure
– That is, if one needs to be changed, they all are likely to need to
be changed
– i.e., what affects one, affects all
62
Design Principles
Rules of Design (3/8)
 Work at multiple levels of abstraction
– Good designers must be able to move between various levels of
abstraction quickly and easily
 Design for extensibility
– A good design is “open-ended,” i.e., easily extendible
– A good design solves a class of problems rather than a single
instance
– Do not introduce what is immaterial
– Do not restrict what is irrelevant
 Use rapid prototyping when applicable
– Before implementing a design, build a high-level prototype and
verify that the design criteria are met
61
Design Principles
Rules of Design (5/8)
 Classes within a released component should be reused together
– That is, it is impossible to separate the components from each
other in order to reuse less than the total
 The dependency structure for released components must be a DAG
– There can be no cycles
 Dependencies between released components must run in the
direction of stability
– The dependee must be more stable than the depender
 The more stable a released component is, the more it must consist
of abstract classes
– A completely stable component should consist of nothing but
abstract classes
63
Design Principles Design Principles

Rules of Design (6/8) Rules of Design (7/8)

 Where possible, use proven patterns to solve design problems
 When crossing between two different paradigms, build an interface
layer that separates the two
– Don’t pollute one side with the paradigm of the other
 Software entities (classes, modules, etc) should be open for
extension, but closed for modification
– The Open/Closed principle – Bertrand Meyer
 Derived classes must usable through the base class interface
without the need for the user to know the difference
– The Liskov Substitution Principle

64 65

Design Principles Design Principles

Rules of Design (8/8) Concluding Remarks

 Make it work correctly, then make it work fast
 Good designs can generally be distilled into a few key principles:
– Implement the design, measure its performance, and if
– Separate interface from implementation
necessary, optimize it
– Determine what is common and what is variable with an interface
 Maintain consistency between representations and an implementation
– Allow substitution of variable implementations via a common
– e.g., check that the final optimized implementation is equivalent to interface
the high-level design that was verified  i.e., the “open/closed” principle
– Also important for documentation . . . – Dividing commonality from variability should be goal-oriented
 Don’t skip the preceding rules! rather than exhaustive

– Clearly, this is the most frequently violated rule!!! ;-)  Design is not simply the act of drawing a picture using a CASE tool
or using graphical UML notation!!!
– Design is a fundamentally creative activity

66 67