Notes

Software Architecture and Design - Goals, Principles and Some Key Considerations
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture predicated on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:

"Software architecture encompasses the group of significant decisions about the organization of a software system like the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of the structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns."

In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when explaining architecture. He identifies these themes as:

"The highest-level breakdown of something into its parts; the decisions which are Hard to change; you can find multiple architectures in something; what is architecturally Significant can change over a system's lifetime; and, ultimately, architecture boils Down to regardless of the important stuff is."

Software application architecture is the process of defining and creating a solution that's well structured and meets all of the technical and operational requirements. The architecture will be able to take into account and improve upon the common quality attributes such as performance, security, and manageability.

The main focus of the program architecture is the way the major elements and components in a application are employed by, or interact with, other major elements and components within the application form. Selecting data structures and algorithms or the implementation information on individual components are design concerns, they're no architectural concerns but sometimes Design and Architecture concerns overlap.

Prior to starting the architecting of any software, there are a few basic questions that people should strive to get answers for. reformar vivienda 're as follows:

How the users of the machine will be interacting with the machine?

How will the application be deployed into production and managed?

Do you know the various non-functional requirements for the application, such as security, performance, concurrency, internationalization, and configuration?

How can the application be made to be flexible and maintainable as time passes?

What are the architectural trends that might impact the application now or after it has been deployed?

Goals of Software Architecture

Building the bridge between business requirements and technical requirements is the main goal of any software architecture. The goal of architecture is to identify the requirements that affect the essential structure of the application form. Good architecture reduces the business risks associated with building a technical solution while a good design is flexible enough to handle the changes which will occur as time passes in hardware and software technology, as well as in user scenarios and requirements. An architect must think about the overall effect of design decisions, the inherent tradeoffs between quality attributes (such as for example performance and security), and the tradeoffs necessary to address user, system, and business requirements.

Principles of Software Architecture

The essential assumption of any architecture ought to be the belief that the look will evolve over time and that certain cannot know everything one have to know up front. The look will generally need to evolve through the implementation stages of the application as one learn more, so when one tests the look against real world requirements.

Keeping the above statement in mind, let's make an effort to list down a number of the Architectural principles:

The system should be created to change instead of building to last.

Model the architecture to investigate and reduce risk.

Use models and visualizations as a communication and collaboration tool.

The key engineering decisions ought to be identified and acted upon upfront.

Architects should consider utilizing an incremental and iterative method of refining their architecture. Focus on baseline architecture to achieve the big picture right, and then evolve candidate architectures as you iteratively test and improve one's architecture. Do not try to get it all right the first time-design just as much as you can so as to start testing the look against requirements and assumptions. Iteratively add details to the look over multiple passes to make sure that you get the big decisions right first, and focus on the details. A common pitfall is to dive into the details too quickly and get the big decisions wrong by making incorrect assumptions, or by failing woefully to evaluate your architecture effectively.

When testing your architecture, consider the following questions:

What were the main assumptions which were made while architecting the system?

Do you know the requirements both explicit and implicit this architecture is satisfying?

Do you know the key risks with this architectural approach?

What countermeasures are in place to mitigate key risks?

In what ways is this architecture a noticable difference over the baseline or the last candidate architecture?

Design Principles

When getting started off with Software design, one should take into account the proven principles and the principles that adheres to minimizes costs and maintenance requirements, and promotes usability and extensibility. The key principles of any Software Design are:

Separation of concerns: The main element factor to be considered is minimization of interaction points between independent feature sets to achieve high cohesion and low coupling.

Single Responsibility principle: Each component or module should be independent in itself and responsible for only a specific feature or functionality.

Principle of Least Knowledge: An element or object should not find out about internal details of other components or objects.

Don't repeat yourself (DRY): The intent or implementation of any feature or functionality should be done at only one place. It should never be repeated in some other component or module

Minimize upfront design: This principle can be sometimes referred to as YAGNI ("You ain't gonna require it"). Design only what's necessary. Especially for agile development, one can avoid big design upfront (BDUF). If the application form requirements are unclear, or if you have a possibility of the design evolving over time, one should avoid making a large design effort prematurely.

Design Practices

Keep design patterns consistent within each layer.

Do not duplicate functionality within an application.

Prefer composition to inheritance. If possible, use composition over inheritance when reusing functionality because inheritance escalates the dependency between parent and child classes, thereby limiting the reuse of child classes. This reduces the inheritance hierarchies, which can become very difficult to cope with.

Establish a coding style and naming convention for development.

Maintain system quality using automated QA techniques during development. Use unit testing along with other automated Quality Analysis techniques, such as for example dependency analysis and static code analysis, during development

Not only development, also consider the operation of your application. Determine what metrics and operational data are required by the IT infrastructure to ensure the efficient deployment and operation of one's application.

Application Layers: While architecting and designing the machine, one needs to carefully think about the various layers into that your application will be divided. There are a few key considerations that need to be considered while doing that:

Separate the regions of concern. Break your application into distinct features that overlap in functionality as little as possible. The advantage of this approach is that a feature or functionality could be optimized independently of other features or functionality

Be explicit about how exactly layers communicate with one another.

Abstraction ought to be used to implement loose coupling between layers.

Do not mix several types of components in exactly the same logical layer. For example, the UI layer should not contain business processing components, but rather should contain components used to handle user input and process user requests.

Keep the data format consistent inside a layer or component.
Here's my website: https://www.gatesofantares.com/activity/p/2174455/