Part 3: Convert to system model
Steven Franklin Software Designers and Process March 2004
This article will continue to introduce this comprehensive application RUP and other Rational tool sample projects to introduce the Rational Rose model of the project. In this article, we will start to create a system model representing the "current" business situation, and convert this business model into " In the future "system model.
This section 3 has focused on early modeling activities completed in Rational Rose. First we are modeling the existing ("AS IS") system, how to display the current things through business use cases and business objects. We will create a system model that meets ASDI's new needs from this model that reflects the existing system, and the system model is used as the basis for establishing software. With this article, there are 2 speeches (from the Rational User Conference 2000) discussed the following topics: Yves Holvoet "Maintenance Analysis model with multiple design models" and Robert Bretall "Structured Your Rational Rose Model ". The latter speech comes with a ROSE model.
Part 3 Snapshot Item 3: Tools and techniques used in Part 3:
Rational Unified Process (RUP) - Guide the software development process, providing recommendations for each phase of the project and Work Products RATIONAL ROSE Enterprise Edition - In order to create a "current" business model (using a unified modeling language (UML)) and On the basis of analyzing clues, create a "future" system model is created or updated work product:
Business Trim Rose - Create Used System "The" Rational Rose "- How to capture the system" Current "business feature is executed between the entity Collaboration, entity interaction and related process and product use case model (Rational Rose) - cannot fully represent business case models; created to get detailed system "future" execution function (it is the basis for building software)
Capture "Current" system has too many new and improved IT systems to be started before the existing system is understood. Even when the system has lacks IT components, it is necessary to analyze the current business activity before the optional and improved solutions are recommended. However, people always skip or have the completion of the grass, but this will result in the following questions:
The understanding of the needs of customers is not sufficient, slowing the next analysis, the impact of the incorrect explanation of the demand cannot be estimated to estimate the impact of the new scheme, resulting in huge work when the software is delivered to the customer. Vibration and require customers to completely change the inconsistent terms and concepts of existing workflows, leading to misunderstandings and confuses between communications with customers
Creating a business model to capture the "current" system can be a very fast task and can generate useful analysis clues, which will simplify the definition of the "future" system. One thing that can help us in this model is working status (SOW). Although SOW is primarily used to describe the "future" needs, it also provides useful background information for the current business process of ASDI.
There is a series of methods for business modeling (also in our project) in the initial phase of the Rational Uniform Process (RUP). Create an IT system with ASDI, we need a "current" model to capture the traffic of the file and the interaction of their current system. We created the following RUP work products in Rational Rose as part of business modeling:
Business use case model, modeling "current" business function. The business object model (sometimes referred to as a domain model), modeling the relationship between the objects of the business function and the relationship between these objects. A business object model may show how an invoice is generated and how to flow in the system, or a process of starting a purchase request. Note In some of the previous projects, we skip the steps of business modeling, because we are building a new system, or because we have very good understanding of existing business models. But because we are unfamiliar with ASDI, we feel that this step is very important.
We also consider developing a business glossary (using the work product template provided by RUP), but we found that most of our terms are quite standard and clear, and these terms are fully captured in our business object model. . More complex or strict projects will benefit from the creation of business glossomes to ensure consistency in all products.
When we use Rational Rose to create our model, we feel that simple creation is not enough. We have found that only the way the model is expressed in the figure, it is easy to understand, but it is difficult to read the reader of the picture, so we attach a document for each figure (click on the figure. And enter text on the document window). We also provide documentation-use cases, business objects, users, or other items for each of the figures - to describe the purpose of each item.
Creating a model We create our new model file (asdi.mdl) from a start point, we use the ROSE template that conforms to the structure defined in RUP (see Figure 1). Because we complete a lot of work in RUP, this will make us work very well. RUP's model template is you can see when Rose is started, and we can access one of several templates through the wizard, or you can also find them in the frameworks directory of Rose applications.
Figure 1: RUP model template
We have made some changes to the structure of the template to meet our needs and choices. For example, we have done it directly:
Instead of tracking the use cases that are included with other use cases, we organize these use cases to the packets that are logically included. We think it can be <
> The prototype and Rational Soda's reporting capabilities are combined, so that we can allow us to identify the use cases that are easily identified when necessary.
We delete the analysis model under the logical view. You can read YVES HOLVOET speech to understand the discussion of the analysis framework reuse and analysis / design cases. We decide that a hierarchical analysis model is not necessary, because we don't expect major business models in the ADSI system to be reused in future projects. Instead, we allow the use case to evolve throughout the project. We first divide the design model through business components, and then the division of the level (both tasks are usually different), rather than starting to lay down the model.
Next we must add a plan (Schema) area to the model to make the database architect to track the operation of data modeling.
The management model will use the ROSE model in accordance with the responsibility of different team members to the package to the package, usually take a certain effort. The structure of the package should be created, which is relatively simple to share responsibilities between team members, which can be achieved by dividing the system to achieve different parts: analysis (such as through use cases and business objects), architecture and design.
Although our team is not very big, we still have to consider collaboration problems on the model. I have a few Rational Rose's floating licenses, which is enough for all our people to access the model, but we also need to make us access to a certain part of the model. Therefore, we use ROSE's "unit control" characteristics to properly decompose the model. The role in our team's organizational structure (as described in Part 2) The input and update of the inputs and updates of the models of the model are shown in Table 1. Therefore, other members of the team, such as primary developers and project engineers will only have access to the model to complete their development.
Role Input / Update Responsibilities Piece / Advanced Analyst Packaging Management Model (Business and System) Business Object Model Architecture Design Senior Developer System Architecture Design Database Architect Architecture Scheme (SCHEMA) Design
Table 1: Model input / update responsibilities
We break down the model, as shown in Figure 2. The structure of this model is at this time, because we have three people directly maintain this model. In the future, when the team and project gradually expand, this model structure can be easily broken down to more * .cat files.
Figure 2: Model decomposition
Additional information about the decomposition ROSE model can be found in the speech of Robert Bretall. Here only points from the valuable things from its model structure discussion:
It is best not to place the content on the top floor of the model. (In our case, all information is placed in the controlled * .cat file.) If you plan to reuse some of your system model in future projects, consider layering the analysis model. (You can also find more related information in your YVES Holvoet speech.) If the structure of the model is created according to RUP, the Rational tool (SODA, REI script, etc.) interacts more efficiently.
It is easy to use the Rational Rose decomposition model to become separate * .cat files. As shown in Figure 3, we simple right click on the package we want to control in separate files; then select Units> Control Use-Case Model in the context menu, which allows us to control all the children in this package. Child. Later, in the project, we will reorganize some * .cat files into several smaller-controlled packets to further publish work products.
Figure 3: Creating a separate * .cat file in ROSE
Model User and Interface A Role (actor) is an external person or thing that is interactive with the system; this can be used as a person using the system or other interface type. Modeling system users and interfaces and their dependencies are very useful; it can not only give you a complete entity of a system, but also provide you with good information on future security and role modeling.
Figure 4 shows how we enable roles in our business model in ROSE - especially, in an example of customer service related to customer service, this example is drawn from our business case model. Two special prototypes are used: business roles and business use cases. Rose can assign custom icons based on prototypes, and we choose this method as a single icon for use case and role allocation, add a slash - because we feel that the system model and business model we feel that the system model and business model is important. .
Figure 4: Example of use case model for customer service
When we enrich the business case model, a series of candidate objects will appear for business object models. Although the business model of creating a "current" system seems to spend a lot of work (the main workload is generated), but we think it is worth it. In our past "current" model, there is already a large number of annotations and formal technical comments in the laboratory workbook. In order to get a clearer and complete view of the business process, it should be captured in ROSE in Rose. Understanding system interactions sometimes puts the focus on a separate part of the system, but it is also very important to interact between the various parts of the system. The interaction of the entire system part will make the integration of the system more obvious. This is why we will use one of the reasons for the interactive diagram (display interactions between the systems) to verify our design; this is critical to identify the process and inherent gap in analysis and design.
In the early stage of the project, we focus on interaction:
Business use cases to roles (what kinds of individuals and interfaces access to the various business tasks we identified) Business objects (how to interact between each business object, and share information) use cases ( Task's dependence, and public tasks shared by a certain process)
We spend some time to capture our understanding of our current business organizations and processes in ROSE, resulting in a business object model that is very useful for us to understand existing systems. In the object model (one of the shown in Figure 5) is similar to a standard class diagram, in addition to their special prototype class: business entity, business control, and business roles. The business entity represents passive domain objects such as invoices or reports, while business control is an object of execution, which can represent alarm or mechanical role. (The business role has been discussed before.)
Figure 5: Excerpt of business object model
We start business object modeling soon after the modeling of business use. Description of business uses text determines a series of suitable business objects. If it is an object across multiple use cases, such as "purchase request" and "product", "product queue", "product queue", and "transport queue" are key objects identified. Sometimes we realize that it is not suitable or has been overwritten by other objects, we will delete this business object. In this way, the business object related to the ASDI service can be quickly filtered in task (use case) and things (business objects).
In some cases, the business object model will evolve into system classes. This is basically correct for entity objects, and physical objects are typically mapped to container classes or database tables. In other cases, the business object model is simple as a binding point to understand the reference to the customer's domain. We confirm that the customer has fully understood the graphical symbols and the contents of each figure, because their inspection and approval are critical.
All in all, we spend a lot of time in business modeling. This is not necessarily a first-class or complete, but for us, it should be a sufficient understanding of the current business process. After the first or two months of the project, we will raise business models, but we feel that it is worth time, because it is a necessary step in forming a system model of the "future" system. When a new member adds to our team, we can help them to understand new areas by browsing business models; however, once it is familiar with it, the business model will rarely be viewed, unless it is elucidated.
Convert SOW to the use case program "future" system, we need to convert the SOW requirements represented by text form (discussed in Part 2) into a well-thoughtable use case. In other words, through the creation of "current" system's business use case (just as discussed earlier), we are ready to refine these use cases. This will not be a quick step, but it experiences more than two weeks. (In the RUP term, this conversion reflects a step-by-step process from the initial stage to the refinement phase.) We work in business modeling, gaining the current system experience and dividing its function into business Use case, this is very helpful to me. (RUP documentation shows the evolution of business use cases to business object model and system case model; we found that this is very correct and helpful.) We don't worry about mapping SOW demand to "current" system business use case Many of the SOW demand does not exist in the current system. The business model we have created earlier is just a temporary product, which is used to ensure that our team understands the current system of ASDI.
Use an example to explain a series of workbooks and work products (including those "references and other resources" that are listed later) explain the benefits of using example modeling and understanding. We have found that many benefits mentioned are true, although the content of the defined case is not a trivial task. Compared with a good text description, if the use case is not well design, it is certainly useless for you.
Here is some misunderstandings when starting to create an example:
The use case is created too large or too small cases in the case where the team is inconsistent with the unreasonable plan unreasonable plan unreasonable plan unreasonable, resulting in a conflict in the process of team analysis collaboration. Define the use case, define everything when you use an example to enter the prototype, design, and develop tasks, which is too simple to define everything, so that the demand can have many explanations
As a result, we decided to use the example modeling standards and guidelines to be defined by the group. These include the following guidelines:
Use examples typically get 10 to 20 days of development and unit testing. This is not RUP rules, but this is a good rule for us. If we find that the case is too large or too small than this standard, we will take additional time to check them to ensure that they have a suitable range. The engineering team must agree on the structure of the package early. This structure may change, but changes should first be discussed with the team.
When determining what should be included in our usage, we should follow the guidelines pointed out in the article FINE TUNING ROSE to Complement Your Process:
Identification - Name, Unique ID, Prototype, Tracking Demand and Introduction Description - Starting Status, End Status Main Arrangement and Change Comments - Temporary "Quick Sign Book" comment
From "Current" to "future" evolution as we move from "current" to "future", many of our business characters have been evolved into real users and interfaces in the system, although meaningful reconstruction is necessary. This is natural because the new IT program is unified when redefining other roles. Some business entities disappear as an abstract concept, while others are mapped into classes through a plan (Schema) or detailed design.
A portion of the use case model for "future" system is shown in Figures 6 to 9. With graphics, collaborative drawings and timing charts and further detailed analysis, it will be mature over time.
Figure 6: Early role model
Figure 7: Customer service case
Figure 8: Customer fixed-order use case
Figure 9: System management case
Just like RUP description, "the most important purpose of modeling model is to communicate with the customer or end user communication system." However, increase complexity can lead to our customers, we can feel uncomfortable, we found that when we fully use case It is very valuable to introduce more advanced inclusion and extended relationships in use. When checking our use case model, the use cases that are included and extended frequently. We have found that even we understand the system's (including user) external interface view, group functionality in an important plan, architecture, and test by inclusion and extension. However, when we see that customers don't have confidence in checking these advanced relationships, we sometimes take the use cases that are included and extended from the check package. Summary We have now a screen that describes the processes and entities in the ASDI business, and has a good start on the modeling of the tasks and roles that will be constructed. Although there are some discussions on jump over business modeling in the team, we feel that our work will receive a return. Other benefits are that it enables customers to enter the use in a comfortable and relatively non-technical level.
The model model between different projects has a significant difference; the definition of the use case, the relationship between the use case, the extent of detailed, and the like are often argued. Finally, we found that when we show our use model model, the consistent and frequent check is the key to success.
We plan to get technical powerful progress in the future. Customers are requesting us more information about the user interface, code prototypes, and tools. We must begin to provide screen simulations and start considering the choice of appropriate technology; now it's important to start using more actual, technology products and purchase tools (especially if we need more training).
Although we have not started to enter the architecture phase, we know that the system must be web-based and cross-platform, while the prototype to enterprise-level programs can be expanded. We have already learned J2EE, and the IT manager hired by ASDI also preferred this technology platform. Therefore, we feel that the cost and ability to start exploring J2EE are wise. Our team does not need too much training in this field, this is another factor. The storage of data should be considered more, however, because IT managers have tried to advocate object-oriented database (ODB) schemes. Because we are more in relation to relational databases, this is a difficult path for us, but we still agree with the OODB program.
Our informal trials of our work products, but our clients are time to check. In the next few weeks, we will build our Rational Soda template so that we can provide our first formal delivery: detailed software needs. We agree that this document should include use cases and non-functional requirements (reliability, availability, etc.).
Our use case begins to stabilize and start specifying the right trackable location for SOW. We need to use Rational RequisitePro to ensure that SOW is mapped between the SOW and our usage.
Our next direction should be:
Technical advances, especially tools and technologies to choose the necessary Rational Soda template to generate our first formal document refine our use case to add traceable to SOW
Main risks We still feel that time is very tight, and there is some time schedule or some of the budget - and our risk list is still growing, and we have not started any serious technical exploration. Among them, there are new risks:
Surrounded by excessive competition, sometimes there will be spear views in the system. We need to clarify the process of clarifying customers. If we choose an OODB solution, we must expand our depth, so this will have an forced training and an uncertainty of the time progress of the engineering team. Customers urgently require an important formal and detailed work product of the first phase, and we envisaged this is just a conceptual confirmation. We still communicate with our customers, and try to increase their comfortable feelings in the work products and symbols in RUP. Quote and other resources
UML Essence Second Edition: Summary Guide Martin Fowler and Kendall Scott (Addison-Wesley, 1999) Unified Modeling Language User Guide Grady Booch, James Rumbaugh, and Ivar Jacobson (Addison-Wesley, 1998) Rational Unified Process: Philippe Kruchten the introduction of the second edition (Addison-Wesley, 2000) 2000 speech from the Rational user Conference Download: Maintaining an Analysis Model in Synch with Multiple Design Models by Yves Holvoet Structuring Your Rational Rose Model by Robert Bretall
