Use Rational Tools to simplify J2EE-based projects Part 1: Transition to System Models

This article demonstrates the series of Rational tools used in distributed, J2EE-based projects.Article(As listed below.

• Part 1: Project Introduction and high-level planning
• Part 1: risk management and demand management
• Part 1: model creation and access control; Requirement Analysis
• Part 1: Refined use cases, production reports, and selection of tools and technologies
• Part 1: architecture and design
• Part 1: Detailed design; early development; Bidirectional Engineering; early Unit Testing
• Part 1: Continue development; early build; Demonstration
• Part 1: unit test policy; function test; GUI test script
• Part 1: system construction and testing; defect tracking; Product Delivery
• Part 1: project completion; Conclusion; Future Work

In this article, we are a fictitious software company lookoff technologies inreceivated. Our customer audiophile speaker design, Inc. (ASDI) hired us to fulfill their initial it needs. For more information, see section 1st.

This Part 1 focuses on the early modeling activities completed in Rational Rose. First, we will model the existing ("as is") system of ASDI, and use cases and business objects to show how the current task works. We will create a system model that reflects the existing system model to meet the new requirements of ASDI, and use this system model as the basis for building software.

With this article, we have two speeches (from the rational User Conference 2000), which discuss the following topics: yves Holvoet's "maintain the synchronization between analysis models and multiple design models" and Robert bretall's "structured your Rational Rose model ". The last speech is accompanied by a rose model.

Part 1 snapshots

Part 1 tools and technologies used: Rational Unified Process (RUP)-Guides the software development process and provides suggestions for each stage of the project. Rational Rose Enterprise Edition-To create the "current" business model (using the Unified Modeling Language (UML) and create a "future" System Model Based on the Analysis clues Created or updated work product: Business Case model (Rational Rose)-Created to represent the "current" business functions of the system Business Object Model (Rational Rose)-It is created to capture how the system's "current" business functions are executed: collaboration between entities, interaction between entities, and related processes and products. Use Case model (Rational Rose)-The business case model cannot be completely expressed. It is created to obtain detailed system "future" execution functions (which serves as the basis for building software)

Capture the "current" System

There are too many new and improved IT systems started before the existing systems are understood. Even if the existing system still lacks IT components, it is necessary to analyze the current business activities before the optional and improved solutions are recommended. However, this step is always skipped or completed, but this will cause the following problems:

• Insufficient understanding of the customer's needs, slowing down the subsequent analysis
• Incorrect explanation of requirements
• The impact of the new solution cannot be accurately estimated, causing a huge vibration to the customer's work when the software is delivered to the customer and requiring the customer to completely change the existing workflow.
• Inconsistent terms and concepts lead to misunderstandings and confusion in communication 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 helps us in creating this model is the working state (SOW ). Although sow is mainly used to describe the requirements of the "future" system, it also provides useful background information about the current business process of ASDI.

In the initial phase of Rational Unified Process (RUP), there are a series of methods for business modeling (also in the 1st phase of our project ). To create an IT system together with ASDI, we need a "current" model to capture the flow of files and the interaction activities of their current system. In Rational Rose, we created the following RUP work product as part of business modeling:

• Business Case ModelTo model "current" business functions.
• Business Object Model(Sometimes calledDomain Model) To model the relationships between the objects that execute business functions and these objects. A business object model may show how an invoice is generated and transferred in the system, or the process from the beginning to the end of a purchase request.

Note that in some previous projects, we skip the business modeling step because we build a brand new system or because we have a good understanding of the existing business model. However, this step is very important because we are unfamiliar with the ASDI business.

We also consider developingBusiness Glossary(Using the work product template provided by RUP), but we find that most of our terms are fairly standard and clear, these terms are fully captured in our business object model. More complex or rigorous projects will benefit from creating business glossary to ensure consistency across all products.

When we use Rational Rose to create our model, we feel that simple graph creation is not enough. We found that it is easy for the graph creator to express the model only through graphs, but it is difficult for the readers to understand the graph, therefore, we have attached a document for each graph (by clicking on the graph and entering text in the document window ). We also provide documents-use cases, Business Objects, users, or other items-for each item in the figure. One or two lines of text are used to describe each item.

Create model

We create our new model file from a starting point (ASDI. MDL), We use the rose template that complies with the structure defined in the RUP (see figure 1 ). Because we have done a lot of work in the RUP, it will make us work well. The model template of the RUP can be seen when Rose is started. We can access one of the several templates through the wizard, or you can apply the template in Rose.ProgramOfFrameworksDirectory.

Figure 1:RUP model template

We have made some changes to the template structure to meet our needs and selection. For example, we made the following changes:

• Instead of tracing the included use cases that are separated from other use cases, we organize these use cases into a logical package that contains their functions. We feel that the <include> prototype can be combined with the reporting capability of rational soda, so that we can easily identify included use cases when necessary.
• We deleted the analysis model in the logical view. You can read the Yves Holvoet speech to learn about the positive and negative views of the Analysis Framework reuse and analysis/design cases. We don't need to decide a layered analysis model because we don't expect most business models in the ADSI system to be reused in future projects. Instead, we allow use cases to evolve throughout the project.
• We first divide the design model through the business components, and then divide them into layers (these two tasks are usually different), rather than dividing the model at the beginning.

Next, we must add a schema area to the model so that database architects can track data modeling.

Manage Models

It usually takes some effort to allocate the rose model to the package according to the responsibilities of different team members. The package structure should be created to make it easier to share responsibilities among team members. This can be achieved by dividing the system into different parts: Analysis (for example, use Cases and Business Objects), system architecture and design.

Although our team is not very large, we still need to consider the collaboration issue above the model. I have several floating licenses for Rational Rose, which is enough for all of us to access the model at the same time, but we also need to enable usConcurrentAccess a part of the model. Therefore, we use the "unit control" feature of rose to properly decompose the model.

Roles in the organizational structure of our team (as described in section 2nd) All the input and update accusations of these roles for each part of the model are shown in table 1. Therefore, other members in the team, such as junior developers and project engineers, will only have access to the model to complete their development.

Role	Enter/update responsibilities
Team Lead/Senior Analyst	Packaging Management Case model (Business and System) Business Object Model Architecture Design
Senior developers	Architecture Design
Database architect	Architecture Schema Design

Table 1:Model input/update responsibilities

We have decomposed the model, and the Rose diagram shown in 2. At this time, the structure of this model serves our needs, because three of us directly maintain this model. In the future, when teams and projects expand gradually, this model structure can be easily decomposed into more*. CatFile.

Figure 2:Model Decomposition

Additional information on decomposing the rose model can be found in Robert bretall's speech. Here we only point out a few valuable things from its model structure discussion:

• It is best not to place the content on the top of the model. (In our case, all the information is put under control.*. CatFile .)
• If you plan to reuse some parts of your system model in future projects, consider layering the analysis model. (You can also find more information in the Yves Holvoet speech. )
• If the model structure is created based on the guidance of the rational, the rational tool (soda, Rei script, etc.) will more effectively interact with the model.

Use the Rational Rose decomposition model to become a separate*. CatFile is very easy. 3. Right-click the package we want to control in a separate file, and select units> control use-case model from the context menu, this allows us to control this package and all sub-items in this package. Later in the project, we will reorganize some*. CatThe file becomes the product of several smaller controlled packages for further release modeling.

Figure 3:Create a separate*. CatFile

Modeling users and interfaces

OneRole)Is the external person or thing that interacts with the system. This can be the person who uses the system or another interface type. Modeling System users and interfaces and their dependencies are very useful; it not only gives you a complete entity of the system, it also provides you with good information about future security and role modeling.

Figure 4 shows how we add roles to our business model in Rose-especially in a customer service-related use case diagram, which is taken from our business case model. Two special prototype classes are used: Business Role and business use case. Rose can assign custom icons based on the prototype, in addition, we chose this method to apply a slightly different icon to the use case and role assignment appearance-adding a diagonal line-because we think the difference between the system model and business model used to build the software is important.

Figure 4:Extract the use case model of Customer Service

(Click to enlarge)

When we enrich the business case model, a series of good candidates will appear for the business object model. Although creating a "current" system's business model seems to be a lot of work (the main workload is generating graphs), we think it is worthwhile. In our past "current" model, there have been a large number of comments and formal technical comments in the lab workbooks. To get a clearer and complete view of existing business processes, you should spend some time capturing this information in Rose.

Understanding system interaction

Sometimes people focus on a single part of the system, but in fact the interaction between all parts of the system is also very important. Fully considering the interaction of the entire system part will make the integration of all parts of the system more common and likely. This is one of the reasons why we later used the interaction diagram (displaying the interaction between various parts of the system) to verify our design; this is critical to identifying the process and fixed gaps in analysis and design.

Interactions that we focus on early in the project:

• Business Case-to-role (what types of individuals and interfaces access various business tasks we have identified)
• Business Objects (How do Business Objects interact with each other and share information with them)
• Use Case-to-use case (dependencies between tasks and public tasks shared by a certain process)

We spent some time capturing our understanding of the current business organization and process in rose. The result is a business object model that is very useful for us to understand the existing system. The diagram in the object model (one shown in figure 5) is similar to the standard class diagram, except that they use a special prototype class: business Entity, business control, and business role. Business entities represent passive domain objects, such as invoices or reports, and business control is the object for executing functions, which can indicate alarms or mechanical functions. (The business role has been discussed before .)

Figure 5:Business Object Model excerpt

After business case modeling, we quickly started business object modeling. The description of the business case determines a series of appropriate business objects. For objects that span multiple use cases, such as "purchase request", "product", "Product queue", and "Transport queue" are key objects in the identified business field. Sometimes if we realize that it is inappropriate or has been overwritten by other objects, we will delete this business object. In this way, you can quickly filter business objects related to the ASDI business in tasks (use cases) and transactions (Business Objects.

In some cases, the business object model will evolve into a system class. This is basically true for object objects. Object objects are usually mapped to a container class or a database table. In other cases, the business object model is simply used as a combination of points for understanding the reference of the customer domain. We confirm that the customer has fully understood the graphical symbols and the content of each graph, as their inspection and approval are critical.

All in all, we spend a lot of time on business modeling. This is not necessarily first-class or complete, but we should be able to have a sufficient understanding of the current business process. After the first or two months of the project, we will seldom mention the business model, but we think it is worth the time, because it is a necessary step to form a "future" system model. When a new member joins our team, we can browse the business model to help them understand the new field. However, once we get familiar with it, the business model is rarely viewed, unless it is a clarification term.

Convert sow to use case

To plan a "future" system, we need to convert sow requirements that have been expressed in text form (discussed in Part 1) into well-thought-out use cases. In other words, by creating the Business Use Cases of the "current" system (as discussed earlier), we prepare to refine these use cases for the "future" system. This is not a quick step, but it takes more than two weeks. (In terms of RUP, this transformation reflects a gradual transformation process from the initial stage to the refinement stage .) Our work on business modeling has gained experience in the current system and divided its functions into business use cases, which is very helpful to me. (The documents in the RUP show the evolution from the business case model to the Business Object Model and the system case model. We find this is very correct and helpful .)

We are not worried about ing sow requirements to "current" system business cases because many of sow requirements do not exist in the current system. The business model we created earlier is just a temporary product, which is used to ensure that our team understands the current ASDI system.

Use case description

A series of workbooks and work products (including those listed below "references and other resources") explain the benefits of case modeling and understanding requirements. We found that many of the advantages mentioned are true, although defining the content of a case is not a trivial task. Compared with good text descriptions, if the use cases are not well designed, they certainly do not work for you.

Here are some misunderstandings when creating use cases:

• The case is created too large or too small.
• Use Cases are inconsistent across teams
• No good plan for case grouping packages
• Unreasonable model access control leads to conflicts in the Process of Team analysis and collaboration
• Define a case with too much detail and define everything before the case enters the prototype, design, and development task.
• Defining use cases is too simple, so that the requirements can be explained by the engineering team.

As a result, we decided that the use case modeling standards and guidelines should be defined by the leader. These include the following guidelines:

• Typical use cases include 10 to 20 days of Development and unit testing. This is not a rule of RUP, but it is a good rule for us. If we find that the use cases are too large or too small than this standard, we will spend extra time checking them to ensure they have a proper range.
• The engineering team must reach an agreement on the package structure at an early stage. This structure may change, but the change should be discussed with the team first.

When deciding what should be included in our use case, we should follow the Guide "fine tuning rose to complement your process" stated in the article ":

• Identifier-Name, unique ID, prototype, traceable requirement, and description
• Description-Description and change of the main process in the start and end statuses
• Note-Temporary notes for "Notes"

From "current" to "future" Evolution

When we move from "current" to "future", many of our business roles are evolved into real users and interfaces in the system, although meaningful refactoring is necessary. This is natural, because when other roles are redefined, the new IT solution unifies some of the original roles. Some business entities disappear as abstract concepts, while others are mapped to classes through schema or detailed design.

Figure 6-9 shows part of the "future" system use case model generated by our early work. With the help of graphs, collaboration graphs, timing graphs, and further detailed analysis, it will mature over time.

Figure 6:Early Role Models

Figure 7:Core Customer Service Cases

Figure 8:Customer Order Case

Figure 9:System Management Cases

As described in the RUP, "the most important purpose of case modeling is to communicate system behavior with customers or end users ." However, increasing complexity can lead to the risk that our customers may feel uncomfortable. We find that introducing more advanced inclusion and extension relationships in the use cases is very valuable when we enrich the use cases. When checking our use case model in detail, included and extended use cases frequently appear. We found that even when we understand the external interface view of the system (including users), grouping functions by including and expanding use cases produces benefits in important plans, architectures, and tests. However, when we see that the customer has no confidence in checking these advanced relationships, we sometimes remove included and extended use cases from the check package.

Summary

We now have a picture describing the existing processes and entities in the ASDI business, and have a good start in modeling the tasks and roles of the system to be built. Although there are some discussions on skipping business modeling within the team, we feel that our work will be rewarded. The other benefit is that it makes it easy for customers to enter the use case at a comfortable and relatively non-technical level.

Case modeling varies significantly between different projects. The definition of cases, the relationship between cases, and the degree of detail are often controversial. Finally, we found that when we show our use case model to customers, consistent and frequent checks are the key to success.

Plan the future

We need to get strong technical progress. Customers are asking us for more user interfaces and,CodeInformation about the prototype and tool selection. We must begin to provide screen simulation and consider appropriate technical options; now it is important to start using more practical, technical products and purchasing tools (especially if we need more training ).

Although we have not yet begun to enter the architecture stage, we know that the system must be web-based and cross-platform. At the same time, from prototype to enterprise-level solutions can be expanded. We have learned J2EE, and the IT manager hired by ASDI is also the preferred technology platform. Therefore, we feel that it is wise to start exploring the costs and capabilities of J2EE. Our team does not need much training in this field. This is another factor. Data storage should be considered more. However, IT managers strongly recommend the object-oriented database (OODB) solution. Because we are more familiar with relational databases, this is a difficult journey for us, but we still agree to the OODB solution.

We informal reviewed all our work products with our customers, but it was time to perform a formal check. In the next few weeks, we will create our rational soda template so that we can provide our first formal delivery: detailed software requirements. We agree that this document should include use cases and non-functional requirements (reliability, availability, etc ).

Our use cases are starting to stabilize and start to specify a suitable traceable location for sow. We need to use rational requisitepro to ensure that the soing between sow and our use case is maintained.

Our next direction should be:

• Technical progress, especially the selection of tools and technologies
• Create necessary rational soda templates to generate our first formal document
• Refine our use cases to add trackability to sow

Major Risks

We still feel that the time is very tight, and there are some discrepancies in the time progress or budget-and our risk list is still growing, we have not even begun any serious technical exploration. There are the following new risks:

• Too many people involved in the competition, sometimes there is a degree of opinion on the function of the system. We need to clarify the process with the customer.
• If we choose the OODB solution, we must expand our depth, which will generate forced training and uncertainty about the time schedule of the engineering team.
• The customer was eager to ask for the important formal and detailed work Outcome of the first stage, and what we imagined was just a conceptual validation. We still communicate with our customers about the RUP and try our best to increase their comfort in the work products and symbols in the RUP.

References and other resources

• UML premium version 2: Overview guide for standard Object Modeling LanguageBy Martin Fowler and Kendall Scott (Addison-Wesley, 1999)
• Unified Modeling Language User GuideGrady booch, James Rumbaugh, and Ivar Jacob (Addison-Wesley, 1998)
• Rational uniied process: Version 2Philpe kruchten (Addison-Wesley, 2000)
• Download the 2000 speech from the rational User Conference:
• "Maintaining an analysis model in synch with multiple design models" by Yves Holvoet
• "Structuring your Rational Rose model" by Robert bretall

about the author Steven Franklin has extensive background in software design, architecture, and engineering processes., these experiences are usually used in large distributed information management and control systems. He has been using Rational tools since 1997 and is primarily interested in XML, J2EE, wireless, and software engineering technologies. You can contact Steven via steve@sfranklin.net.