Please enable JavaScript.
Coggle requires JavaScript to display documents.
Introductions to Software Architecture Design - Coggle Diagram
Introductions to Software Architecture Design
Briding Requirements and Implementation
Software architecture plays a very important role in the SDLC. The architecture design provides a blueprint and guideline for developing a software system based on its requirement analysis specification
Software architecture specification must describe the elements and connectors between elements and the constraints and runtime behaviors
Map the SRS to the software architecture design and guarantee that functional and nonfunctional requirements are met
Software Architecture Design
Software Architecture
Design Space
Overview
Software architecture design is a set of software elements connected by a set of connectors
Software element can be a package, a class,
a component, or a loadable library
Types of Software Structures
Software Static Structure
Software project is implemented in static file types: executable files; library files; binary software component modules; deployment descriptors; and other resource files
At software development time, the main software elements are source code modules or files
Connectors may exhibit attributes
Synchronization
Sequence
Direction
Java units declared inside other units yield a tree-like hierarchy. Furthermore importing separately compiled units defines a linear partial ordering which, when combined with the tree structure of subunits, defines the software static structure
Software Runtime Structure
At runtime a project consists of one or more threads, processes, functional units, and data units
These elements run on the same computer or on
multiple computers across a network. The same element in a code structure may implement or support multiple runtime elements
The connectors' attributes
Multiplicity
Distance and connection media
Universally invocable
Self-descriptive
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived
Software Elements
Software element has well-defined functions and connects to the other elements into a dependency graph through connectors
Basic guidelines for mapping runtime elements into
their implementations
If the elements contain heavy computations for deployment at a particular location, a cluster of processors will enhance CPU data processing power
If an element is assigned complex but well-defined functions, similar to those of some commercial off-the-shelf software components, and the performance of this element is not critical, then it is more cost-effective to use an existing software component to implement the element's functions
If an element has high multiplicity and its performance is important to the global system performance, an application server should be used for the element's implementation so that it can take advantage of thread and resource pooling, data caching, and dynamic element life cycle management to conserve resources
A complex element can be expanded into a subsystem with its own elements and connectors. A well-defined interface should be used to encapsulate the subsystem's design and implementation details from the existing architecture
If an element is not reentrant and multiple threads or processes need to communicate with it, it must be run on separate threads or processes in order to be thread-safe
A complex element can be transformed into a sequence of vertical layered elements if each layer provides a virtual machine or interface to its immediate upper-layer element, and each layered element hides away some low-level system details from the upper layers
A complex element can be transformed into a sequence of horizontally tiered elements if the business logic can be achieved by processing data with a sequence of discrete processing stages, and these processing stages can be implemented by tiered elements with well-defined interfaces and balanced workloads
Software Connectors
The connectors in a software architecture are refined during the design process and are heavily influenced by a project's deployment environment
Connector indicates the necessity during system execution for one of the elements to send a message to another element and potentially get a return message
Classified according to many attributes, including synchronization mode, initiator, implementation type, active time span, fan-out, information carrier, and environment
Agile Approach
Traditional software architecture designs do not emphasize the iterative refinement nature and do not use element and connector attributes to capture the key architecture requirements of a software project, so there is big gap between a project's requirement specification and a concrete software architecture for its detailed design and implementation
Another weak point of traditional architecture design is that if the deployment environment changes, which is happening more often with the economy's globalization, the architecture design must start from scratch
Agile approach maximizes the reuse of architecture, design, and implementation investments
This abstract software architecture will generally be free of deployment considerations, then go through multiple refinement processes to support particular deployment constraints
Models for Software Architecture
Overview
Software architecture must describe its collection of components and the connections, interactions among these components and specify the deployment configuration of all components and connections
Software architecture design must conform to the project's functional and nonfunctional requirements
A box-and-line diagram can be used as a business concept diagram describing its application domain and process concepts
UML for Software Architecture
Unified Modeling Language is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a
software-intensive system
UML offers a standard way to draw a system's blueprints including conceptual notions such as business processes and system functions as well as concrete designs such as programming language statements, database schemas, and reusable software components
UML is widely used as a guideline for software requirement analysis and design documents, which are the basis for software development
UML provides several modeling diagrams that can be grouped into two major categories: structural (static) and behavioral (dynamic)
Class Diagram
Class diagram provides a static view of the system, captures the vocabulary of the designed system
Class diagrams describe each individual class with its type, interface, properties, methods and accessibility (visibility) of each attribute and operation
Object Diagram
Object diagram is used to describe a sample subset of objects in the system at a specific point in time
This diagram shows a snapshot of class instance connection and interaction
Composite Structure Diagram
Composite structure diagram is used to describe the composition of interconnected elements or the collaboration of runtime instances
Two basic notations in a composite structure diagram: collaboration and structured class
Component Diagram
Component is neither a class nor an object
Component is a deployable, reusable building block used in software design and development
In a component diagram, some of the components may exist and be available in-house or on the market. Other components are designed and developed by those working on the project
Package Diagram
Package is represented by a tabbed folder that indicates where all included classes and subpackages reside
Package diagram shows the dependency relationship between packages in which a change of one package may result in changes in other packages
Package diagram is often used for component-based software architecture design
Deployment Diagram
Deployment diagram depicts the physical configuration of the software system deployed on hardware server nodes and the network between the nodes
This diagram is generated in the later phase of
the software development life cycle
Behavior 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
Use case diagram describes a set of scenarios; scenarios may have a set of subordinate, or lower-level, use cases
Use case diagrams are used in the early stages of the software development life cycle, such as analysis and design
Use case diagram is one of the most frequently used
UML diagrams for object-oriented system analysis and design
Activity Diagram
Activity diagram is used to describe complex business processes, typically involves complex workflow, decision making, concurrent executions, exception handling, process termination
Activity diagram is a workflow-oriented diagram describing the steps in a single process. One activity diagram corresponds to one business process. There are many activities in a business process, and this diagram explores their dependency within the process
State Machine Diagram
State machine diagram is widely used for embedded systems and device software analysis and design
It is an eventoriented diagram in which the system's elements change their states in response to external or internal stimuli
State machine diagrams are ideal for specifying the internal behavior of objects
Interaction Overview Diagram
Interaction overview diagram describes the control flow of the interactions rather than the message, a variant of the activity diagram
Sequence Diagram
Sequence diagram is one of the most important and widely used UML diagrams for software system analysis and design
It is a time-oriented interaction diagram showing the chronological sequence of messages between objects
Communication or Collaboration Diagram
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
It summarizes how objects in the system receive and send messages. It is an extension of the static object diagram in which the links between objects represent association relationships
Timing Diagram
Timing diagram is a new diagram in UML 2.0
It combines the state diagram and time sequences to show the dynamic view of state change caused by external events over time
Timing diagram is often used in time-critical systems
such as real-time operating systems, embedded system designs, etc
Architecture View Models
A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view that can present all aspects of complex software to stakeholders
The Scenario View
Scenario view describes the functionality of the system, i.e., how the user employs the system and how the system provides services to the users
It helps designers to discover architecture elements during the design process and to validate the architecture design afterward
Scenario view helps to make the software architecture consistent with functional and nonfunctional equirement
Scenario view is used to drive architecture design in the earlier phases of software development and is also used for software validation at later phases of the development cycle
The Logical or Conceptual View
Logical view is based on application domain entities necessary to implement the functional requirements, focuses on functional requirements, the main building blocks, and key abstractions of the system
The logical view is an abstraction of the system's functional requirements, and is typically used for object-oriented (OO) modeling from which the static and dynamic system structures emerge
The logical view is typically supported by UML static diagrams including class/object diagrams and UML dynamic diagrams such as the interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram
The Development or Module View
Development view derives from the logical view and describes the static organization of the system modules
The development view maps software component elements to actual physical directories and files
The Process View
Process view focuses on the dynamic aspects of the system, i.e., its execution time behavior, derives from the logical view
Process view looks at the system's processes and the communications among them
Process view takes care of the concurrency and synchronization issues between subsystems, can be described at several levels of abstraction, from independently executing logical networks of communicating programs to basic tasks running within the same processing node
The stakeholders of this view are the developers and integrators
The Physical View
Physical view describes installation, configuration, and deployment of the software application, concerns itself with how to deliver the deployable system.
The physical view shows the mapping of software onto hardware. It is particularly of interest in distributed or parallel systems
Physical view takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), throughput performance, scalability performance, and security
This view explains the nonfunctional requirements and quality attributes such as performance, availability, reliability, and scalability. The physical view must address network connections and communication protocols such as server nodes and multi-tier distributed environment configurations
The stakeholders of this view are system installers, system administrators, system
engineers, and operators
The User Interface View
The User Interface view is an extended view that provides a clear usercomputer interface view and hides implementation details, often provided as a series of screen snapshots or a dynamic, interactive prototype demo
Architecture Description Language
Architecture Description Language is a notation specification providing syntax and semantics for defining software architecture, and provides designers with the ability to decompose components, combine components, and define interfaces of components
An ADL is a formal specification language with well-defined syntax and semantics used to describe architecture components and their connections, interfaces, and configurations
Object-Oriented Paradigm
Overview
OO software engineering refers to the whole process of analysis, design, and programming following the object-oriented paradigm
Three main OO principles
Inheritance
Polymorphism
Encapsulation
Object-Oriented Paradigm
Classes and Objects
A class groups together related data and their operations
A class defines the attributes and behaviors shared by all
of its objects
An object is an
instance of a class
Relationships
Composition
Composition represents the whole/part relationship between classes
the parts of a class have the same lifespan as their owner, and the parts cannot be involved in another composition
Aggregation
Aggregation is a similar but more relaxed compositional relationship
Parts involved in an aggregation relationship do not have to share thesame lifespan as the owner
Association
Association represents the logical relationship among classes. Composition is one specific type of association
Inheritance
To prevent repeatedly writing the same code for
similar classes, OO provides the inheritance mechanism
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
Be careful when using inheritance as it could weaken the encapsulation of an OO design
OO Analysis
An OO development process has three stages
Design
Responsibilities are assigned to each class that constitutes the system
The attributes and operations of
each class also are determined in this stage
Implementation
OO design is implemented using an OO programming language
Analysis
Concerned with initial domain and problem requirement analysis
Establishes an object-oriented abstract model of the system to be built
Step 1 Design of a UML Use Case Diagram
A use case diagram consists of multiple actors and use cases
Actor is a role played by a user—a user might be a real person, an organization, a computer system, or a component of the whole software system
A use case may be a concrete use case or an abstract one, is composed of other use cases, and can be extended by other use cases
Step 2 Develop an Analysis Class Diagram via Noun Extraction
An analysis class diagram describes the key classes of a system and their interrelationships but is not the design of the system
An analysis class diagram describes the functionality of the system in terms of abstractions (classes) of the concepts found in the problem and the domain
It captures the functionalities and logical relationships among the different elements of the system. It is a model of the system, abstracting design details so that people can better understand the system's overall architecture
In the design stage, the class diagram will be further refined; the relationships among the classes might be changed or fine-tuned to trade for speed, economy, or other system requirements
OO Design
The goal of design is to develop the structural architecture of a system
Step 1: Identify Classes—CRC Card
CRC card modeling is a team-based approach
In CRC modeling, a responsibility of a class is a task that must be performedby the class or the knowledge that is known by the class
Step 2: Construct an Interaction Diagram
Based on the design of CRC cards, you can now construct the interactiondiagram for each use case
An interaction diagram describes how the objects that compose the system interact with one another to accomplish a use case
Step 3: Build a State Machine Diagram
When the analysis class diagram, interaction diagrams for each use case, and CRC card designs are completed, you can proceed to the detailed level design
The objective of the detailed level design is to specify the interface of each class and make decisions about implementation
The outcome of the detailed design process is a detailed class design diagram, where for each class a list of attributes and operations are listed
Step 4: Class Specification
The first step in a detailed class specification is to identify the public interface of the class. While the implementation of a class can change over the time, the public interface is nailed down after the design phase
By examining the class's responsibilities and interaction diagram, you can list the attributes and operations that must be declared in the class
Design Principles
The design process does not simply identify one solution for a problem and then furnish the solution's details, but identify several alternative design solutions and select the one that fits the project requirements best
Principle of Decoupling
A system with a set of highly interdependent classes is very hard to maintain because a change in one class may result in cascading updates of other classes
In an OO design, tight coupling may be removed by introducing new classes or inheritance
Ensuring Cohesion
While coupling involves two or more classes, cohesion is about the design of a single class
Although lack of cohesion does not affect the functionality of the whole system, it makes the overall structure of the software hard to manage, expand, maintain, and modify
As operations of a less-cohesive system are not logically grouped together, any modification over the existing design may involve more than the necessary classes
Open-Closed Principle
Two pratice guidelines to OO designers
Open to extension: the system should have the ability to be extended to meet new requirements
Closed to modification: the existing implementation and code of
the system should not be modified as a result of system expansion
Thumb of rules during OO design
Separate interface and implementation
Keep attributes private
Minimize the use of global variables
Architecture Styles
Contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
Key Components
Elements that perform functions required by a system
Connectors that enable communication, coordination, and cooperation among elements
Constraints that define how elements can be integrated to form the system
Attributes that describe the advantages and disadvantages of the chosen structure
Importance
Each architecture style has a set of
quality attributes that it promotes
By identifying the styles, we can verify whether the architecture is consistent with the requirement specifications, and identify which tactics we
can use to better implement the architecture
Quality Attributes
Implementation attributes
Maintainability and extensibility
Testability
Interoperability
Portability
Scalability
Flexibility
Runtime attributes
Performance
Usability
Security
Maintainability
Availability
Reliability
Business attributes
Cost
Lifetime
Time to market
Tradeoffs
Reliability and performance
Scalability and performance
Space and time
Guidelines
Think of abstract design before thinking of concrete design
Think of nonfunctional requirements early in the design process
Think of what to do before thinking of how to do it
Think of software reusability and extensibility as much as possible
Try to promote high cohesion within each element and loose coupling between elements
Avoid ambiguous design and over-detailed design
Tolerate refinement of design
Overview
Definition
Architecture design: the relationship between major structural elements of the software, the styles and design patterns, and constraints which affect the implementation of the architecture
Software design: build a model that meets all customer requirements and leads to successful implementation
Importance
Poor design: deficient product that does not meet system requirements not adaptive to future requirement changes, is not reusable, exhibits unpredictable behavior, or performs badly
Good design: reduces the risks associated with software production, helps development teams coordinate better, makes the system traceable for implementation and testing, and results in a product that have higher quality attributes.
When
Software design is an early phase of
the Software Development Life Cycle
During which, software designers model the system and assess its quality so improvements may be made before the software goes into the production phase
SDLC consists of: software requirements analysis; software design (architecture and detailed); software development and implementation; and testing and quality assurance, maintenance, and evolution
Outcome
An overall representation of the software to be built
Serves as the blueprint for the implementation phase
Describes the elements of a system, the modules that compose each element, and the detailed information of each module