Software architecture
On this page 8 headings
Software architecture is a way of organising your code: how classes/modules should be organised. It is like the architecture of a building, considering efficiency of space and functionality. It defines the software elements/modules, the relations among them, and the properties of both. This is the “big picture view” taken after design — modular/layered design and UML.
1.1 Why architecture matters
Reflect on Google search versus a compiler. Their components interact differently.
These patterns of information between components are called software architecture styles.
1.2 Client–server
In client–server architecture, data is transacted in response to requests.
Google search: the query goes to a server, which returns a response; this is predominantly how the Internet works.
1.3 Pipe-and-filter
Data is passed from component to component and transformed/filtered along the way.
Compiler: source code → assembly code → executable file run by the OS.
1.4 Model–View–Controller (MVC)
MVC separates views of the data from manipulations of the data. Model = the component that models the data for the service. In the Amazon Seller portal, these are the classes/objects that model the database tables.
View = GUI objects, the presentation layer and visual representation of the model; it retrieves data from the model and displays it. Controller = coordinates multiple views on the screen and helps users manipulate the model, e.g. filtering catalogue items by name.
1.5 Peer-to-peer
Peer-to-peer is a distributed application where systems form nodes and share resources. There is no centralised system monitoring all transactions.
Nodes make processing power, disk storage etc. directly available to other nodes without central coordination.
1.6 Components, connectors and protocols
Component = well-defined functionality or behaviour, separate from other functionality, e.g. client software and server; browser and search-engine server. Connectors = code that transmits information between components and regulates their interaction.
Protocol = a set of predefined rules describing how components interact; client and server must agree on the message format. The most common connectors are function calls and REST API calls.
| Concept | Question it answers | Example |
|---|---|---|
| Component | Who does the work? | Client software / Server |
| Connector | How do parts interact? | Function call, REST API call |
| Protocol | What rules govern the exchange? | Agreed message format |
1.7 Design patterns, design smells and refactoring
Past solutions that experienced designers reused became standardised. A design pattern is a description of communicating objects and classes customised to solve a general design problem in a particular context. An anti-pattern is a pattern used incorrectly, or new code added along the way.
Design smells are warning signs that your code may be heading towards an anti-pattern. SOLID guidelines help avoid design smells. Refactoring moves back to a good design: moving code between classes, creating new classes/modules, and removing classes that are not required.
Summary
- Styles: client-server, pipe and filter, peer-to-peer, MVC.
- Design patterns: common patterns of organising code that have worked in the past.
- Design smell: lack of proper design patterns.