The complexity of software design

What is the complexity of software design

One of the mission of Software technology development is control complexity (complexity). From the generation of high-level language, to structured programming, to object-oriented programming, component programming and so on. The definition of complexity is inconsistent, and you can read the many Faces of complexity in software Design for more information.

There are subtle differences between complex and complicated in English. But summing up, the software complexity of the partial negative significance, including two points:
-Difficult to understand (difficult to maintain and extend.) )
-Unpredictable behavior

Complexity is inevitably generated as the size of the software grows. It is a relative concept in itself, and the complexity of the same system is different for designers, developers, and maintainers. At different times, the complexity that a programmer can master is also different, which is also a goal of a programmer's continuous improvement.

Now that the industry has been fighting the complexities for decades, let's sort it out. reduce complexity with decomposition

The main features of the design in a decomposed manner are:
-Separation duty (seperation of concerns, refer to single duty principle)
-Focus on interfaces (define interactions)

This is the most commonly used technology. A big problem, constantly disassembled for each small problem of analysis and research, and then combined together. In the West called Divide and conquer Principle (divide and conquer principle).

In the era of structured programming, modularity (Modularization) is advocated. The first engineers who proposed software complexity proposed component-based software (Component Based software). I don't know if it's inspired by Lego bricks, splitting the system into different components, implementing them, and then assembling them together.

In the architecture design, whether the C/s style, layering, or N-tier,soa, as in the previous component, are all in the decomposition, they are more emphasis on the combination of interaction. Design, the division of responsibilities, define the interface, you can develop each. Then, the interaction is limited to the interface layer, it can control the complexity of the whole system well.

For example, the application layer uses a voice library (Speech library, a modular application in the form of a library), without concern for its internal implementation, as long as it knows how to use its API. improved low-Lai reduces complexity

Key points for improving dependencies:
-No ring-dependent
-Stable Dependency principle (SDP)

Decomposition can reduce the complexity of the system hierarchy, but there is also a complexity that cannot be solved, that is, the problem of dependency. This is a detailed discussion of dependencies in Agile Software development: principles, patterns, and practices. As participants increase, the interaction becomes complex. and the current software size, the system of various SDK API, the framework of the API, a variety of third-party libraries more and more, the dependencies between the modules will become more and more complex.

Obviously there are too many modules or components in the system and need to be further sorted out. But the real problem is that there is a two-way and ring dependency. For example, the computing module in charge of the calculation above also relies on the UI module, perhaps because the UI layer holds a key parameter required for the calculation. If the UI layer changes, it can affect the computing, unpredictable behavior, and give the customer an unstable impression.

Therefore, the dependencies between the modules must be simplified, and there should never be a ring dependency. Taking chromium as an example, it has a strict definition of the dependencies on each module, and there are deps to ensure that programmers do not make mistakes during the compilation period. The following figure is a definition of the chromium component dependency, where the dependencies of the component internal directory are also defined:

When the underlying module needs to rely on the implementation of the upper module, it is handled by a dependency inversion (DIP). In simple terms, an interface is defined by the underlying module, which requires the upper module to be implemented and injected into the underlying module.
use abstraction to reduce complexity

One of the most effective ways of learning is to classify it, and to use it is abstract thinking. In the face of fickle weather, humans can predict weather changes by abstracting the shape of the cloud. Here is an abstract modeling process.

Abstract is not the object-oriented language of the exclusive, in fact, it is not related to language, is essentially a way of thinking. The biggest difference between it and separation is that the abstract emphasizes the hidden details, focusing only on the essence of the core. The latter focus on the decomposition and combination of detail problems.

The quickest route for fixing two points is an example. From a separate point of view, it can be decomposed into the following questions: How long does it take to walk? How long does it take public transportation? How long does the taxi take? Combine the answers above and evaluate which is the quickest way.

And from an abstract point of view, the solution would be this:

Traverse all possible modes of transport, taking the least time-consuming:
1. Walking
2. By public transport
3. By taxi

First, an abstract solution is given, and the details are further realized. The greatest power of abstraction is that it is more stable than the implementation and most useful for curing core designs. In the development process, often around the details of the discussion, it seems that the abstract is too virtual. But if there is no abstraction to create a systematic panorama of design, some discussions will become inefficient.

In Agile Software Development: principles, patterns and practices, Uncle Martin simply uses the ratio of abstract classes in the total number of classes as a measure of abstraction, combined with a measure of stability, to evaluate the design. For details, refer to the concept of component design principles (III.). reduce complexity with popular principles

The introduction of unnecessary abstraction or decomposition in design and implementation is also a complication. Considering extensibility is also about determining what needs to happen, or introducing unnecessary complexity. This is what agile design advocates.
Some of the customary naming, often implicit design. such as observer, Client, adapter and so on. We need to learn these patterns and name them exactly. Otherwise it is easy to create an understanding problem. Summary

Software design is a balanced process, the complexity of software determines the maintainability, scalability and flexibility of the system. Let's review the previous three principles that define software design: modularity, abstraction, and information hiding. McCabe also has a paper devoted to the complexity of applying metric designs to cyclomatic complexity, but it has been long history. It is now more efficient to evaluate the complexity of the design in terms of dependencies. Interested to know about Cppdepend. In addition, Google's engineers based on LLVM IR also implemented a tool for dependency analysis (generateing precise Dependencies for Large software).

Reprint Please specify source: Http://blog.csdn.net/horkychen