My Definition of Software Architecture

Back in college, a whole two months ago, various software engineering courses required students to keep logbooks. Entries had to be relevant to the course and appear at a minimum frequency.

A recent post here will show that I am a stickler for correct usage of terms. It bugs me that going to five different sites that define the terms “software architecture” and “software design” will give me five different answers. (no links on those two terms because I am defining them here!)

The only solution was to come up with my own definition, naturally. If you can’t beat them, join them.

I wrote this entry in my “Engineering Enterprise Software Systems” course after we discussed the definition of software architecture, system architecture, and SOA:

You know I can’t resist spewing philosophical on the definitions of software architecture, software design, system architecture, and where SOA fits.

My official definition of software architecture:

Software architecture is the sum of the software implications of a functional requirements specification for a system. These are the aspects of the software that, if changed, will not meet the requirements. If they are high-level enough to be specified or implied by your customer, they are high-level enough to be included in your requirements.

Software architecture is a synthesis of functional divisions of software, their interfaces, their time, space, and other constraints, and how they interact to fulfill the requirements. This includes the 4+1 views of software architecture: physical, process, development, logical, and use cases.

Software design, on the other hand, is the analysis of architectures. Note that if you compare architecture A and B, and B doesn’t fulfill all requirements, then the choice between A and B is architectural. If they both fulfill the requirements, then the choice between A and B is a design decision. Essentially, what qualifies as architecture is in the eyes of the architect (and by implication, what goes in the requirements). Everything else is design. This distinction is greatly influenced by the Intension/Locality Hypothesis.

SOA, then, is clearly a software architecture.

One example I just thought of is whether to use the blackboard pattern for a data-driven application as opposed to something else like client-server or clustered. If I give this to you with no requirements, then the choice is asthetic and a matter of taste, and thus design. On the other hand, if I throw some reliability, availability, security, extensibility, or schedule requirements at you, then suddenly one of these might seem more attractive than the other. Now it becomes an architectural decision.

System architecture is a superset of software architecture. System architecture involves more than just software and the hardware considerations of that software. A software architecture could be part of a manufacturing system, a criminal justice system, a military system, etc.

More on the Intension/Locality Hypothesis in a later post.

A few semesters later, in the software project course for seniors, the 4+1 model of software architecture is pushed. You know you really need your own clarity when it appears as though the CS curriculum was contradicting itself. I followed up with these thoughts:

I started thinking about the development view of the 4+1 model. In Krutchen’s paper, it is stated that the logical view focuses on the functional requirements, and it is essentially a domain model for the system.

Following my own definition and what I learned in “Software Architecture & Component-based Design” during the software design portion of the course, it seems to me that the logical view is more of a software design issue than a software architecture issue. There are many different domain models that can fulfill the requirements of a given system, and surely a domain model remains true under expansion.

Also, the 4+1 development view is stated to be focused on what the modules are and how they interact in a (recommended) layered style. This is exactly what we focused on in the design part of “Software Architecture & Component-based Design”, although now I see that we also talked about layered as an architecture, so it may be possible that the design portion assumed a layered architecture.

2:45PM: let me add that after reviewing some of my notes from “Software Architecture & Component-based Design”, and basically thinking about my own real-world application of domain-driven design, I see now that the 4+1 development view is probably purely abstract. Domain-driven (software) design bridges the gap from the purely abstract and conceptual to a realized incarnation of those intractable thoughts in code. It also addresses the issues of reuse, plugability, cohesion, coupling, refactoring, etc.

To sum it up, software architecture is

• the software implications of your requirements
• the synthesis of functional divisions of software and how they are glued together
• the 3+1 views: development, physical, process, and use case scenarios
• in the eyes of the architect; if the architect finds that something is necessary system-wide, it is architectural
• something that cannot be given to developers to produce code
• all statements about the system that are not preserved under expansion

Software design is

• everything not implied by your requirements
• the analysis of architectures to find the best one that meets the requirements
• the logical view of the 4+1 views, plus the “physical” incarnation of the development view
• in the eyes of the architect; if the architect does not find that something is necessary system-wide, it is design
• something that can be given to developers to produce code; this depends on your language and platform. For example, in Java, this would be class diagrams, but in C, you’d need to probably specify function signatures, structs, and header files.
• all statements about the system that are preserved under expansion

The last bullet of each list, talking about “expansion”, is rather vague, and I will try to discuss them in that future post on the Intension/Locality Hypothesis.

So from now on, this post is the guideline for what architecture and design mean. Be sure in the comments you write here that you adhere to these definitions!

About these ads