The thing about software development: the way to solve it

The previous cycle of software development: expectations-shattered-collapse-a new cycle, where is our solution?

My reflection--not to break out in silence, to perish in silence.

Reflection, I am reflecting on ...

For the changes from the customer, I will never forget the teacher's teachings in college. In the Software engineering class, the teacher always repeatedly stressed that the need to change the needs of the elimination in the requirements analysis phase. According to the past Waterfall development theory, it always requires us to understand all the requirements of the customer in the requirements analysis phase, and write the software Requirement specification to the customer for signature. Once the customer has signed the software Requirement specification, the requirement can no longer be changed, and the software is developed according to this. But over time, software theorists have found that the business changes in the software design process are becoming more and more impossible for people to ignore. Then, one after another theory came out, what software design patterns, UML, Extreme Programming (XP), agile development, iterative development, and so on. According to the current theory, the business change runs through the entire software system lifecycle from requirements analysis to later maintenance, and we are always responding to various business changes. What we need to do is to make the least of the cost of a business change by reasonably designing, which is what we often say to design a maintainable system. If you do not respond to each business change, all our programming theory becomes worthless, we no longer need to pay attention to what "low coupling, cohesion well-structured classes poly", no longer need layered structure, we will return to the "sky is blue, life is beautiful, program design is also relaxed and happy" such a pure age. But the reality is that we have to make changes, and we have to work hard to design a flexible, maintainable system.

How can we ensure that we are designing a maintainable system, and that the Masters have given us one way or another through practice. Generally speaking, it is to establish the model, namely, in order to build the use case model, domain model, analysis model and design model, the iterative way to design our system step by step. The model is an abstraction of the problem space we want to solve. We abstract the real world into a model, can help us to more orderly understanding and analysis of problems, using the knowledge we have mastered to design a more reasonable system.

The use case model and the domain model are mainly completed in the requirement Analysis phase, while the analysis model and design model are mainly completed in the analysis design phase after confirming the requirement and beginning programming. However, as the whole process of software development, as the requirements of each change in the synchronous update, so as to form one after another version. The following is a brief introduction to the functions of these four models and their respective roles in turn.

Use case models (Use-case model)

The use case model is the beginning of software requirements analysis. When our users begin to express their needs in written or verbal form, the requirements are messy and need to be sorted out. When we are sorting out the needs, we should make the table reach the graphics and text which can let the customer understand and can let the technical staff understand. To do so, on the one hand, in order to further communicate with customers, confirm demand, on the other hand, for the technical personnel analysis and design system to provide the basis and basis. To do this, it contains two parts: use case diagrams and use case descriptions.

A use case diagram focuses on three things: use cases, participants, and system boundaries.

A use case is a set of scenarios that describe how a participant uses the system to achieve its goals. Sounds abstract, we might as well understand that a module in the function, such as operating on an ATM, is a set of scenarios, that is, the ATM management module in the banking management system. It can continue to be subdivided into ATM machine withdrawals, ATM inquiries, ATM transfer and other scenarios, that is, ATM management sub-module of withdrawals, inquiries, transfers and other functions, each of them is a use case diagram in a child use case. One of the important roles that use use case analysis requirements brings to us is to split the entire problem space that the user wants to describe into one module after another, and then describe the problem further under each concrete module. Another function of using use cases is to translate the customer's rugged requirements description into a very rigorous language description, detailing the entire process of each process in the scenario. At the same time, the extension and intension of the professional words used in the description must be clearly stated, avoiding the occurrence of two meanings (the function, meaning, design process and guidelines of the use case model, which I will describe in detail in the things about the use case model).

The most intuitive knowledge of the participants is those of the operating system, but more precisely the roles of the operating system. The use case model requires a system analyst to describe each step of each scene in the system and what role the operator is. However, participants, in addition to those representing the operating system, also represent other systems that are associated with the use cases within the system boundary, outside the system boundary. Therefore, only defining the boundaries of a system can define which are the use cases within the system and which are participants inside and outside the system.

The system boundary is the scope of the whole problem space that a software system needs to deal with. A software system cannot handle all problems, and we have to define the scope of this problem space. Which is our software can handle, which is our software is not able to deal with, that is, project management in terms of the scope of the project.

A use case diagram visually shows all the use cases, actors, system boundaries, and relationships between requirements. However, a use case diagram cannot describe in detail each use case, each participant, system boundary, and the definition of the relationship between them. At the same time, each use case also describes its predecessor condition, the post condition, the basic path, the extended path and so on a series of words. Therefore, we need a use case specification document to elaborate the use case diagram.

In addition to use case diagrams and use case descriptions, you can draw some simple activity diagrams and state diagrams to describe complex or critical processes when needed.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

Domain models (domain model)

System Analyst in the requirements analysis phase, in addition to building and writing a use case model, not enough to support our later system analysis and design, he should also establish a domain model. The domain model is an expression of all the important concepts that are contained in the whole problem space and their interrelationships in the process of communicating with customers. In the domain model, the problem space is also expressed as the business domain. And all the important concepts in the business domain are described as objects or attributes, one after another. For example, student status management is the field of management system, students in this business area are described as "student" objects, and the student's name is described as the "student" object in the "name" attribute. However, the student's home address, as required by the customer, can be described as the "home Address" attribute in the "student" object, or it can be described as another "home address" object and include attributes such as "City", "Street", "Mailing Address", and "postal code". This shows that the domain model is a bunch of class diagrams.

The domain model is a factual description of the business domain and does not contain any technical implementations or any analysis design. The domain model focuses on important concepts in the business domain and their relationships with each other. The domain model does not focus on all the concepts and relationships in the business domain. It focuses on the concepts and relationships that are useful to the software systems we are developing. The concepts and relationships in the domain model may be acquired during a conversation with a customer (the author of domain-driven design Eric Evans even encourages us to work with our clients to draw a domain model on paper), while the other part is derived from the language description of the use case model.

The domain model is not a large picture. A class diagram that encompasses all the concepts and relationships in the business world is often confusing. The domain model should be a scene after another, in which we describe the relevant concepts and relationships in a scenario. (For the analysis and design of domain models, I will describe them in detail in the "talking about the domain model".) ）

Analysis Models (Analyze model)

When the system analyst and customer for a period of full communication, the business requirements are basically confirmed, the project began to enter the analysis of the design phase. The main work in the analysis design stage is to establish the analysis model. The task of building analytical models is very complex, it is the beginning of the ooa/d, which needs to establish a static model for each scenario in the requirements analysis (a system class diagram or object graph, a description of the various classes and relationships that the system needs to establish) and a dynamic model (a system of action diagrams, sequence diagrams, state diagrams, Describes all the processes in the system, including the main process, the branching process, and the invocation relationships of the various objects in the process, and the state changes in the objects in the process. The task of establishing an analytical model is an iterative process, the initial iteration is the actual description of the requirement, and then grasp the design pattern and other OO analysis theories to optimize the static model and dynamic model, and find a more flexible, easy to maintain, high cohesion and low coupling design scheme.

The analysis model should be the height of the whole system to look at each scene in the design, it must fully consider the collaboration of each module and the reuse of common code. Therefore, the functional and business logic to be used by each module is extracted. However, the biggest difference between the analysis model and the design model is that it does not contain any actual technology. Your system is implemented either by Java EE or by. NET to achieve, the analysis model is the same. It's also not about whether you're using a two-tier structure or a three-tier structure, using Oracle or a SQL Server database, which is not a concern. Using the analysis model, we can stand at a higher altitude to design our system, so that our system planning more reasonable. This is one of the important reasons why we introduce analytical models. (The process, methodology, principles, and grasp design model of the analysis model, which I will describe in detail in the "talking about the analysis model".) ）

Design Model

After several iterations, the analysis model gradually transitions to the design model without a clear gap. The important difference of the design model is that it begins to take into account a variety of specific technologies. The output of the design model is being born into the code we want to design through tools such as rational rose, but this is very theoretical and impractical. The most confusing design model is the extent to which it is refined. That is to say, the design model has to be designed so that we start programming. The analysis design is done by the system analyst, and the programming is accomplished by the programmer. If the design model is too thin, the system analyst is a huge workload, and the work of many programmers to do, at the same time, the constraints on the programmer too much. If the original design is flawed, it will be necessary to return to the system analyst to revise the design model, time-consuming and laborious. So I think the design model should not be too thin, from the overall grasp of the main part on it. At the same time, programmers can design their own design model in the process of designing the program, then we often say that the GOF design pattern can come in handy. It helps us to improve design level and code quality. (The process, theory, and some common gof design patterns of the design model, which I'll describe in detail in the "talking about the design model".) ）