The architecture of a system describes its major components, their relationships (structures), and how they interact with each other. Software architecture and design includes several contributory factors such as Business strategy, quality attributes, human dynamics, design, and IT environment.
We can segregate Software Architecture and Design into two distinct phases: Software Architecture and Software Design. In Architecture, nonfunctional decisions are cast and separated by the functional requirements. In Design, functional requirements are accomplished.
Architectural design is a creative process so the process differs depending on the type of system being developed. However, a number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system:
Is there a generic application architecture that can be used?
How will the system be distributed?
What architectural styles are appropriate?
What approach will be used to structure the system?
How will the system be decomposed into modules?
What control strategy should be used?
How will the architectural design be evaluated?
How should the architecture be documented?
Systems in the same domain often have similar architectures that reflect domain concepts. Application product lines are built around a core architecture with variants that satisfy particular customer requirements. The architecture of a system may be designed around one of more architectural patterns/styles, which capture the essence of an architecture and can be instantiated in different ways.
The particular architectural style should depend on the non-functional system requirements:
Performance: localize critical operations and minimize communications. Use large rather than fine-grain components.
Security: use a layered architecture with critical assets in the inner layers.
Safety: localize safety-critical features in a small number of sub-systems.
Availability: include redundant components and mechanisms for fault tolerance.
Maintainability: use fine-grain, replaceable components.
Each architectural model only shows one view or perspective of the system. It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are distributed across a network. For both design and documentation, you usually need to present multiple views of the software architecture.
4+1 view model of software architecture:
A logical view, which shows the key abstractions in the system as objects or object classes.
A process view, which shows how, at run-time, the system is composed of interacting processes.
A development view, which shows how the software is decomposed for development.
A physical view, which shows the system hardware and how software components are distributed across the processors in the system.
Related using use cases or scenarios (+1).
Architectural patterns
Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of a good design practice, which has been tried and tested in different environments. Patterns should include information about when they are and when the are not useful. Patterns may be represented using tabular and graphical descriptions.
Application systems are designed to meet an organizational need. As businesses have much in common, their application systems also tend to have a common architecture that reflects the application requirements. A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements. application architectures can be used as a:
Starting point for architectural design.
Design checklist.
Way of organizing the work of the development team.
Means of assessing components for reuse.
Vocabulary for talking about application types.
Examples of application types:
Data processing applications
Data driven applications that process data in batches without explicit user intervention during the processing.
Transaction processing applications
Data-centred applications that process user requests and update information in a system database.
Event processing systems
Applications where system actions depend on interpreting events from the system's environment.
Language processing systems
Applications where the users' intentions are specified in a formal language that is processed and interpreted by the system.
