当前位置：网站首页>Bao Yan notebook IV software engineering and calculation volume II (Chapter 8-12)

a) To define the architecture of a system or component in order to make a software system meet specified requirements 、 parts 、 The process of interfaces and other features ;
b) The result of the design process .

2. The core idea of software design

Complexity control
decompose 、 abstract 、 Hierarchy

The ninth 、 Ten chapters Software architecture design and construction

1. Architecture concepts

High level abstraction ( Architecture = parts + Connections + To configure )

parts + Connections + To configure
parts ： Main functions of the bearing system , Including processing and data
Connections ： Define the interaction between components , Is an abstract representation of a connection
To configure ： Defines how components and connectors are associated , Organize them into the overall structure of the system

2. Advantages and disadvantages of architectural style

Common style patterns ：

(1） The main program / Subroutine style

parts ： Program 、 function 、 modular
Connections ： Calls between them
Design decisions and constraints
1. Based on the statement - Use ( Program call ) Relationship building connector , Establish system components in a hierarchical decomposition way , Together, they form a hierarchy .
2. Every time ⼀ Upper layer components can " Use " Lower part , But the lower parts cannot " Use " Upper part , That is, it is not allowed to call in the opposite direction .( Hierarchical decomposition , Use relationships based on definitions )
3. The system should be Single thread Of board ⾏. The main program component has initial execution ⾏ control power , And in " Use " Transfer control to the lower subroutine .
4. Subroutines can only gain control through upper level transfer , You can hold ⾏ Transfer control to lower level subroutines , And must return the control right to the upper part after its own execution .
5. Implicit subsystem structure .
advantage ： The process is clear , Easy to understand ; Strong control .
shortcoming ：
1. Program call is a kind of strong coupling connection , Very dependent on the interface specification of the interacting party , It makes the system difficult to modify and reuse ;
2. Based on program call （ Statement － Use ） The connection mode of relationship limits the data interaction between components , It may make different parts use implicit shared data communication , Generate unnecessary public coupling , And then destroy its “ correctness ” Control .
Realization ： Functional decomposition 、 Centralized control , Each component has a module implementation , Mainly one-way dependency . Use utility or tools And other basic modules

(2） Object oriented style

parts : Object or module
Connections : Function or call （ Method ）
Data representation is hidden from other objects ; Objects are responsible for maintaining the integrity of the data representation （ For example, some invariants ）; Each object is an autonomous proxy ; Data representation and related operations are encapsulated in abstract data types , example : Abstract data types
advantage ： Modifiability of internal implementation ; Easy to develop 、 Easy to understand 、 A reusable structural organization .
shortcoming ： Interface coupling ; Coupling of identification ; side effect （Ex：A and B All modified C）.
Applicable to the core issue is the identification and protection of relevant institutional information （ data ） Application
Realization ： Task breakdown ,（ Entrustment ） Decentralized control , Each component has a module implementation , Use interfaces to convert bidirectional dependencies into unidirectional dependencies . Divide each component into multiple modules , To ensure one-way dependency , Use utility or tools And other basic modules

(3） Layered style

The upper layer calls the lower layer , Reverse calls are prohibited , Call across layers
parts : Usually a collection of programs or objects
Connections : It is usually a program call or method call with limited visibility
advantage ： The design mechanism is clear , Easy to understand ; Support parallel development ; Better reusability and internal modifiability .
shortcoming ： The interaction protocol is difficult to modify ; Performance loss ; It is difficult to determine the number and granularity of layers .
application ： It is applicable to applications containing different types of services , And these services can be organized hierarchically . Especially when the application may change in some layers , for example Interaction , signal communication , Hardware , platform etc. . Example : Layered communication protocol , Each layer provides the basis for communication in a certain degree of abstraction , Low level defines the low-level interaction. The lowest level is hardware connection （ The physical layer ）
Realization ： Separation of concerns （ Each layer is abstracted step by step ）, The interface between layers uses fixed protocols （ Fixed control ）, One or more modules in each layer realize , One way dependency , Establish special modules for data transmission between layers , Use utility or tools And other basic modules

(4）MVC style

Model —— View —— controller
Model The subsystem is designed not to rely on any View or Controller Subsystem , Their state changes will spread to View Subsystem
parts ：Model Components are responsible for maintaining domain knowledge and notifying view changes ;View The component is responsible for displaying information to the user and sending user gestures to the controller ;Controller Change the state of the model 、 Map user actions to model updates 、 Select a view to respond
Connections : Program call , news , event
advantage ： Easy to develop ; Modifiability of views and controls ; Features suitable for network system development .
shortcoming ： complexity ; Model modification is difficult .
Suitable for the following applications : At run time , User interface changes are easy and possible . The adjustment or transplantation of the user interface will not affect the design and coding of the functional part of the application . example :Web application
Realization ： Specific technology , Usually dedicated to WEB：Model And Controller A one-way ,Controller And View two-way ,Model And View two-way
Typical implementation ：View：JSP,HTML;Controller：Servlet;Model：JavaBean

subject
Module partition in the way of functional decomposition can achieve high cohesive software design :√
The main purpose of software system design is to make a blueprint for the system , (D) Not what the software design model is concerned about .
Overall structure of the system
data structure
Interface model
Project scope ( This is done in the requirements section )
Architecture design It's software Non functional The implementation of the , and Detailed design Mainly software Functionality The implementation of the .√

3. The process of architecture design

Analyze key requirements and project constraints ： Analyze use case documents and requirements specifications ( Include requirements specifications and project constraints ). Note that both functional requirements should be considered , Also consider non functional requirements , Even in a large sense, architecture is designed to meet non functional requirements .
By choosing an architectural style ： Choose a layered style ( The information system 、 Concurrent development 、 Not web application ), Review .
Into the ⾏ Software architecture logic ( abstract ) Design ： Generate logical package diagram
Software architecture based on logical design ( Realization ) Design ： Generate a physical class diagram
Improve the architecture design ： Key class diagram , Definition of persistent data format, etc
Add component interface ： package 、 Creation of important documents , Defining interfaces
iterative process 3-6

Take the supermarket system design as an example , Reading a book .

4. The principle of package

The supreme principle ： There must be no duplication or redundancy between packages 、 Reuse release equivalence principle 、 Principle of common closure 、 Common Reuse Principle 、 The principle of acyclic dependence 、 Principle of stable dependence 、 Stable abstract principle

Reuse release equivalence principle (REP): The granularity of reuse is the granularity of Publishing
Principle of common closure (CCP): All classes in the package should be closed to changes in the properties of the same class , If a change affects a package , Will affect all classes in the package , It has no effect on other packages .
Common Reuse Principle (CRP): All classes in a package should be reusable together .
The principle of acyclic dependence (ADP): There cannot be a ring in the dependency graph of a package .
Principle of stable dependence (SDP): Rely on stability
Stable abstract principle (SAP): The abstraction level of a package should be consistent with its stability

The first three describe dependencies , The last three describe coupling

4.1. Common Closure Principle (CCP) Principle of common closure

Classes modified together should be put together
Minimize the impact of changes on programmers
When changes are needed , Good for programmers
If changes affect as few packages as possible due to compilation and link times and revalidation
Example

summary
1. Group classes with similar closures
2. Target the expected change closure
3. Limit changes to a few packages
4. Reduce packaging release frequency
5. Reduce the programmer's workload
6. Only for predictable changes , Unpredictable changes will bring great damage to the system , And can't predict .

4.2. Common Reuse Principle (CRP) Common Reuse Principle

What is reused together should be together
The package should be focused , Users should use all classes in the package
summary
1. Group classes according to common reuse ： Avoid giving users unnecessary dependencies
2. follow CRP It usually causes the software package to be split ： Get more , smaller , A more focused package
3. Reduce the work of re-use

A compromise between the principle of common closure and the principle of common reuse

CCP and CRP The principle is Mutually exclusive Of , That is, they cannot be satisfied at the same time .
CRP Make life easier for reuse people , and CCP Make life easier for maintainers .
CCP Try to make the package as big as possible , and CRP Try to make the package small .
Early in the project , The architect can set the package structure , send CCP Take the lead , And assist in the development and maintenance of . later , As the architecture stabilizes , Architects can refactor the package structure , In order to make External reuse program CRP Maximize .
That is to say, at different stages of software development CCP and CRP The degree of emphasis on reuse varies , We should learn at different levels according to the progress of the project .

4.3. Reuse-Release Equivalency Principle (REP) Reuse release equivalence principle

The unit of reuse is the publishing unit
About reusing software
Reusable software is external software , You can use it , But others can maintain it .
There is no difference in reuse between commercial and non-commercial external software .
Example

summary
1. Group components for the reuser ( class )
2. A single class is usually not reusable ： Several collaboration classes form a package
3. The classes in the package should constitute reusable and releasable modules ： Modules provide consistent functionality
4. Reduce the work of re-use
5. Publish with associated classes , Instead of publishing it separately

4.4. The Acyclic Dependencies Principle (ADP) The principle of acyclic dependence

The dependency structure of the package must be a directed acyclic graph (DAG)
Stabilize and release projects in batches
Organize package dependencies in a top-down hierarchy
Once the ring is formed, it may be infinitely modified ( The modification of packets in the ring will lead to a large number of modifications )

4.4.1. Dependencies are a DAG

The tree on the left forms a ring structure

4.4.2. Rely on the loop to break the loop ： The first way ：

This situation is a closed loop caused by one-way dependence
A solution , take Common error The one who depends on GUI One of the bags is placed outside alone , You can avoid circular dependency .

4.4.3. Rely on the loop to break the loop ： The second way ：

Another case , This is a closed loop of interdependence ,A Depend on X,Y Depend on B
Solution : from Y Provide an interface ( This interface is B Realization , By Y hold )
1. B Realization BY:B Depend on BY

4.4.4. Application scenarios of the acyclic dependency principle

Hierarchical style and main program / Subroutine styles usually do not produce
⾯ Object oriented style especially it is to be noted that
C/S Of MVC The style may be ⽣
Based on data flow 、 event / news 、 The architectural style of data sharing and interaction is usually not ⽣

4.5. Stable Dependencies Principle (SDP) Principle of stable dependence

Dependency should point in a stable direction ( The effort needed to change him )
stability ： Corresponds to the time required to change the packaging
Stable software package ： Difficult to change within the project
Stability can be quantified

4.5.1. Principle of stable dependence

Why? X It is stable. , and Y It's not stable ( Changes in others will not affect me )

The stability measure of packets

One way is Calculate into 、 Figure out the number of dependencies of the package . These values can be used to calculate the positional stability of the package (positional stability).
(Ca) Input coupling (Aﬀerent Coupling)： Refers to the number of classes that are external to the package and depend on the classes within the package ⽬.
(Ce) Output coupling (Eﬀerent Coupling)： Refers to the number of classes inside the package that depend on classes outside the package ⽬.
( Instability I)I = Ce / (Ca + Ce)
The value range of this measure is [0,1].I=0 Indicates that the package has Great stability .I=1 Indicates that the package has Great instability . By calculating and ⼀ The number of classes outside the package that have dependencies on classes inside the package ⽬, You can calculate the entity Ca and Ce .
When ⼀ A bag of I The measure is 1 when , This means that no other package depends on this package (Ca = 0);⽽ This package depends on other packages (Ce>0). This is a ⼀ Packet unstable state ： It is irresponsible and dependent . Because no package depends on it , So it has no reason not to change ,⽽ The packages it depends on provide it with rich reasons to change .
another ⼀ aspect , When ⼀ A bag of I The measure is 0 when , This means that other packages will depend on this package (Ca > 0), But this package does not depend on any other package (Ce = 0). It is responsible and independent . This kind of bag has reached ⼤ Degree of stability . Its dependencies make it difficult to change ,⽽ And no dependencies will force it to change .

4.6.Stable Abstractions Principle (SAP) Stable abstract principle

Stable packages should be abstract packages ( Interface )
Unstable packages should be specific packages
Stable packaging includes high-level design .
Making them Abstract opens them for extension , But you can turn them off and modify them (OCP).
Some flexibility is preserved in the stable and hard to change packaging .

5.8.1. Abstract metrics

The abstraction of a package is defined by the number of abstract classes ⽬ And the number of all classes in the package .
Suppose the total number of classes in the package is Nc, Number of abstract classes ⽬ yes Na, So abstract A = Na / Nc

String class (Instability、Abstraction origin )
String A class is an awkward package at the origin , Cause any to String Any modification of the previous development may lead to java The program won't run .

5.8.2. Example

5. Definition of interfaces between architectural components

Definition of interfaces between architectural components ：
- Services provided （ For interface ）： grammar 、 precondition 、 Postcondition
- Required services （ Required interface ）： service name 、 service

Determine the external interface of the module according to the allocated requirements , For example, the logic layer interface is obtained according to the requirements of the interface , The data layer interface is called according to the logic layer .
Determine the interface according to stimulation and response , Define the interface content according to the detailed specification （ data 、 Return value ）
（1） Usually ,VIEW Of required The interface can be directly used as the corresponding Logic Of Provided
（2） Usually ,LOGIC Of required Interfaces need to be decomposed into modules of the same layer and different Data Of Provided
（3）Data Generally, there is no inter layer dependency , The interface usually comes from the corresponding module of the upper layer

【 Example 】saleLogic Other interface sources :
（1） Others are classified as saleLogic The requirements undertaken by the module , Such as return use case
（2） Dependencies between modules of the same layer
Remove two-way dependency ： It needs to be abstracted as an independent interface and independent package ,saleLogic Then import the above package
Independent interfaces and independent packages also belong to saleLogic The module finally undertakes Provide Interface , It also needs to be transformed into right Data Of Required Interface
Gradually improve when analyzing other modules , For example, when giving gifts, you can view the sales records of specific customers 、 During inventory analysis, you can view the sales records of a certain period of time or the sales records of a specific commodity
Define restricted domain classes in independent interfaces and packages for external use , For example, objects are limited to query interfaces , Limit the type of data, etc

6. Architecture development integration test cases ：Stub and Driver

（1） Establish pile program according to module interface Stub—— Temporary code used to compile and connect programs , Externally simulate and replace the key classes that undertake the module interface , It is much simpler than the real program , Use the simplest logic

【 Example 】P177 SalesBLService_Stub

（2） Write drivers , Carry out integration test with the help of pile program
View The test of is special , Other layers need to be added Driver To test
Can be based on Junit To write Driver; Design test cases based on interface specifications
Development View When the layer ： need logic Of stub
Development logic When the layer ： Need to imitate view Of driver, need data Of stub, It is necessary to simulate the call of the same layer driver and stub
Development data When the layer ： Need simulation logic Of driver

（3） Continuous integration ： Write the internal program of each module step by step , Replace the corresponding pile program
Real programs not only implement business logic , And will use the interface program of other modules （ Real program or pile program ）
Start ： client : view driver, logic stub, data stub; Server side : logic driver, data stub
progress ： client : ( Gradually replace )driver, Gradually replace logic stub, data stub; Server side : logic driver, Gradually replace data stub
Finally, the joint debugging ： Use real clients and servers

The first 11 Chapter Human computer interaction design

1. Usability （ A term is used to explain ）

Usability is an important and complex concept in human-computer interaction . It not only focuses on the process of people using the system , At the same time, we also pay attention to the effect of the system on the people who use it , Because it's complicated , So usability is not a single quality dimension , But multi-dimensional quality attributes . In terms of ease of measurement , Common dimensions of usability include ： Easy to learn 、 Easy to remember 、 Be efficient 、 Low error rate and subjective satisfaction .

2. Precautions and explanation of interface design （ At least 5 individual ）

【 Question type 】 Which interface design principle does the example violate
（1） Do not expose the internal structure
Example ： The design clearly exposes the software structure , Three independent software processes ： establish 、 to update 、 relieve
（2） Show details —— What you see is what you get
（3） Common interface types ： Software systems usually use multiple interface types at the same time , To adapt to different users and tasks .

3. Mental model , Difference

（1） Mental model is the task model in the mind of users when they interact with human-computer
Metaphor can be carried out according to the mental model （Metaphor） Design ： Metaphor is also called visual metaphor , It's a visual image , But it will be mapped to business things by users . When the user recognizes the image , Will use metaphor to link control functions to known familiar things , Form a task model ; In essence, metaphor is to build a new set of knowledge on the basis of users' existing knowledge , Realize the perceptual connection between interface visual prompt and system function .
（2） What users want to see + What you want users to see ： Identify and add functions that can help users complete tasks , The frequency of the task should also be taken into account
Common mistakes ： Add some easy ones （ For example, it happens to be an independent software process ） The function of , This will disturb the user's mental model , Affect the smoothness of the use process
（3） New users ： Focus on Learnability , Conduct business navigation , Try to avoid mistakes
Expert users ： Focus on efficiency
Skilled users ： Make a compromise between learnability and efficiency
Good human-computer interaction should provide different interaction mechanisms for different user groups .
It provides a human-computer interaction mechanism with high learnability for novice users （ The graphical interface ）
It also provides efficient human-computer interaction mechanism for expert users （ Command line 、 Shortcut 、 Hot key ）

（1） Navigation
Take the initiative to tell users their products and services concisely , The purpose is to provide users with a good entry to complete the task , Good navigation will make this entry very consistent with people's mental model .
The global structure organizes the functions of software products according to the task model , And distinguish different importance and themes to provide to different users . Common navigation controls for global structures include windows 、 menu 、 list 、 Shortcut 、 Hotkeys, etc . The design of the global structure is mainly based on the functional hierarchy and task interaction process .
Local structure by arranging interface layout details , Create visual clues to provide users with navigation . Common navigation controls for local structures include visual control layout and composition 、 Button settings 、 Text color or font size, etc . The design of local structure is mainly based on the task details concerned by users .

（2） feedback
Let users be aware of the results of their actions , But you can't interrupt the stream of consciousness when users work
Users prefer shorter response times ; Long response time （>15 second ） Destructive ;
Users will adjust their working methods according to changes in response time ;
Shorter response time leads to shorter user thinking time ; A faster pace may improve efficiency , But it also increases the error rate ;
Select the appropriate response time according to the task ： typing 、 Cursor movement 、 Mouse positioning ：50～150 millisecond ; Simple and frequent tasks ：1 second ; Ordinary tasks ：2～4 second ; Complex tasks ：8～12 second
A modest change in response time is acceptable ; Unexpected delays can be devastating ; Experience testing helps set the appropriate response time .

（3） Collaborative design
A. Simple design （ Abstract pictures are better than words ）
list 、 hide 、 give （ label 、 Clues such as icons suggest ）
B. Consistent design （ Confirm that the relative position of the delete key is inconsistent ）
C. Low error rate design （ Use specific instructions to prompt users for errors ）
Limit input ： list 、 Optional components such as optional boxes replace input boxes ; Button instead of command line ; Restricted input ： type , Range , Format …
Limits ： Simplify single step operation
auxiliary ： Advance notice ; After the fact check ; It can be revoked at any time
D. Easy to remember design
Reduce the burden of short-term memory ; Present information in a step-by-step manner ; Use intuitive shortcuts . Recognition is easier than memory ; Set meaningful defaults , It can help users reduce the burden of memory .

The first 12 Chapter Overview of detailed design

Middle level design ＋ Low level design ： Achieve all functionality ＋ Nonfunctional requirements

1. The starting point of detailed design

Results of requirements development （ Requirements specification and requirements analysis model ） And software architecture （ Software architecture design scheme and prototype ）

Clarify responsibilities and establish static models （ Design class diagram ）, Clear collaboration to build dynamic models （ Detailed sequence diagram ）
GRASP（General Responsibility Assignment Software Patterns）
（1） Information expert model
One of the basic principles of responsibility allocation , Assign responsibilities to those who have the information needed to complete the responsibilities
for example ： The total price （ entrust ）—— number —— The unit price —— Promotion strategy ： Coupling has not increased
The total price （ obtain ）—— number 、 The unit price 、 Promotion strategy ： Added coupling （ I know too much about the total price ）
advantage ： Promote low coupling 、 High cohesion 、 Maintenance package
（2） controller
Handle external events （ External interaction between user and system clock ）
The core idea ： decoupling
Don't call the code directly from the interface , Don't call the interface directly with code , Put the system ／ people ／ Use case as controller
（3） Creator mode
Determine which class to create an instance according to the relationship between the potential creator class and the instance class
When the following conditions are met ,B establish A：B“ contain ”A, perhaps B Combine A;B Use it directly A;B Have A Initialization data of ;B Record A
（4） Pure fiction
Software specific ui、DAO、RMI、 File read and write 、 Complex behavior 、 Design patterns 、 Complex data structures 、 Interface and logic layer model, Does not belong to the real world
effect ： Keep code reusable , High cohesion 、 Low coupling

2. Assignment of duties

Build a static model through responsibilities ： Object oriented decomposition , The system is made up of many objects . The objects complete their respective responsibilities , So as to cooperate to complete a big responsibility . The responsibilities of class mainly consist of two parts ： Attribute responsibility and method responsibility . Classes do not exist in isolation , There is a certain relationship between them . Relationships express the division and combination of corresponding responsibilities . Their order of strength is ： rely on < relation < polymerization < Combine < Inherit .

3. Collaboration

Build dynamic models based on collaboration ：（1） From small to large , Aggregate the small responsibilities of objects to form large responsibilities ;
（2） Big to small , Assign big responsibilities to small objects . In both ways , Jointly complete the abstraction of collaboration .

4. Control style

In order to complete a big responsibility , Many decisions need to be made on the allocation of responsibilities . Control style determines who makes decisions and how to make decisions
Decentralized ： All system behaviors are widely spread in the object network
Centralized ： A few controllers record the logic of all system behaviors
Entrustment （ Type authorization ）： Decisions are distributed in the object network , Some controllers make major decisions

5. Establish design class diagram or detailed sequence diagram

Responsibilities of abstract classes -> The relationship between abstract classes -> Add auxiliary classes
Auxiliary class ： Interface class 、 Record class （ Data class ）、 Start class 、 The controller class 、 Classes that implement data types 、 Container class