What is software architecture? In the previous article "What is architecture?" we stated that architecture is about:
So any program you build has at least the following structural elements:
Inside your code you will also have shared services that are used by every layer, this is diagrammed as follows:
Where layer 1, 2, ..., N represent the layers in your code and the share services are shown vertically as they cut across all the layers. Layer N represents the UI layer of the system and the functionality at that layer depends on all the layers below it.
So now we have defined what structural and connective elements are in software, next we describe what it means to have good architecture and bad architecture.
- Structural elements
- Connective elements
Let us talk about these with regard to a software system. In our next article we'll talk about good and bad architecture.
Structural elements
Structural elements in software are layers that support other layers in the system:- the language libraries are built on the functionality provided by the O/S
- the functionality of the software product is built on the language libraries
- 3rd part libraries that you are using are built on the previous 2 layers
- your code is built on all the previous layers
So any program you build has at least the following structural elements:
In a well designed system, your code will also break into layers specific to the application that you are building. Each layer ideally only depends on layers underneath it, otherwise you will have circular references; asignal that there is a challenge or that something is wrong.
Connective elements
Every software system has connective elements that communicate across the different layers. Often 3rd party libraries are shared services that provide core services like data structures (XML, JSON, etc), logging, debugging, and other services.Inside your code you will also have shared services that are used by every layer, this is diagrammed as follows:
Where layer 1, 2, ..., N represent the layers in your code and the share services are shown vertically as they cut across all the layers. Layer N represents the UI layer of the system and the functionality at that layer depends on all the layers below it.
Generalizing Architecture
When people are talking about software architecture, they are not just talking about the structure of the code. Often people are talking about the machines and O/S components as well. So for example when people are talking about the LAMP architecture they are talking about:- The O/S -- i.e. Linux
- The web server -- Apache, running on Linux
- The database -- MySql, running on Linux,
- The code -- PHP running on the MySql database using services from the O/S
Note: The PHP layer is further broken down like the diagram above in the Structural Elements section.
The LAMP architecture involves structural elements. Connective elements are simply the ones created inside the PHP layer or generally provided by the O/S.
So when relevant, architecture includes:
So when relevant, architecture includes:
- The O/S
- All support services, i.e. webserver, database, etc.
- The high level applications written by you or a 3rd party
General Software Architecture
For the structural elements of software we are taking about layers. Those layers can be relative to the O/S such as how the O/S communicates with support services (web servers, databases, etc) or how your applications communicate with support services and the O/S.
Within your application there are different layer interactions, there is 1) how your base layers are built on the APIs of your language and the 3rd party libraries that you have installed, and 2) how you have broken up your layers to communicate with the different parts of your software.
The main structural elements of any model-view-controller (MVC) program looks somewhat like this:
- The model layer a.k.a. business layer is built on 3rd party APIs and O/S APIs
- The view layer a.k.a. GUI layer is built on 3rd party GUI APIs
- The data layer is build on database APIs
All of the APIs that you are using are based on the standard APIs of the language that you are using.
Implications
- Changing languages requires that every layer above it be reconsidered
- This means that if you change languages and some 3rd party API must be changed then the layer above also needs to be changed
- Strict separation in layers means that you can change a 3rd party API and only a single layer of the MVC system is affected
- Often developers color between the lines and a change of a 3rd party library causes quite a bit of pain as the layer infractions are found
- Not having enough of a business layer will be problematic because it is one of the main separating structures between your view/GUI and data layers.
- People discover lacking business layers when they change their database APIs or databases and have the problems propagate all the way through the GUI
- Often when business functionality is built into the model/GUI layer then that functionality is lost and needs to be recoded when a new GUI API is used
Connective elements
Connective software elements are used to shuttle data between the structural layers of the system. These connective elements are generally available everywhere (although they can be limited to a few layers).
Easily understood connective elements are those used in debugging and logging. These elements are available universally, e.g. debugging and logging routines can be made available in all layers without worrying about layer dependency.
Other connective elements are most easily recognized because they are routines shared across layers of the architecture. More specifically, they are the libraries/modules that are included into multiple layers of the program.
Other connective elements are most easily recognized because they are routines shared across layers of the architecture. More specifically, they are the libraries/modules that are included into multiple layers of the program.
So now we have defined what structural and connective elements are in software, next we describe what it means to have good architecture and bad architecture.
No comments:
Post a Comment