Design Methodology Flashcards
The Design Problem
Small amount of developers but a large requirement specification.
Stages of Design
Problem understanding -> look at the problem from different angles to discover design requirements.
Identify one of more solutions.
Describe solution abstractions -. use graphical formal or other notions to describe design’s components.
Repeat process for each identified abstraction until design is expressed in primitive terms.
Phases in Design Process
- architectural design
- abstract specification
- interface design
- component design
- data structure
- algorithm design
Architectural Design
Identify sub-systems.
Abstract Specification
Specify sub-systems.
Interface Design
Describe sub-system interfaces.
Component Design
Decompose sub-systems into components.
Data Structure
Design data structures to hold problem data.
Algorithm Design
Design algorithms for problem functions.
Computer system, modular or monolithic?
Modularity, like subroutines, are more cheaper and efficient and therefore are used for computer systems.
Objectives for defining system modules.
Identify what they are, what they should know and how modules interact with one another.
Modularity Requirements
The modules must be:
- Autonomous -> can work by itself.
- Coherent - strength of the correlation of the elements inside the module.
- Robust - can cope with errors.
High Cohesion
Elements inside module work together well.
Low Coupling
High interdependence between modules.
Functional Decomposition
Leads to procedural abstraction.
Procedural Abstraction
Procedures represent distinct logical functions in a program.
Object Orientated Design
A collection of interacting objects, with the system state being decentralised and each object manages its own state.
Five Criteria in evaluating modular design methods.
- Modular decomposition
- Modular composability
- Modular understandability
- Modular continuity
- Modular protection
Modular Decomposition
Design method supports the decomposition of a problem into smaller problems.
Modular Composability
A design method which creates modules that may be freely combined to create new systems.
Modular Understandability
A design method which encourages easily understandable modules.
Modular Continuity
Can be updated without effecting the whole system (only one or a small amount of modules).
Modular Protection
Yields architecture in which abnormal conditions at run-time only effect one or a small amount of modules.
Repository Model
All shared data is held in central database which may be accessed by all sub-systems.
Advantages and disadvantages of repository models.
Databases are efficient in sharing large amounts of data.
The model is also visible through repository schema.
Requires agreement and limited evolution.
Good system properties
- useful and usable
- reliable (low coupling)
- flexible (low coupling, high cohesion)
- affordable (reusable software)
- available (decreased development time through reuse)
Interface
Defines some features of a module which upon other parts of the system may rely, and is known as an abstraction of the module.
Encapsulation
An encapsulation of a module means that users of said module cannot know more about the module than what is given by the interface.
Good Interface Design Principals
- linguistic modular units
- few interfaces
- small interfaces
- explicit interfaces
- information hiding
Linguistic Modular Units
Modules must correspond to linguistic units in the programming language used.
Few Interfaces
Overall communication between modules should be minimal, and every module should communicate with others as little as possible.
Small Interfaces (loose coupling)
Implies that if any two modules communicate, they exchange as little information as possible.
Explicit Interfaces
Communication between modules should be traceable.
Information Hiding
All information about a module should be private to the module unless it is specifically declared otherwise.
Tight coupling v loose coupling
Tight coupling is the overuse of shared variables and control information exchange. In other words, modules communicate too much, compared to loose coupling, which allows component changes to not affect other modules due to lack of communication between modules.
Cohesion Levels
- coincidental cohesion (weak)
- logical association (weak)
- temporal cohesion (weak)
- communication cohesion (medium)
- sequential cohesion (medium)
- functional cohesion (strong)
- object cohesion (strong)
Coincidental Cohesion
Parts of a component are simply bundled together.
Logical Association
Components which perform similar functions are grouped.
Temporal Cohesion
Components which are activated at the same time are grouped.
Communicational Cohesion
All elements of a component operate on the same input or produce the same output
Sequential Cohesion
The output for one part of the component is the input to another part.
Functional Cohesion
Each part of a component is necessary for the execution of a single function.
Object Cohesion
Each operation provides functionality which allows objects attributes to be modified or inspected.
Cohesion with inheritance
Inheriting attributes from super-classes weakens cohesion since it allows communication.
Cohesion v Encapsulation
Cohesion is the measure of abstraction that means developers do not need to concern themselves with the internal working of a module.
Encapsulation means that developers are unable to use hidden information within a module, ensuring that subtle errors cannot be introduced when using connected modules.
High cohesion, low coupling and well defined interfaces.
The combination of these three can lead to reusability of modules in other systems.
