Summary of Software engineering introduction eighth Chapter

The eighth chapter object-oriented design

Concept of Design

Design activities

Main activities of object-oriented design process

Design principles

1. Modular

For complex systems, the effective way to reduce complexity is to modularize the system, which is to break up a complex large system into several relatively simple smaller parts called subsystems. If a subsystem remains complex, it continues to decompose until it is easy to develop and manage. The number of layers in the subsystem should not exceed 5±2, and no more than 7±2 subsystems in the same hierarchy.

Another form of system decomposition is the decomposition of the system into a peer subsystem, each subsystem responsible for a different type of service, the subsystems are independent of each other.

2. Coupling degree and cohesion

The coupling degree represents the degree of association between two subsystems. When one subsystem changes, the effect on another subsystem is very small, it is called loosely coupled, and conversely, if the effect of the change is very large, it is called tightly coupled. The lower the coupling, the better.

Cohesion is the degree of correlation within the subsystem. When multiple objects related to each other in a subsystem perform similar tasks, the subsystem is considered high cohesion, whereas when multiple objects within a subsystem are unrelated to each other, they are considered to be low-cohesion. The higher the cohesion, the better.

3. reusability

To build a software system, the so-called reuse is to make use of some developed software elements that are useful for building new systems to generate new software systems.

Software components, which have a certain degree of integration and can be reused, are called soft components, and software reuse is the direct use of existing soft components to generate new systems by assembling or reasonably modifying them.

Software architecture

Typically, software architecture involves the overall organization of software systems, global control, data access, and communication protocols between subsystems.

Typical software Architecture: Warehouse architecture, tiered architecture, MVC architecture, client/server architecture, Pipeline and filter architecture, minilibrary system architecture.

System Design

Identify design elements

Determine the basic principles of design elements:

(1) If an "analytic class" is relatively simple and represents a single logical abstraction, then it can be mapped to a "design class". Usually, the corresponding boundary class of the active participant, the control class and the general entity class can be mapped directly into the design class.

(2) If the responsibilities of the "analytic class" are complex and difficult to bear by a single "design class", it should be mapped to "subsystem interfaces". Typically, the corresponding boundary class for a passive participant is mapped to a subsystem interface.

(3) The division of subsystems should conform to the principle of high aggregation and low coupling.

Data storage Policies

There are 3 common ways to manage data storage:

(1) Data files: Data files are storage forms provided by the operating system, which stores data in byte order and defines how and when data is retrieved.

(2) Relational database: In a relational database, data is stored as a table in a pre-defined type called schema.

(3) Object-oriented database: Unlike relational databases, object-oriented databases store objects and relationships as data. It provides inheritance and abstract data types, but its queries are slower than relational databases.

Deploying subsystems

The UML deployment diagram reflects the physical architecture of software and hardware in the system, representing the processing nodes of the system at runtime and the deployment of components in the nodes.

System Design Review

As with the analysis phase, the system design is also generated after several iterations and adjustments, but its quality review does not require user involvement and is formally reviewed by the developer to ensure the correctness, completeness, consistency and feasibility of the system design.

Detailed design

Method modeling

1. Naming the method

method to be named with the full description, using the "MethodName ()" form.

2. The visibility of the method

Protected (Protected): called only within the class hierarchy and cannot be called externally, using the symbol "#";

Private: Called only in the class in which it is defined, using the symbol "-";

Method modeling for 3.BorrowerInfo classes

Property modeling

Sets the visibility of all properties to private;

The property is updated only by the Set method;

Access properties only through the Get method;

In the set method of the attribute, the simple validation is implemented, and the complex logic verification is implemented in the independent verification method.

State modeling

State modeling is a dynamic modeling technique, which is mainly used to determine system behavior. In a detailed design, state modeling generally occurs only on classes that rely on state to show different behaviors. In state modeling, the state is represented by the value of the object property, and the transfer is the result of the method invocation, often reflecting the business rules.

Relational modeling

Global: An object can be "referenced" directly by other objects in the global scope;

Parameter: An object is an action parameter or a return value of another object;

Partial: An object acts as a temporary variable in an operation of another;

Domain: An object is a data member of another.

Application Design Patterns

Abstract Factory mode

The purpose is to encapsulate a specific platform so that applications can run on different platforms.

Adaptor mode

The purpose of the adapter design pattern is to encapsulate the code of the legacy system.

Bridge mode

This mode separates the interface of a class from the implementation.

Facade mode

The facade mode encapsulates subsystems with a simple unified interface, reducing the dependency between classes.

User interface Design

User interface Design principles

1. User Control design Principles

2. Consistency

3. Personalization

4. Tolerance

5. Feedback

6. Aesthetics and Usability

Web Interface Design

Web interface design requirements are concise, avoid the use of many complex pictures and animations and other causes of user distraction, and the interface layout should be suitable for the clear expression of information, and have a matching navigation.

User support

The user interface should provide clear system hints and feedback, and provide some form of online help.

Design document

The results of software architecture design and detailed design should form a design document, and the development organization should adopt a standard software Design specification template.

Summary of Software engineering introduction eighth Chapter