Information system architectures and architectingEinar Landre, NTNU 23 September 2003 einar.landre@bouvet.no

Topics coveredIntroduction • Definitions and terminology• The role of the architecture• Representation of software architecturesHistory of information systems and their software architectures• Client / Server• Web• Components• Services• Future trends and requirementsFrom domain model to code – A practical tour• Levels of design• System decomposition• ServicesAcademic foundation• Design by contract, Open-Closed, Liskov, Dependency inversion, Package stabilityReferences

Introduction

Ancient architecture

Known facts of the Cheops pyramidheight = 280 cubitsperimeter = 1760 cubits perimeter = 2**height1:43.200 scale model of earthKings chamber 3-4-5 trianglecubit = 52.35 cm

Architecting a dog’s house

Easily built by one personRequires

Minimal modelingSimple processSimple tools

Architecting a houseBuilt most efficiently and timely by a teamRequires

ModelingWell-defined processPower tools

Forces in software

Technology churn

Our enemy is complexity, and it’s our goal to kill it.Jan Baan

Performance Throughput

Capacity

Availability

Fail safe

Fault tolerance

Cost Compatibility

Resilience

The challenge over the next 20 years will not be speed or cost or performance;it will be a question of complexity.

Bill Raduchel, Chief Strategy Officer, Sun Microsystems

Defining architecting and architecture

Architecting, the planning and building of structures, is as old as human societies and as modern as the exploration of the solar system.

Architecting, the art and science of building systems.Eberhardt Rechtin, The art of systems architecting

Architecture – The set of design decisions about any system (or smaller component) that keeps its

implementors and maintainers from exercising needles creativity.

Objects, Components and Frameworks with UML

A (software) systems architecture consists of:

• The structure of it’s parts (including design-time, test-time, runtime hardware and software parts).

• The nature and relevant external visible properties of those parts (modules with interfaces, hardware units, objects).

• The relationships and constraints between them.

Software architecture

Defines how the software is built• Acts as the knowledge base of the software

• Foundation for improvement

• Foundation for change

• Foundation for new features

Characteristics of a good architecture• Built from recognizable patterns and archetypes

• Facilitates change and extension

• Supports the open closed design principle

• Easy to understand – provides conceptual integrity

• Supports the driving requirements

• Clear separation of concern

• Balanced distribution of responsibility

• Balances economic and technical constraints

Architecting versus Engineering

Architecting, deals largely with unmeasurables using non quantitative tools and guidelines based on practical lessons learned (heuristic)

• Software design patterns• Best practices

Engineering, deals almost entirely with measurables using analytical tools derived from mathematics and the hard sciences

• Proven reliability of a system• Formal validation and verification of correctness• Response time requirements

Architecture depends on purpose• Architectures are tightly connected to their purpose, and to some extent they are only

understood through their purpose

• The pyramids?

• To be successful a architecture must meet two requirements:

• Acceptable cost

• Acceptable time

• Some architectures has been stable for 100 years

• Automobiles

• Airplanes

• Railroad systems

• Others close to thousand

• Cathedrals

• Ships

Software as critical system component• Software – the centerpiece of complex system design

• Airplanes• Ships – (The frigate project, probably the largest IT project in the country)• Healthcare• Business (banking, retail, public services, traditional industry)• Energy (Oil & Gas wells, electrical power plants, nuclear power plants)

• Classical systems engineering is based on Decomposition & Integration• The system hierarchy• Software become a sub-system of its processor unit

• Software architectures are layered• Library units call another library unit

• Software and hardware hierarchies become disconnected• The engine control software is a subsystem of the engine• The user interface is a subsystem of the dash board. • The software architecture is layered (user interaction and engine control)• Understanding this is critical when architecting software intensive systems

Situation illustrated

Car

EngineDashboard

Engine

Controller

Engine

Control

View

Car Engineer View

Controller

Software Engineer View

User Interface

Communication

Both views are correct, but their purpose and target group differs

System and software architecture dependencies

• System - response to a need/problem

• Bank self service• Mobile communication system• Naval communication systems• Energy supply system

• System architecture (software intensive)

The structures and parts of a system• Defines software environment• Naval communication system

• Satellites, phones, antennas,….

• Software architecture

The structures and parts of software• Includes design time, test times,

language constraints and interfaces

Purpose

System Architecture

Software

Architecture

System

Representing software architecture – the four viewsSource: Applied Software Architecture

• Code view • The organisation of the source code files and binaries• Java packages and their dependencies• Release and configuration management

• Module view• Layer and packages• Subsystems

• Execution view• Allocation of software to appropriate hardware entities• Communication, coordination and synchronisation between them

• Conceptual view• Describes the system in terms of its major design elements and the

relationship between them• The role of the Software Architecture Document (SAD)

Concerns addressedConceptual• How system fulfils the requirements• How to integrate COTS components (Common of the shelf)• How to support product lines

Module• How is the product mapped to the software platform• How and where are system services used• How to minimize dependencies between modules

Execution• How to meet performance, recovery and reconfiguration requirements• How to balance resource usage• How to achieve necessary concurrency, replication, and distribution without adding to

much complexity

Code• How to reduce product upgrade effort (and time)• How to manage product versions and releases• How to reduce build time

Summary

• Today I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important step toward conceptual integrity.

Fredrick P. Brooks, JRThe mythical man month after twenty years

Learned in the trenches: • Conceptual integrity is for all practical purposes impossible to measure, but identifying

conceptual conflicts is possible. A range of problems can be identified and understoodwhen linked to the concept of conceptual conflicts.

• As an example; Mapping of objects to relational databases is difficult, but the hardness of the mapping can be understood when the concept of conceptual conflict is used.

•

History of information systems and their software architectures

Architectural evolution in terms of generations

Client / Server• Enabled specialisation of computers• Client and server share state • Does not scale

N-tier

• Distribute applications across systems• Requires a tightly controlled network• An extension of the client/server model• CORBA, EJB and DCOM

Network to Network

• Systems in different networks can communicate using standardized interfaces

• System register its services and enables dynamic binding

• Dominated by Web services (XML, UDDI, SOAP)• Systems itself built with N-tier technology

Participant to participant

• A participant in one network can identify and communicate with a participant located in another network

• Jini network technology• Multi agent designs

Client / Server

N-tier

Network to Network

Participant to Participant

Jim Waldo, Sun Microsystems

1974 - IBM releases Systems Network Architecture (SNA)

MVSV

T

A

M

CICS

TSO

RJE

D

A

T

A3270

Terminal(1)3274

Terminal

Controller3270

Terminal(32)

3705

Front-End

Controller

3705

Front-End

Controller

3270

Terminal(1)3274

Terminal

Controller3270

Terminal(32)

Before SNA terminals was physically attached to programs

SNA enabled effective use of thousands of terminals distributed across wide areas

Application areas involved:

• 3270 terminal (synchronous terminal and printer)

• Transaction Processing, Time sharing and Batch

The almighty god in a SNA network was VTAM (Virtual Telecommunications Access Method)

The actual software architectures is still monolitic (user interface, data and algorithms in one chunk)

1974 was also the year Kerf & Kahn released the TCP/IP specification

Phone

Lines

Client / Server – The architecture of the 1980ties

Client Server

User Interface

&

Business Logic

Files

&

Databases

protocol

Originally used to scale mini computer networks

• Client machine(s) responsible for user interaction and business logic

• Server machine(s) responsible for data and common services as print

Applied at both at system and software levels

• Boosted by the BSD Unix release embedding the TCP/IP protocol stack in 1981

• Workstations and PCs are the dominant users of the architecture

Identified problems:

• Tight coupling of client and server made changes hard

• Distribution of software to many clients

• Lack of scalability in the large

• Sensitive to network latency

• Unreliable outside local area network environment

• Client and Server share state

Component architectures (1990 – ?)

Component

Component

Computer

Component

Component

ComputerTCP/IP

Network

Convergence of distributed object models (CORBA) and Transaction Processing Monitors

• Enterprise Java Beans (EJB)

• Distributed Component Object Model (DCOM) from Microsoft

• Move software towards assembly of “pluggable-parts”

Based on the concept of hiding implementation from specification

• Object Oriented

• EJB uses the Java interface construct combined with Remote Method Invocation

• Network transparent

Identified problems

• Solutions become more rigid than first anticipated (not as easy to plug)

• More TP monitor than distributed objects

• Sensitive to network latency

• No accepted standard

Internet and Web oriented architectures (1994 - ?)

Client

Browser

Server

Web ServerInternet

HTTP Transport

Browser installed on any type of computer with graphical user interface attached to Internet

• http://www.bouvet.no - The Unified Resource Locator (URL) was born

Web server provided textual content formatted in HTML

Java launches and become famous for its ability to download code across networks (the applet)

Web servers evolve to handle dynamic content

• Common Gateway Interface (CGI) and Perl

• ActiveX, Java Server Pages, Servlets, Active Server Pages, Dynamic HTML, JavaScripts, PHP, ...

New server side technologies has emerged including J2EE and MS .NET

• Provide comprehensive software frameworks for development and deployment of web based systems

The N-tier web architecture – practical use of components

Client

Browser Internet

HTTP TransportServer - side

Web

Server

Application

Server

(EJB)

Database

Server

The server side is dominated by the N-tier architecture

• Web, Application and Database servers are large software components

• They can reside on one or more physical computers

• The architecture provides scalability and redundancy

• Based on the same principles as IBM applied in 1974

• Designed to handle thousands of interactive users

• Practical use of component architectures

Identified problems:

• More rigid than first anticipated

• More TP monitor than distributed object model

• Sensitive to network latency

Beyond components – Network to Network Services

Network Network

XML

Network to Network

system system

Enables systems in different networks to communicate

• Also known as web services

• Supports synchronous and asynchronous communication

Supported by mechanisms such as

• UDDI (Universal Description, Discovery & Integration)

• SOAP (Simple Object Access Protocol – XML)

• Systems within network built on N-tier technology

Typical use:

• Place an order at a supplier system

• Reserve a ticket

• Addresses some of the key issues found in Enterprise Application Integration

Problems:

• Scalability

• Management

Challenge - Systems become more and more distributed

• Deutsche’s fallacies of networking becomes an issue:

1. The network is reliable

2. The latency is zero

3. Bandwidth is infinite

4. The network is secure

5. The topology doesn’t change

6. There is one administrator

7. Transport cost is zero

8. There is one administrator

• These issues are not handled by classical architectures such as:

• Client / Server

• N - tier

Distributed architectures – Participant to Participant

Network

Participant

Network

Participant

protocol

Participant can be anything from a super computer, printer, mobile phone, PDA or car, or just an agent

• Participants may be limited with respect to power supply, memory and cpu capacity

• Participants will be switched on and off

• A participant must advertise its services, and be able to find other participants services

Existing architectures does not support this:

• They fail on Deutsche’s fallacies

• Dynamic lookup of services

Sun Jini network technology provides a solution:

• Dynamic distribution of networked services is built into the language run-time environment

• www.jini.org

• rio.jini.org

• java.sun.com/jini

Why distributed architectures are needed

• Distributed solving of problems• Problem can be solved in independent chucks

• Utilises available but idle CPU cycles

• Grid computing

• (distributed) Solving of distributed problems• Analysis, identification, fault finding and control of physically distributed systems

• Control of communication or energy network

• Traffic control systems

• Monitoring of underwater oil wells

• Monitoring is distributed to each node in the system

• The knowledge of how to react to different situations must exist within each node in the system

• Use of agents in multi agent desigs provides the required tools

Understanding agentsSource: Multi agent systems, Ferber

An agent is a physical or virtual entity:• Which is capable of acting in an environment

• Which can communicate directly with other agents

• Which is driven by a set of tendencies / individual objectives

• Which possesses resources of its own

• Which is capable of perceiving its environment

• Which as only a partial representation of its environment

• Which possesses skills and can offer services

• Which may be able to reproduce itself

• Whose behaviour tends toward satisfying its objectives, taking into account of the resources and skills available

Common used multi agent architectures• Blackboard designs

• Agents communicates using a shared blackboard

• Conceptually simple and easy to understand

• Hard to implement due to control issues

• JavaSpaces provides a powerful platform for building blackboards (Collaborating agents/systems)

• Production systems (rule based systems)• The most common approach when constructing a knowledge base

• Production rules are expressed on the form:

IF <list of conditions> THEN <list of actions>

• Required when solving “Ill structured problems”; Eg. Where should I go for a holyday?

• Implemented in rule engines

• JESS (Java Expert System Shell) provide a powerful toolkit for a dive into the world of rules

• ILOG – JRules among other

JavaSpaces – the ultimate distributed blackboard

A JavaSpace is service defined by a Java interface:

interface JavaSpace {

write(Entry tmpl, Transaction txn, Long lease)

read(Entry tmpl, Transaction txn, Long timeout)

readIfExist(Entry tmpl, Transaction txn, Long timeout): Entry

takeIfExist(Entry tmpl, Transaction txn, Long timeout) : Entry

Take(Entry tmpl, Transaction txn, Long timeout) : Entry

notify(Entry tmpl

snapshot(Entry e)

An entry is a Java object implementing the Entry interface

interface Entry ….

Class PersonEntry implements Entry, PersonBean {

Public String name; // Space requires public

Public String address:

Public void setName(String name)

Public String getName()

JavaSpace is based on Linda Tuple spaces

Developed at Yale (Gelerntner)

Think of Duke as agents with differentgoals and objectives conversing with each other across the JavaSpac.

Example of a space based web architecture• The Servlet receives HTTP requests and process these

requests.

• Business objects are stored as JavaBeans in a JavaSpace, and the servlet will read and write bean objects to and from the space

• Behind the space specialized agents listens for specific types of requests in the space and produces valid response objects.

• The effect of this architecture is total decoupling of client side from server side.

• The space can be located anywhere and neither the servlet nor the agents need to worry about that.

• This architecture is an example of a alternative to client/server and N-tier, though the blueprint conforms to an N-tier solution.

Web ContainerServlet

SomeBean

Void setX(i:X)

X getX()

read

write

take

JavaSpace

DB

AgentDB

Agent

DB

Agent

SummaryThe Web builds on the same concepts as IBM’s terminal world of 1974

• Systems Network ArchitectureClient/Server and N-tier components requires stable and controlled networks

• Deutsche’s fallacies• Understanding round-trip delay and latency is required• Components more rigid than first anticipated

New architectures required for next generation of distributed systems• Jini Network technology provides a solution• Multi agent designs• Use of rule engines providing inference and knowledge

Architectures are critical in today’s software systems• The more complex systems success depends on architecture at both

system and software levels.

From domain model to code

A practical tour based on Java

The design process – Building a working system

• Decompose system into modules• Maximize cohesion • Minimize coupling

• Determine relations between modules• Inheritance• Composition• Identify where flexibility is desirable and where it is not

• Determine the form of inter module communication• Remote Procedure Calls• Messaging

• Specify module interfaces• Should be well defined• Facilitate independent testing• Improve group communication

Characteristics of bad design and their cause

• Rigid• hard to change because every change affect the whole system

• Fragile • when making a change, unexpected parts of the system fails

• Immobile • hard to reuse in other applications because of tight couplings

• The main cause of bad design is direct mapping of the domain model• Violating documented design principles• Object oriented languages makes this worse• What about components?

Design in practice – LevelsArchitectural (system) design:

• Scope: Subsystems, Processors, Tasks, Packages, safety & reliability

• Patterns: Micro kernel, Rendezvous, Broker, Proxy

• Define terminology

• The four views

Mechanistic design:

• Scope: Class collaboration

• Patterns: Design Patterns (GOF) and Core J2EE patterns

Detail design:

• Scope: Class, Data and O-R mapping

Phases of design, scope and deliveries Source: Doing hard time, Douglas 1999

Algorithmic detail within class

Details of data members (types, ranges)

Details of functional members (arguments)

Intra-objectDetailed

Instances of design patterns of multiple collaborating objects

Containers and design-level classes and objects

Medium-level error handling policies

Inter-objectMechanistic

Number and type of processors

Packages of objects running on each processor

Inter-process communication

Concurrency model, and inter-thread communication strategies

Software layering and vertical slices

Error handling policies

System wide

Processor wide

Architectural

What is specifiedScopeDesign phase

Architectural design – Processors

Web Server

EJB Container

Web ServerWeb Server Web Server Web Server

EJB Container

Database Cluster Processor boundary = network boundary

Think of the software layers

Architectural design – Tasks• Definition

• Separate function that must occur or appear to occur concurrently• Task types:

• Event driven • Clock driven• Priority and Critical• Task coordinator

• Implementation:• Java Threads• Agents• Message driven beans• Standalone processes• EJB session beans

Architectural design – Packages

• Packages is a grouping mechanism of functionality• UML has a representation, the same has Ada , C++ and Java

• A poor package structure in Java will haunt the system in its lifetime• Separate specification from implementation • Use separate source threes

• Package structure defines the architectureSpecifications:• no.bouvet.marketplace.business.MarketServiceFactory• no.bouvet.marketplace.business.UserAccountServiceImplementation:• no.bouvet.marketplace.business.MarketServiceFactoryImpl• no.bouvet.marketplace.business.UserAccountServiceImpl

Architectural design – Sub-systems

• Group functionality into logical packages

• Required to manage complexity

• Identify interfaces and package dependencies

• Abstract versus concrete packagesTrade EngineUser

Managemet

Account Management

Report ing & Statistics

Common Messaging

Subsea Segment

Airborn Platform

Ground Segment

Communication System

Commercial system

Defence system

Architectural design – Layers

User Interface Layer

• Responsible for all user interactions• Realized by portal frameworks and to

some extent Swing components.• Includes Web services and XML

interfaces for communication

Business Service Layer

• Responsible for domain specific functions

• Realized by JavaBeans,Session Beans, Jini Services and Servlets and other ordinary classes

Data & Integration Layer

• Responsible for data access and access to other systems

• Implemented in databases (SQL), Entity Beans and Data Access Objects

• Asynchronous messaging a part of this layer

User Interaction Layer

Business Services Layer

Data & Integration Layer

Architecture – IllustratedUser Interaction Layer

• Tag libraries a issue• Usability a issue• Information architecture a issue

Business Service Layer• Defined by interfaces and interfaces only.• Interfaces should be network ready. Eg.

throw RemoteException.• Implemented with EJB, Servlet,JavaBean’s

or Jini servicesData & Integration Layer

• Defined by interfaces, message standards and database tables.

• Agents are self contained processes with a well defined purpose

• Agents can also implement domain specific business rules

• Agents can execute rules defined in rule based tools such as JESS and JRule

• Message service can be JMS, Corba, JavaSpaces

• Data can be local databases or external legacy systems. Communication managed by agents

User Interaction Layer

•Web, Rich client (swing) and Mobile

Agent

Data

Business

Service

Business

Service

Business

Service

Business Service Layer

Message Service

Data & Integration Layer

Access Service Access Service

Agent

DataData

Mechanistic design• Mechanistic design is concerned with adding and

organizing classes to support a particular implementation strategy

Bruce Powel Douglass

• Goal:Transform the analysis model into a effective working design• Maximize cohesion• Minimize couplings

• Tools:• Separate specifications from implementation• Design patterns (GOF book)• Inheritance and composition• What about EJB’s?

Practical design step one – decomposing the domain model

RequestOffer

Type

Seller Bu yer

Autom obi le

id : Integ erval id Ti me : Integerpri ce : Integerown erNam e : Stringdescri ption : S tringmake : St ri ngmod el : S tringyear : In tege rcol or : St ri ng

Bi d

id : IntegervalidTime : IntegercarId : IntegerownerName : Stringmessage : Stringprice : Integer

Contract

id : IntegeritemName : Stringbuyer : Stringseller : Stringprice : Integer

Marketplace

makeBid()acceptBid()findBid()makeOffer()findOffer()makeRequest()findRequest()findAllContracts()findContractBySeller()findContractByBuyer()

Identified services and data objects

• ContractService• findAll• findBySeller• findByBuyer

• OfferService• makeOffer• FindOffer

• ResponseService• makeResponse• acceptResponse• findResponse

• RequestService• makeRequest• findRequest

• ResponseBean

• getPrice

• setPrice

• CarMarketBean

• setPrice

• getPrice

• Contract

• getPrice

• getBuyer

Marketplace services and factory specification

MarketFactory

createBidService() : BidServicecreateRequestService() : RequestServicecreateOfferService() : OfferServicecreateContractService() : ContractServicecreateBid() : BidBeancreateCarMarketBean() : CarMarketBean

<<interface>>

ContractBean

getBidder()getParticipant()getPrice()getMessage()getType()

<<interfa ce>>

ContractService

findAll() : Collection

findBySeller(name : String) : ContractBeanfindByBuyer(name : buyer)

<<interface>>

OfferService

make(offer : CarMarketBean, validTime : Integer)find(template : CarMarketBean) : Collection

<<Interface>>

RequestService

make(request : CarMarketBean, validTime : Integer)find(template : CarMarketBean) : Collection

<<interface>>

BidService

make(abid : BidBean, validTime : Integer)find(template : BidBean) : Collectionaccept(abid : BidBean)

<<interface>>

BidBean

getMessage()getParticipant()getPrice()setMessa ge()setParticipant()setPrice()init()

<<interface>>

CarMarketBean

setMake()setModel()setColour()setYear()setPrice()getMake()getMode l()getColour()

getYear()getPrice()init()

<<interface>>

Service specification

Specification consists of:• Specification is composed of package and interface• The service throws RemoteException and is implicit

networked enabled• Its up to the implementer to decide on distribution or

notSample code

package no.bouvet.business.marketplace;

import Java.rmi.RemoteException;

public interface RequestService {

public Collection find(...) throws RemoteException;

public void makeRequest(..) throws RemoteException;

}

RequestService – EJB design

RequestService

make()find()

<<Interface>> MarketplaceFactory

createBidService() : BidServicecreateOfferService() : OfferServicecreateRequestService() : RequestServicecreateUserService() : UserService

<<Interface>>

RequestServiceRemote<<interface>>

EJBObject<<ejb-specification>>>>

SessionBean<<ejb-specification>>>>

RequestSe rviceBean<<SessionBean>>

RequestServiceHome

create() : RequestServiceRemote

<<interface>>

EJBHome<<Interface>>>>

MarketplaceEJBFa ctory

Service implementation – EJB exampleSpecify EJB specific interfacespackage no.bouvet.business.marketplace;import javax.ejb.EJBObject;public interface RequestServiceRemote extends EJBObject,

RequestService{}

public interface RequestServiceHome extends EJBHome {public RequestServiceRemote create() throws RemoteException

}

Implementing the beanpackage no.cellnetwork.business.marketplace;public class RequestServiceBean implements SessionBean, RequestService {

public Collection findRequest(){}public void makeRequest() {}public void acceptRequest() {}

}

Implementing the factory

public RequestService createRequestService() {RequestServiceRemote remote = null;InitialContex ctx = new InitialContext();try {

Object ref = ctx.lookup("RequestService"); RequestServiceHome home =

(RequestServiceHome)PortableRemoteObject.narrow(

ref,RequestServiceHome.class); remote = home.create(); } catch (Exception e) { // throw new MarketException("Could not create

RequestService"); } return (RequestService)remote; }

Detail design – the last step before code

• Scope:• Classes and type safe attributes• Representing complex data structures• Database design and OR mapping• Object oriented databases and Java Data Objects

Making attributes type safe

Ada provides:• Type Missile_Speed_Type is float 0.0..6000.0;

• Type Missile_Range_Type is float 0.0..4000.0;

• Missile_Speed : Missile_Speed_Type;

• Missile_Range : Missile_Range_Type;

• Some_Float : Float;

• Some_Float := Missile_Range + Missile_Speed; -- Stopped by compiler !!

Java requires class encapsulation:• Lack of operator overloading an issue:

• Class Speed_Type …..

• Class Range_Type ……

Mapping objects to relational databases• Database on 3’d normal form is good for objects too

• No redundancy - performance an issue, use your brain • No internal dependency - unique rows

• Database should be designed to support the object model• Relations a result of business methods in objects• Complex queries best done manually (Torque is a tool but performance an issue)• Stored procedure speeds performance

• What about entity beans• Think of it as a persistent object• Spann one table, though EJB 2.0 supports foreign key• Small result sets

• Consider to use a Data Access Service• Returns valueObjects (JavaBean’s)• Encapsulates your SQL

Using the Data Access Service

DataAcce ssService

insert(Persistable object)delete(Persistable object)update(Persistable object)find(Persistable object)

<<interface>>

Persistable<<Interface>>DataAccessServiceFactory

cre ateDa taAccessSe rvice()

<<Interface>>

MyObjectLocalDataAccessImplMyObjectEntityBeanImpl

MyObject

Composite data structures (GOF 104)

Task

cost : Integer

calculateCost()

Project

cost : Integer

calculateCost()

Activ ity

add()remove()getActivity()calculateCost()

<<Interface>>

Key success factors

• Architecture• Services ( interface’s)• Layers (packages)• Separate specification from implementation (package+interface = true)

• Understanding of OO design principles• More than inheritance• Patterns a good tool• Understand the network boundary (bandwidth & latency)

• A good process addressing the right problem at the right time• Hacking is banned – Model your system and evolve it carefully• Starting with the database is banned – Database derived from object

model• Think in terms of design levels - Stay at the right abstraction level

Academic Foundation

Design challenges

• Bad design is the result of violating well documented design principles:

• Maximize cohesion• Minimize coupling

• Academic foundation:• Design by contract• The Open / Closed principle• Liskov’s substitution principle• The dependency inversion principle

Design by contract – the assertion mechanismPre-conditions

• Specify properties that must hold whenever an operation is called

• Client responsible for checking

Post-conditions

• Describe properties that the operation guarantees when completed

• Class responsible for ensuring

Invariants

• Global properties of class that must be preserved at all times

• Class responsible for ensuring consistency

Exception

arises when pre-conditions satisfies but one or more post-conditions fail

Inheritance & Design by contract

Parents invariant rule• Class invariants of parent are retained in the

subclass

Assertion redefinition rule• Pre-conditions may only be weakened in the

subclass

• Post-conditions may only be strengthened in the subclass

Class

Subclass

The open closed principle

Software entities (classes, modules, components) should be open for extension but closed for modification

Closed Client• The client is closed because, in order to use

another server, its code must be changed to mention the new server.

Open Client• The client is open because it uses services

published for an abstract class. In order to introduce change to the server, the designer need only to add new derived server classes. The Client class remains unaltered.

Client Server

Client is closed

Client AbstractServer

Client is open

ServerOne ServerTwo

Liskov substitution principle (Polymorphism)

Functions that use base class interfaces must not depend on nor be confused by any derivatives of those interfaces

• This rule is a logical consequence of the open-closed principle

More formally:• Consider a function F that uses type T.

• Given S a subtype of T, F should be able to use objects of type S without knowing it.

Breaking it requires code like this:

void F(T input) {

if (input instanceoff S) { …….Barbara Liskov’s work is featured in Jim Coplien’s book Advanced C++ Programming Styles and Idioms

The dependency inversion principle

• Abstractions should not depend on details. Details should depend on abstractions.

• Inverted dependency with abstract layers• Each layer derives from an abstract class. Lower layers used by higher

layer through lower layer’s abstract interface. So – Layer’s depends on abstract classes

PolicyLayer MechanismInterface<<abstract>>

MechanismLayerUtilityInterface<<abstract>>

UtilityLayer

Policy

Mechanism

Utility

Package Stability

The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than that it is.

Robert Martin’s Package Stability Metrics

• Ca - Afferent Couplings: The number of classes outside this package that depend upon classes within this package.

• Ce – Efferent Couplings: The number of classes inside this package that depends upon classes outside this package.

• I – Instability: (Ce / (Ca+Ce)): This metric has a range [0,1]. I=0 indicates a maximally stable package. I=1 indicates a maximally instable package.

Not all packages should be stable

• If all packages in a system where maximally stable, the system would be unchangeable.

• We want to design our package structure so that some packages are instable and some are stable.

• The ideal configuration for a system with three packages has the changeable packages on top. They depend upon stable packages at the bottom.

I=0, Stable

I=1, instable I=1, instable

The stable abstraction principle

Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.

Abstraction versus stability

It should be noted that many packages do fall within (0,0) zone. An example would be a database schema. Database schemas are notorously volatile and are highly dependent upon. This is one of the reasons that the interface between OO applications and databases is so difficult.

Abs

trac

tion

Instability 1

1 A=1, I=1: Abstract and no dependants

A=0, I=0 Stable and concrete

Main

Sequence

Abstraction (A) = Abstract classes / total classes

Instability = Ce / (Ca + Ce)

References• The art of systems architecting, 2nd edition, 2002, Maier, Rechtin, ISBN: 0-8493-0440-

7

• Objects, Components and Frameworks with UML, D’Souza, Wills, 1999, ISBN 0-201-31012-0

• Applied Software Architecture, Hofmeister, Nord & SONI, 2000, ISBN 0-201-32571-3• Object oriented software engineering, Jacobson, 1992, ISBN: 0-201-54435-0• The Jini specification, 2nd edition, Waldo et al, ISBN: 0-201-72617-3• Doing hard time, Douglas, 1999, ISBN: 0-201-49837-5• Design patterns, 1995, Gamma et al, ISBN: 0-201-63361-2• Core J2EE Patterns, 2001, Crupi et al, ISBN 0-130-64884-1• Multi Agent Systems, An Introduction to distributed artifical intelligence, 1999, Ferber,

ISBN: 0-201-36048-9• JESS in action, 2003, Friedman-Hill, ISBN: 1-9310110-89-8• www.sei.cmu.edu• www.bredemeyer.com