Transcript Architectural

Information system architectures and
architecting
Einar Landre, NTNU 23 September 2003
[email protected]
Topics covered
Introduction
•
Definitions and terminology
•
The role of the architecture
•
Representation of software architectures
History of information systems and their software architectures
•
Client / Server
•
Web
•
Components
•
Services
•
Future trends and requirements
From domain model to code – A practical tour
•
Levels of design
•
System decomposition
•
Services
Academic foundation
•
Design by contract, Open-Closed, Liskov, Dependency inversion, Package stability
References
Introduction
Ancient architecture
Known facts of the Cheops pyramid
height = 280 cubits
perimeter = 1760 cubits
perimeter = 2**height
1:43.200 scale model of earth
Kings chamber 3-4-5 triangle
cubit = 52.35 cm
Architecting a dog’s house
Easily built by one person
Requires
Minimal modeling
Simple process
Simple tools
Architecting a house
Built most efficiently and timely by a team
Requires
Modeling
Well-defined process
Power tools
Forces in software
Cost
Capacity
Compatibility
Fail safe
Availability
Performance
Technology churn
Fault tolerance
Throughput
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
Our enemy is complexity, and it’s our goal to kill it.
Jan Baan
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 Engineer View
Car
Dashboard
Software Engineer View
User Interface
Engine
Communication
Controller
Engine
Engine
Control
Controller
View
Both views are correct, but their purpose and target group differs
System and software architecture dependencies
Purpose
•
•
System
System Architecture
Software
Architecture
•
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
Representing software architecture – the four views
Source: 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 addressed
Conceptual
•
•
•
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, JR
The 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 understood
when 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
Jim Waldo, Sun Microsystems
Participant to Participant
Network to Network
N-tier
Client / Server
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
1974 - IBM releases Systems Network Architecture (SNA)
3270
Terminal(1)
3270
Terminal(32)
3274
3705
Terminal
Front-End
Controller
Controller
V
3705
T
Front-End
A
Controller
M
Phone
Lines
3270
Terminal(1)
3270
Terminal(32)
3274
Terminal
MVS
CICS
TSO
A
T
RJE
Controller
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 
D
A
Client / Server – The architecture of the 1980ties
Client
protocol
Server
User Interface
Files
&
&
Business Logic
Databases
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 – ?)
Computer
Component
Computer
TCP/IP
Component
Network
Component
Component
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
HTTP Transport
Internet
Server
Web Server
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
Server - side
HTTP Transport
Web
Application
Database
Server
Server
Server
Internet
(EJB)
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 to Network
• Also known as web services
XML
Network
system
Enables systems in different networks to communicate
Network
system
• 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
protocol
Participant
Network
Participant
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 agents
Source: 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
Think of Duke as agents with different
goals and objectives conversing with each
other across the JavaSpac.
Public String address:
Public void setName(String name)
Public String getName()
JavaSpace is based on Linda Tuple spaces
Developed at Yale (Gelerntner)
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 Container
Servlet
read
write
take
JavaSpace
SomeBean
Void setX(i:X)
X getX()
DB
DB
DB
Agent
Agent
Agent
Summary
The Web builds on the same concepts as IBM’s terminal world of 1974
• Systems Network Architecture
Client/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 – Levels
Architectural (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
Design phase
Scope
What is specified
Architectural
System wide
Processor wide
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
Mechanistic
Inter-object
Instances of design patterns of multiple collaborating
objects
Containers and design-level classes and objects
Medium-level error handling policies
Detailed
Intra-object
Algorithmic detail within class
Details of data members (types, ranges)
Details of functional members (arguments)
Architectural design – Processors
W eb Server
EJB Container
W eb 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 architecture
Specifications:
• no.bouvet.marketplace.business.MarketServiceFactory
• no.bouvet.marketplace.business.UserAccountService
Implementation:
• no.bouvet.marketplace.business.MarketServiceFactoryImpl
• no.bouvet.marketplace.business.UserAccountServiceImpl
Architectural design – Sub-systems
Defence system
Ground
Segment
Airborn
Platform
Communication
System
Subsea
Segment
Commercial system
Report ing &
Statistics
User
Managemet
Comm on
Messaging
Account
Management
Trade Engine
• Group functionality into
logical packages
• Required to manage
complexity
• Identify interfaces and
package dependencies
• Abstract versus concrete
packages
Architectural design – Layers
User Interaction
Layer
Business
Services Layer
Data & Integration
Layer
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
Architecture – Illustrated
User Interaction Layer
•Web, Rich client (swing) and Mobile
Business Service Layer
Business
Business
Business
Service
Service
Service
Data & Integration Layer
Access Service
Access Service
Message Service
Agent
Agent
Data
Data
Data
User 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 services
Data & 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
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
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
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
not
Sample 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
Service implementation – EJB example
Specify EJB specific interfaces
package 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 bean
package 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
Composite data structures (GOF 104)
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 mechanism
Pre-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
Cl as s
Parents invariant rule
•
Class invariants of parent are retained in the
subclass
Assertion redefinition rule
Subclas s
•
Pre-conditions may only be weakened in the
subclass
•
Post-conditions may only be strengthened in
the subclass
The open closed principle
Software entities (classes, modules,
components) should be open for extension but
closed for modification
Client is clos ed
Client
Server
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
•
Client is open
Client
AbstractServer
ServerOne
ServerTwo
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.
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
Policy
Mechanism
<<abstract>>
MechanismInterface
MechanismLayer
<<abstract>>
UtilityInterface
Utility
UtilityLayer
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
I=1, instable
I=0, Stable
I=1, instable
•
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.
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 (A) = Abstract classes / total classes
Abstraction versus stability
Instability = Ce / (Ca + Ce)
1
A=1, I=1: Abstract and no dependants
Instability
1
A=0, I=0 Stable and concrete
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.
References
•
•
•
•
•
•
•
•
•
•
•
•
The art of systems architecting, 2nd edition, 2002, Maier, Rechtin, ISBN: 0-8493-04407
Objects, Components and Frameworks with UML, D’Souza, Wills, 1999, ISBN 0-20131012-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