Entry #3: Software Architecture
Chapter 14 of Pete Goodliffe’s book “Code Craft: The Practice of Writing Excellent Code” titled “Software Architecture: Laying the Foundations of Software Design” explains the essential theory of Software Architecture, using definitions, characteristics, examples, and reasons of why we should implement it.
According to the author, architecture is the single largest influence on the design and future growth of a software system, and it is needed to be developed in the early stages of software development. Developing a correct software architecture will allow us to know how the software should be adapted or implemented in future changes or releases and what components should be put in each module.
Architecture must consider performance, simplicity, comprehensibility, modularity, flexibility, reusability and requirement fulfillment for the components that could be an object, process, library database, etc., and connections that are simple function calls, data flowing through a pipe, an event handler, etc. The connections can be synchronous or asynchronous.
Software Architecture can be compared like pasta types:
- Spaghetti: Messy, uncontrollable and without an order.
- Lasagna: Layered, based on a hierarchy.
- Cannelloni: Logical flow with sequences and filters.
- Gemelli: Client/Server architecture, two-tiered architecture or even as a three-layer architecture.
- Conchiglie: Decentralized components that communicate with each other.
- Canned Ravioli: Existing frameworks or libraries.
However, another 4 views of the software architecture can be:
- Conceptual view/Logical view: Only show the major parts of the system and its interconnections.
- Implementation view: Actual implementation modules may differ from the conceptual model sometimes.
- Process view: Show the structure as tasks, communication or process terms in a more dynamic form.
- Deployment view: Show the allocation of the tasks to physical nodes in a more distributed system.
The architecture is used to validate what is going to be built, how it is going to communicate the design to everyone involved and how to make correct decisions. It is very recommended to document the system architecture where everyone involved in it can check whenever it is needed.
Comentarios
Publicar un comentario