filmov
tv
Ch. 6 : Architectural Design, part 1, Architectural design decisions, and Architectural views
Показать описание
Subscribe to my channel
00:00 Introduction
2:15 Architectural design definition
3:59 Agility and architecture
4:55 Example: The architecture of a packing robot control system
6:52 Architectural abstraction
7:58 Advantages of explicit architecture
8:55 Architectural representations
9:44 Box and line diagrams
10:50 Architectural design decisions
26:57 Architectural Views
Architectural design
Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system.
Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them.
The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.
Architectural design decisions
Architectural design is a creative process so the process differs depending on the type of system being developed.
However, a number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system.
Chapter 6
Architectural Design covers the fundamental concepts and decisions involved in designing a software system's architecture. This chapter typically introduces the process of defining the high-level structure of a software system and how different components and subsystems interact with one another. Let's break down the key topics:
1. Architectural Design Decisions
Architectural design decisions are critical as they determine the overall structure and behavior of the system. These decisions involve choosing among different design alternatives, considering the system's functional and non-functional requirements, and selecting the appropriate architectural patterns and styles.
2. Architectural Views
Architectural views are used to describe the different aspects of the system's architecture. Each view addresses specific concerns of different stakeholders, such as developers, system administrators, or end-users.
Architectural Views:
- Logical View: Focuses on the functionality that the system provides to end-users. It describes the system in terms of its components and their relationships.
- Development View: Focuses on the organization of the software modules. It helps developers understand how the system is structured and where to make changes.
- Process View: Focuses on the dynamic aspects of the system, such as its runtime behavior, processes, and communication between components.
- Physical View: Focuses on the physical deployment of the system, showing how software components are mapped to hardware nodes.
4+1 View Model: A well-known framework for architectural views introduced by Philippe Kruchten, which includes:
1. Logical View: Captures the logical (or conceptual) structure.
2. Development View: captures the static organization of the software in the development environment.
3. Process View: Captures the dynamic aspects of the system.
4. Physical View Captures the hardware aspects and how software is distributed.
5. Scenarios (Use Cases): Used to describe how the architecture supports specific use cases or requirements.
Architectural views
What views or perspectives are useful when designing and documenting a system’s architecture?
What notations should be used for describing architectural models?
Each architectural model only shows one view or perspective of the system.
It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are distributed across a network. For both design and documentation, you usually need to present multiple views of the software architecture.
A logical view, which shows the key abstractions in the system as objects or object classes.
A process view, which shows how, at run-time, the system is composed of interacting processes.
A development view, which shows how the software is decomposed for development.
A physical view, which shows the system hardware and how software components are distributed across the processors in the system.
Related using use cases or scenarios (+1)
00:00 Introduction
2:15 Architectural design definition
3:59 Agility and architecture
4:55 Example: The architecture of a packing robot control system
6:52 Architectural abstraction
7:58 Advantages of explicit architecture
8:55 Architectural representations
9:44 Box and line diagrams
10:50 Architectural design decisions
26:57 Architectural Views
Architectural design
Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system.
Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them.
The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.
Architectural design decisions
Architectural design is a creative process so the process differs depending on the type of system being developed.
However, a number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system.
Chapter 6
Architectural Design covers the fundamental concepts and decisions involved in designing a software system's architecture. This chapter typically introduces the process of defining the high-level structure of a software system and how different components and subsystems interact with one another. Let's break down the key topics:
1. Architectural Design Decisions
Architectural design decisions are critical as they determine the overall structure and behavior of the system. These decisions involve choosing among different design alternatives, considering the system's functional and non-functional requirements, and selecting the appropriate architectural patterns and styles.
2. Architectural Views
Architectural views are used to describe the different aspects of the system's architecture. Each view addresses specific concerns of different stakeholders, such as developers, system administrators, or end-users.
Architectural Views:
- Logical View: Focuses on the functionality that the system provides to end-users. It describes the system in terms of its components and their relationships.
- Development View: Focuses on the organization of the software modules. It helps developers understand how the system is structured and where to make changes.
- Process View: Focuses on the dynamic aspects of the system, such as its runtime behavior, processes, and communication between components.
- Physical View: Focuses on the physical deployment of the system, showing how software components are mapped to hardware nodes.
4+1 View Model: A well-known framework for architectural views introduced by Philippe Kruchten, which includes:
1. Logical View: Captures the logical (or conceptual) structure.
2. Development View: captures the static organization of the software in the development environment.
3. Process View: Captures the dynamic aspects of the system.
4. Physical View Captures the hardware aspects and how software is distributed.
5. Scenarios (Use Cases): Used to describe how the architecture supports specific use cases or requirements.
Architectural views
What views or perspectives are useful when designing and documenting a system’s architecture?
What notations should be used for describing architectural models?
Each architectural model only shows one view or perspective of the system.
It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are distributed across a network. For both design and documentation, you usually need to present multiple views of the software architecture.
A logical view, which shows the key abstractions in the system as objects or object classes.
A process view, which shows how, at run-time, the system is composed of interacting processes.
A development view, which shows how the software is decomposed for development.
A physical view, which shows the system hardware and how software components are distributed across the processors in the system.
Related using use cases or scenarios (+1)
0:45:32
0:10:39
0:35:43
2:20:26
0:10:40
0:37:21
0:30:23
0:05:11
0:00:16
0:31:37
0:04:15
0:06:31
0:00:06
0:05:46
0:07:37
1:00:05
0:45:13
0:18:35
0:06:25
0:05:14
0:19:27
0:00:12
0:16:51
0:00:20