Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture Model - Coggle Diagram
Software Architecture Model
Overview
Specifies a high-level of abstraction of a software system
Must describe the collection of software components and the connections and interactions between these components
Specifies the deployment configuration of all components and connections
Must conform to the functional and non-functional requirements of the software project
Can be described the software architecture formally or informally in many ways
Box-and-line diagrams
Describes the business concepts and processes during the analysis phase of the software development life cycle
Will be used throughout this book for specification purposes
Comes with descriptions of components and connectors, accompanied by other descriptions that provide common intuitive interpretations
The dynamic software architecture describes the behavior of objects (i.e., instances of classes) in the system such as object collaboration, interaction, activity, and concurrency
Model
Logical View/Conceptual View
Identifies software modules and their boundaries, interfaces, external environment, usage scenarios, etc
Process View
Addresses non-functional requirements such as module communication styles and performance issues at runtime
Development View/Module View
Organizes the software units in well-defined ways according to the actual file or directory structure
Physical View
Specifies the deployment infrastructure in terms of software, hardware, and networking configurations, installation, and deployment for delivery purposes
UI View/Scenario View
Describes the graphical interface to verify and validate the user interface requirements; these have significant impact on the system usability and other quality attributes for end user
Unified Modeling Language (UML)
Is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system
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
A typical OO analysis and design notational tool provides diagrams that can be used to map requirement specifications to architectural designs and from these to coding
Two major categories
Structural (static) diagrams
Class
Describes each individual class with its type, interface, properties, and methods
Object
Describes a sample subset of objects in the system
Composite Structure
Describes the composition of interconnected elements or the collaboration of runtime instances
Component
Is a deployable reusable building block for software design and development
Package
Is represented by a tabbed folder that indicates where all included classes and sub packages reside
Deployment
Depicts the physical configuration of the software system deployed on hardware server nodes and the network between the nodes
Behavioral (dynamic) diagrams
Use case
Describes user requirements in terms of system functionality (use cases) as a contract between the user (actors) and the software system
Activity
Describes complex business processes; they typically involve complex workflow, decision making, concurrent executions, exception handling, process termination, etc
State Machine
Is used for embedded systems and device software analysis and design
Sequence
Is a time-oriented interaction diagram showing the chronological sequence of messages between objects
Interaction Overview
Describes the control flow of the interactions rather than message
Communication
Describes ALL message passing sequence, flow control, object coordination, etc, between the objects that participate in certain use case
Timing
It combines the state diagram and time sequences to show the dynamic view of state change caused by external events over time
The related UML diagrams are sequence diagram, collaboration diagram, activity diagram, etc
Summary
View
Is an architecture verification technique for studying and documenting software architectural design.
Each view provides a window for the different aspects
Covers all aspects of a software architecture for all stakeholders
Views are interconnected; thus, based on the scenarios view, we can start with logical view, and then move to development or process view and, finally go to physical view
UI view is also established during this process