Information system architectures and architecting - PowerPoint PPT Presentation

1 / 69
About This Presentation

Information system architectures and architecting


The role of the architecture. Representation of software architectures ... that keeps its implementors and maintainers from exercising needles creativity. ... – PowerPoint PPT presentation

Number of Views:197
Avg rating:3.0/5.0
Slides: 70
Provided by: idiN


Transcript and Presenter's Notes

Title: Information system architectures and architecting

Information system architectures and architecting
  • Einar Landre, NTNU 23 September 2003

Topics covered
  • Introduction
  • Definitions and terminology
  • The role of the architecture
  • Representation of software architectures
  • History of information systems and their software
  • 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

Ancient architecture
Architecting a dogs house
Architecting a house
Forces in software
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
  • Eberhardt Rechtin, The art of systems
  • 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 its 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
  • 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
  • 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
  • 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
  • Software architectures are layered
  • Library units call another library unit
  • Software and hardware hierarchies become
  • The engine control software is a subsystem of the
  • The user interface is a subsystem of the dash
  • The software architecture is layered (user
    interaction and engine control)
  • Understanding this is critical when architecting
    software intensive systems

Situation illustrated
Car Engineer View
Software Engineer View
Both views are correct, but their purpose and
target group differs
System and software architecture dependencies
System Architecture
Software Architecture
Representing software architecture the four
views Source Applied Software Architecture
  • Code view
  • The organisation of the source code files and
  • Java packages and their dependencies
  • Release and configuration management
  • Module view
  • Layer and packages
  • Subsystems
  • Execution view
  • Allocation of software to appropriate hardware
  • 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

Concerns addressed
  • Conceptual
  • How system fulfils the requirements
  • How to integrate COTS components (Common of the
  • How to support product lines
  • Module
  • How is the product mapped to the software
  • 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

  • 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 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
Architectural evolution in terms of generations
Jim Waldo, Sun Microsystems
1974 - IBM releases Systems Network Architecture
  • Before SNA terminals was physically attached to
  • 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 ?

Client / Server The architecture of the 1980ties
  • 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
  • Distribution of software to many clients
  • Lack of scalability in the large
  • Sensitive to network latency
  • Unreliable outside local area network
  • Client and Server share state

Component architectures (1990 ?)
  • Convergence of distributed object models (CORBA)
    and Transaction Processing Monitors
  • Enterprise Java Beans (EJB)
  • Distributed Component Object Model (DCOM) from
  • Move software towards assembly of
  • 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 - ?)
HTTP Transport
  • Browser installed on any type of computer with
    graphical user interface attached to Internet
  • http// - The Unified Resource
    Locator (URL) was born
  • Web server provided textual content formatted in
  • 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
HTTP Transport
  • The server side is dominated by the N-tier
  • Web, Application and Database servers are large
    software components
  • They can reside on one or more physical
  • The architecture provides scalability and
  • Based on the same principles as IBM applied in
  • Designed to handle thousands of interactive
  • 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
  • Enables systems in different networks to
  • Also known as web services
  • Supports synchronous and asynchronous
  • Supported by mechanisms such as
  • UDDI (Universal Description, Discovery
  • SOAP (Simple Object Access Protocol XML)
  • Systems within network built on N-tier
  • 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
  • Deutsches fallacies of networking becomes an
  • The network is reliable
  • The latency is zero
  • Bandwidth is infinite
  • The network is secure
  • The topology doesnt change
  • There is one administrator
  • Transport cost is zero
  • There is one administrator
  • These issues are not handled by classical
    architectures such as
  • Client / Server
  • N - tier

Distributed architectures Participant to
  • 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 Deutsches 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

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
  • The knowledge of how to react to different
    situations must exist within each node in the
  • 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
  • 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
  • Production systems (rule based systems)
  • The most common approach when constructing a
    knowledge base
  • Production rules are expressed on the form
  • IF ltlist of conditionsgt THEN ltlist of actionsgt
  • 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
  • ILOG JRules among other

JavaSpaces the ultimate distributed blackboard
  • A JavaSpace is service defined by a Java
  • 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)
  • notify(Entry tmpl
  • snapshot(Entry e)
  • An entry is a Java object implementing the Entry
  • 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
Example of a space based web architecture
  • The Web builds on the same concepts as IBMs
    terminal world of 1974
  • Systems Network Architecture
  • Client/Server and N-tier components requires
    stable and controlled networks
  • Deutsches fallacies
  • Understanding round-trip delay and latency is
  • 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
  • Architectures are critical in todays software
  • 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
Architectural design Processors
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
  • Implementation

Architectural design Sub-systems
Architectural design Layers
Architecture Illustrated
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 EJBs?

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
  • The service throws RemoteException and is
    implicit networked enabled
  • Its up to the implementer to decide on
    distribution or not
  • Sample code
  • package
  • import Java.rmi.RemoteException
  • public interface RequestService
  • public Collection find(...) throws
  • public void makeRequest(..) throws

RequestService EJB design
Service implementation EJB example
  • Specify EJB specific interfaces
  • package
  • import javax.ejb.EJBObject
  • public interface RequestServiceRemote extends
    EJBObject, RequestService
  • public interface RequestServiceHome extends
  • public RequestServiceRemote create() throws
  • Implementing the bean
  • package
  • public class RequestServiceBean implements
    SessionBean, RequestService
  • public Collection findRequest()
  • public void makeRequest()
  • public void acceptRequest()

Implementing the factory
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 3d normal form is good for objects
  • No redundancy - performance an issue, use your
  • No internal dependency - unique rows
  • Database should be designed to support the object
  • 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
  • Small result sets
  • Consider to use a Data Access Service
  • Returns valueObjects (JavaBeans)
  • Encapsulates your SQL

Using the Data Access Service
Composite data structures (GOF 104)
Key success factors
  • Architecture
  • Services ( interfaces)
  • Layers (packages)
  • Separate specification from implementation
    (packageinterface true)
  • Understanding of OO design principles
  • More than inheritance
  • Patterns a good tool
  • Understand the network boundary (bandwidth
  • 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
  • Liskovs 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
The open closed principle
Liskov substitution principle (Polymorphism)
Barbara Liskovs work is featured in Jim
Copliens book Advanced C Programming Styles
and Idioms
The dependency inversion principle
Package Stability
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.

The stable abstraction principle
  • The art of systems architecting, 2nd edition,
    2002, Maier, Rechtin, ISBN 0-8493-0440-7
  • Objects, Components and Frameworks with UML,
    DSouza, 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
  • Design patterns, 1995, Gamma et al, ISBN
  • Core J2EE Patterns, 2001, Crupi et al, ISBN
  • Multi Agent Systems, An Introduction to
    distributed artifical intelligence, 1999, Ferber,
    ISBN 0-201-36048-9
  • JESS in action, 2003, Friedman-Hill, ISBN
Write a Comment
User Comments (0)