1 / 21

Software Design

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

zeroun
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Design From Requirements to Implementation

  2. Concepts • process • the stages of design • strategies • how to go about it • quality • some traditional measures

  3. 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

  4. Strategies • functional • function driven • data driven • object-oriented

  5. 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

  6. Architectural Design Deciding on the major sub-systems and how they fit together

  7. Architectural Design • introduction • system structuring • control • sub-system decomposition • domains

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. Control Models • centralised • call-return (sequential systems) • manager (concurrent systems) • event-driven • broadcast • interrupt

  16. 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

  17. Problems with Broadcast Model • uncertainty about event handling • is there a server? • is there more than one server? • how long will it take?

  18. 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

  19. Problems with Interrupt Model • programming difficulties • validation difficulties • (hardware) limited number of interrupts

  20. Sub-System Decomposition • functional or object-oriented (+ others) • delay decisions about sequential or concurrent systems • weeks 4 & 6

  21. Summary • concepts • process, strategy, quality • architectural design • division into sub-systems • use a model or combination of models

More Related