Information system architectures and architecting - PowerPoint PPT Presentation

1 / 69
About This Presentation
Title:

Information system architectures and architecting

Description:

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
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com