Software design
Download
1 / 21

Software Design - PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on

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

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 ' Software Design' - zeroun


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


ad