I’ve always been interested in computers and was fortunate to have been introduced at a young age. My passions grew over the years and I found myself pursing a software engineering degree in my early 30’s. I’ve found a love for software development and the importance of good software design. In Peter Freeman and David Hart’s book A Science of Design for Software-Intensive Systems they define software design as:
“all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems” or “the activity following requirements specification and before programming, as a stylized software engineering process.”
The purpose of the Design Phase of the Software Development Life Cycle is to take the information received from the requirement phase and plan how an application will function and the interactions that take place within itself and with various other systems through interfaces. By detailing the implementation of these inner workings of the system the development team can save valuable time creating the system by working on individual portions independently while simultaneously developing the system as a team. The project document created in the Design Phase should also contain plans for operation, maintenance, and countermeasures for worst case scenarios as well as training to mitigate data loss, manipulation, and theft. The information gathered in this document will later be given to the development team.
Now that we know what software design is let’s look at a few key concepts of design:
Abstraction: a process that allows data on an object to be hidden to increase efficiency and simplify the complexity of a program.
Refinement: a process that hones the high levels of details in software down to a more simplified form.
Modularity: a process of breaking up a program into smaller programs called modules that utilize a common interface to send data between modules.
Software Architecture: the design of the software structure to serve as a plan for proper execution utilized by the development team.
One consideration for the system architecture is the methodology in which we will approach designing our software. When designing software there are two main approaches to consider, a structural approach in which we focus on the functionality of the system, and an object oriented approach in which we focus on the data and how it flows through the system.
The structured approach is said to be a top down approach in which the software is broken into a series of global functions or methods. Top down design is when you think of what the system’s purpose will be and from that create systems and subsystems to fulfill its purpose. In the structured approach these sub-routines are then run sequentially. By breaking the project down into smaller portions the software is more easily managed. Projects utilizing the structured approach to software design have clearly defined phases due to its sequential nature. Often the structured approach is utilized on larger projects that can span a year or more.
The object oriented method is a bottom up approach in which data is passed through classes. In a bottom up approach you may have multiple purposes for the software. In such cases the software needs to function more dynamically by calling the method/function when it is needed. The bottom up approach shines when it comes to scalability; by utilizing methods and method calls we can easily reference methods already created. Due to this reusability it has quickly become the most widely utilized approach to software design.
By further understanding the structured and object oriented approaches to software design it is easy to see how different these approaches are. One of the reasons these approaches are so different is as technology evolved we began to utilize software and the data it provides differently. With these new requirements we needed to explore different methods to design software. All though scalability of object oriented programming is one of the largest perks we shouldn’t count out the structured approach, as it has an overall greater performance due to its linear architecture. As in most cases, the correct answer for choosing the architecture of your software depends on the system we’ve gathered the requirements for.
As you can see good software architecture will refine the problem down to the simplest form and abstract it reduce redundancies insuring a reliable and secure system. By creating a method and calling it when needed throughout the software we can eliminate unnecessary repetition by utilizing the principal of reusability. We should also account for future needs, by designing a solution that is loosely coupled and modular, allowing for the software’s evolution, this flexibility will create a better overall experience and increase the longevity of the software. Finally one of the most important questions we should ask ourselves is where our software is most vulnerable. By accounting for potential errors, and verifying and validating user input we can mitigate many vulnerabilities thus creating a more robust and secure system.
Software Design is no simple task, by spending more time in the software design portion of the Software Development Life Cycle we may more thoroughly design the architecture of the system, alleviating unnecessary issues arising later in the life cycle. What I have covered throughout this paper is just the tip of the iceberg on the subject of software design; it however proves a useful introduction to its complexities and some important considerations to implement into our own designs.
References
System Development Life Cycle (n.d.). retrieved from: https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_development_life_cycle.htm
Timothy Budd (2002). Object-Oriented Programming retrieved from: http://web.engr.oregonstate.edu/~budd/Books/oopintro3e/info/chap02.pdf
Software Architecture (2021). retrieved from: https://en.wikipedia.org/wiki/Software_architecture
Peter Eeles (2006). What is a software architecture? Retrieved from: https://www.ibm.com/developerworks/rational/library/feb06/eeles/index.html#:~:text=The%20software%20architecture%20of%20a,and%20the%20relationships%20among%20them.
Difference between structured programming and OOP (2015). retrieved from: https://www.scriptcaseblog.net/scriptcase-es/difference-between-structured-programming-and-oop/
Object Oriented Approach (n.d.). Retrieved from: https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_object_oriented_approach.htm#:~:text=Structured%20design%20programming%20usually%20left,suitable%20for%20in%2Dhouse%20development.
