Download - Software Design
![Page 1: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/1.jpg)
Software Design
Deriving a solution which satisfies software requirements
![Page 2: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/2.jpg)
Stages of Design
Problem understanding Look at the problem from different angles to discover
the design requirements.
Identify one or more solutions Evaluate possible solutions and choose the most
appropriate depending on the designer's experience and available resources.
Describe solution abstractions Use graphical, formal, or other descriptive notations to
describe the components of the design. Repeat process for each identified abstraction
until the design is expressed in primitive terms.
![Page 3: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/3.jpg)
The Design Process
Any design may be modeled as a directed graph made up of entities with attributes which participate in relationships.
The system should be described at several different levels of abstraction.
Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary.
![Page 4: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/4.jpg)
Phases in the Design Process
Architecturaldesign
Abstractspecificatio
n
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
![Page 5: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/5.jpg)
Design Phases
Architectural design: Identify sub-systems. Abstract specification: Specify sub-
systems. Interface design: Describe sub-system
interfaces. Component design: Decompose sub-
systems into components.
Data structure design: Design data structures to hold problem data.
Algorithm design: Design algorithms for problem functions.
![Page 6: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/6.jpg)
Hierarchical Design Structure
System level
Sub-systemlevel
![Page 7: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/7.jpg)
Top-down Design
In principle, top-down design involves starting at the uppermost components in the hierarchy
and working down the hierarchy level by level. In practice, large systems design is never
truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.
![Page 8: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/8.jpg)
Design Methods
Structured methods are sets of notations for expressing a software design and guidelines for creating a design.
Well-known methods include Structured Design (Yourdon), and JSD (Jackson Method).
Can be applied successfully because they support standard notations and ensure designs follow a standard form.
Structured methods may be supported with computer aided software engineering (CASE) tools.
![Page 9: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/9.jpg)
Method Components
Many methods support comparable views of a system.
A data flow view showing data transformations.
An entity-relation view describing the logical data structures.
A structural view showing system components and their interactions.
![Page 10: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/10.jpg)
Method Deficiencies
They are guidelines rather than methods in the mathematical sense. Different designers create quite different system designs.
They do not help much with the early, creative phase of design. Rather, they help the designer to structure and document his or her design ideas.
![Page 11: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/11.jpg)
Design Description
Graphical notations: Used to display component relationships.
Informal text: Natural language description.
![Page 12: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/12.jpg)
Design Strategies
Functional design The system is designed from a functional
viewpoint. The system state is centralized and shared
between the functions operating on that state. Object-oriented design
The system is viewed as a collection of interacting objects.
The system state is decentralized and each object manages its own state.
Objects may be instances of an object class and communicate by exchanging methods.
![Page 13: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/13.jpg)
Functional View of a Compiler
AnalyseBuild
symboltable
Scansource
Generatecode
Symboltable
Outputerrors
Sourceprogram
Tokens Tokens Syntaxtree
Objectcode
ErrorindicatorSymbols Symbols
Errormessages
![Page 14: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/14.jpg)
Object-oriented View of a Compiler
Sourceprogram
Tokenstream
Symboltable
Syntaxtree
GrammarError
messages
Abstractcode
Objectcode
Scan Add
CheckGet
Build Print
Generate
Generate
![Page 15: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/15.jpg)
Mixed-strategy Design
Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary.
Good software engineers should select the most appropriate approach for whatever sub-system is being designed.
![Page 16: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/16.jpg)
Design Quality
Design quality is an elusive concept. Quality depends on specific organizational priorities.
A “good” design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc.
The attributes discussed here are concerned with the maintainability of the design.
Quality characteristics are equally applicable to function-oriented and object-oriented designs.
![Page 17: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/17.jpg)
Attribute: Cohesion
A measure of how well a component “fits together”.
A component should implement a single logical entity or function.
Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component.
Various levels of cohesion have been identified.
![Page 18: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/18.jpg)
Cohesion Levels
Coincidental cohesion (weak) Parts of a component are simply
bundled together. Logical association (weak)
Components which perform similar functions are grouped.
Temporal cohesion (weak) Components which are activated at the
same time are grouped.
![Page 19: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/19.jpg)
Cohesion Levels
Communicational cohesion (medium) All the elements of a component operate on
the same input or produce the same output. Sequential cohesion (medium)
The output for one part of a component is the input to another part.
Functional cohesion (strong) Each part of a component is necessary for
the execution of a single function. Object cohesion (strong)
Each operation provides functionality which allows object attributes to be modified or inspected.
![Page 20: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/20.jpg)
Cohesion as a Design Attribute Not well-defined. Often difficult to
classify cohesion.
Inheriting attributes from super-classes weakens cohesion.
To understand a component, the super-classes as well as the component class must be examined.
Object class browsers assist with this process.
![Page 21: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/21.jpg)
Cohesion vs coupling
Cohesion A measure of how well a component
“fits together”
Coupling A measure of the strength of the inter-
connections between system components.
![Page 22: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/22.jpg)
Attribute: Coupling
Loose coupling means component changes are unlikely to affect other components.
Shared variables or control information exchange lead to tight coupling.
Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing.
28
![Page 23: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/23.jpg)
Tight Coupling
Module A Module B
Module C Module D
Shared dataarea
![Page 24: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/24.jpg)
Loose Coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
![Page 25: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/25.jpg)
Coupling and Inheritance
Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing.
However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes.
![Page 26: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/26.jpg)
Attribute: Understandability Related to several component
characteristics Can the component be understood on its
own? Are meaningful names used? Is the design well-documented? Are complex algorithms used?
Informally, high complexity means many relationships between different parts of the design.
32
![Page 27: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/27.jpg)
Attribute: Adaptability A design is adaptable if:
Its components are loosely coupled. It is well-documented and the documentation is
up to date. There is an obvious correspondence between
design levels (design visibility). Each component is a self-contained entity (tightly
cohesive). To adapt a design, it must be possible to
trace the links between design components so that change consequences can be analyzed.
33
![Page 28: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/28.jpg)
Design Traceability
P O R
D
A
B
F
C
D Object interactionlevel
Object decompositionlevel
![Page 29: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/29.jpg)
Adaptability and Inheritance Inheritance dramatically improves
adaptability. Components may be adapted without change by deriving a sub-class and modifying that derived class.
However, as the depth of the inheritance
hierarchy increases, it becomes increasingly complex. It must be periodically reviewed and restructured.
35
![Page 30: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/30.jpg)
Architectural Design
Establishing the overall structure of a software system
![Page 31: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/31.jpg)
Architectural Parallels
Architects are the technical interface between the customer and the contractor building the system.
A bad architectural design for a building cannot be rescued by good construction; the same is true for software.
There are specialist types of building and software architects.
There are schools or styles of building and software architecture.
![Page 32: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/32.jpg)
Sub-systems and Modules
A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.
A module is a system component that provides services to other components but would not normally be considered as a separate system.
![Page 33: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/33.jpg)
Architectural Models
Structure, control and modular decomposition may be based on a particular model or architectural style.
However, most systems are heterogeneous in that different parts of the system are based on different models and, in some cases, the system may follow a composite model.
The architectural model used affects the performance, robustness, distributability and maintainability of the system.
![Page 34: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/34.jpg)
System Structuring
Concerned with decomposing the system into interacting sub-systems.
The architectural design is normally expressed as a block diagram presenting an overview of the system structure.
More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed.
![Page 35: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/35.jpg)
The Repository Model
Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or
repository and may be accessed by all sub-systems.
Each sub-system maintains its own database and passes data explicitly to other sub-systems.
When large amounts of data are to be shared, the repository model of sharing is most commonly used.
![Page 36: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/36.jpg)
CASE Tool Set Architecture
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
![Page 37: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/37.jpg)
Repository Model Characteristics Advantages:
Efficient way to share large amounts of data. Sub-systems need not be concerned with how data
is produced. Centralized management e.g., backup, security, etc. Sharing model is published as the repository
schema. Disadvantages:
Sub-systems must agree on a repository data model. Data evolution is difficult and expensive. No scope for specific management policies. Difficult to distribute efficiently.
![Page 38: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/38.jpg)
Client-server Architecture Distributed system model which shows
how data and processing is distributed across a range of components.
Set of stand-alone servers which provide specific services such as printing, data management, etc.
Set of clients which call on these services.
Network which allows clients to access servers.
![Page 39: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/39.jpg)
Film and Picture Library
Catalogueserver
Catalogue
Videoserver
Film clipfiles
Pictureserver
Digitizedphotographs
Hypertextserver
Hypertextweb
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
![Page 40: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/40.jpg)
Client-server Characteristics Advantages: Distribution of data is straightforward. Makes effective use of networked systems. Easy to add new servers or upgrade existing servers.
Disadvantages: No shared data model so sub-systems may use
different data organizations. Redundant management in each server. No central register of names and services - it may be
hard to find out what servers and services are available.
![Page 41: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/41.jpg)
Object Models
Structure the system into a set of loosely coupled objects with well-defined interfaces.
Object-oriented decomposition is concerned with identifying object classes, their attributes and operations.
When implemented, objects are created from these classes and some control model used to coordinate object operations.
![Page 42: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/42.jpg)
Invoice Processing System
IssueSend reminderAccept paymentSend receipt
invoice #dateamountcustomer
Invoice
customer #nameaddresscredit period
Customer
invoice #dateamountcustomer #
Receipt
invoice #dateamountcustomer #
Payment
![Page 43: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/43.jpg)
Abstract Machine Model
Used to model the interfacing of sub-systems. Organizes the system into a set of layers (or
abstract machines) each of which provide a set of services.
Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.
However, often difficult to structure systems in this way.
![Page 44: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/44.jpg)
Version Management System
Operatingsystem
Database system
Object management
Version management
![Page 45: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/45.jpg)
Broadcast Model
Effective in integrating sub-systems on different computers in a network.
Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event.
Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them.
However, sub-systems don’t know if or when an event will be handled.
![Page 46: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/46.jpg)
Selective Broadcasting
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
![Page 47: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/47.jpg)
Pipe and Filter Models
Functional transformations process their inputs to produce outputs.
May be referred to as a pipe and filter model (as in UNIX shell).
Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems.
Not really suitable for interactive systems.
![Page 48: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/48.jpg)
Invoice Processing System
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
![Page 49: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/49.jpg)
Domain-specific Architectures Architectural models which are specific to
some application domain. Two types of domain-specific model
Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems.
Reference models which are more abstract, idealized model. Provide a means of information about that class of system and of comparing different architectures.
Generic models are usually bottom-up models.
Reference models are top-down models.
![Page 50: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/50.jpg)
Generic Models Compiler model is a well-known example
although other models exist in more specialized application domains. Lexical analyzer Symbol table Syntax analyzer Syntax tree Semantic analyzer Code generator
Generic compiler model may be organized according to different architectural models.
![Page 51: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/51.jpg)
Compiler Model
Lexicalanalysis
Syntacticanalysis
Semanticanalysis
Codegeneration
Symboltable
![Page 52: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/52.jpg)
Language Processing System
Syntaxanalyser
Lexicalanalyser
Semanticanalyser
Abstractsyntax tree
Grammardefinition
Symboltable
Outputdefinition
Pretty-printer
Editor
Optimizer
Codegenerator
Repository
![Page 53: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/53.jpg)
Reference Architectures
Reference models are derived from a study of the application domain rather than from existing systems.
May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated.
Open Systems Interconnection (OSI) model is a layered model for communication systems.
![Page 54: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/54.jpg)
OSI Reference Model
Application
Presentation
Session
Transport
Network
Data link
Physical
7
6
5
4
3
2
1
Communica tions medium
Network
Data link
Physical
Application
Presentation
Session
Transport
Network
Data link
Physical
![Page 55: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/55.jpg)
Distributed Systems Architectures
Architectural design for software that executes on more than one processor
![Page 56: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/56.jpg)
Distributed systems
Virtually all large computer-based systems are now distributed systems
Information processing is distributed over several computers rather than confined to a single machine
Distributed software engineering is now very important
![Page 57: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/57.jpg)
System types Personal systems that are not distributed
and that are designed to run on a personal computer or workstation.
Embedded systems that run on a single processor or on an integrated group of processors – performs a few dedicated functions.
Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network.
![Page 58: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/58.jpg)
Distributed system characteristics
Resource sharing Openness Concurrency Scalability Fault tolerance Transparency
![Page 59: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/59.jpg)
Distributed system disadvantages
Complexity Security Manageability Unpredictability
![Page 60: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/60.jpg)
Issues in distributed system design
Design issue DescriptionResourceidentification
The resources in a distributed system are spread across differentcomputers and a naming scheme has to be devised so that users candiscover and refer to the resources that they need. An example ofsuch a naming scheme is the URL (Uniform Resource Locator) thatis used to identify WWW pages. If a meaningful and universallyunderstood identification scheme is not used then many of theseresources will be inaccessible to system users.
Communications The universal availability of the Internet and the efficientimplementation of Internet TCP/IP communication protocols meansthat, for most distributed systems, these are the most effective wayfor the computers to communicate. However, where there arespecific requirements for performance, reliability etc. alternativeapproaches to communications may be used.
Quality of service The quality of service offered by a system reflects its performance,availability and reliability. It is affected by a number of factors suchas the allocation of processes to processes in the system, thedistribution of resources across the system, the network and thesystem hardware and the adaptability of the system.
Softwarearchitectures
The software architecture describes how the applicationfunctionality is distributed over a number of logical components andhow these components are distributed across processors. Choosingthe right architecture for an application is essential to achieve thedesired quality of service.
![Page 61: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/61.jpg)
Distributed systems archiectures Client-server architectures
Distributed services which are called on by clients. Servers that provide services are treated differently from clients that use services
Distributed object architectures No distinction between clients and
servers. Any object on the system may provide and use services from other objects
![Page 62: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/62.jpg)
Middleware Software that manages and supports
the different components of a distributed system. In essence, it sits in the middle of the system
Middleware is usually off-the-shelf rather than specially written software
Examples Transaction processing monitors Data converters Communication controllers
![Page 63: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/63.jpg)
Multiprocessor architectures Simplest distributed system model System composed of multiple
processes which may (but need not) execute on different processors
Architectural model of many large real-time systems
Distribution of process to processor may be pre-ordered or may be under the control of a despatcher
![Page 64: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/64.jpg)
A multiprocessor traffic control system
Traffic lights
Lightcontrolprocess
Traffic light controlprocessor
Traffic flowprocessor
Operator consolesTraffic flow sensors
and cameras
Sensorprocessor
Sensorcontrolprocess
Displayprocess
![Page 65: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/65.jpg)
Client-server architectures The application is modelled as a set of
services that are provided by servers and a set of clients that use these services
Clients know of servers but servers need not know of clients
Clients and servers are logical processes
The mapping of processors to processes is not necessarily 1 : 1
![Page 66: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/66.jpg)
A client-server system
s1
s2 s3
s4c1
c2 c3 c4
c5
c6c7 c8
c9
c10
c11
c12
Client process
Server process
![Page 67: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/67.jpg)
Computers in a C/S network
Network
SC1SC2
CC1 CC2 CC3
CC5 CC6CC4
Servercomputer
Clientcomputer
s1, s2 s3, s4
c5, c6, c7
c1 c2 c3, c4
c8, c9 c10, c11, c12
![Page 68: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/68.jpg)
Layered application architecture Presentation layer
Concerned with presenting the results of a computation to system users and with collecting user inputs
Application processing layer Concerned with providing application specific
functionality e.g., in a banking system, banking functions such as open account, close account, etc.
Data management layer Concerned with managing the system databases
![Page 69: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/69.jpg)
Application layers
Presentation layer
Application processinglayer
Data managementlayer
![Page 70: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/70.jpg)
Thin and fat clients
Thin-client model In a thin-client model, all of the application
processing and data management is carried out on the server. The client is simply responsible for running the presentation software.
Fat-client model In this model, the server is only responsible
for data management. The software on the client implements the application logic and the interactions with the system user.
![Page 71: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/71.jpg)
Thin and fat clients
Thin-clientmodel
Fat-clientmodel Client
Client
Server
Data managementApplicationprocessing
Presentation
Server
Datamanagement
PresentationApplication processing
![Page 72: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/72.jpg)
Thin client model
Used when legacy systems are migrated to client server architectures. The legacy system acts as a server in its
own right with a graphical interface implemented on a client
A major disadvantage is that it places a heavy processing load on both the server and the network
![Page 73: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/73.jpg)
Fat client model
More processing is delegated to the client as the application processing is locally executed
Most suitable for new C/S systems where the capabilities of the client system are known in advance
More complex than a thin client model especially for management. New versions of the application have to be installed on all clients
![Page 74: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/74.jpg)
A client-server ATM system
Account server
Customeraccountdatabase
Tele-processing
monitor
ATM
ATM
ATM
ATM
![Page 75: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/75.jpg)
Three-tier architectures
In a three-tier architecture, each of the application architecture layers may execute on a separate processor
Allows for better performance than a thin-client approach and is simpler to manage than a fat-client approach
A more scalable architecture - as demands increase, extra servers can be added
![Page 76: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/76.jpg)
A 3-tier C/S architecture
Client
Server
Datamanagement
PresentationServer
Applicationprocessing
![Page 77: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/77.jpg)
An internet banking system
Database server
Customeraccountdatabase
Web server
Client
Client
Client
Client
Account serviceprovision
SQLSQL query
HTTP interaction
![Page 78: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/78.jpg)
Use of C/S architectures
Architecture ApplicationsTwo-tier C/Sarchitecture withthin clients
Legacy system applications where separating applicationprocessing and data management is impracticalComputationally-intensive applications such as compilers withlittle or no data managementData-intensive applications (browsing and querying) with littleor no application processing.
Two-tier C/Sarchitecture withfat clients
Applications where application processing is provided byCOTS (e.g. Microsoft Excel) on the clientApplications where computationally-intensive processing ofdata (e.g. data visualisation) is required.Applications with relatively stable end-user functionality usedin an environment with well-established system management
Three-tier ormulti-tier C/Sarchitecture
Large scale applications with hundreds or thousands of clientsApplications where both the data and the application arevolatile.Applications where data from multiple sources are integrated
![Page 79: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/79.jpg)
Distributed object architectures There is no distinction in a distributed object
architectures between clients and servers Each distributable entity is an object that
provides services to other objects and receives services from other objects
Object communication is through a middleware system called an object request broker (software bus)
However, more complex to design than C/S systems
![Page 80: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/80.jpg)
Distributed object architecture
Software bus
o1 o2 o3 o4
o5 o6
S (o1) S (o2) S (o3) S (o4)
S (o5) S (o6)
![Page 81: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/81.jpg)
Advantages of distributed object architecture
It allows the system designer to delay decisions on where and how services should be provided
It is a very open system architecture that allows new resources to be added to it as required
The system is flexible and scaleable It is possible to reconfigure the system
dynamically with objects migrating across the network as required
![Page 82: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/82.jpg)
Uses of distributed object architecture As a logical model that allows you to
structure and organise the system. In this case, you think about how to provide application functionality solely in terms of services and combinations of services
As a flexible approach to the implementation of client-server systems. The logical model of the system is a client-server model but both clients and servers are realised as distributed objects communicating through a software bus
![Page 83: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/83.jpg)
A data mining system
Database 1
Database 2
Database 3
Integrator 1
Integrator 2
Visualiser
Display
Report gen.
![Page 84: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/84.jpg)
Data mining system
The logical model of the system is not one of service provision where there are distinguished data management services
It allows the number of databases that are accessed to be increased without disrupting the system
It allows new types of relationship to be mined by adding new integrator objects
![Page 85: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/85.jpg)
CORBA
CORBA is an international standard for an Object Request Broker - middleware to manage communications between distributed objects
Several implementations of CORBA are available
DCOM is an alternative approach by Microsoft to object request brokers
CORBA has been defined by the Object Management Group
![Page 86: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/86.jpg)
Application structure
Application objects Standard objects, defined by the OMG,
for a specific domain e.g. insurance Fundamental CORBA services such as
directories and security management Horizontal (i.e. cutting across
applications) facilities such as user interface facilities
![Page 87: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/87.jpg)
CORBA application structure
CORBA services
Object request broker
Domainfacilities
HorizontalCORBA facilities
Applicationobjects
![Page 88: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/88.jpg)
CORBA standards
An object model for application objects A CORBA object is an encapsulation of
state with a well-defined, language-neutral interface defined in an IDL (interface definition language)
An object request broker that manages requests for object services
A set of general object services of use to many distributed applications
A set of common components built on top of these services
![Page 89: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/89.jpg)
CORBA objects
CORBA objects are comparable, in principle, to objects in C++ and Java
They MUST have a separate interface definition that is expressed using a common language (IDL) similar to C++
There is a mapping from this IDL to programming languages (C++, Java, etc.)
Therefore, objects written in different languages can communicate with each other
![Page 90: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/90.jpg)
Object request broker (ORB) The ORB handles object communications.
It knows of all objects in the system and their interfaces
Using an ORB, the calling object binds an IDL stub that defines the interface of the called object
Calling this stub results in calls to the ORB which then calls the required object through a published IDL skeleton that links the interface to the service implementation
![Page 91: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/91.jpg)
ORB-based object communications
o1 o2
S (o1) S (o2)
IDLstub
IDLskeleton
Object Request Broker
![Page 92: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/92.jpg)
Inter-ORB communications
ORBs are not usually separate programs but are a set of objects in a library that are linked with an application when it is developed
ORBs handle communications between objects executing on the same machine
Several ORBS may be available and each computer in a distributed system will have its own ORB
Inter-ORB communications are used for distributed object calls
![Page 93: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/93.jpg)
Inter-ORB communications
o1 o2
S (o1) S (o2)
IDL IDL
Object Request Broker
o3 o4
S (o3) S (o4)
IDL IDL
Object Request Broker
Network
![Page 94: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/94.jpg)
CORBA services
Naming and trading services These allow objects to discover and refer
to other objects on the network Notification services
These allow objects to notify other objects that an event has occurred
Transaction services These support atomic transactions and
rollback on failure
![Page 95: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/95.jpg)
Example of a SimpleCORBA Application
Written in Java
![Page 96: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/96.jpg)
Starting Clients, Servers, and Name Servers # Compile the IDL into a Java stub
idltojava -fno-cpp Hello.idl
# Compile the Java program and stub javac *.java HelloApp/*.java
# Initiate the name server on king.mcs.drexel.edu on port 1050. tnameserv -ORBInitialPort 1050 -ORBInitialHost king.mcs.drexel.edu
# Initiate the hello server (relies on the name server being on king's 1050 port.) java HelloServer -ORBInitialPort 1050 -ORBInitialHost king.mcs.drexel.edu
# Initiate the hello client (relies on the name server being on king's 1050 port.) java HelloClient -ORBInitialPort 1050 -ORBInitialHost king.mcs.drexel.edu
![Page 97: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/97.jpg)
“Hello World” IDL Specification
module HelloApp{ interface Hello { string sayHello(); };};
![Page 98: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/98.jpg)
“Hello World” Client Java Program
import HelloApp.*; import org.omg.CosNaming.*; // package used for name serviceimport org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*; public class HelloClient { public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // args contain info. about
// name server port/host // get the root naming context org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef);
// casting ...// continued on next page ...
![Page 99: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/99.jpg)
“Hello World” Client Java Program (Cont’d)
// resolve the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; Hello HelloRef = HelloHelper.narrow(ncRef.resolve(path)); // call the Hello server object and print results String Hello = HelloRef.sayHello(); System.out.println(Hello); } catch (Exception e) { System.out.println("ERROR : " + e) ; e.printStackTrace(System.out); } }}
![Page 100: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/100.jpg)
“Hello World” Server Java Program
import HelloApp.*;import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*; class HelloServant extends _HelloImplBase { public String sayHello() { return "\nHello world !!\n"; }}
![Page 101: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/101.jpg)
“Hello World” Server Java Program (Cont’d)
public class HelloServer { public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // create servant and register it with the ORB HelloServant HelloRef = new HelloServant(); orb.connect(HelloRef); // HelloRef will be published ... // get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef);// continued on next slide ...
![Page 102: Software Design](https://reader031.vdocuments.us/reader031/viewer/2022020417/56813a25550346895da20373/html5/thumbnails/102.jpg)
“Hello World” Server Java Program (Cont’d)
// bind the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; ncRef.rebind(path, HelloRef); // clobber old binding if any ... // wait for invocations from clients java.lang.Object sync = new java.lang.Object(); synchronized (sync) { // aquires a mutex lock on thread sync.wait(); // server sleeps ... } } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } }}