Information system architectures and architecting

1
Information system architectures and architecting

• Einar Landre, NTNU 23 September 2003
• einar.landre_at_bouvet.no

2
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

3
Introduction
4
Ancient architecture
5
Architecting a dogs house
6
Architecting a house
7
Forces in software
8
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 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.

9
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

10
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

11
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

12
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

13
Situation illustrated
Car Engineer View
Software Engineer View
Both views are correct, but their purpose and
target group differs
14
System and software architecture dependencies
System
System Architecture
Software Architecture
15
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)

16
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

17
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 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.

18
History of information systems and their software
architectures
19
Architectural evolution in terms of generations
Jim Waldo, Sun Microsystems
20
1974 - IBM releases Systems Network Architecture
(SNA)

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

21
Client / Server The architecture of the 1980ties
Client
Server
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

22
Component architectures (1990 ?)
Computer
Computer

• 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

23
Internet and Web oriented architectures (1994 - ?)
HTTP Transport
Client
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

24
The N-tier web architecture practical use of
components
HTTP Transport
Client

• 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

25
Beyond components Network to Network Services
Network to Network

• 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

XML
26
Challenge - Systems become more and more
distributed

• Deutsches fallacies of networking becomes an
  issue
• 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

27
Distributed architectures Participant to
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 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
• www.jini.org
• rio.jini.org
• java.sun.com/jini

28
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

29
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

30
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 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
  rules
• ILOG JRules among other

31
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.
32
Example of a space based web architecture
33
Summary

• 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
  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 todays software
  systems
• The more complex systems success depends on
  architecture at both system and software levels.

34
From domain model to code

• A practical tour based on Java

35
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

36
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?

37
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

38
Phases of design, scope and deliveries
Source Doing hard time, Douglas 1999
39
Architectural design Processors
Processor boundary network boundary Think of
the software layers
40
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

41
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.MarketServiceFactor
  y
• no.bouvet.marketplace.business.UserAccountService
• Implementation
• no.bouvet.marketplace.business.MarketServiceFactor
  yImpl
• no.bouvet.marketplace.business.UserAccountServiceI
  mpl

42
Architectural design Sub-systems
43
Architectural design Layers
44
Architecture Illustrated
45
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?

46
Practical design step one decomposing the
domain model
47
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

48
Marketplace services and factory specification
49
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

50
RequestService EJB design
51
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()

52
Implementing the factory
53
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

54
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

55
Mapping objects to relational databases

• Database on 3d 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 (JavaBeans)
• Encapsulates your SQL

56
Using the Data Access Service
57
Composite data structures (GOF 104)
58
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
  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

59
Academic Foundation
60
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

61
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

62
Inheritance Design by contract
63
The open closed principle
64
Liskov substitution principle (Polymorphism)
Barbara Liskovs work is featured in Jim
Copliens book Advanced C Programming Styles
and Idioms
65
The dependency inversion principle
66
Package Stability
67
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.

68
The stable abstraction principle
69
References

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