Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture and Design - Coggle Diagram
Software Architecture and Design
Introduction to Software Architecture
Overview
Who is responsible for developing the architecture design?
Software architects
Designers
Why is software architecture design so important?
Poor design
Not reusable
Not meet system requirements
not adaptive to future requirement changes
What is the architecture design?
Defines the relationship between major structural elements of the software, the styles and design
patterns that can be used to achieve the requirements defined for the system
the constraints that affect the way in which architecture can be implemented
When is software design conducted?
Software Development Life Cycle (SDLC)
Software requirements analysis
Software design (architecture and detailed)
Software development and implementation
Testing and quality assurance, maintenance, and evolution
What is the outcome of the software architecture design?
Software Design Descriptions (SDD)
Software Architecture: Bridging Requirements and
Implementation
An architecture design must cover
The software's functional
Specifies the functionality of the software system
Nonfunctional requirements
Specifies system qualities, constraints, and behaviors
What is software architecture?
Definitions of GarIan and Shaw (1996)
The description of elements that comprise a system, the interactions and patterns of these elements, the principles that guide their composition, and the constraints on these elements
Definitions of IEEE
The fundamental organization of a system embodied in its elements, their relationships to each other, and to the environment, and the principles guiding its design and evolution
Results of requirements analysis can help software designers better understand the
software requirements
Unified Modeling Language (UML)
Data Flow Diagrams (DFD)
State Transition Diagrams (STD)
Use-case specifications
Software architect's tasks
Perform static partition and decomposition of a system into subsystems and communications among subsystems.
Consider and evaluate alternative architecture styles
Perform tradeoff analysis on quality attributes and other nonfunctional requirements during the selection of architecture styles
Establish dynamic control
Architecture Styles
What is architecture style ?
(also known as an "architecture pattern") Abstracts
the common properties of a family of similar designs
Contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
It governs runtime interaction of flow control and data transfer
Key components of an architecture style
Connectors that enable communication, coordination, and cooperation among elements
Constraints that define how elements can be integrated to form the system
Elements that perform functions required by a system
Attributes that describe the advantages and disadvantages of the chosen structure
Why are architecture styles so important?
Having a set of quality attributes that it promotes
Can verify whether the architecture is consistent with the requirement specifications
Quality Attributes
Implementation attributes (not observable at runtime)
Interoperability
The ability to exchange data among internal components and with the outside world
Maintainability and extensibility
Modify the system and conveniently extend it
Testability
Whether the system allows easy debugging
Portability
Can the system be deployed on different platforms
Scalability
A system's ability to adapt to an increase in user requests
Flexibility
The ease of system modification to cater to different environments
Runtime attributes (observable at runtime)
Availability
A system's capability to be available 24/7
Security
A system's ability to cope with malicious attacks from outside or inside the system
Performance
Increasing a systems efficiency with regard to response time
Usability
Completeness, correctness, compatibility and user friendliness
Reliability
The ability to recover from failure, and the failure
predictability
Maintainability
Extensibility, adaptability, serviceability, testability,
compatibility, and configurability
Business attributes
Time to market
The time it takes from requirements analysis to
the date a product is released
Cost
The expense of building, maintaining, and operating the system
Lifetime
The period of time that the product is "alive" before
retirement
Quality attribute tradeoff
Tradeoff between space and time
Tradeoff between reliability and performance
Tradeoff between scalability and performance
Software Architecture Design Guidelines
Think of what to do before thinking of how to do it
Think of abstract design before thinking of concrete design
Think of nonfunctional requirements early in the design process
Think of software reusability and extensibility as much as possible
Try to promote high cohesion within each element and loose coupling between elements
Tolerate refinement of design
Avoid ambiguous design and over-detailed design
Software Architecture Design Space