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 • sd, sa, jsd [data flow, entity-relation, structure] • oo [inheritance, structure, use] • description • graphical, pdl, text
Strategies • functional • function driven • data driven • object-oriented
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 Deciding on the major sub-systems and how they fit together
Architectural Design • introduction • system structuring • control • sub-system decomposition • domains
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 • 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 • 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 (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 • 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 • 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 • 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 • centralised • call-return (sequential systems) • manager (concurrent systems) • event-driven • broadcast • interrupt
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 • uncertainty about event handling • is there a server? • is there more than one server? • how long will it take?
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 • programming difficulties • validation difficulties • (hardware) limited number of interrupts
Sub-System Decomposition • functional or object-oriented (+ others) • delay decisions about sequential or concurrent systems • weeks 4 & 6
Summary • concepts • process, strategy, quality • architectural design • division into sub-systems • use a model or combination of models
