An Introduction to Software Architecture

1
An Introduction to Software Architecture

• Prof. R K Joshi
• Department of Computer Science and Engineering
• IIT Bombay

2
Why Do We need Architecture?

• Understand the system
• Complex systems
• Organize the development
• According to architectural partitioning
• Reuse
• Componentization
• Evolution
• Changes and dependencies

3
Several Approaches to Architecture e.g. see in
Malveau Moubray 2001

• Zachman Framework (IBM)
• 30 architectural viewpoints
• Open Distributed Processing (ISO standard)
• 5 viewpoint reference model
• Domain Analysis
• 41 View Model (Unified Process-Rational)
• Academic Software Architecture Approaches

4
The Zachman FrameworkZachman institute of
framework advancement

• To keep the business from disintegrating, the
  concept of information systems architecture is
  becoming less of an option and more of a
  necessity Zachman in 1987
• Developed by Zachman from observing how
  architectures in engineering, construction and
  manufacturing managed change
• Intersection between roles in the design process
  and product abstractions
• Roles (in rows) Owner, Designer, Builder
• Product Abstractions (in columns) What is it
  made up of (data), How it works (process), Where
  are the components located (geometry)
• 3 additional columns Who (people), When (time),
  Why (motivation)
• 2 additional rows Planner, Subcontractor

5
Open Distributed Processing Reference Model

• For architecture supporting distribution,
  internetworking, interoperability and portability
• Five viewpoints
• Enterprise (purpose, scope and policies)
• Information (semantics of information and
  information processing)
• Computational (functional decomposition)
• Engineering (infrastructure to support
  distribution)
• Technology (for implementation Mappings between
  objects and specific standards and technologies)
• The set of viewpoints is not closed
• Each of the viewpoint is object oriented

6
ODP Enterprise viewpoint

• Directly understandable by managers and end users
• Defines business purpose, scope and policies
• Includes permissions, prohibitions and
  obligations
• Example
• Active objects managers, tellers, customers
• Passive objects accounts
• Bank managers must advise customers when interest
  rate changes (obligation)
• Cash less than 40000 can be drawn per day
  (prohibition)
• Money can be deposited (permission)

7
ODP Information viewpoint

• Definitions of information schemas as objects
• State and structure of objects
• E.g. account balance and amount withdrawn today
• Three kinds of schemas
• static
• At midnight, amount withdrawn today2000
• Invariant
• At anytime, amount withdrawn today lt40000
• Dynamic
• A deposit of X increases the balance by X and a
  withdrawal of X decreases the balance by X
• Always constrained by invariant
• Schemas may relate objects
• E.g. in customer object owns account static
  schema

8
ODP Computational viewpoint

• Software components which are capable of
  supporting distribution
• Large grained object encapsulations, subsystem
  interfaces and behaviors
• Objects can offer multiple interfaces
• 3 types of interactions among objects
• Operational client-server, RPC with
  parameters and results
• Stream oriented
• Signal oriented
• Inheritance of Interface and subtyping
• Operations such as object creation, trading for
  an interface, interface creation, binding,
  operation invocation
• Examples
• Application objects Bank branch with bank teller
  (deposit, withdraw) and bank manager (create
  account, deposit, withdraw) interfaces for
  customers
• ODP infrastructural objects Trader

9
ODP Engineering viewpoint

• Brings out the distributed nature of the system
• Objects and Channels
• Objects
• Basic engineering objects correspond to
  computational objects
• Infrastructural objects such as protocol objects
• E.g. stub, binder and protocol object
  (proxy/skeletons) communication interface
  between protocol objects
• Engineering structure of the system is described
• E.g. cluster, nucleus object, capsule of
  clusters, a machine node, a cluster may contain
  many engineering objects, an object can contain
  many activities, inter-cluster communication via
  channels

10
ODP Transparencies Defined

• Access
• hides the difference in data representation and
  invocation mechanism enables heterogeneous
  systems to communicate
• Failure
• Hides failures and possible recoveries of objects
  for fault tolerance
• Location
• Hides the location information while finding and
  bind to an object
• Relocation
• Masks the changes in the location of an object
  from its clients
• Migration
• Masks the awareness of changes in location of the
  object from itself and from others
• Replication
• Masks the existence of replicated objects
• Persistence
• Masks activation and deactivation of objects
• Transaction
• Masks coordination of activities to achieve
  consistency

11
41 View ModelP.B. Kutchen, 1995

• Sometimes software architecture suffers from
  system designers who go too far..other software
  engineers fail to address the concerns of all
  customers
• 41 view model Has 5 concurrent views
• Logical view- e.g. object model using object
  oriented design method
• Process view concurrency and synchronization
  aspects
• Physical view mapping of components to
  hardware, distribution aspect
• Development view organization of the actual
  software modules libraries, packages,
  subsystems
• Use case view

12
Unified Process Model of Architecture

• Architecture description is a proper extract of
  the models of the system (use case model,
  analysis model, design model, deployment model,
  implementation model)
• e.g. Contains only architecturally significant
  use cases, whereas final use case model contains
  all use cases
• Similarly architectural view of design model
  realizes only the architectural use cases
• First version of architecture is extract at the
  end of elaboration phase and so on
• Developed iteratively during elaboration phase
• Focus on significant structural elements of the
  system
• Subsystems, classes, components, nodes
• Use cases architecture

13
Commonly occurring Architectural Patterns

• Fundamental structural organization schemas
• For example
• Layers
• Pipes and Filters
• Blackboard
• Broker
• Model-View-Controller
• Presentation-Abstraction-Control
• Microkernel
• Reflection
• Client-server

14
Frameworks An Approach to Adaptable Architecture

• Partially complete software
• It is instantiated as a product
• For product families/product lines
• Frozen spots and hot spots

15
Enabling Techniques

• Abstraction
• Encapsulation
• Information Hiding
• Modularization
• Separation of Concerns
• Coupling and Cohesion
• Sufficiency, Completeness and Primitiveness
• Separation of Policy and Implementation
• Separation of Interface and Implementation
• Single point of reference
• Divide and Conquer

16
Languages for Architectural Description

• Architectural components
• Connectors
• Constraints
• Different ADLs have their own metamodels for the
  above

17
ACME

• Developed at CMU
• 7 types of elements
• Component
• Connector
• Systems
• Ports
• Roles
• Representations
• Representation maps

18
Components and Ports

• Primary computational elements
• Data stores
• Ex clients, servers, filters, objects,
  blackboards, databases
• Can have multiple interfaces termed as ports

19
Connectors and Roles

• Represents interactions among components
• They also have interfaces termed as roles
• Each role defines a participant in the
  connectors interaction
• Binary connectors 2 roles
• Ex1 caller, callee on RPC
• Ex2 reading, writing on Pipe
• Ex3 sender, receiver on message passer
• Multiple roles
• Ex. Broadcast connector 1 event announcer, many
  event receivers

20
System and Attachments

• A Graph
• Nodes are components
• Arcs are connectors
• Components are attached to roles of connectors
  through component ports
• Topology of a system is given by the list of
  attachments

21
Representations

• Supports hierarchical descriptions
• A component or connector can be further detailed
  by low level description called representation
• Multiple representations for a single component
  are possible
• To represent multiple views

22
Representation Maps

• Rep-maps establish correspondence internal
  representation and external interface
  (ports/roles) of components/connectors that
  represent
• E.g. association between internal ports and
  external ports in case of components
• Or Associations between internal roles and
  external roles in case of connectors

23
Properties

• Beyond structure, document extra-structural
  properties
• Any of the 7 classes of Acme entities can be
  annotated with properties
• A property can be a tripple ltname,type,valuegt
• List of properties may be associated with an
  element
• Ex scheduling constraints, resource consumption
  etc.

24
An Example Description

• System S
• component client port sendReq
• component server port recReq
• connector RPC Roles caller, callee
• Attachments
• client.sendReq to rpc.caller
• server.recReq to rpc.callee

25
An Example Description pictorial view
Connector RPC
sendReq port
recReq port
Role caller
Role callee
client
server
System RPC
26
Detailing Server component

• component server
• port recReq
• Representation serverDetails
• System serverDetailsSys
• component connectionManager
• component securityManager
• component database
• connector sqlQuery
• connector clearanceRequest
• connector securityQuery
• Attachments .
• Bindings connectionManager.externalSocket
  server.recReq

27
Using Representations for Hierarchical
Descriptions
clearanceRequest
Connection manager
security manager
SQLQuery
database manager
securityQuery
28
Internal Components

• component connectionManager
• ports externalSocket, securitycheck, dbQuery
• Component securityManager
• ports securityAuthorization, creditialsQuery
• Component database
• ports securityManagement, query

29
Components Pictorial View
Port externalSocket
Port Securty Check
Security Manager
Connection Manager
Port Securty Authorization
Port credintialsQuery
Port dbQuery
Port security Management
Port query
Database
30
Internal Connectors

• Connector SQLQuery
• roles caller, callee
• Connector clearanceRequest
• roles requester, granter
• Connector securityQuery
• roles securityManager, requester

31
Connectors Pictorial View
clearanceRequest
granter
requester
Port Securty Check
caller
securityManager
SQLQuery
securityQuery
callee
requester
32
Internal Attachments

• Attachments
• connectionManager.securityCheck to
  clearanceRequest.requester
• securityManager.securityAuthorization to
  clearanceRequest.granter
• ConnectionManager.dbQuery to SQLQuery.caller
• Database.query to SQLquery.callee
• securityManager.credintialQuery to
  securityQuery.securityManager
• Database.securityManagement to
  securityQuery.requester

33
References/Readings

• John Zachman, A Framework for Information Systems
  Architecture", IBM Systems Journal, Vol 26, No 3,
  1987
• Kerry Raymond, Reference model for Open
  Distributed Processing (RM-ODP) Introduction,
  CRC for Distributed Systems Technology,
  University of Queensland
• Raphel Malveau, Thomas Mowbray, Software
  Architect Bootcamp, Prentice Hall 2001
• Buschmann, Meuneir, Rohnert, Sommerlad, Stal,
  Pattern-oriented Software Architecture A system
  of patterns, John Wiley Sons, 1996
• P.B. Kruchten, The 41 View Architecture, IEEE
  Software, November 1995
• Jacobson, Booch, Rumbaugh, The Unified Software
  Development Process, Addison Wesley Longman, 1999
• Garlan, Monroe, Wile, Acme Architectural
  Description of Component-based Systems, in
  Foundations of Component based systems, Cambridge
  University press, 2000