- Analysis: User needs → specifications
- Design: Decomposition into elements that can be developed separately → specifications of each element
- Coding: Programming of each element separately (+ isolated tests)
- Integration: The elements are put together and the complete system is tested
- Maintenance: Occasional changes (errors or improvements).
- Just to gain experience
- The code does not reject
- They are used for the design analysis phases
- The code is rejected
- Cyclic process of cascade model
- In each round the prototype is improved until reaching a complete system.
System model concept
- The model specifies WHAT the system does without specifying HOW it does it
- Different techniques can be used
- Decomposition in subsystems
- Modification of an existing model
- Domain analysis → study environment, terminology, similar systems.
- Objective → obtain the software specifications (build the model)
- Study of the system in context: SW system is part of a complex system (SW + HW + mechanics + …..) → study of all other systems + study of the domain
- Identification of needs: interaction with the client → real needs
- Establishment of the system model
- Hierarchical development → division into subsystems + development of each subsystem
- Ends with a requirements specification document
Different possible notations for the specification
- Natural language → for very simple systems or as a complement to others
- Data flow diagrams (DFD) → model the processing of data in the system
- State transition diagrams (DTE) → model system dynamics
- Data dictionary → model the data
- Tell how the system will do what it has to do.
- Ends with an architectural design document and a detailed design document.
- Architectural design
- Structure and organization of the system.
- Division into subsystems or modules + interfaces between them.
- Detailed design → development of each module
- New modules appear, others are grouped or disappear.
- Define the structure of each module, with its data and associated services.
- Design the algorithms for the development of each module → it is detailed in pseudocode without reaching a very detailed level (it would be almost coding).
- Data design → design of the databases associated with the system (if necessary)
- It is one of the many tools for design
- Proposed by E. Yourdon as a tool for structured design
- Describe the hierarchy of modules and sub-modules (architectural design)
- The Yourdon module concept fits into what is a C function
Characteristics that a Module Must Fulfill
Coupling (it must be weak) → it is the interrelation that it has with other modules
- (Very Strong) By content → access to local data and code (between modules).
- (Strong) Common → data area common to several modules.
- (Medium) Control → the modules are passed control signals.
- (Weak) By reference → the modules are passed data by reference (eg: C struct).
- (Very Weak) By value → passing data from one module to another (only the ones you need).
Cohesion (must be medium / high) → group related elements in a module
- (Very Low) casual → no relationship (eg: I take a program of 1000 lines of code, I break it into blocks of 100 lines and I make a module with each block).
- (Low) Logic → the module contains operations whose execution depends on a parameter (eg: a Calculation function (operation, data) that can make sums or products).
- (Medium-Low) temporary → the module contains operations that are executed at the same time (eg: system initialization routines).
- (Media) communication → the module performs different operations that run in “parallel” and that they all operate on the same data set.
- (Medium-High) sequential → the module performs different operations that are carried out sequentially on the data, so that the output data of an operation is input data for the next.
- (High) functional → the module performs only one function.
Comprehensibility → simple and understandable functioning (for those who have not designed it).
Adaptability (very difficult) → possibility to change it easily.
Design Document (In the case of modular design)
1. Introduction → overview of the document
- 1.1. objective
- 1.2. Ambit
- 1.3. Definitions, acronyms and abbreviations
- 1.4. References
2. Overview of the system → overview of the requirements + reference to the requirements specification document.
3. System context → connections with other systems.
- 3.n. Definition of external interface,
4. System design → description of the upper level of design (architectural design)
- 4.1. High-level design methodology → description of the methodology used
- 4.2. Decomposition of the system → system components (modules) and the relationship between them.
5. Design of the components → design of each module.
- 5.n.0. Identifier of the component.
- 5.n.1. Type → module.
- 5.n.2. Objective → justification of the need to exist.
- 5.n.3. Function → what does it do?
- 5.n.4. Subordinates → components (modules) what do you use.
- 5.n.5. Dependencies → components (modules) for which it is used.
- 5.n.6. Interfaces → rules of interaction with other elements (modules).
- 5.n.7. Resources.
- 5.n.8. References.
- 5.n.9. Process → algorithms (defined with pseudocode).
- N 5.n.10. Data → internal data used by the component (module).
6. Feasibility and estimated resources → to carry out the system.
7. Matrix requirements / components.
Development Proposal for Small Systems
- Very briefly say what the system does without saying how.
- In natural language or structured natural language,
- No software specification document → included in the design document
- Architectural design
- Division into modules and the interfaces between them.
- Reflected in a structure diagram.
- Detailed design
- Design of each of the modules.
- Specified as pseudocode (best) or flowchart.
- Is reflected in the design document.
- Brief introduction and overview of the system.
- Detailed development of system design and components.