Figure 1: Analysis of the core concepts of RUP

Figure 1: Analysis of the core concepts of RUP Original Author: wakeful
Reprinted Please note: From the sawin system analysis window
Last modification time: 2005-2-22

 

 

A picture is better than a thousand words: RUP Core conceptsIn practice, the author found that the understanding of concepts is not in place, especially the relationship between concepts, it is one of the reasons that impede the successful application of the RUP by many people. This article uses the modeling of concepts and their relationships to investigate the concepts and their relationships, in order to gain an in-depth understanding of the core concepts of RUP. 1. Clarify the necessity of conceptsWith the continuous development of software and software, there are more and more "terms. However, is the meaning behind the term growing so much? For example. In 1986, Barry Boehm proposed a software development spiral model. Since then, the spiral model has been treated as a standard method for software development. The spiral model has other common names, such as the evolution model or the iteration model [1]. There are many similar examples. It seems that there are many such phenomena in the software field: A new term appears. It may only wear a new form of expression, but its meaning is actually the same as an old term. The author believes that, in today's rapid development of the software discipline, it is the most convenient way to understand the true meaning behind the many terms of "Changing infinity. 2. Methods in this article:This article uses the modeling of concepts and their relationships to not only evaluate the meaning of a single term, but also the relationship between nouns. A picture is better than a thousand words. The essence of a concept often needs to be reflected in its relationships with other concepts. This method not only examines individual, but also examines the relationship between multiple individuals. In system theory, it is compared to "1 + 1> 2 ". What is pleasant is the other side of the coin. The method of focusing on the relationship is "1 + 1 <2" in terms of cost ". 3. Analysis of the core concepts of RUP 3.1 task source ProblemsThe well-known two-dimensional structure of RUP. Its time-dimension concepts include stages, iterations, milestones, etc. The content-dimension concepts include workflows, roles, activities, and artifacts. However, I found that many people do not have a deep understanding of these concepts, especially the relationship between them, which leads to problems in practice. In addition, it is iterative development-this kind of best practice that is consistently favored by various software engineering processes, including the RUP-what is the relationship with the basic concepts of activities and artifacts. I don't know the relationship between iterations, activities, and artifacts. How can I implement the idea of iterative development in actual application of RUP? In addition, configuration and change management is essential to all modern software development processes. It is also listed as one of the six best practices of RUP. However, I found that many developers think that configuration and change management is too troublesome, just because they do not understand the basic relationship between configuration and change management and artifacts. Our tasks come from these problems. Can I use a picture to solve these problems? 3.2. yitu wins qianyanIt is a UML class diagram that summarizes the concepts related to the above problems and focuses on the relationship between concepts. The rich semantics of this image is analyzed in the following sections. 3.3 role execution activities, activity production artifactsIn any software engineering process, role, activity, artifact, and other concepts (or similar concepts) are indispensable ). These concepts are well understood. Roles are the responsibilities of individuals or a group of developers. The relationship between specific people and roles is like the relationship between people and hats. Activity is the unit of work for role execution. The workpiece is the finished or semi-finished product. However, the relationship between these concepts is even more important. The role's responsibilities are embodied in its activities and responsibilities. The workpiece is produced by the activity. The workpiece is the output of the activity. For example, the coding specification is formulated. However, the activity itself may also be input by the workpiece-the activity may require the use of the workpiece; for example, the encoding activity should refer to the coding specification. There is also a relationship between the input of an activity and the output of an activity-modifying an activity, for example, modifying the code specification. 3.4. stages and iterations: provide different levels of decision making opportunitiesSolving major risks as early as possible is an important principle in software engineering management. As Tom glib said: "If we do not take the initiative to resolve risks, they will come to the door on their own ." [2] It is dangerous to be lucky. RUP is risk-driven. It divides the entire development lifecycle into four stages: initial stage, refinement stage, construction stage, and handover stage. The initial phase focuses on resolving business risks and ensuring that all stakeholders reach an agreement on the project. The Refinement phase mainly resolves technical risks and defines and creates an executable system architecture. When determining the start of the construction phase, the risk is relatively small. Of course, risks change dynamically, and there will still be such risks in the construction and handover phases. Each stage of the RUP can be divided into one or more iteration cycles. Iterative development means continuous feedback. Feedback is the basis of decision-making and the basis for Risk Resolution. The main purpose of iterative development is to reduce risks as soon as possible, and resolve risks as soon as possible by analyzing in each iteration, ranking by importance, and solving major risks. The timing of making decisions based on continuous feedback is called milestone ). There are two types of milestones. The milestones corresponding to the end of the phase are called the main milestone (major milestone), and the milestones corresponding to the end of the iteration are called the secondary milestone (minor milestone ). It can be said that stages and iterations provide different levels of decision-making opportunities for the development team. The above analysis ideas are clearly expressed. Milestones can be divided into two types: major milestones and secondary milestones. stages can contain multiple iterations. Each stage must end with a major milestone identifier, and each iteration must end with a secondary milestone identifier. The specific process of iteration depends on the role to execute relevant activities. The many-to-many relationship between iterations and activities highlights the characteristics of iterative development-multiple (or even all) development activities are executed in each iteration. 3.5 configuration and change management support iterative baseline-based developmentIterative development means that each subsequent iteration is based on the previous iteration, and the system is continuously evolved and improved until the final product is completed. For some time in history, in order to emphasize this point, RUP has specifically promoted "iteration and incremental development ". Baseline is established and managed to provide strong support for iterative development. Two key points of the baseline are as follows: one is to pass the review, and the other is to be controlled by the configuration and change management. The full definition of the IEEE baseline is a protocol or product that has been formally reviewed and approved. It can therefore serve as the basis for further development and can only be changed through the formal change control process. Configure and change management to complete the task of establishing and managing baselines. Artifacts placed under configuration and change management are called configuration items. Therefore, configuration items are modeled as subclasses of the artifacts. A baseline is an instantaneous snapshot composed of multiple configuration items-Because configuration and change management control are necessary for a baseline. The static concepts "artifacts-configuration items-baselines" are discussed above. Next we will discuss the dynamic concepts. Any artifacts may be changed. Just as not all artifacts are configuration items, changes may not be controlled. For example, temporary designs used for discussion do not need to be controlled. Only configuration item changes need to be controlled by configuration and change management. Which artifacts should be controlled depends on actual conditions and should be weighed between standardization and flexibility. 3.6. What is publishing and what is publishing?Release is a stable and executable version of a software product. It includes release instructions, user manuals, and other related artifacts. A document or a software version that cannot be executed is not published. Publishing is the result of an iteration cycle, but not every iteration cycle uses Publishing. The figure shows that publishing is a special baseline. This means that publishing is not a single workpiece, but a collection of artifacts. All published artifacts should be placed under the control of configuration management. This is because you must identify and track these artifacts, many activities of the development team or users are related to them. 4. SummaryUML has been widely used in software development activities. Visualized expressions make it easy to understand and solve problems. This article is another application of UML. It is used to clarify the relationship between concepts and hope to inspire everyone. References:[1] Gary pollice, translated by Song Rui. software development for small teams: a rup-centric approach. translated by Xu Zhengsheng, China Power Press, 2004 [2] per Kroll. rational Unified Process: practitioner guide. china Power Press, 2004

 

[Author]Wakeful

Wen Yu, architect, Senior Consultant, founder of loosely coupled space (http://lcspace.nease.net. He is good at object-oriented, architecture and framework design, and has in-depth research on design patterns, UML and software engineering.
Author email address: xinxiu123@sina.com