Software Architecture and Design - Goals, Principles and Some Key Considerations

1. Software Architecture and Design - Goals, Principles and Some Key Considerations Characterization: Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of design based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is: "Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural substances and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software structure also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic fears. "

2. In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when clearing up architecture. He identifies these themes as: "The highest-level breakdown of a system into its parts; the options that are Hard to change; there are multiple architectures in a system; what is architecturally Significant can change over a system's lifetime; and even, in the end, architecture boils Down to whatever the important stuff is. " Software application architecture is the process of defining and creating a solution that is well structured and meets all of the technical and operational requirements. The architecture should be able to take into account not to mention improve upon the common quality attributes such as performance, security, and manageability. The main focus of the Software architecture is normally how the major elements and components within an application are used by, or interact with, other major elements and ingredients within the application. The selection of data structures and algorithms or the implementation details of individual components are design conditions, they are not an architectural concerns but sometimes Design and Architecture concerns overlap. Before starting the architecting of any sort of software, there are some basic questions that we should strive to get answers for. They are as follows: How the users of the process will be interacting with the system? How will the application be deployed into production and managed? What are the various nonfunctional prerequisites for the application, such as security, performance, concurrency, internationalization, and configuration? How can the application be designed to be flexible and also maintainable over time? What are the architectural trends that might impact your application now or after it has been deployed?

3. Goals of Software programs Architecture Building the bridge between business requirements and technical requirements is the main goal of any software architectural mastery. The goal of architecture is to identify the requirements that affect the basic structure of the application. Good architecture reduces the business pitfalls associated with building a technical solution while a good design is flexible enough to be able to handle the changes that will show up over time in hardware and software technology, as well as in user scenarios and requirements. An architect must glance at the overall effect of design decisions, the inherent tradeoffs between quality attributes (such as performance and security), and the tradeoffs required to address user, system, and business requirements. Principles of Software Architecture The basic assumption with any architecture should be the belief that the design will evolve over time and that one cannot know everything one essential info up front. The design will generally need to evolve during the implementation stages of the application as one learn more, and as one checks the design against real world requirements. Keeping the above statement in mind, let's try to list down some of the Architectural principles: The machine should be built to change instead of building to last. Model the architecture to analyze and reduce risk. Use designs and visualizations as a communication and collaboration tool. The key engineering decisions should be identified and acted upon upfront. Designers should consider using an incremental and iterative approach to refining their architecture. Start with baseline architecture to get the big picture correct, and then evolve candidate architectures as one iteratively test and improve one's architecture. Do not try to get it all right the first time-design just as much as you

4. can in order to start testing the design against requirements and assumptions. Iteratively add details to the design across multiple passes to make sure that you get the big decisions right first, and then focus on the details. A common pitfall is to plunge into the details too quickly and get the big decisions wrong by making incorrect assumptions, or by failing to judge your architecture effectively. When testing your architecture, consider the following questions: What were the main assumptions that were produced while architecting the system? What are the requirements both explicit and implicit this architecture is satisfying? What are the key problems with this architectural approach? What countermeasures are in place to mitigate key risks? In what ways is this structures an improvement over the baseline or the last candidate architecture? Design Principles When getting started with Software design, one should keep in mind this proven principles and the principles that adheres to minimizes costs and maintenance requirements, and promotes usability plus extensibility. The key principles of any Software Design are: Separation of concerns: The key factor to be kept in mind can be minimization of interaction points between independent feature sets to achieve high cohesion and low coupling. Read More Single Duty principle: Each component or module should be independent in itself and responsible for only a specific feature or functionality. Process of Least Knowledge: A component or object should not know about internal details of other components or objects.

5. Don't perform repeatedly yourself (DRY): The intent or implementation of any feature or functionality should be done at only one position. It should never be repeated in some other component or module Minimize upfront design: This principle is also from time to time known as YAGNI ("You ain't gonna need it"). Design only what is necessary. Especially for agile development, one can stay away from big design upfront (BDUF). If the application requirements are unclear, or if there is a possibility of the design evolving after a while, one should avoid making a large design effort prematurely. Design Practices Keep design patterns consistent within each film. Do not duplicate functionality within an application. Prefer composition to inheritance. If possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of infant classes. This also reduces the inheritance hierarchies, which can become very difficult to deal with. Establish a coding style and naming custom for development. Maintain system quality using automated QA techniques during development. Use unit testing and other robotic Quality Analysis techniques, such as dependency analysis and static code analysis, during development Not only development, also look at the operation of your application. Determine what metrics and operational data are required by the IT infrastructure to ensure the efficient deployment as well as operation of your application. Application Layers: While architecting and designing the system, one needs to carefully consider the various clleular layers into which the application will be divided. There are some key considerations that need to be kept in mind while doing that:

6. Separate your areas of concern. Break your application into distinct features that overlap in functionality as little as possible. The main benefit of this approach is definitely that a feature or functionality can be optimized independently of other features or functionality Be explicit about how sheets communicate with each other. Abstraction should be used to implement loose coupling between layers. Do not mix different types of components in the exact same logical layer. For example , the UI layer should not contain business processing components, but instead should contain components useful to handle user input and process user requests. Keep the data format consistent within a layer or component. Ingredients, Modules, and Functions: Key Considerations In the previous sections we talked about key considerations that need to be kept in mind while architecting or designing an application. We also touched based on what needs to be kept in mind when we are dividing our application inside various layers. In this section let's take a look at some key considerations for designing component, modules and Functions. An element or an object should not rely on internal details of other components or objects. Never overload the functionality on the component. For example , a UI processing component should not contain data access code or attempt to provide additional purpose. Explicitly state how the components will communicate with each other. This requires an understanding of the deployment scenarios your application must support. You have got to determine if all components will run within the same process, or if communication across physical or approach boundaries must be supported-perhaps by implementing message-based interfaces.

7. Keep crosscutting code (such as logging and performance) abstracted from the application business logic as far as possible.