In practice, the author discovered that the understanding of the concept is not in place, especially the relationship between the concept is not in place, is one of the reasons for obstructing many people successfully applied RUP. This paper adopts the method of "modeling the concept and its relationship", and investigates the concept and its relationship, in order to understand the core concept of RUP.
1. The necessity of clarifying the concept With the continuous development of software disciplines and software industry, more and more "nouns". However, "meaning" behind "noun" is really so growing? for example. In 1986, Barry Boehm proposed a spiral model for software development. Since then, the spiral model is treated as a standard method for software development. The spiral model has other common names, such as evolution models, or iterative models [1]. There are still many similar examples. It seems that there are many phenomena of "new bottled old wine" in the software industry - a new noun appears, it may be just a new expression in the form of coat, and its meaning is actually the same as an old noun. The author believes that today's rapid development of software disciplines is the true meaning behind the "change of infinite", is the most convenient way.
2, the method of this article: a picture of the Thousands of Thousands of words " A picture wins thousands of words. The essence of a concept often needs to be reflected from its relationship with other concepts. Not only inspects individuals, but also examines the relationship between multiple individuals, this method is in systemism, which is called "1 1> 2". The pleasant is the other side of the coin, paying attention to the relationship of this method, from its cost angle, is "1 1 <2".
3, RUP core concept Analysis 3.1, the task comes from the problem of RUP famous two-dimensional structure, the conceptuality related concepts, iteration, milestones, etc. But the author discovered that many people have not understood these concepts, especially the relationship between the concepts, can't grasp, causing problems in practice.
In addition, iterative development - this kind of software engineering process, including RUP, is consistent with the best practice - and activities, the basic concepts of workpieces. I don't know the relationship between iterations and activities, the workpiece, how do I implement the idea of Iterative development when I actually apply RUP? Also, configuration and change management is an indispensable support for all modern software development processes. RUP is one of the "6 best practices of RUP". But the author found that many developers believe that configuration and change management is too trouble, just because they do not understand the basic relationship between configuration and change management and workpiece. Our task comes from these issues. Can I solve these problems with a picture?
3.2, a picture of the thousand words below the picture is a UML class map, which summarizes the related concepts of the above problems and highlights the relationship between the concept. The rich semantics of this figure, we are analyzed in the following sections.
3.3, role execution activities, any software engineering process for the production of workpieces, there is less than the concept (or similar concept), such as Role, Activity, Artifact.
These concepts themselves are well understood. The role is a provision for the responsibility of individuals or as a group of people in the development team; the relationship between specific people and roles, like people and hats. Activity is the work unit that the role is executed. The workpiece is a finished product or semi-finished product. It is more important to have the relationship between these concepts. The role is responsible, which is reflected in his executive activities and responsible for workpieces. The workpiece is the activity produced - the workpiece is an active output; for example, a "encoding specification" is developed. However, the activity itself may also be input to the input - activity may require the use of workpieces; such as the encoding activity to refer to "Code Specification". There is also a relationship, the workpiece is both an active input and its output - activity modification workpiece; such as modifying "coding specification". 3.4, stages and iteration: Provide different levels of decision-making time to solve significant risks as soon as possible, and is an important principle in software engineering management. As Tom Glib said: "If we don't active risks, then they will find themselves." [2] The heart is very dangerous. RUP is risk-driven. It divides the entire development life cycle into 4 phases: the initial phase, the refinement phase, the construction phase, and the transfer phase. In the initial stage, you will focus on business risk and ensure that all people have a consistent understanding of the project. The refinement phase mainly resolves the technical risk to define and create an executable system architecture. Relatively speaking, the risk is already smaller when deciding to start the construction phase. Of course, risk is dynamic, and there will be such risks in the structural phase and the transfer phase.
Each stage of RUP can be divided into multiple iterative cycles. It is an iterative development means that there is a continuous continuous feedback; feedback is the basis of decision making, and it is also the basis for resolving the risk. One of the main purposes of iterative development is to reduce risks as soon as possible. By analyzing each iteration, sort and resolve the main risks in terms of importance, to achieve the purpose of resolving the risk as soon as possible.
This time based on continuous feedback, called Milestone. There are two milestones, and the corresponding milestone called the main milestone (MAJOR MILESTONE); the corresponding milestone called the secondary milestone (MINOR MILESTONE). It can be said that phases and iterations provide different levels of decision-making opportunities for the development team.
The above figure clearly expresses the thoughts of the above analysis. The milestone is divided into two main milestones and secondary milestones; the stage can contain multiple iterations; each stage must have a major milestone identification end, each iteration necessarily ends with a secondary milestone identity. The specific proceedings of iteration are to perform related activities by role. Multi-to-many relationships in the above figure, wonderful reflecting the characteristics of iterative development - each iteration is performed with multiple (even all) development activities.
3.5, configuration and change management Support Iterative Baseline-based development iterative development means that each successive iteration is based on one iteration, constantly evolving and improving the system until the final product is completed. For a period of history, in order to emphasize this, RUP has specially publicizes "iteration and incremental development". Establish and manage baselines, providing strong support for iterative development. The main points of the baseline are two: First, the second is to be controlled by configuration and change management. IEEE's complete definition of baseline is: A regimental or product that has been formally reviewed and approved, it can therefore be used as a foundation for further development and can only be changed by formal change control processes. Configuration and change management completed the establishment and managing the task of the baseline. The workpiece placed under configuration and change management is called a configuration item - thus the following figure is modeled to the subclass of the workpiece. The baseline is an instantaneous snapshot of multiple configuration items - because the configuration and change management control is the necessary condition of the baseline.
The "Workpiece - Configuration Items - Baseline" is discussed above, and the relevant dynamic concept is discussed below. Any workpiece is likely to change; as not all artifacts are all configuration items, the changes are not necessarily controlled, for example, temporary design for discussion does not have to be controlled. Only the change of the configuration item is to be controlled by configuration and change management. Which workpieces should be controlled and determined based on practical conditions, should be considered in normative and flexibility. 3.6, what is released, released is not released (Release) is a stable, executable version of the software product, which includes published instructions, user manuals and other related artifacts. Simple document or unforgettable software version is not published. Publish is the result of a certain iterative cycle, but not every iterative cycle is published. It is very clear that it is a special baseline. This means that the release is not a single workpiece, but the workpiece set; and the published workpiece should be placed under the control of configuration management, because you must identify and track many of these artifacts, developing teams or users, many activities and them Related.
4. Summary UML has been widely used for software development activities, visual expression makes it easy for understanding and solving problems. This article is another application of UML, which is used to clarify the relationship between the concept, I hope to inspire everyone.
Reference: [1] Gary Police is waiting, Song Rui and other translations. Small team software development: RUP-centric approach. China Power Press, 2004 [2] Per Kroll is waiting, Xu Zhengsheng et al. Rational Unified Process: Practitioner Guide. China Electric Press, 2004
About the author: Wen Wei, architect designer, loose coupling space (http://lcspace.nese.net) founder. Good at object-oriented, architecture, and frame design, have an in-depth study of design patterns, UML and software engineering. You can contact the author via wenyu@china.com and the author.
