Software design
A programmer wrote to me: “Why do we have to document software design? Is it possible keeping the design in your mind and start to write code instead? What is the difference between architecture and design?
Answer: Basically design is a map of the software product that you are going to build. If you are the only person who build the product then it is possible not to document it. You can start coding from what you have in mind.
However, today most people develop software in team. Your team members cannot read your mind so you need to document your design to communicate the concepts to other people in the project. Typical Design has two major parts: The high level or the architecture and the low level or the detailed design.
Design document describes areas that need to be investigated to identify what may works and what may not. Since software project is done by a team of people, it is important to share the design so the team can evaluate and discuss to identify any errors early in the project. Since software requirements often change, the design provides a common reference point for the team to assess the impact of changes and make design decisions.
The high level or the software architecture indicates how the system is divided into major components; how these components are related to each other; how they interfaces to the user; how they interact to other systems; and how they interact between themselves. The software architecture also identifies data definitions; what data will be stored and where they will be stored. The architect identifies system constraints, quality attributes such as performance, expansion, security, portability and platform technology (e.g., PC-based, cloud-based).
From the architecture, developers shifts to the low-level or detailed design where they breakdown each component into smaller modules where each functions could be specified as well as its constraints on its interface. Each module should also have entry and exit criteria with internal data structures and algorithms defined.
Design information can be documented in textual notes (e.g., “The server responds every 5 seconds with XYZ output,” “Component ABC will handle all errors,” or “The databases will be synced every 5 minutes:”) or it can be documented in graphical form (e.g., modeling languages, UML, event tables, context diagram, flow diagrams, timing diagrams etc.) or it can be documented as pseudo code – a textual description of what the code will do.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
