Apply Rational Tool Simplify J2EE-based projects

Application Rational Tool Simplifies J2EE-based project (1)

The first part introduces Steven Franklin Software Designers and Process experts in March 2004. This series of articles consisting of many articles tells how to use the Rational Unified Process (RUP) and other tools for Tight time and budget. To develop a software item. The first part of the article contains high-level planning and demand. RAIONAL's development kits support two-way engineering (RTE), distributed, and collaborative development, highly iterative development cycles and more features. This first part of this series of many articles will show you the role of the Rational tool and show you that you can simplify distributed J2EE (Java 2 Platform, Enterprise Edition) by using Rational tools. We will look at a single fictional project and the introduction of high-level plans and demands as a development and will transition to various stages of the Rational Unified Process (RUP). This article assumes that you have a certain understanding of RUP; if you don't know RUP you can view the relevant resources listed in the article. For the sake of simplicity, we don't want to complete all the necessary iterations in the RUP, but only in each stage of the project. The characteristics of the tool used. We will follow our small sample project, complete its first main building, as follows: Understand the concept of RUP and the use of Rational Tools, apply them to deal with remote development, tight time planning and limited time Budget Challenges Using Rational Technologies Implementation of end-to-end-end-to-end management management in J2EE projects integrated Rational tools in J2EE projects, completes automated testing, bidirectional engineering, geographic distribution code check and quality assurance (QA) Rational technology and J2EE tool integration For the final solution, in particular the application J2EE, the relationship database such as DB2 or Oracle and the Java integrated development environment This series of articles have similar organizational form, each article starts with a road sign, like the following As, each link will be part of the corresponding article. Part 1: Project introduction; high-level plans Part 2: Risk management; requirements management Part 3: Model creation and access control; demand analysis Part 4: Use example refine; production report; tools and technology Section 5 : System architecture and design Part 6: Detailed design; early development; two-way engineering; early unit testing Part 7: Continue development; early construction; demo Part 8: unit test strategy; function test; GUI test script Part 9 : System construction and testing; defect tracking; product delivery Part 10: Project completion; conclusion; future work first partial snapshots Tools and technology in the first part of the first part: Rational Unified Process (RUP) - Used for project high-level plans or Updated Work Products: Dante Chart - is created for the purpose of project management, as a baseline that is time progress and project budget is measured. The sample project introduces the virtual assumption in this article is that we are a software company, named Lookoff Technologies Incorporated, our company's main business is in IT systems, including integration, support, and development. Our headquarters in Toronto and have some small offices throughout Canada. Because our analysis and development team is very close to our large multinational customers, this company's structure allows us to concentrate our experts (typical backend development and project management) in a very good way.

We assume another virtual company, AudioPhile Speaker Design, Inc. (ASDI), this company is located near New Brunswick. ASDI begins with a small company engaged in speaker manufacturing and design, mainly developing some custom speaker schemes for personal users. With the increase of ASDI's reputation, they have developed more mainstream speaker product lines and supplies products to users and electronic stores in Canada and North America. ASDI's technical facilities do not meet their growth needs. They have been difficult to manage orders, plan to produce materials, track part demand and management transportation. More importantly, ASDI customers complain that they lack the ability to browse the availability and delivery. ASDI realizes that the transition from paper and spreadsheets to automated asset management systems is accompanied by risk, and ASDI decides to give all of their IT requirements to a home. They choose our main reason is that our good reputation is very close (easy to support) from their company. Note that although the sample project is fictional, it's based on my personal experiences, observation of other projects, and knowledge I've acquired through excellent books such as those listed under Note: Although the sample project is fictional, but it is based on my Personal experience, observations of other projects and I have obtained knowledge through some excellent books (such as those listed in the end of the article). Like a high-level demand like many small non-IT companies, ASDI realizes their problems, but they don't know what they look like. Their original working state only two papers, and it is a mix of contract, functional, and programming. We are sitting down to discuss each of their needs; the greatest interest here is the contract and programming questions, discussing the following: Contract issues Customer (ASDI) I hope we sign a company fixed price (FFP) contract, contract value One hundred hundred thousand Dollar (CDN), the software system should be delivered within 10 months according to the contract. It is impossible to sign this contract for us without a clear demand vision. This will bring us too much risks and may be unfair to customers, and we can determine that their technical needs will be satisfied. We started the first meeting to discuss the development of the iterations and and incremental software development is superior to the order ("Waterfall"). Our key features of RUP emphasize our customers include: iterative engineering, reducing risks and aggregated programs do doing the most likely to use existing tools, technologies, and developed products to reduce cost enhancement quality. Management and control changes to customers' lack of product customers who create high quality product customers who make up the production of products. Through some discussion, we successfully showed that customers from the beginning to end of the project should have a sufficient understanding of the progress of the project. They also want the project's budget to pay in phases, and ask us to fulfill some obligations when performing projects. Therefore, the project plan is divided into two to the stage: stage 1 - "Conceptual" version of the system creates system. Customers will pay our fees according to the work, but within the preselection of the first phase. Stage 2 - Create a product version of the system, pay the fee according to FFP. For the stage 1, the customer requires the upper limit of 250K CDN, we feel that this budget is very sufficient for the demo version of us to create the first prototype system. We created the Dante chart of Figure 1, which we have shown this point in four months should have a demo version and review with the customer to ensure that at least the first phase of the timetable is roughly synchronized.

(Then we have more closely with them to check this time schedule) Figure 1: Phase 1 Dantecha map is created with Microsoft Visio, but you can easily use Microsoft Project or some similar software Tools to plan your project. This chart is the main purpose of our work to reach the time-proof and milestone, and establish a layered map of the work decomposition structure (WBS), each of the work decomposition structure can be tracked, estimated, and executed. Programming Problem ASDI is an ISO certified company, and they are very faithful, continuous milestones, and wide quality control. They are not a very technical company, they have their own ideas on the process. One of our challenges in cooperation with them is to find a process and a collection that is satisfied with the work product, and will not make our team feel more. They conducted several meetings and highlighted to have a lot of thorough detailed documentation. Moreover, their milestones are sequential, and their thoughts are that every task must end before the next task begins. Their understanding of the process allows us to make greater challenges in the most likely ways. Although ASDI agreed to develop (based on RUP) methods we used iterations and increments, they don't seem to be interested in this approach. They want to get the following things: fixed milestones: System Demand Check (SRR), Preliminary Design Inspection (PDR), and Key Design Check (CDR) Demo Release Factory Upon acceptance test (FATS) and customer acceptance test (CATS We simply insert these milestones into our process (as shown in Figure 1). A formal demand document, a design manual and accept the test document. These are newly-oriented symbols based on RUP methods, and ASDI is not very concerned about all of them, but ASDI still agrees to maintain their high-level levels of their delivery work, so that we can make The work product of RUP meets the work products expected by ASDI. We feel that you can use the Rational tool to generate a document you need, will not cause great hindrance to our process, and you can successfully communicate the information to the customer. Specifically, Rational SODA enables us to generate a document from the model easier. ASDI also plans to hire an IT manager to contact us and is also responsible for maintaining and managing completed projects. We need ASDI's people to join the project, this person should be a technical authority for the project. Unfortunately, this IT manager (for the company is an emerging thing) lacks knowledge of customer operation, just like our team. Summary In a series of meetings that start with our customers, we have achieved some very good progress. ASDI's deliberation is a significant flexibility for delivering products and time, and allows us to develop based on RUP-based methods. We reached a rough time schedule for the project and established a good relationship with our customers. Through discussions with customers, we recognize some risks, followed by our priority and project management we used to divide the task. One of the highest priorities that we should conduct in the future is to start the vision of the project from the customer's work (SOW). We have obtained a probably understanding of customer needs, but we also need to analyze the specific work that needs us. We must also refine our time schedule and start our best in the starting stage as soon as possible. During phase 1, to ensure that a solution is cost-effective and meet customer needs, we must find out how to meet customer needs. Customers have already mentioned that the main factors that decide whether to proceed to the second phase is the maintenance of the final system and the cost of system architecture software / hardware.

All in all, what we should do in the past few weeks include: Customer Working Status (SOW) described in detail in the project, and entering project requirements in Rational RequisitePro. To stage 1 refine the time schedule After successful design, create a project plan to display how to transition to the second phase. Develop a detailed implementation plan to mitigate the beginning of the identified risk main risk project for a few weeks of establishing an effective customer relationship and keeping projects in the right and appropriate technical direction. We don't have much time to find the needs of the technology and integrate these technologies into our team, because the customer's expectation project is very fast. We believe that we must establish a database of databases, we can make action entries, questions, and risks in a centralized lookup database. By publishing this information to the web, you can monitor project information in either a centralized office or a remote development team. If there is a necessary, even long-distance workers can track and update the risk of the project. Application Rational Tool Simplifies J2EE-based project (2) Startup item ===================================== =====================

Part II: Starting items Steven Franklin Software Designers and Process experts in March 2004 This series of series of articles describe how to gradually apply the Rational Unified Process (RUP) and other Rational tools, this article The detailed plan is discussed around management needs and risks. Part 2 Subshot Part 2 Display Tools and Techniques: Rational Unified Process (RUP) - Support Project Plan WORKAMS - Draft Project Vision Document Rational RequisitePro V2001A - Used for Database Rational ClearQuest V2001A - Risk Management Products that will be created or updated: RequisitePro database - is created to store requirements from the customer's work description (SOW); then demand is converted into a more detailed system requirements specifications for direct analysis work. ClearQuest Risk Database - (by modifying the ClearQuest plan) is created to track the project risk From the start plan or plan to fail in a software project, get a good start is critical. You will not only want your early labor to determine the tone of the entire project, but you also want to quickly identify the high-risk and challenges in the system. About more than half of the project's destiny has been destined in the first month of the project, and the factors determined include: not enough budget management (including not good management capabilities, risk priority division) Worse project scope management) The lack of unconventional time schedule of the Silver Bomb Engineering Skills and Experience Rational Uniform Process (RUP) The factors that can reduce the failure of the project by improving the efficiency and guidance of the team's efficiency and guidance team. Good data can affect the administrator of the project to the project management, better tools can support engineering teams, better processes to help software products develop in a foreseeable way. Part 2 of this series will focus on some of the early strategies we can apply to get some things that are swaying in our sample projects. Note That Project Management Involves Some Activities That Aren't Currently Addressed In The Rup. I Highly Recommend The Book Please note that project management includes some activities currently not included in the RUP. I strongly recommend this book to quickly develop: tame crazy software progress It can serve as a further reference for reducing risk factors in the development project. Refining the first phase time Progress We hope to start the software engineering as soon as possible, but we must first get the consent from our customers on a range of schedule issues. We brought the time schedule we have created (at the end of the 4 months) and ended more closely with our customers more closely. The following questions have been proposed, all the questions are justified and some discussion: "Use iterative development, how will the engineering team know how many iterations need to achieve our goals?" "" "" The necessary conditions in the analysis and architecture are reached Before starting design architecture and design, it is uncomfortable to us. "" In 4 months, we will get what functional system demonstration? "" What tools you will use to create a system? We want to start buying And the training process. "This is the main concern of our customers, and we have made every item: Worried that the project spiral continuous progress is not clear delivery. Because ASDI is a very followed ISO standard company, so they tend to develop specific time bottom lines in the order from one to another early. We point out that iterations can reduce risks and avoid elaborate issues with all products. Although the number of iterations may vary during the project, customers can progress than only a single iterative better observations.

Although a single iteration looks more simple, we need multiple iterations to create a system with more cost effective. ASDI's participation in early iterations will give them more benefits, which makes customers have the opportunity to provide their own views on the development system. Worried about the needs and insufficient analysis of omissions. It will be mentioned here that the ASDI ISO background makes them prefer to believe that the analysis should be performed and documentated before any design begins. We emphasize that RUP has the benefits of allowing tasks to overlap execution; that is, tasks in different phases can be performed in parallel. For example, the detailed design can include the creation of prototypes and some other code development to verify design assumptions, reduce performance risks, and more. The waterfall development process has little flexibility and will not provide you with a lot of early warnings for high-risk. Worried about tracking of project progress. ASDI has begun to have a concern of an iterative development method, and they need to see a guarantee that can be made in the project into system demonstration. At this point we can't tell them what is defined. This requires one or two months when we can be determined when we understand the key and high-risk areas of the system. We explain to them that at least system demonstrations should show a deep part of the architecture of the main risks we have identified. We also expect the system demonstration to display the workflow, availability issues, and interactivity between components throughout the system. Worried that we choose tools that they cannot provide or support in the future. This is important for ASDI because they plan to bear the responsibility of the maintenance system after the end of the project. They don't want to see premature use of exciting but risky technologies. In terms of tool selection, we need to make some early exploration work for customers' technical needs, maintenance programs and other needs. The OTS assessment (including what we recommend) will give ASDI to review our standards and reasons for tools and technologies. At this point, ASDI still has no confidence in its own implementation conditions. They currently have few IT infrastructure to promote us quickly decisions. In summary, we don't think we have a time schedule is too confident, and we have confidence to complete the task within the customer's cost. About us to meet the progress of time comics comes from our team structure, in the project team we review the projects with ASDI. As shown in Table 1, we planned to include some part-time character. For example, we have a separate QA personnel in our project, and this person also plays a role in her project; showing her as a 20% role in our project, this thinks in our project She a week: Role Time Commitment Project Management Project Manager 50% Financial Support 15% Quality Assurance 10% Project Engineering Project Engineer 50% Project Support (including Configuration Management, System Management, etc.) Part-time Support and Review Team (Regular Review and Consulting ) Part-time (from projects and projects) Group leader / senior analyst full-time senior developer full-time general developer full-time database architect 25% Table 1: The team structure is always, we plan to need 450 people Workload to create system demonstrations for these four months. During the progress of the project, we will know if we need to add time or completed in advance, and we will also notify the ASDI project. When presenting the system demonstration, we also have to prepare in-depth design reviews, and can show the estimates of the second phase of the project. If ASDI is satisfied with the work of our conceptual inspection (POC) in the first stage, they will develop product-based systems with the 2nd phase of our launch project. Although we are still creating a demonstration of ASDI, ASDI is very happy to see the work we work will be a good input to further develop product system. At least they have been close to the demand for review, screen mode, OTS evaluation, architectural review, two actual version and a system presentation. Managing risks are extremely important from the beginning.

In the previous project, we used Microsoft Excel to manage risks, this time we decided to use Rational ClearQuest to simplify risk input, management, and reporting. ClearQuest is not a cheap tool, and it is not a cost effective tool for risk management. However, it can also centralize our integration and testing issues. In addition, we plan to take this cost in other projects in Lookoff. Using ClearQuest Designer can be very convenient to design new data structures and forms. For example, creating a risk entry form is similar to the defect form that has been displayed in ClearQuest Designer, we can delete some unnecessary entries and renamed others according to the Defect Tracking Schema. Entries, similar updates, corresponding forms, delete, or rename the necessary prompts and domains. Here is how you can test themselves: Suppose you have installed ClearQuest and have administrator, you should be able to find the ClearQuest Designer application. From the File menu, select Create Plan (New Schema) and select an existing plan you want to modify (Schema). We choose to modify the defect tracking plan (DefectTracking Schema). Once you give you a new program (Schema), you will be prompted to create a database associated with this plan (Schema). Unless you make a special method, you will create this database in the form of a Microsoft Access database. When you are asked to associate this new database with a plan (Schema), select the plan you just created and named. (SCHEMA). Then you can check the edit and modified forms and data types to meet your requirements. For example, you can expand the record type and a list of table nodes of the directory tree to see the existing defect_base_submit form. These forms can be renamed, some domains can be deleted, added, and more. For more information on ClearQuest forms, create and modify the ClearQuest documentation. I can quickly enter the risk of our project to ClearQuest in our desktop. All members of the entire team can access risk databases and enter the risk they observed. Although only project managers (PM) and project engineers (PE) should have permission to close risks, it is nothing wrong with the permissions of each member of the team. The project manager first wants to view the risk visible for the customer, because some of the risks may not be associated or can be solved quickly. For example, Figure 1 shows a form that is used to enter the risk of the project we have discussed. Figure 1: ClearQuest Risk Enter Form I found and entered and a total of 17 risks for the beginning of the project. This is not a very large number, some of which (such as challenging time schedules) will exist until the final period of the project. Figure 2 shows the ClearQuest interface of a list of a part of the project risk we query. The risk is listed above and is strictly arranged in order. More detailed single risk information can be obtained by clicking the risk item in the list. Figure 2: ClearQuest Risk Report Tracking Progress Management requires tools to track project progression. In the early stage of the project, we cannot rely on any icon defect, change request, and test results to measure the success of the project. Instead, we must estimate the proportion of actual completion based on the work decomposition structure (WBS) item and our progress. Good working decomposition structure (WBS) is very important for tracking project progress.

The Dantecha in Part 1 describes the work task package in our first stage. In order to enable us to refine the useful matrix, these task packs must be clearly defined and appropriately planned for the size of each work task package. We typically allocate 10 to 40 days of working workload for these tasks. In addition, ClearQuest can also help us track the variable parts in the system - in these variable parts, the change request is extremely high. In some previous items, we found too much change request in the refinement phase is usually one or more of the following aspects: not enough analysis, difficult to get along with customers, fragile engineering teams, poor Process execution or complex project. If these symptoms have occurred in certain aspects of the system, managers and group leadiers need to have additional attention to these parts. Managing Customers expects to be easier to reduce customers' meeting and contact; however, it is actually one of the most important members of your project team members, and customers should be included in the entire project from the beginning. This can not only produce better analysis and improve the results obtained by each iteration, but can better manage customers's expectations by letting customers see the product and understanding of the product and understanding of understanding. Especially when customers are not very proficient in technology, their expectations of the final product will be greatly exceeded by real cost, time progress and feasibility. We suspect that real project priority and motivation do not reflect the current situation of customers, we also need to understand the main priority and expectations of customers. In order to achieve anything, we drafted a profile of vision documents to help understand more customers expect. (Due to time limitations, we combine business vision and project vision into a document.) Whether it is a work status (SOW) or the vision documentation is required to make multiple revisions with customers. The vision document is based on one of the Microsoft Word templates provided by several RUP installation packages. We installed these templates in Word specified (through tool> option> file location). As shown in Figure 3, we generate a preview for each template (by opening each .dot template file, select File> Properties> Summary, check "Save Preview Screen", save the file) and rename the title of the template *. DOT files make them easier to browse. Figure 3: Browsing RUP Microsoft Word Template Management Demand Demand is not insignificant for the system. Similarly, because ASDI has few IT infrastructure, the system requirements are required to be fully costly software requirements to the detailed software requirements. Rational RequisitePro can help us to complete this task, which allows us to manage our needs and tracking projects throughout the project. The current situation of the customer has begun (SOW) can be used as a baseline of our system. In many cases, we start with business modeling and demand analysis as described in RUP. This should include a collection of business use, supplementary system specifications and business object models. But it is very important to meet their expectations from our customers and build it in their work. We will generate a RUP product called Software Demand Manual (SRS) in accordance with the current situation, and put it as a base collection of demand, according to it we can track our later analysis and modeling products. RequisitePro's ability is very easy to help us insert demand from our client's operating status (SOW). The rules we create should match our "bullets" style, or match any or all keywords "Must", "Will", and "Should" match. Others can help us establish a demand level to obtain a demand block at the same level, and set the default value for the appropriate parent requirements under the demand block creation label, and then let the creation tool complete the next job.

(First we use the demand block to create no parent demand, so we must return to every requirement and set the parent demand for each requirement - this is a tedious work.) Figure 4 shows A page from the customer service subsystem (about 40 pages). Just like you see, RequisitePro's interface is closely integrated into the Word application, so you can use Microsoft Word and RequisitePro at the same time. Figure 4: Rational RequisitePro interface What kind of information we closely communicated with our customers is needed, but we let them do a lot of work on demand documents. This proves to be a very effective way; we can teach their team skills, and they can give our team their discipline. We tend to invest in some fields in some areas, while in other fields are just at very high levels. In some cases it is very reasonable, but in other cases they excessively fanatically excessively. By reviewing the document, we can guide the ASDI to write appropriate and detailed demand collection. Because we are processing the Word document, interoperability on the specification is easy. When we are satisfied with this document, we can run RequisitePro on the document. At this time, we pay attention to the non-functional needs of the system, which means that these needs will not be described by the system's functional specification. These non-functional requirements include the availability requirements of the factors (such as comfortableness of learning and use) and reliability requirements. Summarizing this point in the project, we operate a small team. Develop plans and obtain resources is our primary task. Until we know what direction we should work and know how to achieve goals, our team will become more and more fighting. It is first most important for us to complete our client's working condition (SRS), which specifies the basic system and software requirements of the project. Planning the future we hope to make an engineering team as soon as possible, but our next task requires a senior analyst to make RUP's initial phase more progress. First, the demand displayed in our working status (SOW) is essentially a series of decomposed specifications that cannot be guided by clear work decomposition, or even clues that can not produce many architectures. We have always believed that the demand expressed by the white text will not bring the same benefits to the needs of the unified modeling language (UML), so we plan to convert our needs into use case (use UML in Rational ROSE). Similarly, we need a formal way to manage customer change requests, customers concerned from places and customers. Although we didn't use the ClearQuest's web interface, it looks like a perfect tool to keep the development team and customers synchronize. Establishing ClearQuest Web is the highest priority of us or the second week. Main risks Our risk has no significant change: we must continue to put energy in establishing effective customer relationships and fast moving projects along the correct direction. I now have a problem database, so we can close this risk; however, until we have established a ClearQuest's web interface, customers can see the risks of the project and they can support our fields more clearly. (Later, when we shut this risk, we can't provide time or infrastructure to establish ClearQuest, but a large project will be clearly benefited from ClearQuest.) Customer is very happy that our progress is completed as scheduled, part of our Work products do not feel unrelated to them.

When we continue to move to RUP products, we must maintain our comfort and gentle access to new concepts through a large number of guidance: use cases, business objects, and more. We feel that our time schedule is the actual and design is good in addition to very small accidents. This means that resources must be in place as soon as possible, and the review must be timely. We must also pay attention to high-level risks from the beginning, because we can't let them go in the first stage of the project later. Application Rational Tool Simplifies J2EE-based project (3) Convert to system model =================================== =================================================================================================================================================================================

Part 3: Convert to System Model Steven Franklin Software Designers and Process experts in March 2004 This article will continue to introduce sample projects of the project through this comprehensive application RUP and other Rational tools, which we will Started to create a system model that represents "current" business conditions, and converts this business model to "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 Part 3: Rational Unified Process (RUP) - Guide the software development process, providing recommendations for each phase of the project and work product RATIONAL ROSE Enterprise Edition - In order to create "current" Business model (using a Unified Modeling Language (UML)) and starts to create a "future" system model on the basis of the analysis clues or updated work products: business use case model (Rational Rose) - is created System "The current" Business Function Business Object Model (Rational Rose) - The created "Current" "Current" business function is executed: the collaboration between the entity, the interaction between the entity and related processes and products Use an example model (Rational Rose) - cannot fully represent a business case model; it is created to obtain a detailed system "future" execution function (which is the basis of building software) Capture "current" system has too many new and Improved IT systems are 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 down the next analysis of the incorrect explanation of the demand cannot be accurately estimated new solutions The impact is caused to cause huge vibrations and requirements for customers' work when software is delivered to customers, and require customers to completely change the inconsistency of existing workflows, resulting in misunderstanding and misunderstanding between communications with customers. Confusion Creating a business model to capture the "current" system can be very fast task and can generate useful analysis clues, which will simplify the definition of "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 ROSE as part of business modeling work: 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 separated from other use cases, we organize these use cases to logically contain their features. We feel that the <> prototype and Rational Soda's reporting capabilities can be combined so that we can allow us to identify the use cases that are readily included 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 Package Management Model (Business and System) Business Object Model Architecture Design Senior Developer System Architecture Design Database Architect Architecture Plan (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 About Decomposition Rose Model You can find in the speech of Robert Bretall. Here only comes from several 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 modeling user and interface in ROSE (actor) is a person or thing that is interacting with the system; this can be used in the system, or other interface types . 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: Customer Service Usage Model Examples When we enrich the business case model, a range of candidate objects will occur 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 the interaction: business use cases (what kind of individual and interface access to our identified business tasks) business objects (how to interact with each other between each business object, and them Type of shared information) Use case to use case (dependence on each other, and a common task shared by a certain process) We spend some time to capture our understanding of current business organizations and processes in ROSE, resulting in generating We understand the very useful business object model for 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: Business object model excerpts We start business object modeling after business use case modeling. 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 creating a use case: the use case is created too large or too small cases in the case where the team is inconsistent without consistently performing a good plan unreasonable, the model is unreasonable, resulting in a team In the process of analyzing collaboration, conflict is too detailed. If you enter the prototype, design and development tasks, it is too simple to define everything, so that the demand can have many interpretation results by the engineering team, we decided to use case Modeling standards and guides need to be defined by the leader. These include the following guidelines: Typical acquisition of 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 comply with the guidelines pointed out in the article FINE TUNING ROSE to Complement Your Process: Identification - Name, the only ID, prototype, tracking requirements and profile description - start status, end Status main proximacity description and change comments - temporary "Sign Book" comment From "Current" to "future" evolution as us from "current" to "future", many of our business characters is evolved into The real user and interface 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 Study Example Figure 8: Customer Delivery Used Example Figure 9: System Management Example RUP Description, "The most important purpose of model modeling is to communicate with customers or end users Behavior. "However, increasing complexity can lead to our clients that we can feel uncomfortable, we found that when we enrich the 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 progress, especially tools and techniques 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 are some time schedules or budgets - and our risk list is also growing, and we have not started any serious technical exploration. Among them, there are new risks: too many competitions, 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. Application Rational Tool Simplify the progress based on J2EE project (4) analysis and tools =================================== ==============================================

Part 4: Progress in Analysis and Tool Steven Franklin Software Designers and Process experts in April 2004 In this next phase of the sample items used by RUP and other Rational tools, the use of examples are added by adding documents and traceability Demand is refined, and tools and techniques used are evaluated and selected. The focus of this section 4 is in the refinement phase of the ASDI project, especially in use case analysis (refining our use cases to add trackerability, and standardize and generate example documents) and select appropriate Tools and technology. Part 4 Snapshots in Section 4 Tools and Techniques: Rational Rose Enterprise - Tools for use Case Requisium Rational Soda - Tools for Customer Check for Customer Rational RequisitePro - used to manage SOW demand and use case The product of trackability or updated: Rational Rose model - modified and add more detailed content use case reports in all aspects of the use case - Generate the REQUSITEPRO database from ROSE use case - Updated to include SOW requirements And the Trackable Refining and Documentation Documentation Example Figure 1 shows the evolution of the use case in the first phase of the ASDI item (initial and refinement phase) of the RUP. As we discussed in Part 3, we created business use cases in the initial phase, and then transition business use cases into an example of the "current" system in the initial stage of the refinement phase. Now we are the most intense moment in the refinement phase, we are preparing to refine our use case, and complete the conversion of the system to detailed needs. This evolution is naturally formed, because until it is determined whether the use case we start defined is correct, we can add more detailed information for the use case. Once the detailed system demand is completed, we will be reviewed as a formal delivession by ASDI. Figure 1: Evolution standardization of the use case of the first phase of the first stage Our use of the use case is annotated in our meeting with ASDI's informal inspections. The use of the example and bags are also regularly checked by our senior team members, a "sound" check will bring the following results: feedback to the group leader useful analysis recommendations, mode and functional decomposition of unstable or missing aspects Considering System View Engineering Team Exchange for detailed requirements Our current focus is to record what we have learned. We agree with ASDI in the form of use case documents, and we are very happy that they are willing to accept ways to add documents directly in the ROSE model. This is a simpler for us, because this means lowering the beautiful expectations of documents. In the case of multiple team members working together, we found that we need to standardize documents associated with each use case. Therefore, we drafted a document template for a use case and applied to each use case of the ROSE model. The content shown in FIG. 2 is a document window that is pasted into each use as a template. Note We use the term "variation" as a speed notger mark for RUP optional flow concepts in this template. Figure 2: Using an example document template later in the project, we realize that there is a large number of ASCII forms in the model (* .mdl and * .cat) file, making the model's loading slow down. Thanks to our fast computer, this side effect can also be tolerated, but in later projects we use more formal ways to maintain the content of the usage, through a custom interface (just like in article Fine Tuning Rose to Complement Your Process discussed there). Another optional method is to use ROSE with a separate Microsoft Word document to the characteristics of the use case (select the use case by right-click and select NEW> file from the context menu).

The traceability of use cases ASDI original expectations are SOW will eventually become a document in a large text. Through the continuous discussion with them, we finally realized the shortcomings of this method and made a concessional posture. They now understand the benefits of using the use case and soon understand the relevant concepts, and understand the use case will give them a very powerful and appropriate feedback of the model. In any case, a good time and energy distribution have entered SOW, you can understand that ASDI wants us to ensure that it will not miss anything captured in SOW. In order to provide this guarantee, we use the Rational's tool to create trackability between SOW requirements and our fairly stable use case. First we associate the Rose model with the managed demand document through RequisitePro, and select SOW by selecting Tools> Rational RequisitePro> Associate Model to Project. Then we map each use case to the main SOW requirements, select Requirement Properties> New by right-clicking the case and select Requirement Properties> New in the context menu. As shown in Figure 3, we show a list of SOW requirements and select the appropriate needs. Figure 3: Relevance requirements and use cases we have established these associations in the model, we can track the needs of the needs, and the opposite is possible. Bidirectional trackability is important, so we can find out the need for omissions or find new needs. I miss a need for unacceptable, tracking needs to use cases can make us discover any of our missions. Adding requirements without clear adjustments will result in the spread of the project and have a negative impact on the time planning and budget of the project. In order to prevent all this, we should track all the SOW requirements or change requests that exist to each. Unlike the tracking needs, the tracking of the opposite direction is often ignored, but we can easily complete this in Rose. To browse the SOW demand associated with an example, we are simple to right click on the Rose model and select Select View RequisitePro Association from the context menu. This will pop up a window indicating which SOW requirement is the selected case tracking, as shown in Figure 4. If the use case is not mapped to a SOW requirement, the two domains at the bottom will display "NONE". We can also produce more complex tracking reports through Rational SODA. Figure 4: Note that SOW requirements for Rose is important to use a shortcut in this method. Through the way we use, we can only associate a use case to a requirement, and vice versa; however, a use case is actually tracking back to several needs, the same requirement may be distributed into multiple usage. We don't have to distress multi-to-many relationships. We directly associate with the needs of the SOW, but a better way is to introduce a use case specification document managed by the RequisitePro, which contains many text descriptions of many use case requirements and multi-to-many mappings. (Detailed description You can find in Rational White Paper USE Case Management With Rational Rose and Rational RequisitePro.) We now think that the use case specification document is an important step we should not skip. The inspection cycle of using an example document We understand that the frequent check cycle of documents will lead to endless cycles. End any document is difficult, because every time you read documents, check people often produce some new ideas. In an iterative method, the same "When the end" challenge will also appear in the software documentation and other tasks. In order to meet the concern about the end, we describe what we will do with the inspection cycle of the use case document, we work hard to borrow the concepts described in RUP (see Figure 5).

Figure 5: Document Check Period Graph is like what you see, every document has passed a series of iterations. For us to find a tool to support it, we find such a tool in Rational Soda, which allows us to generate documents other than ROSE models. Although it is tempting for direct modifications to documents, this will bring the risk of documentation and model. If you will put energy in one or more documents, a better way is to put energy in the model. In addition to the software user manual you develop, the model is almost the product that can continue to be referenced and maintained after the software is delivered. By using SODA, it is simple to generate a report. For the customer's check generation case document, we select Soda Report from ROSE's report menu, which will have a list of report templates, as shown in Figure 6. From our choice of a Rup Use-Case Model Survey Template. Figure 6: SODA Report Select Each template provides a default report (as a Microsoft Word document) accompanying an empty part and the corresponding content form (TOC). Figure 7 shows the TOC we choose to report. We started with ASDI checking TOC and we viewed our use case to decide whether it would require appropriate cropping according to our needs in the report. Figure 7: Soda Use-Case Survey Report (TOC) You may want to know why we worry about check TOC with ASDI before writing any actual content. We found this is an important step. Sometimes ASDI gives us a DID (data item description), which provides a TOC on formal delivery, but we find that it is useful to get information from ASDI (or internal team checkpoint) before starting enrichment. Sometimes we fill in every part to display the title we will refine, but there is almost no paragraph content in the first TOC check. Subsequent article section discusses more detailed information about Rational SODA and template customization. Refining: Not just use cases in order to make life more difficult, ASDI expects us to create a use case document before continuing subsequent tasks. We must remind them that the document will be "completed" by the software to be delivered, unless they do not want us to update when demand changes or new demands. We persuaded them, they would not be interested in the completed milestones or even confident milestones. However, they want to put a check mark to the next "detailed use case document" item, because it is very mature, we agree with this point. The real challenge is to persuad all the activities of ASDI should be parallel, not all milestones are delivered in order. We use it as a routine focus in the early project, it is still not completely resolved. In order to let him meet some of the activities of the use case analysis, we have proposed these two perspectives: the simulation of the screen will simplify the needs of the demand, and you can tell a wide passage than the use case. There are no forward-looking prototypes, tools, installation, and training should not happen. We are very happy ASDI agreed to simulate and prototype as a useful part of the analysis phase. This allows us to enter the architecture and tool selection problem before useful analysis is completed. Choosing tools and technology tools and technologies have never been tight tasks, although it is often ignored. The team often selection according to the start of the cost, "small tool factors", curiosity or loyalty to tools and technology. Instead, they should consider production cost, reliability, training, team skills, and characteristic standards. Add some formal procedures during the evaluation process to ensure that the choice of tools makes the project-based rather than personal subjective comments. The official tool assesss a rare place in RUP is a team to pick off-the-shelf - also known as the Commercial Spot Supply (COTS) - Tools.

It can be understood that one place in this process area is Carnegie-Mello Software Engineering (SEI), where cots-based systems initiative focuses on the choice of COTS products and adoption strategies. It is particularly interesting for SEI's Product Feature Checklist; although it is more concerned about the component and framework of the software system, many of them can also be used to select software development tools, web services, databases, and more. Tool Select Standard ASDI to show us that they feel that they will affect our tool selection: they finally undertake the core development and maintenance team of the system contains 3 to 5 people. The system can be accessed by 4 to 7 internal users and 1 to 5 from 20 to 30 companies (although the future versions of the system will support thousands of people online users). Cross-platform technology is important because ASDI expects that this system is still available in a few years. Training for all technologies must be easily obtained. They strongly prefer Java-based solutions. They prefer OODB (object-oriented database) as data storage. The early versions of the system will run on the Linux system, although they will run on the Solaris system. Developers need to be able to use software on Windows 2000 machines. Performance is not an important challenge, as only a few users are interacting with the system at the same time. Application Server Selection We have experience in the J2EE application server, so we are very lucky ASDI selection based on Java solutions. However, in our rapid assessment of computing techniques (mainly Microsoft .NET / DNA) after entry-level Web schemes such as Perl / CGI and PHP. We unanimously discovered that Orion Application Server is a friendly and a cost effective development environment. There is a low-level aspect of Orion is the stability and support of the supplier. Companies that provide Orion products are very small and have the ability and reputation of WebSphere, a WebLogic or IBM. However, after discussion with ASDI's inspector, we agreed with the benefits of Orion's J2EE standard compliance to offset these risks. If the second phase is developed, careful development will ensure that we have a lightweight to port to other application server solutions. So we chose Orion - this means that this start-up cost is zero because ORION is free. The web server selects Orion with a high-speed built-in web server, so the selection process of the Web server is also conclusively when ORION is selected. Its main competitor is apache. However, it is displayed on the Orion website to reach and exceed the Apache in some tests. The selection of which database selection is not obvious. Databases usually do not perform high loads, but it needs rich feature support. For example, a complex data relationship requires a complete reference integrity limit. At the same time, the system must be running uninterrupted 24 hours, so we hope it has hot standby functions, replicates, other usability and fault tolerance features. Whether we will use all features will be decided later. We think that PostgreSQL is just a candidate with a qualified open source. It has good ANSI SQL support and reference integrity, and as long as it is not too big to grow, it can maintain good performance. However, data storage requires more CommTed support from one vendor. In addition, we feel that PostgreSQL online support (such as user community discussions) is not enough. MySQL is actually a more popular open source database, but it lacks too many features (such as foreign key support).

Then we go to the mainstream database: DB2, Oracle, and Microsoft SQL. We have a wealth of experience in Oracle, but the new processor unit price model is too expensive for our application. Oracle's basic load per MHz per CPU means that ASDI will endure high production environment costs unless they are willing to mount Oracle on a P-133 machine. Microsoft SQL is eliminated because it is based on a private platform. If you create a DNA-based solution, Microsoft SQL is naturally preferred, but is rarely selected for J2EE. Finally, we chose DB2, our survey indicated that DB2 has very good support, powerful fault-tolerant features, failed price modes, and a collection of online users that are growing and trained. IBM's JDBC driver is high performance, and their personal version can be used for development teams. Unfortunately, we lack DB2 skills, which means that some training is needed during prototyping activities. You may just want to know what happens about the choice of ASDI's preferred OODB. After passing the prototype and exploring the product, we quickly reached the conclusion, the benefits of using OODB are not enough to offset the risk it brings. About this more ideas, look at the following article references and other resources. Integrated Development Environment (IDE) Select at this point, we don't want to use any high-end IDE products, there are several reasons: we don't clarify the proven of the first stage concept. Enterprise JavaBeans. The investment of IDE is expensive. Team members have already had their own choices. Because the time of the first stage is very tight, the learning curve brought by VisuaLage, such as IBM is unbearable. Instead, we mix the following tools: JCREATOR - Free Java-based IDE CodeGuide - Low-cost IDE Log4J - Simplified server-side debug log Tool Jikes - Quick Strigual Java Compiler is natural, these tools can be used by using Rational Tools To make up for the lack of testing, tuning and code coverage. Summary At this stage we have seen the evolution of the use case (via trackability and documentation) and the use of the use case participating in ASDI, we quickly discovery that we are experts in the world. This is usually one of the biggest challenges in the software development project, so early and effectively establishing this relationship is true victory. Our concern is usually very good to ASDI. They quickly understand and agree to the RUP-based development process without spending too much energy. This is surprising that the development of the preferred waterfall type to finally achieve this sum. Many methods of iterative and incremental development encouraged by RUP are well adjusted, and ASDI also sees good. We are fortunately the choice of tools is quite simple and is completed early in the project. Some of Rational's tools are used to save our time. In the previous project, we used Excel to manage requirements, but we found Rational RequisitePro to be a first-class and complete solution. In addition, Rational Soda reports can greatly reduce the cost of our documentation. Because this project is our first use SODA, we are very happy with ASDI to expressed satisfaction with standard SODA templates. Planning the future until now, we put the focus on the product related to the needs, and spend relatively small time to assess technology and create prototypes to support tools. It is now important to disclose the system more complex fields by creating more challenging prototypes, and began to use tools in actual development.

Will we use XML? If we use, what kind of interpreter should we use? What kind of safety mechanism do we need? Should we use Enterprise JavaBeans? I will have an answer like these issues. In other words, it is time to transfer from the analysis to the architecture and design - as fast as possible, because most technical risks will appear in the next few weeks. We have a good function baseline containing a series of well-defined cases. It is important to avoid analyzing the driving force of paralysis and maintenance. Main risks have no new risks to be identified; in fact, our risk list is shorter than before. Because ASDI agrees that this project OODB is not suitable, we will no longer have technical risk to be managed. They also relaxed our formal forms of our delivery and their expected structure, and they have not retained our RUP framework-based documentation. On the issue of the remaining time and workload of our concern, when we increase the understanding of the required understanding and familiarity, we feel that the budget is more in line with the project. Further technology explores that do not doubt new challenges. Application Rational Tool Simplifies J2EE Item (5) Architecture and Design ===================================== ==========================

Part 5: Architecture and Design Steven Franklin Software Designers and Process experts in April 2004 When this is conducting RUP and other RUP and other judicial tools J2EE sample items are converted into architecture and design (including data modeling and Building a test design imaginary prototype), this project has entered a more technically staged stage. This series of Part 5 first checks the time schedule of the project, and then when we enter the architecture, design, data modeling, and create prototypes, we have made it in the next stage. Part 5 Snapshots Tools and Techniques Demonstration in Part 5: Rational Rose Enterprise Edition is used to create design models (including data modeling using ROSE Data Modeler) Rational RequisitePro - used to add or refine demand or updated Product: Rational Rose - Created to add architectures and design information (including database planning (Schema) RequisitePro Database - time schedules that are updated to add or refine demand projects based on architecture and design exploration, starting in detail Before the architecture and design work, let's check the overall progress of the ASDI project. As you can recall in Part 1, this series of articles composed of multiple parts cover the first stage of the project: a series of needs, a reference architecture and code (ideal reusable) as the result of the results Verification. So far, we probably use one-third of the first phase budget, but we are approaching the project time progress. This is among our expectations, because we are interested in making progress slightly slow. Analysis and planning activities are always moving with slower pace, and teams should have gradually established them at the beginning of the project. Because the first phase requires evidence of a related structured and formal concept, we use it as a small project to complete it by testing and QA (peer review) on the evolved product. RUP has some mechanisms for developing concept evidence, which is basically in the synthesis of the implementation architecture of the workflow. We are further transforming the concept's evidence into available beta products. We can put more features, risk reduction, and product maturity. The more we use skills and knowledge to use the system's product version, the more happy our customers will. This next series of tasks will be more technical than the previous activities. We are very good to architecture. Design, data modeling and prototype advancement. In Part 4, we discussed some prototypes and assessment how our tool selection; now our prototypes focus on testing our ideas, system descriptions and design. Transition to architecture and design architecture and design activities are the most pleasant and creative tasks in the ASDI project. We are proud of us to promote the efficient, safe and simple and elegant and elegant system plan. The prospects of the technical solution have been produced in many exciting meetings, free discussions and technical explorations. Simply put, architecture is intended to capture technical flexible programs, which can cover the system requirements we defined last month. Whether it is to look forward (for design) or backward (for demand), the architecture team will suffer huge pressure. The Rational Rose's integrated development environment simplifies this challenge by allowing us to do the following: Use SODA to generate documents to allow architectures and design elements to distribute, simplify check and keep everyone have a consistent current vision. Directly update the class's signature (method and attribute) from the scene to make us not need to return to the class's instructions to add a missing method. To automate tasks, such as generating Rosescripts, checking the integrity and validity of the naming habits, and test models of the model (you can get access to the Tools menu).

With ROSE's RUP template, provide a model framework for RUP guides. Drag the class from the J2EE class frame in Rose. The model decomposes the model decomposes the model with Rose's "unit control" feature to be controlled by the team. Note that because the system we created in the past project is similar to the current system, if we reference some reference architecture, our architecture will benefit from it. However, we cannot find any reusable opportunities in existing packages or design patterns, so we just refer to the ideas and classes that may be used in future uses. Transformation from the use case to the design class is slow, and multiple iterations are needed. This involves analysts and designers, because we have few more comfortable and customer discussions in the field of business, can be used to analyze and refine the designers. The goal of this activity sometimes seductive translations directly into code. In fact, we do this in the previous project (because we have a very detailed demand instructions), we are very confident in our understanding of the project. This creates an error. Demand is missing, the range is difficult to be tracked, and a lot of work and rework is useless. Use design models to connect between demand and code is important; design models can capture errors and problems in the development and testing. In the process of transformation from the use case, we hope to be able to implement: the knowledge of the analysis team will be transferred to the engineering team. Identify technical solutions that meet all needs - or where it is not possible, identifying the needs of technical solution conflicts, and determines if they are important or changed or deleted. Identify help determine the team structure, architecture hierarchy, and a candidate for purchasing software. Specify the details of the technical solution and start plan how to assign work in the team. Prevalence of Plan and Budget Based on Design Models. Assign classes to platforms, products and private code. For feedback and synchronization, software architectural documentation is generated, and the software architecture document can be distributed to internal and external team members. Realization of stable design from the use case and analysis of the design and design of the design and design class is inevitable. We need to do a lot before we can have a satisfactory design. Figure 1 shows the main activities we define a stable design in our way. Figure 1: Most of the activities and products prepared as "architectures" as "architectures" as "architectures" (especially SOW requirements, use cases, business object models, and analysis classes) are discussed as described in the articles of the Model Model. In addition, these other activities are also important to design work: Determining the structure modeling data of the package (Create Database Plan) Creating prototypes and screen simulation These will be discussed along with how to handle new and changing needs. The package and subsystem structures begin to consider a good package structure before considering the design class. Regardless of our final decision, it should be a guideline in the design process, and all team members must comply with this guideline. The choice of package structure We have been arguing that it is divided according to subsystems (Fig. 2) or in the hierarchy of the architecture (Figure 3). Table 1 lists the actions and disadvantages of each method. Figure 2: Follow the sub-system definition package Figure 3: Division method for packets in accordance with the schema's level, the disadvantage, according to the subsystem definition package, it simplifies the management of the model. Complex subsystems can be assigned to large teams with a single * .cat file or * .cat file. It can be easily tested for dependent dependence on subsystems. It simplifies the plan for project increments. It encourages reducing subsystems to make architectures easier to understand. It increases the possibility of subsystem reuse. Consistency between subsystems and the shared relationship will be harder to coordinate. For example, DBA may be more struggling to understand the blueprint of the data layer, or dependence between data abstractions and planned entities. It promotes the discouraged reuse of universal service packages. The consistency between the scratch classes of the architecture is maintained.

It isolates different technical fields: JavaServer Pages (JSP) of the user interface; Enterprise JavaBeans (EJB) and servlets in the business logic layer; entity beans, classes, and data layers. It adds the possibility of reuse system architectures. Not all code is just a layer in line with the three-layer architecture. For a subsystem, team leadership or remote team must check (check out) several * .cat files to update or obtain all permissions of subsystem models. If all models are not detected (Check Out), it is often difficult to report or present a specific subsystem. Table 1: Comparison of packaging methods Eventually we use the first method to divide the design model according to subsystems. We think the system is small enough, we can keep the consistency between the subsystem. Subsystem structure design Our top-level package structure is like Figure 4. You can see the identified subsystem from the top package (so prototype <> is assigned to each subsystem). Figure 4: The structure of the top bag has conducted a lot of discussion before we turned this early draft into the final stable package structure. Below is some of our concerns: How do we organize universal services? Answer: Public services are placed separately in a sub-package (log service; data synchronization and backup service; access control service and login service). Should we draw a line between Shipping and Part Management? Answer: We don't need to connect them two. We define subsystems based on the field or architecture? Answer: Architecture can be combined with the domain in most places. Do we allow bidirectional dependence between packets? Answer: No. This is a bad design practice that violates our internal design guidelines. As an example, we will focus on the Command Gateway subsystem. Although many places in the system are centered on an internal and external Web interface, we still plan to provide a secure, XML-based command gateway (Command Gateway), this command gateway allows ASDI's system with its large customers A B2B (Business-To-Business) interface is formed. This feature allows these customers to be able to query, submit, and update information from their existing systems. This is very important because some companies' needs cannot be accessed through the web interface. On the contrary, they need to be batch from the company's code or behind the scenes. In each package, our initial class maps come from our usage example, business object model, annotation, and interviews. Figure 5 shows the evolution process of the Command Gateway subsystem from early thinking to detailed design. Figure 5: In the initial design of Command Gateway In this first round, we simply identify the main part of the Command Gateway subsystem, there is a problem that must be concerned at this level: Do we use XML? (Problems include broadband consumption, stability, and interpreter maturity). Do we want to send and receive data to customers? We want to provide a client software for command or just a specification for this command? Do we want to transfer XML via SSL (Secure Sockets Layer, HTTP or private socket communication In subsequent design (Figure 6), we identify more dependencies in the system and start identifying things that look like implementing classes. We are still in debate the high-level concept, so we are not interested in the signature of documents and classes (methods and properties). The signature of the document and class should be filled in when we feel that the design began to stabilize.

Figure 6: The medium-term design of Command Gateway is like Figure 7 shows that we will later refine some dependencies, appropriate methods and properties (hidden in the figure to save space), and add some technologies Detail. For example, by establishing a prototype we identify a solution to the JSSE (Java Secure Socket Extension as an SSL connection between the customer and the server. JSSE is integrated directly into JDK 1.4, which is just an additional part to JDK 1.4. Figure 7: Mature CommanD Gateway Design This design is not final. Although the design has been tested through numerous scenes, it will find incorrect or missing details in the design in the next few week and months. Changes to manage requirements When we schedule and design, we identify the need to add new needs or refine the existing system requirements. Ignore some small changes is tempting, but we see a considerable budget to complete changes. Small gaps on the budget will increase the time required and give the customer a poor precedent. We find that all adds and changes will help us keep your expectations and forced us to ask, "Do we really need this in the future?" This is a key point we usually ignore: If a demand is not enough Enter the system, this demand is not worth implementing. Sometimes the introduction of demand will have a negative impact on existing evolution and budget. This requires us to sit down and discuss the choice - but first, we should discuss our internal, so that we can trustworthy to make an alternative, not a simple "impromptu performance." Selection usually includes the following aspects: postponed demand. This usually occurs when demand is not important, or other needs are not currently being built. Remove the demand. This happens when it is more important. Instead of replacing an existing demand with a new requirement. If there is something that already exists is not important or this is not particularly urgent, we can postpone or remove this demand for new demand in time schedule and budget. Add demand to current work. This choice is only considered only when unacceptable risks to existing needs and the entire system plan. Adding any important needs naturally require additional time and budget. Change the use case is not a problem because we have strict version controls for the use case and can be updated directly in the model. In addition, it is also easy to use Rational RequisitePro's use to integrate programming back to SOW. However, traceability we hope, we have spent time to establish Rational ClearQuest to manage the changes in demand. Sometimes the change is identified inside, but more cases are external requests. Our changes management process is very awkward, including monthly conferences, hard-copy files, and more. A more seamless change request process is almost growing in the control range, producing better systems and higher and more than a more opportunity. Data modeling When we started the design work described above, we also started modeling data. In the previous project, we used Rational Rose to design and found that the split between persistent classes and temporary classes was a bit awkward: once we identified a class for lasting storage, we set its persistent attributes and started Other tools model him. In ASDI projects, we used Data Modeler integrated in Rational Rose Enterprise to perform data modeling and found over more mature. In fact, we originally used the old way to make a mistake - put your lasting object into their own folders, and forgot them - but we could make them with ROSE to convert these objects into data models. .

Put all collected persistent classes into a package, we can click on the package with the mouse button and convert them into data models (select Data Modeler> through the context menu). The data modeling creates a database plan in the ROSE model. We will then translate these plans from its logic to a physical DB2 installation and access the watch and test data to the engineering team. The prototype is based on the foundation of architecture and design, and good analysis is important, but prototype is also very valuable. Many ideas look very good on paper, but our assumption only has evidence to provide. The engineering team is very like prototype activity. Typical time plan for these activities is very confident, the goal is blurred, technology is new, and QA is relaxed, so prototype is usually very interesting - a lot of waste of money. We have found that if the prototype does not have clear, we can measure the target, it will soon fall to "what I can do ...", rather than reducing risk. We usually do our best to maintain consistent with RUP's evolution product theory. RUP can guide us to evolve all our prototypes into ultimate products. In fact, we retain the term "prototype" for fast exploration. In order to release the greatest value from the prototype, we often ignore the code standard, the same level check, and similar processes. Some aspects of prototype (instructions, design modes or coding habits) may be reused, but we have a very small pressure to reuse this. Instead, our prototypes are often summarized as a technique for technical comments or become a sample application that can be found in the project. It's right away, a work package must be drafted. For its developers, this package can summarize the target of specific prototypes. We allocate budget and time plan for each prototype, including interim checks before the task is completed. We don't always create prototypes by direct coding. Sometimes we execute tools for the tool by learning any code. When evaluating the database, for example, we are based on our experience, the information provided by the supplier and the third party check from the class list. We have found several ways to build prototypes and tools: review (read, repeated view, interview) encoding (in-depth code snippet can detect specific interface, demand or performance issues, and clear, concise code snippets can Display connectivity, workflow and availability) Prototype installation and demo tool providers The key to use prototypes is to determine the degree of implementation of prototypes. Few prototypes can be designed to be 100% confidence in recommendation. Instead, the prototype must demonstrate enough results to reduce risk to an endurance level. Table 2 lists some specific prototype activities we have adopted in this project.