Software design, Software architecture, Software system, Software pattern
I’m not an expert in
Software Engineering but have been working as a Software Engineer since last ten years. During my PhD, I recently came across several terms that confused me and my entire understanding of the software development paradigm. Let me give you examples:
Researchers and book authors used these terms extensively in their manuscripts when explaining any system or software. Some authors distinguished these terms while others used these terms interchangeably. To have a deeper understanding, I tried to consult some of my senior professors. Honestly, I become more confused.
Both as a developer and as a researcher, I wanted to dig more into this. And as any other person would do, I started to
I discovered fascinating and opinionated definitions of software architecture and software design. Not many resources explaining the difference between software architecture and information architecture.
Available resources are minimal and directed towards their understanding. Definitions were ambiguous and lacked discrete difference between these two.
I decided to share this experience with others. If you are reading this post, that means you are on the same path as me.
First thing first, what is the difference between system and software? Checkout an interesting discussion on Quora about the difference between system and software.
A system is a group of interacting or interrelated entities that form a unified whole..
Several books attempt to use this definition, which makes sense. With this definition, we know, a system can be a cultural system, economic system, physical system, biological system and many more. We are not interested in those. A system is a set of hardware, software, people, policies, directives, and others. See the examples given below:
From a computer science perspective, the system is a hardware system or a software system or a combination of both. Software is a specific term used in the computer science field which defines a collection of executable programs. A program is a set of instructions.
A software is a system but a system might not be a software.
This is why we refer computer as system. A computer system contains both several hardwares and software. I hope I was able to clear concept. Having understood the difference between system and software, it should be much clear when I say,
A software engineer designs and creates engineering specifications for building software programs, and should have broad information systems experience. Software engineers work with QA and hardware engineers to develop testing plans.
A systems engineer in IT does the same work as a software engineer in that he or she develops software components. But systems engineering additionally involves specifying, building, maintaining and supporting technical infrastructure. That infrastructure can include the build, test and production environments used to deliver software as a Service, and the systems used to monitor deployed software solutions’ performance.
Now, back to the main topic. We know what software is. As aforementioned, if you are into software engineering, you will face the term software architecture, and software design repeatedly. What are the main differences between these two terms? The answer to this question is opinion-based.
Here are links that I had bookmarked at the start of my PhD.
Software architecture is the skeleton of the entire system. It is the highest level of abstraction to comprehend how the whole system. Software design is about detail specifications of individual modules/components and their technical relationships.
Wikipedia defines software architecture as:
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations .
Similarly, software design is defined in Wikipedia as:
Software design is how an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints .
I am not sure how clear is these definitions. To simply put, architecture is a bigger picture and design is a smaller picture.
Software architecture activities involve a) architecture analysis, b) architecture creation, c) architecture evaluation, d) architecture evolution and e) architecture support such as documentation, communication and others.
Here are the lists of terms associated with software architecture. Explaining each of them is beyond the scope of this article. However, I will try to give a short definitions of each terms that are easier to remember. Official definitions of these terms are one Google search away.
Software design involves low-level component and algorithm design of a high level software architecture. During software design process, software designers attempts to achieve software quality attributes such as compatibility, extensibility, modularity, fault-tolerance, maintainability, reliability, robustness, security, usability, performance, portability and scalability.
During software design process we answer following questions:
Two essential concepts about software design are a) design patterns, and b) principles and practices.
Do not confuse software architecture with information architecture. I have written a separate posts about information architecture and associated terms..
During software designing phase, a software designer uses a design pattern. A design pattern is the re-usable form of a solution to a design problem. There are several types of software design patterns, such as:
In this article, we will discuss about design patterns in brief and discuss one of the creational design pattern named as Factory Method Design Pattern.
Software designers are expected to software design principles and practices. There are several standard principles and practices. I can not cover each of them here. However, I have a
TODO list in my backlog to write on the topic. Commonly mentioned principles includes:
Well, well, well! Too many technical terms. One technical term to explain another word. This practice is the reason why I found technical documentation very confusing and hard to read. I hope to use simple words to describe these terms and how they fit into the broad picture. Before I wrap up, I would like to mention that there are some opinion-based definitions mentioned in this post. The descriptions are explained based on my understanding and research for the last ten years in the software industry. Validity or reference to the definitions is cited where ever applicable. Happy researching and learning. Keep tuned in for the next post.
Books Authored by Me