What Are The Basics Of Software Design?
Software design is the method of converting user specifications into an appropriate shape that will aid the programmer in software coding and execution.
An SRS (Software Requirement Specification) document is developed to determine user specifications, while more complex and comprehensive software requirements are required for coding and implementation. This process’s output can be explicitly used in programming language implementation.
The first phase in the SDLC (Software Design Life Cycle) is software design, which shifts the focus from the problem domain to the solution domain. It attempts to decide how to meet the specifications outlined in the SRS.
Levels in Software Design
There are three levels of consequences from programme design:
Architectural Design – The architectural design is the system’s most abstract version. It describes the device as a machine of several interconnected parts. At this stage, the designers have a good understanding of the possible solution domain.
High-level design- The high-level design framework in architectural design splits the ‘single entity-multiple component’ concept into a less-abstracted view of sub-systems and components and illustrates their relationship with one another. High-level design is concerned with how the framework and all of its elements should be applied as modules. It understands the modular structure of each subsystem, as well as their relationship and connection with one another.
Detailed Design- Like the former two designs, detailed design deals with the execution of what is seen as a structure and its sub-systems. It delves further into modules and their implementations. It determines the logical structure of each module as well as their interfaces with other modules.
Modularisation is a method for dividing a software system into distinct and autonomous modules that are meant to perform task(s) independently. These modules could serve as the foundation for the whole programme. Designers typically create modules that can be executed and/or compiled individually and independently.
Unintentionally, modular architecture meets the principles of the ‘divide and conquer’ problem-solving approach. This is due to the fact that there are several other advantages to software’s modular architecture.
Historically, all software are designed to be implemented sequentially. By sequential execution, we say that the programmed instructions will be executed one after the other, meaning that only one part of the programme will be triggered at a time. If a programme contains several modules, only one of them can be active at any given time during execution.
Concurrency is applied in programme architecture by dividing the software into several independent units of execution, such as modules, and running them in parallel. In other words, concurrency allows programme to run several parts of code concurrently.
It is important for programmers and designers to identify certain modules that can be executed in parallel.
As an example, the spell check function of a word processor is a programme module that works alongside the word processor.
A software program’s functions are grouped into many modules depending on those features as it is modularised. Modules, as we all know, are groups of commands that are placed together to accomplish a certain mission. They are, however, considered a single body, but can refer to each other in order to collaborate. There are criteria that can be used to determine the consistency of a module’s configuration and interaction with other modules. This is known as pairing and stability steps.
Cohesion is a metric that defines the degree of interdependence among module elements. The higher the software concept, the greater the cohesion.
There are seven forms of cohesion, which are as follows:
Co-incidental cohesion – It is unplanned and spontaneous cohesion, which may be the product of splitting the software into smaller modules for the purposes of modularisation. It is usually not-accepted since it is unplanned and can cause misunderstanding to programmers.
Logical cohesion is achieved as logically classified components are combined to form a module.
Temporal Cohesion – Where module components are arranged in such a way that they are processed at the same time, this is referred to as temporal cohesion.
Procedural continuity occurs as members of a module are clustered together and performed sequentially to complete a task.
Communicational continuity occurs when components of a module are clustered together, are performed sequentially, and function on the same data (information).
Sequential harmony occurs as module elements are clustered and the output of one element acts as the input to another, and so on.
Functional cohesion, which is the greatest level of cohesion which is strongly anticipated. Module elements are clustered in functional harmony since they all adhere to a similar well-defined feature. It is also reusable.
Coupling is a metric that determines the degree of interdependence between software modules. It determines the degree at which the modules interfere and communicate with one another. The lower the coupling, the more effective the software.
There are five degrees of coupling, which are as follows:
Content level coupling occurs when one module may explicitly view, alter, or refer to the content of another module.
Popular or global coupling occurs when several modules have read and write access to certain global data.
Control coupling- Two modules are said to be control-coupled if one of them agrees on the function of the other or adjusts its execution flow.
Stamp coupling occurs when several modules share a single data system and function on different parts of it.
Data coupling- Data coupling occurs as two components communicate with one another by exchanging data (as parameter). If a module sends a data structure as a parameter, the receiving module must use all of its elements.
In an ideal world, no coupling is preferred.
The software design method creates design documentation, pseudo codes, detailed logic diagrams, process diagrams, and a detailed overview of both functional and non-functional specifications.
The next step, programme execution, is dependent on all of the above-mentioned outputs.
It is then necessary to validate the production before moving on to the next step. The earlier an error is found, the better; otherwise, it might not be detected until the product is tested. If the results of the design process are in formal notation form, the methods associated with them can be used for testing; otherwise, a detailed design analysis should be used for verification and validation.
Reviewers can spot flaws created by missing those criteria using a formal verification technique. For good programme design, accuracy, and usability, a good design review is essential.