Wondershare EdrawMind
MindMap Gallery Chapter 4 Design Engineering Mind Map
- 29
Chapter 4 Design Engineering Mind Map
Chapter 4 Design Engineering Mind Map. This mind map includes an overview of software design engineering, software design principles, software architecture design, component-level design technology, design specifications and design review. It is used for review and preview.
Edited at 2023-11-14 21:39:57
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
Chapter 4 Design Engineering Mind Map
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
- Recommended to you
- Outline
Chapter 4 Design Project
Software Design Engineering Overview
Software Design Engineering Overview
Software requirements analysis solves the problem of "what to do", while the software design process solves the problem of "how to do it"
Software design is the process of transforming software requirements into software representation. It mainly consists of two stages: software architecture design stage and component-level design.
Software design tasks
Using a design approach, information about the software requirements represented by data, functional and behavioral models in the software analysis model is passed to the design phase, resulting in data/class design, architecture design, interface design, component level design
Data/class design: Transform the analysis-class model into class implementation and data structures required for software implementation
The detailed data content described in the classes and data objects and relationships defined in the CRC and the data dictionary provide the basis for data design activities.
The data design process includes the following two steps:
First, selecting a logical representation for the data objects determined in the requirements analysis phase requires algorithmic analysis of different structures in order to select the most effective design solution;
Then, identify the program modules that operate on the logical data structures necessary to limit or scope the impact of individual data design decisions.
Architectural Design: Architectural design defines the overall structure of the software
Architectural design defines the overall structure of the software, which consists of software components, externally visible attributes, and the relationships between them.
Architectural design representations can be derived from system specifications, analysis models, and interactions of subsystems defined in the analysis model.
Interface design: Interface design describes how to communicate within the software, between the software and collaborative systems, and between software colleagues.
Interface design mainly includes three aspects:
Design interfaces between software modules
Design interfaces between modules and other non-human information producers and consumers (such as external entities)
The interface between designer (user) and computer
Component-level design: Component-level design transforms the structural elements of the software architecture into a procedural description of the software components.
Component-level design transforms the structural elements of the software architecture into procedural descriptions of software components.
The information obtained from class-based models, flow models, and behavioral models is the basis for component design.
Software design goals
In the process of software design, we must pay close attention to the quality factors of the software.
The goals of the McGlanghlin software design process are:
1) The design must implement all explicit requirements described in the analysis model and must meet all implicit requirements expected by the user.
2) The design must be readable and understandable, making it easy to program, test, and maintain in the future.
3) The design should start from the implementation perspective and give a complete picture of the software related to data, functions, and behaviors.
Technical standards for measuring design
1) The designed structure should be a hierarchical structure to establish control between software components.
2) The design should be modular, logically dividing the software into components that complete specific functions or sub-functions.
3) The design should include both data abstraction and process abstraction.
4) The design should establish modules with independent functional characteristics.
5) The design should establish interfaces that reduce the complex connections between the module and the external environment.
6) The design should be able to establish a driveable and repeatable method based on the information obtained from software requirements analysis.
software design process
1) Develop specifications
2) Architecture and interface design
3) Data/class design
4) Component level (process) design
5) Write design documents
6) Design review
software design principles
Abstraction and gradual refinement
Abstraction is a basic strategy for controlling complexity as the scale of software design gradually increases.
The process of abstraction is from the specific to the general. The upper-level concept is the abstraction of the lower-level concept, and the lower-level concept is the refinement and refinement of the upper-level concept.
Each step in the software engineering process is a concrete description of the interpretation of a higher level of abstraction.
The main abstraction methods in software design are: process abstraction and data abstraction
Process abstraction (also called functional abstraction) means that any operation that completes a clearly defined function can be treated as a single entity by the user, although this operation is actually completed by a series of lower-level operations
Data abstraction refers to the definition of data types and operations applied to objects of this type, and limits the value range of objects. Data can only be modified and observed through these operations.
Gradually seek refinement
Step by step refinement, breaking down the problem-solving process into several steps or stages, with each step being more refined and closer to the solution to the problem than the previous step.
Abstraction enables designers to describe processes and data while ignoring low-level details, while refinement helps designers reveal low-level details during the design process.
Modular
Modularization, that is, dividing software into smaller, independent but interrelated components according to prescribed principles, is actually a process of system decomposition and abstraction.
A module is a collection of program objects such as data descriptions and executable statements. It is individually named and can be accessed by name.
For example, process. Functions, subroutines, macros, etc.
information hiding
The implementation details of each module should be hidden from other modules
The information (including data and procedures) contained in the block is not allowed to be used by other modules that do not need this information.
Through information hiding, access restrictions on the process details and local data structures of the module can be defined and enforced.
Functionally independent
Functional independence: Functional independence is a direct result of concepts such as modularity, abstraction, information hiding, and localization. Functional independence can be achieved by developing modules that are functionally specific and avoid excessive interactions with other modules.
The importance of functional independence
Functionality is separated and interfaces are simplified making software easier to develop
Since the side effects caused by modifying the design or modifying the coding are limited, the spread of errors is reduced, and module reuse becomes possible, thus making the software easier to maintain and test.
Functional independence can be measured by two indicators: cohesion and coupling
Cohesion is a measure of how closely the elements within a module are integrated with each other.
General module cohesion is divided into seven types
1) Coincidental cohesion (accidental cohesion): A module that separates the same program code segments that do not clearly exhibit independent functions in several modules is called a coincidental cohesion module.
2) Logical cohesion: refers to a module that completes a set of logically related tasks. When the module is called, the control parameters passed to the module determine which function the module should perform.
3) Time convergence: means that all tasks in a module must be executed within the same time period. For example, initialization module and termination module
4) Process cohesion: refers to a module completing multiple tasks, and these tasks must be executed according to a specified procedure (procedural)
5) Communication cohesion: means that all processing elements in a module are concentrated in an area of a certain data structure
6) Sequential cohesion: refers to a module completing multiple functions, and these functions must be executed sequentially
7) Functional cohesion: refers to the fact that all parts of a module work together to complete a specific function, are closely related, and are indivisible
Coupling is a measure of the relative independence between modules (how closely they are connected to each other)
Generally, there are seven types of possible coupling methods between modules.
1) Content coupling: If one module directly accesses the internal data of another module; or one module does not go to the other module through the normal entrance; or the two modules have a part of the program code overlap; or one module has multiple entrances, Then content coupling occurs between the two modules.
2) Public coupling: If a group of modules all access the same common data environment, the coupling between them is called public coupling. The public data environment can be a global data structure, a shared communication area, a public coverage area of the memory, etc.
3) External coupling: When modules are connected through an environment outside the software (such as I/O coupling the module to a specific device, format, or communication protocol), it is called external coupling.
4) Control coupling: If the parameters transmitted from one module to another module contain control information, and the control information is used to control the execution logic in the receiving module, it is called control coupling.
5) Tag coupling: Part of a data structure (such as a substructure of a certain data structure) is passed between two modules through a parameter table, which is tag coupling.
6) Data coupling: Only simple data is transferred between two modules through parameter tables, which is called data coupling.
7) Indirect coupling: If there is no direct relationship between two modules, that is, either of them does not depend on the other and can work independently, this coupling is called indirect coupling.
The tighter the connections between modules, the more connections there are, the higher the coupling, and the weaker their functional independence.
The closer the connection between the various elements within a module, the higher its cohesion.
Modules with strong functional independence should be modules with high cohesion and low coupling.
Software architecture design
Software architecture focuses on one or more structures of a system, including software components, the externally visible properties of these components, and the relationships between them.
Bass proposes three key reasons why architecture is important:
① Facilitate communication among stakeholders
②Conducive to early decision-making in system design
③Transmissible system-level abstraction
architecture development process
Common software architecture
Single host structurek
C/S (Client/Server) structure
B/S (Browser/Server) structure
software architecture style
The vast majority can be classified as one of a relatively small number of architectural styles
Each style describes a system category, which includes:
① Some components that implement the functions required by the system (such as databases, computing modules)
②A set of "connectors" used to connect components for "communication, coordination and cooperation"
③ Define system constraints on how components are integrated
④ Semantic model that enables designers to understand the properties of the entire system and analyze known properties
data-centric architecture
Some data (such as a file or database) is stored at the center of the structure and is frequently used, added, deleted, or modified by other components
data flow style architecture
This structure is suitable for input data to be transformed into output data by a series of calculation or processing components.
Call and return style architecture
This style enables a software designer to design an architecture that is very easy to modify and extend.
Contains: main program/subprogram style architecture and remote procedure call style architecture
There are a few concepts to understand here:
Depth of program structure: The number of levels of program structure is called the depth of the structure. The depth of the structure reflects the size and complexity of the program structure to a certain extent.
The width of the program structure: the maximum number of modules at the same level in the hierarchy is called the width of the structure
Module fan-in and fan-out: Fan-out represents the number of other modules that a module directly calls (or controls). Fan-in is defined as the number of modules that call (or control) a given module. Multiple fan-outs mean that many subordinate modules need to be controlled and coordinated. Multi-fan-in modules are usually public modules.
Object-oriented style architecture
Methods for system components to encapsulate data and manipulate data
Interaction and coordination between components are passed through messages
hierarchical style architecture
In this structure, different levels are defined, and each level completes operations closer to machine instructions than the outer level.
Evaluate alternative architectures
For the same software requirement, different software structures will be derived due to different principles of various design methods.
Different software structures for the same problem
ATAM (architecture trade-off analysis method)
1) Define application scenarios (scenarios): express the system from the user's perspective through use case diagrams
2) Derive requirements, constraints and environment description: This is part of requirements engineering to ensure that all customer concerns are listed
3) Describe the architectural style that can handle the above situations and requirements
4) Evaluate each performance of the system individually. Performance for architecture design includes: reliability, performance, security, maintainability, flexibility, testability, portability, reusability and interoperability, etc.
5) For different architectural forms, evaluate the sensitivity of these performances mentioned in step 4. It can be evaluated in this way: make some small changes in the entire architecture, analyze and determine whether there are any sensitive changes in the appeal performance. Those performance that are greatly affected by architectural changes are called sensitive points.
6) Evaluate those architectures proposed in step 3 through the sensitivity analysis in step 5. The method described by SEI is as follows: When the sensitive points of an architecture are determined, we need to find the factors that require the most trade-off points in the system (trade-off points). The trade-off factor means that changing this content in the architecture will cause sensitive changes in the performance of the system. For example, the performance of a system with a client-server structure is closely related to the number of servers in the system (for example, increasing the number of servers will improve the performance of the system to a certain extent)... In this case, the number of servers is this balance point in architecture.
When designing software architecture, you can refer to the following rules:
(1) Improve software structure and improve module independence
(2) Appropriate depth, width, fan-out and fan-in of the module
(3) The module’s judgment scope should be within its control scope
(4) Strive to reduce the complexity of module interfaces
(5) Design a module with single entrance and single exit
(6) Module functionality should be predictable and the module size should be moderate
(7) Generally, it is better for a module to contain around 30 to 50 statements.
(8) A well-designed software structure usually has higher fan-out at the top layer, less fan-out at the middle layer, and high fan-in at the bottom layer.
component level design technology
In structured analysis and design methods components are often called modules
In object-oriented analysis and design, components are called classes. In component-based development methods, components are called components.
In the component-level design stage, the following work is mainly completed:
Determine the algorithm used for each component, select an appropriate tool to express the algorithm process, and write a detailed procedural description of the component
Determine the data structures used internally by each component
At the end of the component-level design, the above results should be written into the component-level design specification and formed into a formal document through review, which will serve as the basis for the next stage (coding stage).
Structured Programming Method
A more popular definition is: "If the code blocks of a program are connected only through the three basic control structures of sequence, selection and loop, and each code block has only one entry and one exit, then the program is said to be structured. of"
With the development of new software development methods and technologies such as object-oriented and software reuse, a more realistic and effective development approach may be an organic combination of top-down and bottom-up methods.
Graphical representation
Program flow chart
Program flow charts are independent of any programming language, relatively intuitive, clear, and easy to learn and master.
In order to use flowcharts to describe structured programs, you must limit the flowcharts to only five basic control structures.
N-S diagram
Nassi and Shneiderman proposed a graphical description tool that conforms to the principles of structured programming, called a box diagram, also called an N-S diagram.
Five basic control structures
PAD
PAD is the abbreviation of Problem Analysis Diagram, which evolved from the program flow chart.
Five basic control structures
Decision table
When the algorithm contains multiple nested condition selections, it is difficult to describe clearly using program flow charts, N-S diagrams or PAD.
However, decision tables can clearly express the correspondence between complex combinations of conditions and the actions that should be taken.
The advantage of the decision table is that it can describe all processing rules concisely and unambiguously.
However, the decision table represents static logic, which is the possible result under a certain combination of condition values. It cannot express the processing sequence, nor can it express the loop structure.
Design Language PDL
PDL (Program Design Language) is a language used to describe the algorithm design and processing details of functional components, called a design language
It is a kind of pseudo code. Generally speaking, the grammar rules of pseudocode are divided into "external grammar" and "inner grammar"
Foreign syntax should conform to the grammatical rules of commonly used statements in general programming languages.
Internal grammar can use some simple sentences, phrases and common mathematical symbols in English to describe the functions that a program should perform.
PDL usage examples
PDL features
1. There is a fixed keyword-external syntax that provides all structured control structures, data descriptions and component features. Keywords belonging to foreign grammar are a limited vocabulary set that can structurally segment the PDL text and make it easy to understand. In order to distinguish keywords, it is stipulated that keywords must be capitalized and other words must be lowercase.
2. The inner grammar uses natural language to describe processing characteristics. The internal syntax is relatively flexible, as long as it is written clearly, there is no need to worry about grammatical errors, so that people can focus on describing the logic of the algorithm.
3. There are data description mechanisms, including simple (such as scalars and arrays) and complex (such as linked lists and hierarchical structures) data structures.
4. There is a subroutine definition and calling mechanism to express interface descriptions in various ways.
Design specifications and design reviews
design specifications
design review
The ultimate goal of software design is to obtain the best solution
"Best" means that among all candidate solutions, the solution that can achieve higher productivity, higher reliability and maintainability is selected based on the conditions of saving development costs, reducing resource consumption, and shortening development time.
Contents of design review
Traceability: that is, analyzing the system structure and subsystem structure of the software to confirm whether the software design covers all identified software requirements and whether each component of the software can be traced back to a certain requirement.
Interface: Analyze the connection between various parts of the software and confirm whether the internal interface and external interface of the software have been clearly defined. Whether the component meets the requirements of high cohesion and low coupling. Whether the scope of the component is within its control range.
Risk: Confirm whether the software design can be implemented on time under the existing technical conditions and within the budget.
Practicality: Confirm whether the software design is practical for the solution to the needs
Technical Clarity: Confirming that the software design is expressed in a form that can be easily translated into code
Maintainability: From the perspective of software maintenance, confirm whether the software design considers the convenience of future maintenance.
Quality: Confirm whether the software design exhibits good quality characteristics
Various options: See if you have considered other options and what are the criteria for comparing various options?
Limitations: Evaluate whether the limitations on the software are realistic and consistent with requirements
Other specific questions: evaluation of documentation, testability, design process, etc.
There are two types of review: formal review and informal review.
In addition to software developers, the formal review also invites user representatives and domain experts to participate, usually in the form of a defense.
Informal reviews are more or less peer-to-peer in nature and are not limited to time or format.