designing the system
Download
Skip this Video
Download Presentation
Designing the System

Loading in 2 Seconds...

play fullscreen
1 / 28

Designing the System - PowerPoint PPT Presentation


  • 269 Views
  • Uploaded on

Designing the System. What is design?(1). Design is the creative process of transforming the problem into a solution What and How Conceptual design tells the customer what the system will do.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Designing the System' - Jimmy


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what is design 1
What is design?(1)
  • Design is the creative process of transforming the problem into a solution What and How
  • Conceptual design tells the customer what the system will do.
  • Technical design allows system builders to understand the actual hardware and software needed to solve the customer’s problem.
slide3

“The user will be able to route messages to any other user on any other network computer.”

Network topology

Protocol used

Prescribed bps rate

. . .

CONCEPTUAL

DESIGN

TECHNICAL

DESIGN

what is design 2
What is design?(2)
  • Good conceptual design
    • It is written in the customer’s language.
    • It contains no technical jargon.
    • It describes the functions of the system.
    • It is independent of implementation.
    • It is linked to the requirements documents.
  • Technical design
    • A description of the major hardware components and their functions.
    • The hierarchy and function of the software components.
    • The data structure and the data flow.
design description
Design description
  • Basis for detailed implementation.
  • Notation used in design documents
    • Graphical notation
    • Program description languages
    • Informal text
design strategies
Design strategies
  • Functional design : Starting with a high-level view and progressively refining this into a more detailed design.
  • Object-oriented design : A collection of objects rather than functions
design quality 1
Design quality(1)
  • Maintainable design can be adapted to modify existing functions and add new functionality.
  • Cohesion
    • Measure of the closeness of the relationships between the components.
    • Cohesion is a desirable characteristic because it means that a unit represents a single part of the solution.
design quality 2
Design quality(2)
  • Coincidental cohesion
  • Logical cohesion
  • Temporal cohesion
  • Procedural cohesion
  • Communicational cohesion
  • Sequential cohesion
  • Functional cohesion
  • Object cohesion
slide9

COINCIDENTAL

Parts unrelated

LOGICAL

Similar functions

TEMPORAL

Related by time

PROCEDURAL

Related by order of

functions

DATA

COMMUNICATIONAL

Access same data

SEQUENTIAL

Output of one part is input to next

FUNCTIONAL

Sequential with

complete, related functions

TIME T0

FUNCTION A

FUNCTION A

FUNCTION A

TIME T0 + X

FUNCTION B

FUNCTION

C

FUNCTION

B

logic

FUNCTION A’

FUNCTION

E

FUNCTION

D

TIME T0 + 2X

FUNCTION C

FUNCTION A”

FUNCTION A

FUNCTION A

FUNCTION A - part 1

FUNCTION B

FUNCTION B

FUNCTION A - part 2

FUNCTION C

FUNCTION A - part 3

FUNCTION C

design quality 3
Design quality(3)
  • Coupling
    • An indication of the strength of interconnections between the components in a desin.
    • Loosely/Tightly coupled system
    • Object -> Loosely coupled system
    • Content coupling : When one component modifies an internal data item in another component or when one component branches into the middle of another component.
    • Common coupling
    • Control coupling : When one component passes parameters to control the activity of another component.
    • Data coupling : When data are passed
slide11

Uncoupled -

no dependencies

Loosely coupled -

some dependencies

Highly coupled -

many dependencies

slide12

A

B

C

Component B

D

E

Go to D1

Component D

Go to D1

D1:

slide13

Global:

A1

A2

A3

Variables:

V1

V2

Common data area

and variable names

Component X

Component Y

Component Z

Increment V1

Change V1 to zero

V1 = V2 + A1

design quality 4
Design quality(4)
  • Understandability
    • Naming
    • Documentation
    • Complexity
    • Inheritance
  • Adaptability
    • A general estimate of how easy it is to change the design.
    • Design should be well documented.
    • Should have a high level of traceabillity.
    • For optimum adaptability, a component should be self-contained.
architectural design 1
Architectural design(1)
  • The initial design process of identifying the sub-systems and establishing a framework for sub-system control and communication.
  • The process model has the following activities
    • System structuring
    • Control modeling
    • Modular decomposition
  • A sub-system is a system in its own right whose operation does not depend on the services provided by other sub-systems.
  • A module is a system component that provides one or more services to other modules.
  • Architectural design may be based on a particular model or style.
system structuring
System structuring
  • The first phase of the architectural design activity is usually concerned with decomposing a system into a set of interacting sub-systems.
  • Block diagram
  • Repository model
  • Client-server model
  • Abstract machine model
the repository model 1
The repository model(1)
  • Two ways of exchanging information
    • All shared data is held in a central DB that can be accessed by all sub-systems.
    • Each sub-system maintains its own DB.
  • Central DB and collection of components that operate on it to store, retrieve, and update information.
  • Characteristics
    • It is an efficient way to share large amounts of data.
    • However, sub-systems must agree on the repository data model.
    • Sub-systems which produce data need not be concerned with how that data is used by other sub-systems.
the repository model 2
The repository model(2)
  • However, evolution may be difficult as a large volume of information is generated according to an agreed data model.
  • Activities such as backup, security, access control and recovery from error are centralized.
  • However, different sub-systems may have different requirements for security, recovery and backup policies.
  • The model of sharing is visible through the repository schema.
  • However, it may be difficult to distribute the repository over a number of machines.
the client server model 1
The client-server model(1)
  • Distributed system model
  • Major components
    • A set of stand-alone servers which offer services to other sub-systems.
    • A set of clients that call on the services offered by servers.
  • A network which allows the clients to access these services.
  • Characteristics
    • Distribution is straightforward. Effective use can be made of networked systems with many distributed processors.
    • However, changes to existing clients and servers may be required to gain the full benefits of integrating a new server.
the abstract machine model 1
The abstract machine model(1)
  • A system organized into a series of layers each of which provides a set of services.(Layered model)
    • example : layered communication protocols
  • Characteristics
    • Supports the incremental development of systems.
    • Basic facilities which are required by all abstract machines may be provided by inner layers.
slide21

Cryptography

File interface

Key management

Authentication

Users

control models
Control models
  • At the architectural level, these models are concerned with the control flow between sub-systems.
  • Two approaches
    • Centralized control
    • Event-based control
centralized model
Centralized model
  • One sub-system has overall responsibility for control and starts and stops other sub-system.
  • Two classes
    • The call-return model : Top-down subroutine model where control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree.
    • The manager model : One system component is designated as a system manager and controls the starting, stopping and coordination of other system processes.
event driven systems 1
Event-driven systems(1)
  • Each sub-system can respond to externally generated events.
  • Two event-driven control models
    • Broadcast models
    • Interrupt-driven models]
  • Broadcast model
    • An event is broadcast to all sub-systems. Any sub-system which is designed to handle that event responds to it.
    • Evolution is relatively simple.
    • Sub-systems don’t know if or when events will be handled.
    • Debugger
event driven systems 2
Event-driven systems(2)
  • Interrupt-driven control model
    • In real-time systems where external interrupts are detected by an interrupt handler. They are then passed to some other component for processing.
    • It allows very fast responses to events to be validate.
    • It is complex to program and difficult to validate.
modular decomposition
Modular decomposition
  • Two models
    • An object-oriented model
    • A data-flow model
object models
Object models
  • A system structured into a set of loosely coupled objects with well-defined interfaces.
  • The decomposition is concerned with object classes, their attributes and operations.
  • Because objects are loosely coupled, the implementation of objects can be modified without affecting other objects.
  • To use services, object must explicitly reference the name and the interface of other objects.
data flow models 1
Data flow models(1)
  • Functional transformations process their inputs and produce outputs.
  • Pipe and filter model
  • Characteristic
    • Need for a common format for data transfer which can be recognized by all transformation.
    • Some filters may duplicate preparatory functions of other filters.
ad