Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture Design - Coggle Diagram
Software Architecture Design
2.2 Types of Software Structures
Software architecture in multiple perspectives
Static Structure
Run-time Structure
Management structure (or Deployment structure)
2.2.1.Software Static Structure
A software project is typically implemented in multiple files . This includes
Binary software component modules
DLL
JavaBeans
Deployment descriptors
Library files
Others resources files
Executable files
At software development time
The connectors at this level are in the form of module dependency
API defined for modules separates module’s interface and implementation
Each modules has assigned functional and nonfunctional attributes
The main software elements are source code files
Static connectors may exhibit some attributes
Synchronization
Sequence
Direction
Managing Static Structural Representations
The software static structure
refers to the organization of physical software modules and their interrelations
This structure play a critical roles in software architecture design.
Managing static structures involves layers of
Abstraction for encapsulation
Refinement showing visibility
Two kinds of static hierarchical relations
A linear client-server relation
A tree-like hierarchy of refinement relations
2.2.2 Software Runtime Structure
A runtime project consists of elements
Threads
Web services
Processes
Distributed objects
These elements may run on the same computer or on multiple computers across a network.
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.
The same element in a code structure can implement or support multiple runtime elements
Several code structure elements may implement or support a single runtime element
2.2.3.Software Management Structure
A large software project is normally designed and implemented by several project teams, each having its well-defined responsibilities at specific SDLC process stages
At this level, each element consists of manipulation of specific code units assigned to each project team, and the connectors are derived from runtime dependency among the code units and software process dependencies.
2.1.Overview
A software architect’s responsibility
Proposing a concrete architecture that best supports the detailed design and implementation of a specific project.
Software architect must understand the software architecture's design space
Design alternatives that can support functional and non-functional requirement specifications
Based on quality attributes
Make the decision by balancing on quality attributes.
2.3.Software elements
At runtime, element is a self-contained component of a system
Has well-defined functions
Implementation can change with the time
Usually interface is public and fixed
Connected with each other via connector
Rule 1: Reentrant
A programmer writes a reentrant program by making sure that no instruction modify the contents of variable values in other instructions within the program.
Commonly required in
operating systems and in applications intended to be shared in multi-use systems.
describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users.
Rule 2: Handle Bottle-Neck First
Treat bottle-neck functionality using the following approaches
(2) Improving its efficiency by replication
(3) Depending on computing needs, allocate cluster or multi-CPU computers for bottle-neck modules in deployment
(1) Wrap it as a separate and highly independent module
Rule 3: Make Things Simple
If a module is too large
Split it into smaller ones
Vertical Layers
Horizontal Layers
2.4.Software Connector
Should be refined within the design process.
Connector refinement is heavily influenced by a project’s deployment environment
Connects the modules of a system
Usually determines the quality attributes of a system
Reliability
Availability
Efficiency
Security
Can be classified into many categories
Connector type – Based on Synchronization
Blocking
A blocking connector allows one of its incident elements to send a request to another and wait for a response.
Non-blocking
A non-blocking connector allows one of its incident elements to send a request to another and continues its execution without waiting for a response.
Connector type – initiator
One Initiator
Two Initiator
Information Carrier
Environment resource
Method
Variable
Message
Connector Implementation type
Signature based
Protocol based
Homogeneous vs. Heterogeneous
Homogeneous:
both elements must be on the same platform
Heterogeneous:
both elements can be on different platforms.
2.5.Agile Design
Traditional Water-Fall Approach
Big gap between
Requirement specification
Software Architecture
Iterative Refinement
Refine designs based on changing requirement