From the use case to the code, the second part: use case design

Gary Evansindependent Object Technology Evangelist, EvaNetics, April 01, China

From Rational EDGE: This is the second part of the "use case to code" series, discuss how to convert the demand captured from the usual example into an achievable expression form and code, this article describes in Rational Unified Process (RUP) Several steps for use case design are related to specific implementation techniques.

This article is the second part of the series, discusses the conversion of demand captured from the usual example into an achievable expression form and code. In the first part "use case analysis", I gradually introduced several major steps 1 for use case analysis in Rational Unified Process (RUP). I introduced a simple case study (hereinafter referred to as vehicle scheduling), this system provides customers with browsing access services, customers can reserve vehicles, cancel an appointment, view rental records, and more. I also gave a simple use case to make an appointment, first is a universal version, then a supplement version, introduced more external interactions, this interaction in this case, this interaction will happen.

After that, I used a simple syntax analysis technology to determine the candidate entities in the case, and use four questions to examine them. These issues are selected from the 41 candidate entities, which are analyzed by testing. Then I identified the responsibilities of each analysis class, so that we have James Rumbaugh, which is "Veteb Boundary" in the definition of each class, "Crisp Boundary").

After identifying eight analytics classes, I introduced four steps to construct the initial analysis class diagram to capture relationships and diversity between the class. Then I also constructed a sequence diagram of the analysis level of the reservation vehicle case. It is strictly restrained from the analysis level, only the analysis class, does not include design classes or implements classes. In order to make the sequence diagram more easily understand, I introduced a general use case controller object to provide an intermediary for the information received by the consumer participant. With these analytics classes and their identified relationship, I also assigned to each analysis class with its responsibilities (data members). Finally, I determined the analysis mechanism for this small case study.

In the second part of this series, we must perform the use case design activities in RUP by step.

Elements of Case Design in RUP Figure 1 Select "Analysis and Design Overview of RUP". It illustrates where other analytical and design activities have occurred in the context of design activities.

Figure 1: Use case design activity in RUP

The purpose of use in RUP is:

Improve the demand for design-based operations with interactive improvements. Improved demand for subsystems and / or its interface operations.

In order to change, the goal of use case is to convert each business abstraction in the system (that is, the analysis class) into one or more design classes that can be implemented and take into account the properties of the target execution environment. Note that the design class is realized. The implementation of the design class (ie, encoding) begins after design stability (although we sometimes write code to study optional design). In design, we must express how to adopt the implementation in the appropriate details to make the programming actually become a problem that only deals with the language and platform. Figure 2 illustrates the steps of the composition of the composition.

Figure 2: Used case design steps

Design activities include maintaining a variety of perspectives regarding the software system you built. A good designer can successfully maintain a variety of different or even opposing views of the target system. Just as there is six faces of a rectangular body, each other is independent of the same overall part, the design of the software system is also multi-face, including: logic, process, implementation, configuration, operational view; system and software architecture; component And class; model and interface; static structure and interaction, etc. In this article, I don't intend to cover all software design practices, but I have to give some specific examples, explain what we can do in the main steps of use case design, as shown in Figure 2. The focus of object-oriented and component-based design policies is class - named units that bundles data and functions to the data operation. In the design phase, we describe classes and classes with other classes or subsystems, and to consider all technical attention points.

These concerns are:

How to express a pair of two or more relationships between two classes? How to express access to the database? Which parts of the class should be visible to other classes? Which parts should be invisible to other classes? How to provide a simplified interface for multiple objects? How to reasonably separate business behavior with the technical behavior required for business behavior in business behavior?

The results of design model use case design activities will produce the contents of the RUP design model, including (of course, more than this):

Design classes required for system (that is, analysis of techniques). Implementation of Software Architecture Document (SAD) in the design class. Each design class will have an operation and attribute. Subjects to actual data types, initial values, or special subsystems or sellers provide software interface. Divide system functions by subsystem or architectural type. The interaction map (ie collaboration map and sequence diagram) indicates how the design class collaborates to complete the business process captured in the case.

The design model will become a raw material, and we translate it into an executable code during the implementation phase. I reiterated that the focus of discussion here is to use C #, Java, C language to develop a new system in object-oriented approach (often known as "green space").

The steps we have to discuss I follow the steps shown in Figure 2 when making the use case design activities, but I add another step, see the following revision list:

Creating a Soft Subsystem Simplified Sequence Diagram between Design Objects (Optional) Describe Continuous Related Behavior Defining Design Mechanisms (RUP is normal in RUP is a software architecture activity) Improve event process description unified class and subsystem assess you result

These steps are not a constant, remember this is important. Based on your understanding of your design, you use RUP experience, your personal preferences you use, or your metaphors followed when designing the design class (for example, application design mode, or comply with some principles such as concerns Separation or interface isolation principles), you will follow the sequences. It is important to complete a comprehensive expression to your final implementation solution.

In the above steps, we just have to carefully scrutinize the following five steps:

Creating a use case implementation Description Design Object Submissions Simplified Sequence Diagram (Optional) Description Continuous Related Behavior Defining Design Mechanism

Architecture criteria are closely interested in design and architectural relationships and are constrained by architectures. Let's consider the Software Architecture (SA), imagine the comprehensive architecture of our reservation system, first agreed SA has made Software Architecture Documents (SAD) It is pointed out that the architecture must support the following technical guidelines:

Profileability. The reservation system and RDBMS (relational database management system) of vehicle scheduling must support multiple, concurrent customer sessions. There is no dependency between each session, and the system must be able to extend thousands of concurrent customers without difficulty. Maintainability. The update of software components must be easily completed, never distributed to represent layer distribution business logic. Technical simplicity. Our car rental company is not intended to train or hire personnel who are skilled in J2EE or .NET's huge components platform. This is a killing chicken with a cattle knife. Existing employees are familiar with Java, Java Serverpages, Servlets, and JavaScript. Weighing technology. The Internet must become a communication medium between browsers and servers, and the system must also use existing programming interfaces on legacy platforms. These guidelines have been given, and the vehicle scheduling items are known to be a developer of Java and Servlet, and SA adds a simple UML architecture model to SAD, as shown in Figure 3.

Figure 3: Initial configuration map of the e-commerce system

Figure 3 explains the easiest view of the layout between the independent customer browser and the legacy reservation database management system (DBMS), which contains information about the appointment, customer, and vehicle. Figure 4 shows more internal details, as well as some communication inside the process.

Figure 4: Advanced Physical Architecture Map

Figure 4 reflects the advanced structure of our application is a schema based on JavaServerPage (JSP) Model 2. Customer completes interaction with browsers on the customer's computer. The browser communicates with the web server via HTTP (hypertext transport protocol), calls the servlet on the web server. I just specifically talked about the reservation vehicle servlet. The servlet appears in the role of the controller, coordinates the various steps that need to be completed in the work of the reservation vehicle. The servlet creates business objects and interacts with each other, and these business objects have an appointment, customers, protect products, etc., all JSPs are used. Business objects (will be implemented as Javabeans) through a Java Database Connection (JDBC) protocol and interface, to obtain its content from legacy relational database management system (DBMS). The servlet forwards the service request to the appropriate JSP.

Using Case Design Step 1: Creating a use case for each use case In the first part of this series, I pointed out that the use case implementation is actually a process of collecting several UML diagrams with other text artifacts, such text workpieces include RUP use case implementation regions Documentation, it confirms that we already have classes, responsibilities, and object interactions that are sufficient to provide behaviors in the use case process.

In the analysis phase, our use case implementation includes only analytics and analysis objects, which can group different UML images such as class diagrams and interactive diagrams. In design, our implementation will include design level information to explain how the use cases are used for collaboration of design objects. Class diagrams from demand, interactive diagram and description will be assembled into our design level implementation. If you use modeling tools such as Rational Rose or Rational XDE products, establishing a use case implementation may only simply create an example model element in the tool, then create UML collaboration with interactive chart below. If you don't have to model the tool, your implementation has to draw a picture on the table, whether it is a paper hand working picture or photographing on a whiteboard. Confirm and name a use case implementation ensures that the interactive diagram and text annotation return to the traceability of the use case. The rest of this article is mainly to discuss the content of design level use case.

Using Case Design Step 2: Describe the interaction between the design object This is a complex step, so a few different pictures in the text, but also observe the iterative process of the runtime. First, pay attention to the paragraph of the first part of this series of articles, according to the attributes of the vehicle rental system, as shown in Figure 5:

Figure 5: Class diagram of the analysis level

This is an appropriate initial description for analytical classes and different classes, but does not become implemented. For example, how do we express a given appointment when designing a given appointment must access 0 or more ProtectionProduct objects? The relationship between VEHICLINVENTORY and VEHICLE is aggregation, and the relationship between RentAllocation and Vehicleinventory is the synthesis (Composition, what is the meaning of this? We should specify what kind of data type for Vehicle's Status and Speciaalequipment properties, and the reservation dates, Times, and EstimatedCost properties. What kind of data type should you specify? What kind of operation should you add in the class? How to express the RDBMS interface to make us request or store changes to the status of the RESERVATION or VEHICLE? Prior to solving these problems, we can review the sequence diagrams (SQD) of the analysis level described in the first part to register the customer (CHECK IN A Passenger), as shown in Figure 6.

The sequence diagram of the analysis level (SQD) looks at the big picture, and the four arrow icons in the lower right corner of the screen are placed to the maximum.

In the use case analysis phase, our goal is to prove feasibility, which is the steps of the business object has the correct responsibility to perform an appointment vehicle. We assume that all objects are static, ignoring the creation and sector of the object to simplify tasks. But in the design phase, we must explicitly explain the creation of the objects (and destructors, this is related to the programming language used). We also ask "Who is responsible for" accessing and "hooking" services needed to serve a customer request.

Let's discuss how to transform this sequence diagram into a design perspective on object interaction. Start from the reservation vehicle case, especially the "Happy Path" scene, there is everything.

How did this reservation vehicle use really start? The sequence picture segment of Figure 7 captures an interaction between objects that may occur. (Simple, I omitted the processing of customer profiles in this sequence diagram, which is placed in the analysis sequence diagram.)

Figure 7: Design sequence temptation of the appointment in the first part looks large. The four arrow icons in the lower right corner of the point are larger.

Step 1, the customer visits the vehicle scheduling website, the home page is visible on the customer's browser, providing several input fields to make customers fill in, including dates, places, vehicle categories. Step 2, the customer requires the system query to meet the available vehicles of these conditions, and JSP sends form data to the reservation servlet (RSVNSERVLET) in step 3. The reservation servlet must check the selected car rental location to match the date time specified by the customer, so servlet creates an empty RentAllocation object in step 4, guiding this object to assemble the data of the confirmed point. RentAllocation must obtain these existing information from the online reservation RDBMS, join a new design class DataAccess in step 6 to implement the FACADE mode. Alternative to a category or component in a simplified interface, which allows us to hide the complex interface. The RentAllocation object Object invokes the retriEVELOCATION (LocationID) of the DataAccess object, returns a structured data group. Call a self-service Fill (DbRecord), parse the data group and assign a field for its appropriate instance variable variable. At the end of step 7, RentAllocation's instance has been fully assembled for a specific car rental location. In the 8th step servlet, please ask this specific rental location through the Validate (Dates): "Are you available in these Date Times?" In the "Happy Path" scene we discussed, "Yes" (OK ). This location is available at the specified date of date, so the servlet gets a list of vehicles that meet the customer's request and display it to the customer. In step 9, RSVNSERVLET creates an empty instance VEHICLEINVENTORY to retain the available vehicles that meet customer requirements. In step 10, the servlet calls VEHICLEINVENTORY's populate () operation passes the selected condition. Because the location list and the information of the available vehicle are located in the online database, the retrievestles (Collection) method for calling the DataAccess object in step 11 VEHICLENVENTORY. This method knows to create an empty VEHICLE object (step 12) to get the vehicle information from the company's RDBMS (unknown), and then call the Fill (DbRecord) operation of the VEHICLE object just created on step 13. In Fill (DBRecord), VEHICLE object resolves the data obtained from DBRecord (a data group), fills in its instance variable. Step 14, the DataAccess object fills the Vehicle object after adding VEHICLEINVENTORY. Repeat paragraph 12-14 until all matching vehicles in the result are in the object. Finally, the Vehicleinventory and Servlets are told that the request has been completed.

The system now displays all available matching vehicles. In step 15 and 16, the reservation servlet stores the VEHICLEINVENTORY object into the session object, so that the next JSP can retrieve it, then call the RequestDispatcher.Forward () operation on step 17 steps to display showinventory JSP.

On the design sequence diagram of this small fragment, we encountered information as the entire analysis sequence diagram. But when we evolved the design sequence diagram, we have explained how the analysis objects and technical objects will interact to complete the reserved vehicle. We have decided that Vehicleinventory is just a collection class, retains multiple vehicle objects. If we continue this sequence diagram, we will add another collection class to keep all ProtectionProduct objects that can be assigned to a RESERVATION. According to the new technical class and new operation found in this part of the booking vehicle sequence diagram, we can now reconstruct the graph (review map 5), as shown in Figure 8.

Figure 8: View larger image by the first version of the operation update, the four arrow icons in the lower right corner of the screen are placed to the maximum.

Let's come back to see the big picture in the development. As shown in Figure 7, we adopted the method of the Java Server Page Model 2 architecture. This method is a variant that separates the principle of concerns, attached to the model - view - controller architecture. On the left side of Figure 7, there are two JSPs, which are introduced page or views, displayed in the browser. In the middle of the sequence diagram, it is an appointment servlet, which is the step of mastering the customer to make an appointment vehicle as a controller. On the right is an entity object, called a model object, and they have the business knowledge and business relationships we need.

When developing the sequence picture segment of Figure 7, we found new operations in three models, Vehicleinventory, and RentAllocation. At this point, they are only available from the online database. When we further develop a subsequent part of this sequence diagram, or when developing a sequence diagram of other use cases, new operations are found in all classes, including access and calculation, and more.

So we don't here. We only see the behavior of accessing an object from the online database. When the customer selects a car and makes an appointment, the next part of the car rental process begins. Figure 9 depicts a sequence diagram of this partial process.

Figure 9: Design sequence map of the second part of the appointment Vehicle looks large.

Step 1, the customer pointed out that he would make a reservation. The request is sent to the servlet, and the servlet makes VEHICLEINVENTORY temporarily marks the car (written as VehicleID) as unavailable. This mark can prevent other car rental customers from appointing the same vehicle. VehicleinVentory forwards the request to the Vehicle object corresponding to the customer's selected vehicle. Vehicleinventory completes this through the Mark (Expiry) operation, where the EXPIRY parameter is reserved for the longest time to cope with the case where he does not complete the appointment.

Note that I have joined UML notes ("" Is it also updated database status? ") As an agile-developed physical power, I strongly recommend that you only use modeling tools for long-term value. But if your long-term model still has a lot of problems to be solved, don't worry too much to put those problems into the model. You don't see this often, but it is important to make problems with everyone, and always remember them.

After tagging the vehicle, the servlet needs to display the car rental information page, the customer's information given by the page check the system, as well as the content of his customer profile. As we have omitted the sequence diagram section for finding the CustomerProfile in Figure 7, we now also need this overview and the Customer object. Customerid is obtained in step 5 servlet (there we have not mentioned HTTPSESESSION objects), which may have already placed the home page of vehicle scheduling. In step 6, servlet creates a Customer object with this ID, gives it to populate (), assembles its instance variable with the client ID. In step 8 and 9, Customer objects are available in a DataAccess object from the DataAccess object in a pattern that is now familiar with. Now the Customer object has instantiated and assembled for the customer, and the 10th step servlet tells the Customer object it corresponds to the CustomerProfile. Step 11 Customer Inform PROFILE It is a parent object of Profile. Now we have established two-way links between these two objects. After completing this processing, the servlet prepares the RenterInformation page, which is completed by the RequestDispatcher.Forward () operation. Step 13, the RenterInfo JSP page enters the active status. Step 14-16, JSP obtains general information from Customer and CustomerProfile objects, and the corresponding data will be displayed. Step 17 The RenterInfo page is displayed on the customer's browser waiting to confirm completion. Step 18 The customer pointed out that he has confirmed, change, or typed data in the RenterInfo page, and ready to continue to make an appointment. Step 19 I generally pointed out that JSP interacts with Customer and CustomerProfile objects (remember they are javabeans), updating them according to screen data. Step 20, the renterinfo page is sent to the servlet, pointing out that the car rental information is complete. Thereafter we will build a model, describe how the system provides for a binding information, including providing purchase protection products, and the like.

We have drawn a lot of interactions in this sequence diagram, and more operations are found. Lifting our sequence diagram messages to the acceptable operation, we get a new version of the class diagram, as shown in Figure 10.

Figure 10: View larger image by the second version of the operation update, the four arrow icons in the lower right corner of the point are larger.

We now see new operations to Vehicle, Customer and CustomerProfile. This is an iterative use case drive method. From the use case and class, we select an object you need to interact from the class and then construct a sequence diagram representing this interaction. The news of the analysis phase is now allocated to the responsibilities, these responsibilities are to give each class. Thereafter, the message is enhanced to accept the operation on the class of the message object. Ideally, these operations are confirmed to be required because they are to satisfy the needs of the use case, and the use case is the functional needs of many systems. Recall this use case design step is called interaction between design objects. This is clearly implemented in our sequence diagram and captures the interaction of those classes known as possible static structures.

Using Case Design Step 3: Using Subsystem Simplified Sequence Diagrams (Optional) The next step of the design case is the use of subsystems to replace the public group to simplify repetitive behavior. In our example, a subsystem, DataAccess object has been identified. This subsystem exposes RETRIEVE ... () to obtain object data from the database. There is already a lot of things inside the DataAccess subsystem: SQL statement generation, error handling, result set management, and more. But internal details are hidden on the customer objects of query data acquisition (which also have data storage). It is usually not aware of a subsystem (with simplified interface) until it is entangled by a large pile of complex classes and interfaces, we finally realize that they have a natural relationship with each other (such as the printing subsystem Class: Spooler, QueueManager, PrinterDrivers, etc.). There is a good principle of a subsystem, and the public closure principle of Robert Martin:

The classes in the package (or subsystem) should be closed together according to the similar changes. Changes to a closed bag (or system) affect all classes in the package, but do not affect any other packages.

In other words, we have to combine a class with a public goal in a clear boundary to isolate the change in the package / subsystem in its interior. When we simplify the model by introducing a subsystem, we replace the large paragraph in the sequence diagram into a simple message to the subsystem. This isolates the complexity of the former to the inside of the subsystem, and we can develop an independent model for the internal interaction of the subsystem, while the subsystem has become a reusable component in the entire system.

Use Case Design Step 4: Description Continuous Related Behavior However, when we correctly hide the DataAccess subsystem correctly, we actually commit a major mistake: our analytics (VEHICLE, RENTALLOCATION ... The information obtained by DBMS. Analysis objects should only know business logic without knowing the storage location, the DBRecord structure layout. Why is this not good? Consider an impact of a simple change of the primary key as an object change, reviewing our current design is to transfer a special identifier (such as locationID) to the DataAccess object. If the identifier is used as a primary key, there is a change, we have to change the logic in the RentAllocation object.

Is there any way to limit or eliminate this impact of this analysis object?

Have. We can reach this logical isolation outside of the explicit physical isolation described in the software architecture document, which is to introduce three new objects:

A Factory object, create an analysis object, assemble a DB object from DBMS, which is the twin object of DBMS, the twins object of the analysis object, is a Persistence Interface, which is a subsystem for reading the database Write information.

In the sequence diagram of Figure 11, we introduce these three objects, and the Customer object needs to recreate the interaction from the online storage.

Figure 11: Design sequence temptation with continuous layers View larger image, the four arrow icons in the lower right corner of the point are larger.

This is a more encapsulated and more reusable design. For each analysis object (such as Customer), we must create a "DB-Aware" object (such as DBCustom) object (such as DBCUSTOMER), which can understand the data of its "normal" twins Fields and formats. These DB-Aware objects will reside on the web server and are created and used by one of the servlets. DB-Aware object knows where to connect, how to build a SQL statement and make it execute, and how to get the result data and store it in the analysis object. Now, the change of DBMS format or result set data structure is isolated under the ObjectFactory layer, and the analysis object will never be affected. We have to evaluate the storage structure and confine whether we can access the data required for objects. Table 1-7 is an example of a logical model of the DBMS layout. Note that most of the fields in each table matches the properties of the class. However, some tables of tables (such as Table 3: Vehicles: Date of Purchase) are not in the corresponding class, because such fields are independent of the reserved vehicle.

Table 1: Rental location

LocationID StreetAddressStatesReetAddressStatesAsegion

Table 2: Reservation (RESERVATION)

RESERVATIONID locationID VIN Customerid Startdate & Time Returndate & Time Quotedcost PaymentMethod

Table 3: Vehicle

VIN ManufacturermodeLassigned Location Vehicle CurrentMileage..

Table 4: Protect Products

ProductType EligibilityCodeslowerLimit UpperLimit BenefitIncrement

Table 5: Customer

Customerid NamestreetAddressemailaddressBusinessPhoneotherphone Driverslicense #issuingStateLicenseExp. DateDate OFBIRTH

Table 6: Customer Profile

Customerid default usfault DamagewaiverDefault Personalaccident Insur.default SupplementallIAbility

Table 7: Award Program

AwardID / Custid CurrentBalanceytd Redemptions

In addition, pay attention to how the primary key () and foreign key () are how to express the relationship between the vehicle scheduling class. Reservation Table knows the corresponding Customer from the Customerid field. The RentAllocation table can get all the vehicles allocated by the Assigned Location primary key field in the Vehicle table. The SQL statement created by the DB-Aware object is generated based on the physical data model of the accessed database. SQL statement "Select * from vehicle where assignedLocation = 42355 Order by vehicle.Vehicles" returned result set is all vehicles allocated to the car, sorted by vehicle category (cheap car, small cars, etc.). Now we can understand this very important expression: you find and use the design class depends on the design method you use. In our first method we resolve, we put DBMS information in the object that represents business abstraction (ie, analysis class). But in the second method, we also created a DB-Aware object layer, specifically used to read the DBMS data.

Using Case Design Step 5: Describe the design mechanism When analyzing the vehicle rental system, we determine the need for the following analysis mechanism:

Persistent. In a normal reservation session or an appointment changing session, the RESERVATION and VEHICLE objects have undergone changes in data and / or status. So we need a continuous mechanism to store new object data. In the analysis phase, we only need to specify a meaningful name for continuous storage, and how to achieve this continuous details will be resolved in the later design phase.

safety. You cannot display other people to the current customer, so you must specify a mechanism to ensure security certification.

Legacy interface. All vehicle information comes from the company's vehicle system (Corporate Vehicle System) that provides centralized vehicle information maintenance for all rental locations. How to dialogue with the company's vehicle system depends on the design mechanism we can choose.

In the design phase, we re-evaluate these things and put them in the design mechanism, which is made according to the persistence (Table 8), safety (Table 9) and the analysis required for the legacy interface (Table 10). Special solution. For each of them, I added the implementation mechanism to meet the design mechanism, as shown in Table 8.

Table 8:

Mechanism persistence design mechanism RDBMS - Analysis determines to access and store object information in a continuous manner. Because our company has several related database management systems (RDMBs), our design mechanism also specifies RDBMS. We have employees that understand this technology, existing data infrastructure includes tools (such as report generators) with SQL interfaces. Implementation mechanism JDBC - we specially mentioned it in the previous paragraph to complete the Factory class, DB-Aware class and the Persistence Interface class. But how do Persistence interface access target RDBMS? In our scene, assume that the reservation rdbms is an Oracle 9i system running on the UNIX server, but it is possible to replace SQL Server running on Windows 2000. This scenario will make us more flexibility to RDBMS with a JDBC interface.

Mechanism Safety Design Mechanism Safety Certification - Analysis Determines It is necessary to ensure that customers can only see his / her own appointment. We use our customers' Awards ID numbers (this is the only identifier) ​​as the index of the customer database. The implementation mechanism Unique Customer Number (Awards ID Number) is used as a unique identifier as an RDBMS index on the Customer table.

The mechanism legacy interface design mechanism is not necessary in our simple vehicle rental system. In the use case analysis, we firmly maintain the vehicle information by the company's vehicle system, which is an RDBMS. The service provided by the persistence mechanism allows us to insert or extract information in our RDBMS. If we must communicate with CICS applications on the IBM MVS mainframe, we need to specify the communication protocol used (eg, Lu 6.2 Appc). Realization mechanism is not. Conclusion In these two series of articles, I gave a lot of examples to explain how to set up the problem domain from the initial use case containing many system requirements in our production environment. There is more problems in system development to consider, but I believe that these examples have given a practical roaming throughout the process, reaching my original intention. On the basis of the sequence diagrams and class diagram details I have given, readers should find that translating these expressions into Java class definitions or JSP is already a simple and straightforward. Through our design workpiece, you can directly enter the system's conceptual certificate coding, or write product code. Each use case will follow the process in the text until all the use cases are completed in this iterative cycle so that we will complete most of the system's encoding work to complete the encoding work of all important business functions captured in the use case.

Reference Rumbaugh et al., Object-Oriented Modeling and Design .pentice-Hall, 1991.

Robert C. Martin, Agile Software Developments: Principles, Patterns, and Practices. Prentice-Hall, 2003. An Award-Winning Book That Covers A Broad Menu of Essential Design Practices.

Eric Gamma, ET Al., Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Required Reading for Any Developer Doing Serious Development Today.

Further Readings Scott Ambler, Agile Modeling. Wiley, 2002. How to do more with less model, ip.

Len bass, et al., Software Architecture in Practice. Addison-Wesley, 1998. Excellent Cover of What Software Architecture Really IS.

Note 1 This series of articles All RUPs are from RUP VERSION 2003.06.00. All UML models in the article are generated by IBM / Rational Extended Developer Environment (XDE) Developer Plus for Java Version 2003.06.

Reference

You can see this article in our website on our world.