Please enable JavaScript.
Coggle requires JavaScript to display documents.
SOFTWARE ARCHITECTURE DESIGN ILLUMINATED - Coggle Diagram
SOFTWARE ARCHITECTURE DESIGN ILLUMINATED
Introduction to Software Architecture
Overview
The goal of software design is to build a model that meets all customer
requirements and leads to successful implementation
The success of a software
product or system largely depends on the success of its architecture design
Software Architecture: Bridging Requirements and
Implementation
The architecture design provides a blueprint and guideline
for developing a software system based on its requirement analysis specification
An architecture design serves as an evaluation and implementation plan for software development and software evolution
The most important job of a software architect is to map the Software
Requirements Specification to the software architecture design and guarantee that functional and nonfunctional requirements are met
Architecture Styles
An architecture style
contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
An architecture style is a viewpoint abstraction for a software
structure that is domain-independent
Quality Attributes
Quality attributes are identified in the requirement analysis process
Implementation attributes
Interoperability
Maintainability and extensibility
Testability
Portability
Scalability
Flexibility
Runtime attributes
Availability
Security
Performance
Usability
Reliability
Maintainability
Business attributes
Time to market
Cost
Lifetime
Typical quality attribute tradeoff pairs
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
Overview
A software architecture design is a set of software elements connected by a set of connectors
A good software architecture should be able to easily adapt to these changing environments without the need for major reengineering of corresponding software systems
Types of Software Structures
Software Static Structure
Managing static structures involves layers of abstraction and of refinement showing visibility and encapsulation, respectively
The software static structure refers to the organization of physical software modules and their interrelations and this structure plays a critical role in software architecture design
Software Runtime Structure
The connectors at this level inherit attributes from their source-code structure counterparts
Multiplicity
Distance and connection media
Universally invocable
Self-descriptive
Software Management Structure
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived
Software management structures are also used for project resource allocation
Software Elements
The elements of a software architecture are usually refined through multiple transformation steps based on their attributes and the project requirement specifications
Depending on each software element's assigned function, there may be different synchronization and performance constraints
Software Connectors
Based on the
implementation
type, a connector may be classified as
signature-based
or
protocol-based
Based on the connector's
synchronization
mode, we can classify all connectors into two categories:
blocking connectors
and
non-blocking connectors
Based on the connector's
initiator
, we can classify all connectors into two categories:
one-initiator connectors
and
two-initiator connectors
Connector active time
refers to when an operation request or message is sent over a connector
Connectors may be classified into
programmed connectors
and
event-driven connectors
Based on the
connector span
between incident elements, we classify the connectors as
local connectors
or
networked connectors
Based on
connector fan-out
we classify connectors as
1—1 connectors
and
1—* connectors
Based on
connector environment
, which is the implementation technology or supporting platforms of a connector's two incident elements, we classify connectors into
homogeneous connectors
and
heterogeneous connectors
An Agile Approach to Software Architecture Design
Models for Software Architecture
Overview
Box-and-line diagrams are often used to describe the business concepts and processes during the analysis phase of the software development lifecycle
The 4+1 view model is another way to show the functional and nonfunctional requirements of a software project
There are five views in the model: the logical view, the process view, the development view, the physical view, and the user interface view
UML for Software Architecture
UML is a typical object-oriented analysis and design notation tool that provides many useful analysis diagrams and even generates code skeleton
Structural (Static) Diagrams
Class Diagram
A class diagram is the interface of each class
Can be derived from use-case diagrams or from text analysis of the given problem domain
Describe each individual class with its type, interface, properties, and methods
Three main relationships among classes: inheritance, aggregation, and association
Object Diagram
Used to describe a sample subset of objects in the system at a specific point in time
Shows a snapshot of class instance connection and interaction
Many other
behavioral diagrams
(sequence diagrams, communication diagrams,...) may make reference to the object diagram
Composite Structure Diagram
Used to describe the composition of interconnected elements or the collaboration of runtime instances
Two basic notations:
collaboration
(dashed
eclipse
) and
structured class
(
rectangular
box)
Component Diagram
A component is a deployable, reusable building block used in software design and development
Each component has an interface to expose its services and hide its implementations
A lollipop shape
of a component represents an implemented interface and
A cup
shape
represents the required interface (provided by
some other components
)
Package Diagram
A package is represented by a tabbed folder that indicates where all included classes and subpackages reside
A package diagram shows the dependency relationship between packages in which a change of one package may result in changes in other packages
Deployment Diagram
This diagram is generated in the later phase of
the software development life cycle
The deployment diagram is used widely to model and design distributed software systems
Behavioral Diagrams
Use Case Diagram
Use case diagrams describe user requirements in terms of system functionality as a contract between the users (actors) and the software system
A complete use case diagram describes a set of scenarios
System analysts employ use case diagrams to capture and verify user requirements
Activity Diagram
Used to describe complex business processes
An activity diagram is a workflow-oriented diagram describing the steps in a single process
An activity diagram gives a detailed dynamic view of a specific task or process within a system so that the software developer can easily recognize the implementation requirements
State Machine Diagram
A state machine diagram, called a state chart in UML 1.x, is widely used for embedded systems and device software analysis and design
Each state machine diagram has one starting point in a solid black circle and has one or more endpoints, the latter indicated by eye-circles
Interaction Overview Diagram
An interaction overview diagram describes the control flow of the interactions rather than the message
Each node (or frame) can be an interaction diagram such as a sequence diagram, communication diagram, activity diagram, or nested interaction overview diagram
Sequence Diagram
One of the most important and widely used UML
diagrams for software system analysis and design
One sequence diagram corresponds to one use case
Communication or Collaboration Diagram
Is a message-oriented diagram that describes all message passing sequences, flow control, object coordination, etc., among the objects
that participate in certain use cases
Every communication diagram is equivalent to a sequence diagram, i.e., a communication diagram can be converted to an equivalent sequence diagram and vice versa
Timing Diagram
Combines the state diagram and time sequences to show the dynamic view of state change caused by external events over time
New diagram in UML 2.0
Architecture View Models
View models provide partial representations of the software architecture to specific stakeholders such as the system users, the analyst/designer, the developer/programmer, the system integrator, and the system engineer
The Scenario View
: describes the
scenarios that capture the most important aspects of the functional requirements, drive the system design, and validate the system
The 4+1 view model
: multiple-view model that addresses different aspects and concerns of the system
The Logical or Conceptual View
: based on application domain entities necessary to
implement the functional requirements
The Development or Module View
: The development view derives from the logical view and describes the static organization of the system modules
The Physical View
: describes installation, configuration, and deployment of
the software application
The User Interface View
: is an extended view that provides a clear usercomputer interface view and hides implementation details
Architecture Description Language (ADL)
An ADL is a notation specification providing syntax and semantics for
defining software architecture
Requirements
for an ADL
Composition
Abstraction
Reuse
Configuration
Heterogeneity
Analysis
Object-Oriented Paradigm
Overview
The popularity of the OO analysis and design paradigm is the logical result of the wide adoption of OO programming languages
Three main
OO principles
:
encapsulation
,
inheritance
, and
polymorphism
Encapsulation
: information hiding, separate interface from implementation
Inheritance
: define new classes that derive from existing base classes
Polymorphism
: refers to the ability of an object to behave differently and assume different forms based on its inheritance hierarchy
Introducing the Object-Oriented Paradigm
Classes and Objects
An object is an
instance of a class
A class defines the attributes and behaviors shared by all of its objects
Relationships
In the OO paradigm, the blueprint of a design usually is represented using a class diagram
Both dynamic and static descriptions
must be provided
Composition
: represents the whole/part relationship between classes
Aggregation
: A similar but more relaxed compositional relationship is called aggregation
Association
: represents the logical relationship among classes
Composition vs. Inheritance
Use the
inheritance relationship
only when the derived class "is-a" base class
Composition
(or aggregation) can be used to model the "has-a"
relationship among classes
OO Analysis
OO analysis, is concerned with initial domain and problem requirement analysis
Step 1
: Design of a UML Use Case Diagram
Step 2
: Develop an Analysis Class Diagram via Noun Extraction
OO Design
The goal of design is to develop the structural architecture of a system
Step 1
: Identify Classes—CRC Card
Step 2
: Construct an Interaction Diagram
Step 3
: Build a State Machine Diagram
Step 4
: Class Specification
Design Principles
Principle of Decoupling
: In an OO design, tight coupling may be removed by introducing new classes or inheritance
Ensuring Cohesion
: A cohesive class is one that performs a set of closely related operations
Open-Closed Principle
The principle encourages OO designers to practice two guildlines
Closed to modification
Open to extension
The open-closed principle has many interesting implications that also serve as the thumb of rules during OO design
Separate interface and implementation
Keep attributes private
Minimize the use of global variables