We have talked a little about Software Design, and to be more specific we have talked about UML. This diagrams tools help us to design our general idea of understandig how software is going to behave.
Software Architecture is a little bit different. In a Software Architecture diagram, you show the “skeleton” of your software, is like thinking in layers were you separate by layer the functionality and each layer is intercomunicates with the others surrounding them by priority or programming level.
Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.
Architecture comprises the frameworks, tools, programming paradigms, component-based software engineering standards, high-level principles.
The goal of architecture is to identify the requirements that affect the structure of the application. Good architecture reduces the business risks associated with building a technical solution.
Key Architecture Principles
Consider the following key principles when designing your architecture:
- Build to change instead of building to last. Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.
- Model to analyze and reduce risk. Use design tools, modeling systems such as Unified Modeling Language (UML), and visualizations where appropriate to help you capture requirements and architectural and design decisions, and to analyze their impact. However, do not formalize the model to the extent that it suppresses the capability to iterate and adapt the design easily.
- Use models and visualizations as a communication and collaboration tool. Efficient
of the design, the decisions you make, and ongoing changes to the design, is critical to good architecture. Use models, views, and other visualizations of the architecture to communicate and share your design efficiently with all the stakeholders, and to enable rapid communication of changes to the design.
- Identify key engineering decisions. Use the information in this guide to understand the key engineering decisions and the areas where mistakes are most often made. Invest in getting these key decisions right the first time so that the design is more flexible and less likely to be broken by changes.
tanks to: https://msdn.microsoft.com/en-us/library/ee658098.aspx
When we talk about software architecture I think on an example diagram, let´s take a look on the following top Architecture diagram (in HW):
This gives us an idea on what the project and the sections of code are doing:
There is an application layer which is usually the top of the diagram.
Followed by the two or N layers of software levels, in this case is an example of firmware, so for being Hardware mostly, we separate it on HIL and HAL distribution.
HAL: Hardware Abstraction Layer
HIL: Hardware Implementation Layer
This is related with software since they are a UNIX concepst on how to slice software and hardware relations in an OS.
At the end of the diagram we have the physic layer, which in this case is a microcontroller.
There is a similar process with a pure software (High level) Architecture diagram representation, personally I have done more HW Architecture diagrams than SW.
