Information system architectures and architecting
This presentation is the property of its rightful owner.
Sponsored Links
1 / 64

Information system architectures and architecting PowerPoint PPT Presentation


  • 109 Views
  • Uploaded on
  • Presentation posted in: General

Information system architectures and architecting. A practical tour Einar Landre Cell Network AS [email protected] Topics covered. Introduction Definitions and terminology History of information systems and their software architectures Client / Server Web Components

Download Presentation

Information system architectures and architecting

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Information system architectures and architecting

Information system architectures and architecting

A practical tour

Einar Landre

Cell Network AS

[email protected]


Topics covered

Topics covered

  • Introduction

    • Definitions and terminology

  • 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

Introduction


Ancient architecture

Ancient architecture

Facts Cheops (Khufu)

height = 280 cubits

perimeter = 1760 cubits

perimeter = 2*p*height

1:43.200 scale model of earth

Kings chamber 3-4-5 triangle

cubit = 52.35 cm


Architecting a dog s house

Architecting a dog’s house

Can be built by one person

Requires

Minimal modeling

Simple process

Simple tools


Architecting a house

Architecting a house

Built most efficiently and timely by a team

Requires

Modeling

Well-defined process

Power tools


Forces in software

Capacity

Fail safe

Availability

Fault tolerance

Performance

Throughput

Technology churn

Resilience

Forces in software

Functionality

Cost

Compatibility

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

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.

  • 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

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

    • Supports the driving requirements

    • Clear separation of concern

    • Balanced distribution of responsibility

    • Balances economic and technical constraints


Architecting versus engineering

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

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

    • Ships

    • Railroad systems

  • Others close to thousand

    • Cathedrals


Software as critical system component

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)

  • Classicalsystems engineeringis based onDecomposition & 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 hierarcys 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


The situation illustrated

The situation illustrated

Car Engineer View

Software Engineer View

Car

User Interface

Communication

Dashboard

Engine

Controller

Engine

Control

View

Engine

Controller

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


System and software architecture dependencies

Purpose

System

System Architecture

Software

Architecture

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


Summary

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


History of information systems and their software architectures

History of information systems and their software architectures


In 1974 ibm released its systems network architecture sna

3270

Terminal(1)

3270

Terminal(1)

3274

Terminal

Controller

3274

Terminal

Controller

MVS

3270

Terminal(32)

3270

Terminal(32)

CICS

V

T

A

M

D

A

T

A

TSO

RJE

In 1974 IBM released its Systems Network Architecture (SNA)

3705

Front-End

Controller

Phone

Lines

3705

Front-End

Controller

  • Before SNA terminals was physically attached to programs

  • SNA enabled effective use of thousands of terminals (users)

  • 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)

  • Software architectures still monolitic (user interface, data and algorithms in one chunk)

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


Client server the architecture of the 1980ties

Client / Server – The architecture of the 1980ties

Client

Server

protocol

Files

&

Databases

User Interface

&

Business Logic

  • 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

    • Unix workstations (SUN) and later PC 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


Internet and web oriented architectures 1994 today

Internet and Web oriented architectures (1994 – today)

HTTP Transport

Client

Server

Internet

Browser

Web Server

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

    • http://www.cellnetwork.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 (the applet)

  • Web servers evolve to handle dynamic content

    • Common Gateway Interface (CGI) and Perl

    • Programs are impossible to maintain

  • Sun launches the servlet concept, enabling server side dynamic HTML management

  • The need to simplify user interface programming results in tag libraries

    • Sun – Java Server Pages (JSP), MS got ASP and Open Source got PHP

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


Component architectures 1990 today

Computer

Computer

Component

Component

Component

Component

Component architectures (1990 – today)

TCP/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


The n tier web architecture practical use of components

The N-tier web architecture – practical use of components

HTTP Transport

Server - side

Client

Internet

Web

Server

Application

Server

(EJB)

Database

Server

Browser

  • 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

  • Identified problems:

    • More rigid than first anticipated

    • More TP monitor than distributed object model

    • Sensitive to network latency


Beyond components network to network services

Beyond components – Network to Network Services

Network to Network

XML

Network

Network

system

system

  • Systems in different networks can 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

  • Problems:

    • Scalability

    • Management


Challenge systems become more and more distributed

Challenge - Systems become more and more distributed

  • Deutsche’s fallacies of networking becomes an issue:

    • The network is reliable

    • The latency is zero

    • Bandwidth is infinite

    • The network is secure

    • The topology doesn’t change

    • There is one administrator

    • Transport cost is zero

    • There is one administrator

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

    • N-tier

    • Client / Server


Distributed architectures participant to participant

Network

Network

Participant

Participant

Distributed architectures – Participant to Participant

protocol

  • Participant can be anything from a super computer, printer, mobile phone, PDA or car

    • 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


Javaspaces an example of a distributed object store

JavaSpaces – an example of a distributed object store

  • A JavaSpace is defined by a Java interface:

    • write(Entry tmpl, Transaction txn, Long lease)

    • read(Entry tmpl, Transaction txn, Long timeout)

    • readIfExist

    • take

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

    • notify(Entry tmpl

    • snapshot(Entry e)

  • An entry is a Java object implementing the Entry interface

  • 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)


Example of a space based web architecture

DB

Agent

DB

Agent

DB

Agent

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

JavaBean

Void setX(i:X)

X getX()


Architectural evolution in terms of generations

Architectural evolution in terms of generations

  • N-tier

    • Distribute applications and services 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

    • Systems itself built with N-tier technology

    • Web services, XML, UDDI, SOAP

  • Participant to participant

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

    • Jini network technology

Participant to Participant

Network to Network

N-tier

Client / Server


Summary1

Summary

  • Web is similar to 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 collaborative systems

    • Jini Network technology provides a solution

  • 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

From domain model to code

A practical tour based on Java


The design process building a working system

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

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

Design in practice – Levels

  • Architectural (system) design:

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

  • Patterns: Micro kernel, Rendezvous, Broker, Proxy

  • Define terminology

  • 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

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


Architectural design processors physical

Architectural design – Processors (physical)

Processor boundary = network boundary

Think of the software layers


Architectural design tasks

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

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.cellnetwork.marketplace.business.MarketServiceFactory

    • no.cellnetwork.marketplace.business.UserAccountService

      Implementation:

    • no.cellnetwork.marketplace.business.MarketServiceFactoryImpl

    • no.cellnetwork.marketplace.business.UserAccountServiceImpl


  • Architectural design packages and sub systems

    Architectural design – Packages and sub-systems

    Defence system

    • Group functionality into logical packages

    • Required to manage complexity

    • Identify interfaces and package dependencies

    • Abstract versus concrete packages

    Commercial system


    Architectural design packages and layers

    Architectural design – Packages and 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


    Architecture illustrated

    Architecture – Illustrated

    • User Interaction Layer

    • Web, Rich client (swing) and Mobile

    • 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. Throws RemoteException.

      • Implemented as EJB, Servlet,JavaBean’s

    • 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

      • Message service can be JMS, Corba, JavaSpaces

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

    Business Service Layer

    Business

    Service

    Business

    Service

    Business

    Service

    Data & Integration Layer

    Access Service

    Access Service

    Message Service

    Agent

    Agent

    Data

    Data

    Data


    Mechanistic design

    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

    Practical design step one – decomposing the domain model


    Identified services and data objects

    ContractService

    findAll

    findBySeller

    findByBuyer

    OfferService

    make

    Find

    BidService

    make

    accept

    find

    RequestService

    make

    find

    BidBean

    getPrice

    setPrice

    CarMarketBean

    setPrice

    getPrice

    Contract

    getPrice

    getBuyer

    Identified services and data objects


    Marketplace services and factory specification

    Marketplace services and factory specification


    Service 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.cellnetwork.business.marketplace;

      import Java.rmi.RemoteException;

      public interface RequestService {

      public Collection find(...) throws RemoteException;

      public void make(..) throws RemoteException;

      }


    Requestservice ejb design

    RequestService – EJB design


    Service implementation ejb example

    Service implementation – EJB example

    Specify EJB specific interfaces

    package no.cellnetwork.business.marketplace;

    import javax.ejb.EJBObject;

    public interface BidServiceRemote extends EJBObject, BidService{}

    public interface BidServiceHome extends EJBHome {

    public BidServiceRemote create() throws RemoteException,,;

    }

    Implementing the bean

    package no.cellnetwork.business.marketplace;

    public class BidServiceBean implements SessionBean, BidService {

    public Collection find(){}

    public void make() {}

    public void accept() {}

    }


    Implementing the factory

    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 createRequestService");

    • }

    • return (RequestService)remote;

    • }


    Detail design the last step before code

    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

    Making attributes type safe

    • Ada provides this:

      • 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

    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 dataaccessservice

    Using the DataAccessService


    Composite data structures gof 104

    Composite data structures (GOF 104)


    Key success factors

    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

    Academic foundation


    Design challenges

    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

    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

    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


    Information system architectures and architecting

    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.


    Liskov substitution principle polymorphism

    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

    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


    Package stability

    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

    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=1, instable

    I=1, instable

    I=0, Stable


    The stable abstraction principle

    Abstraction (A) = Abstract classes / total classes

    Instability = Ce / (Ca + Ce)

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

    1

    Main Sequence

    Abstraction

    Instability

    1

    A=0, I=0 Stable and concrete

    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.


    References

    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

    • Pattern oriented software architectures, Patterns for concurrent and networked objects, 2000, Schmidt et al, ISBN: 0-471-60695-2

    • 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

    • Developing enterprise java applications with J2EE and UML, Ahmed, Umrysh,2002,ISBN 0-201-73829-5

    • www.sei.cmu.edu

    • www.bredemeyer.com


  • Login