Software design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 21

Software Design PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on
  • Presentation posted in: General

Software Design. From Requirements to Implementation. Concepts. process the stages of design strategies how to go about it quality some traditional measures. Design Process. understand activities, resources and products top-down or bottom-up? methods

Download Presentation

Software Design

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


Software design

Software Design

From Requirements to Implementation


Concepts

Concepts

  • process

    • the stages of design

  • strategies

    • how to go about it

  • quality

    • some traditional measures


Design process

Design Process

  • understand

  • activities, resources and products

  • top-down or bottom-up?

  • methods

    • sd, sa, jsd [data flow, entity-relation, structure]

    • oo [inheritance, structure, use]

  • description

    • graphical, pdl, text


Strategies

Strategies

  • functional

    • function driven

    • data driven

  • object-oriented


Quality

Quality

  • cohesion

    • measure of how related the components are

    • objective: high(-ish) cohesion

  • coupling

    • measure of strength of interconnections

    • objective: low(-ish) coupling

  • understandability

  • adaptability


Architectural design

Architectural Design

Deciding on the major sub-systems and how they fit together


Architectural design1

Architectural Design

  • introduction

  • system structuring

  • control

  • sub-system decomposition

  • domains


Models of systems structure

Models of Systems Structure

  • Repository: Sub-systems must exchange information. All shared data is in a central database (repository) OR Easch subsytem has its own dB with message-passing between them to ensure consistency

  • client-server:

  • abstract machine


Repository

Repository

  • centralised storage

    • no copies - ‘efficient’

  • single data structure

    • clear data model - simple

    • clear data sharing - good integration

  • centralised house-keeping

    • backups, security, recovery from error, etc

  • management information systems, CAD


Problems with repository model

Problems with Repository Model

  • large rigid data structures

    • compromise between demands of sub-systems

    • difficulty with adding new sub-systems

    • difficulty with system evolution

  • rigid house-keeping policies

    • sub-systems may require different policies

  • integrity problems if distributed

    • possible redundancy and inconsistency


Client server model

Client-Server Model

  • client

  • server (local data structures and operations)

  • network

  • advantages

    • distributed data and operations

      • ease of expansion

    • concurrent access

      • clients may use more than one server

      • servers may be dealing with more than one client


Problems with client server model

Problems with Client-Server Model

  • getting information on available servers (see internet)

  • difficulties with new servers

    • no shared data model

    • may need changes in other sub-systems

  • all servers must do house-keeping


Abstract machine model

Abstract Machine Model

  • similar to the model for operating systems

  • layered virtual machines from hardware to application (applications also layered)

  • each layer dependent on the next lower only

  • incremental development

  • adaptable

  • portable


Problems with abstract machine model

Problems with Abstract Machine Model

  • inherent difficulty

    • all layers require basic, usually o/s, services

    • layers may be not just on next lower

  • performance

    • layer management overhead

    • may lead to direct access to lower layers


Control models

Control Models

  • centralised

    • call-return (sequential systems)

    • manager (concurrent systems)

  • event-driven

    • broadcast

    • interrupt


Broadcast model

Broadcast Model

  • sub-systems ‘register’ interest in events

  • sub-systems generate events

  • event handler sends events to registered servers

  • also inter-sub-system communication

  • distributed systems

  • easy evolution


Problems with broadcast model

Problems with Broadcast Model

  • uncertainty about event handling

    • is there a server?

    • is there more than one server?

    • how long will it take?


Interrupt model

Interrupt Model

  • used mainly, but not exclusively, for (hard) real time systems

  • a handler in memory for each interrupt event

  • (usually) a fixed number of interrupts

  • reliably quick response


Problems with interrupt model

Problems with Interrupt Model

  • programming difficulties

  • validation difficulties

  • (hardware) limited number of interrupts


Sub system decomposition

Sub-System Decomposition

  • functional or object-oriented (+ others)

  • delay decisions about sequential or concurrent systems

  • weeks 4 & 6


Summary

Summary

  • concepts

    • process, strategy, quality

  • architectural design

    • division into sub-systems

    • use a model or combination of models


  • Login