Architecture & Structure
I would like to preface this post by providing a bit of context. In this article, I share what I’ve learned in my short introduction to software architecture as a patternmaker. I saw many parallels between the two practices in how they are organized and implemented. Both practices operate on levels — abstracting the final product into ‘layers’ — such as technical specification, product use, production processes, etc. Below I share the research that I found quite useful in developing a high-level understanding of software architecture.
patternmaker: noun A person, machine, or software program that makes patterns, as for sewing, carpentry, or industrial machinery.
Patternmakers have a combination of engineering and design skills. They need to be able to understand what the designer wants and translate that into the lines of a pattern that will cause the garment to fit correctly. Patternmaking is taught in conjunction with fashion design education, as it is vital for designers to understand the apparel development process.
An analogy I used to describe my previous profession was to liken it to a structural engineer for clothing — kind of like an architect, building the objects we live in. Except rather than designing the buildings a patternmaker designs the clothing.
Knowing very little about software architecture with the exception of its likeness to patternmaking I recently decided to dig a little deeper and to get a little more curious by asking, ‘What is software architecture?’.
Here are a few things I learned in my exploration:
- The software architecture of a system is about laying out and describing the organization or structure of the system and its behaviors.
- It is the definition/identification of high-level structures of a software system and the discipline of creating such structures and systems.
- The defined structures are software elements and their relationships and properties.
- It defines the blueprint for the system and the developing project, defining the tasks necessary to be executed by the design teams.
All of these descriptions about software architecture immediately sounded familiar and wanted to learn more.
There are several methods that can define a system’s software architecture.
- UML (Unified Modelling Language) — UML is an object-oriented solution used in software modeling and design.
- Architecture View Model (4+1 view model) — The architecture view model represents the functional and non-functional requirements of the software application.
- ADL(Architecture Description Language) — ADL defines the software architecture formally and semantically.
Software Architecture Models
There are three model types that can help build out the architecture categorized by purpose — structural, dynamic procedural, and deployment.
The Static Structural Model
The Static Structural Model shows the major system components/data objects. It declares the objects/classes and their relationships, as well as their properties. I like to think of it as a family tree of sorts. While family trees are uni-directional, static structural models don’t typically have this restriction.
The Dynamic Process Model
The Dynamic Process Model focuses on the inter-component dynamism and shows the process structure of the system. It includes relationships model such as a data-flow model that shows sub-system relationships. So while the structural model shows a diagram of data objects, the dynamic process model focuses on the behavioral outcomes and processes of the data objects. When reading about this process-based model it made me think of the role of the playbook in a number of different team sports. The idea is to map out actions over some amount of time to accomplish a set outcome.
Software Architecture Advantages
The last topic I’ll get into is the advantages of software architecture as a practice. As with all forms of languages — software architecture helps improve stakeholder communication. It provides the support material and documentation to use as a focus of discussion by system stakeholders. In addition to communication, this practice helps improve system analysis to verify whether the system can meet its non-functional requirements. The build of any software architecture in particular can be successfully re-used, which is a huge business advantage. Finally, internally — it is a great support in project planning and predicting the quality attributes of an artifact during the design phase of the development process.
