Gary Evansindependent Object Technology Evangelist, EvaNetics, April 01, China
From Rational EDGE: This is the first part of the series of articles on the Rational Edge, introduces a specific case, extracting the demand from the instance, and analyzes, and further converts it to the format that can be directly encoded.
Since 1992 Ivar Jacobson issued a paper on how to use the use case, from the perspective of the system user, this method has gradually popped up. But there is a most common question: how can I use the code when I get the use case? This article consists of two parts, which will be used in an actual case. How to extract requirements from the use case, and analyze, further convert it to the format that can be directly encoded. I hope to make this process clear so you can use them in the current, or in the next software project!
IBM Rational Unified Process (RUP) advocates the use of example to extract the operational needs in the system. 1 Software Demand Manual, the Software Requirements Specification (SRS), including all the needs of the software, including many related documents. The use case is an important part of it. SRS mainly includes the following parts:
Model model, including:
Model: Visual description system users, and systems are available for users. Role Definition: Describe the system functionality and the service required by the text. Example Description: The main function provided by the text description system. Software Supplementary Specifications: This document includes a variety of requirements related to the entire system, and some hidden needs that are not directly related to system users and use cases.
In the RUP method, this demand document is the starting point of subsequent analysis and design work. Different development methods, the driving force of the project is different, and there will be different documents. If the software is released, you always have a patching defect, you are likely to have no demand documentation at all. Can only be seen from the bug report, the software has been different from the beginning of the design. If you maintain or improve a software version (such as adding a new feature), you may have one or two use cases, how do they interact between these new features and users, but you don't have a software supplementary specifications, because of these The part other than the function has not changed.
Here, use a fictional software project "Green-Field" as an example. This is an object-oriented software project that uses UML to describe the various concepts and relationships in the system. The reader needs to have the basics of objects and classes, familiar with UML version 1.x or class diagrams, sequence diagrams, and collaboration maps.
Use case analysis activities Let's discuss the use case analysis in RUP. As shown in Figure 1, the results of structural analysis in the RUP are integrated.
Figure 1: Structure analysis workflow (Elaboration)
Obviously, if strict, the software development process should focus on the architecture design of the enterprise system, as well as software reuse. However, based on the following three reasons, here I don't have the story of the story of the long story:
My goal is not structural analysis design, but is a more daily work for developers. This is not a monograph, there is not so many spaces to tell the structure analysis. According to my experience in the software architecture and software process, only few software development organizations can make structural analysis. If you are working on structure analysis, you must have experienced some of this article. For a new, or a large software project, the use of structural analysis is a wise choice. But if you are less familiar with structural analysis, the content of this article will benefit you. The purpose of use case analysis:
Find the execution process in the use case, each class of events. By implementing the use case, the behavior of the use case is specified to the specific class. Find out the responsibility, attributes, and their relationship between classes. Normally determine the responsibilities of various cases in the system.
We can also think that the goal of use case analysis is to make our understanding of the use case, transform the value of the needs of the business. In the case of use case design, we abstract business concepts, objects, relationships, components, interfaces, etc., which are directly corresponding to the target system.
Figure 2 References from the RUP analysis and design summary, describing the scenarios, and the relationship between the use case analysis and other steps.
Figure 2: Use example analysis in RUP
The use case analysis in RUP [RUP2003] consists of several parts:
Each use example includes:
Creating a supplementary description of a use case implementation (if required) From the behavior of the use case, find out the analysis class (Analysis classe) to specify the behavior to a specific analysis class for each analysis result:
Attributes and relationships of class responsibilities
Definition class attribute analysis class Direct relationship analysis Inter-related event and events All use case implementation tracking mechanism establishment analysis mechanism to evaluate the results of use case analysis
Note that the order of these steps is not constant. The order you actually adopted depends on your understanding of the analysis of the analysis, your experience of RUP or UML, the model you use, or a habitual way you identify the properties of the analysis class. (For example, based on responsibilities, behavioral, or data-centered) is only if you can create an accurate description of the problem, not the accurate description of our use case design - this will be this article The contents of the second part). I will follow most of this article (but not all) steps, and I will change some steps. In the specific content of each step, I will explain why this will help RUP and OOAD better learning OOAD.
As shown in Figure 3, some steps are separated by the writing cases and implementation code. It is also listed in the RUP's useful steps recommended for use. This picture will point out in the back section, our advancement direction.
Figure 3: Steps for use case analysis
The specific example example of the use case can be better illustrative. This fictional short example is a website system of a car rental company. This system generally has several use cases describe the services provided by customers, such as:
Appointment Car Cancel Reservation View Car Rental History Information View / Edit Customer Profile Join Board Activities, etc.
To simplify the model, assume that our services are only for personal users, and they are not for corporate users.
In order to make the example as simple as possible, it is easy to understand, we only analyze one of the use cases. The following: make an appointment.
Use case: make an appointment.
This use case raises his best to make an appointment of a car. The system prompts customers to enter their hopes and return the time, location, and customers of the car. The system prompts customers to choose the model that wants to rent, the customer choices. The system lists all-eligible cars available at the specified time, place. If the customer needs more detailed information for a car, the system can also be available. If the customer selects a car, the system prompts the customer to enter personal information: name, phone, email, etc., customers enter the above information. The system provides information on various protection products such as automotive damage insurance, passenger insurance, etc.) and asks if the customer is purchased, customer choices. If the last customer said this appointment is accepted, the system notifies the customer to make an appointment has been successful and give the customer a confirmation. This use case is over when the confirmation information appears. It is necessary to describe the use case with a popular way, not only for the web program, even if the customer goes to the business point to make an appointment. Example Description only needs to indicate the result, it is not necessary to explain how the specific system will operate, how the system's customer will operate. If you use the "Sales" instead of the word "system", the above description has become a preparation description of the customer to the business staff to make an appointment. The 7th step is given the confirmation, and it becomes a confirmation of written format here.
When designing the web interface, multiple steps can be placed in the same page, such as steps 2 and 3 in the above description. In a web environment, the confirmation of step 7 will be presented to the customer in the Reservation Transaction Report page.
Also note the text style described in use. The above description is to use the front tone and describe the present time. The front tone refers to the description of the clear decisive, the opposite negative tone refers to passive tone, and a comparative description. For example, "John Punches" is a positive tone, and the executor of the action John is placed in front of the verb. The passive tone of this sentence is "Ball being thrown out by John", or the simpler "ball is thrown", and the active body is also omitted. The actor John of the action is placed behind the action. In all negative tone descriptions, the executor of the action will appear in the preposition phrase. Let your use case describe clear and consistent. Use the front tone, now the time. Don't use too much vocabulary, you can clearly, don't use too much unrelated words, keep it before and after. For example, don't use "customers", but use "customers", or "business partners" is also good. If you use these three at the same time, your readers will think that you are describing 3 different users, their information and permissions are different.
We are ready to describe it as a starting point for the next step. Let us start to analyze the use case analysis process in RUP.
Use case analysis First step: Creating a first step in the use case implementation RUP is to establish a use case implementation. Before we give the definition of the use case implementation, look back and look at it. What is the use case? How do we need to confirm the use case? Our use case is a description of a business process, describing the process of customer appointment. It illustrates that we will follow the fixed business rules (for example, if you do not do anything before getting the customer's name), it is not allowed to provide customers with information that cannot be rented in accordance with the specified time location.
Since we are designing an object-oriented software system, our use case behavior needs to be performed by some objects and classes in our system. But so far, we have no objects and classes, so we need to discover these objects and classes from the usage. You also need to specify which behaviors of each class should be performed in the example.
As shown in Figure 4, the use of an example implementation is actually a set of UML diagrams, which shows what kinds of doors, their duties, and how their instance objects interact, to complete the behavior in the case.
Figure 4: Implementation of a RUP use case in the ticket reservation system
Usually a use case implementation will consist below:
A UML class diagram including all classes that appear in the use case we have focused (sometimes called collaborative classes), and one or more UML interactions that describe the interactive objects, and the call relationship between them. UML defines two types of interactions: sequence diagrams (Figure 4), and collaboration diagrams. It is very effective.
It seems that we have a lot of things to do, is this? Yes, and when you use developments such as Rational Rose or Rational XDE, this work looks more like a household management, you only need to build a lot of structure and store your use case implementation. Behind we will complete the actual class and interactive diagram. But now let's clarify our goals: a class diagram, one or more interactions.
Use case analysis Next: Supplementary example Description When you are analyzing, your use case describes only the user's perspective from the outside of the system. What is the behavior of the system looks like. This is sufficient to describe some invisible operations inside the profile system, but in this description, the specific implementation cannot be completed.
To give an example, see the fourth steps described above: The system lists all the eligible vehicles that are specified for time, location, and available. If the customer needs more detailed information for a car, the system can also be available. Here, have we have a database for search for car information? We might know that car information is managed by CICS (Customer Information Control System), stored on the MVS host, can be accessed by lu6.2 appc, but we cannot determine this. Let us take these things we have to do, especially in our system, and not only know how we want to do it. The following is a fourth step to supplement this information, supplement a car database: The system finds the location of the car by accessing this car database, and lists all the car specified in the specified time location and available.
Here we give information about a car database and compare abstract describes how to use a web to access it. This is a very simple example, but readers can learn some content from it.
In the iterative development process such as RUP, transfer from the analysis phase to the design phase only uses a little time. For a medium-sized, around the project, you may be used to get the needs, do your analysis and design, then use it to write code and test after 3 weeks. The use case you use to analyze will focus on system-external visible behaviors, but you may need to refine these use cases, add more descriptions of how to interact inside the system. This allows your customers and analysts to confirm that you have no missing business. Note that you only need to describe the use case to you can find out the degree of analysis class in your system. For design levels (such as trees, stacks, queues, collections, etc.) can be completed in later stages (such as design phases).
Example: Supplementary "Appointment Car" assumes that our system is a website program. When customers need, we will provide them with private online reservation car services. We must refine our use case for this specific situation, but don't have too much work involving the design phase.
This is a more detailed description of the reservation car usage, or is focused on what to do, not how to do it:
Use case: make an appointment car (supplement)
This use case begins with our appointment. The system prompts customers to enter their hopes and return the time, location, and customers of the car. The system is also provided to a customer's option, such as miniature cars, SUVs, standard cars, and more. Customers can qualify for a car in one or more species. The default is to search all kinds of cars. If the customer participates in our award-winning rental car activities, he can enter his award-winning number on a single place on the web. If he fills in this number, the system will access the customer's file to pre-relevant information. If the customer wants to continue to make an appointment, the system lists all the conditions (time location) who have found in the database, providing the basic rate of each car, can be a little discount according to the customer's rent history . If the customer needs more detailed information of the car, the system finds this information from the database and displays it to the customer. If the customer selects a car to make an appointment, the system allows customers to fill in personal information (name, phone, email, credit card distributor, etc.). If there is already a file file in the system, the corresponding information in the callout system is displayed on the page. Some information is required, and others are optional (such as email). Users need to fill in all required items. The system also provides information on various protection products such as automotive damage insurance, passenger insurance, etc.) and single-day prices, and ask customers if they purchase, customers choose. If the customer means "accepting this appointment", the system displays the profile information (car model, date, time, selected protection product and cost, total cost, etc.), let customers confirm. If the customer fills in the email, the system will send an email address that confirms the letter to the customer. This use case is over when the confirmation information appears in front of the customer. In this replenished use case description, we clearly describe a browser-based program, describing many behaviors that are invisible to customers. But there is no information on the design level.
Do we need to provide similar details for each use case? No need. But remember, supplement details, not to refer to the specific details of the realization. Our goal is to understand enough information to understand the analysis classes in the system, and agree with your customers or analysts on all the business processes of all use cases. If you feel that some details are helpful to find out the analysis class in the system, then add it.
Note: It is difficult to grasp the scale of this detail. It takes time and some exercises. Many playing hands, ask others more, but also remember when you can't decide, it should be slightly biased towards the abstract description. Increase some content that is not written is easier, but it is difficult to find useful information from a lot of messy descriptions.
Why should I write more abstract use cases first? Why don't you use the case supplement more detailed? This is because the abstract use case is the most general description of system behavior (but more description system internal behavior). What if you want to develop a client / server version of the reservation of the car? If you use a detailed use case (Based on the browser system use case), you have to rewrite the entire use case every time you change your implementation platform. This general description is independent of technology, especially when you have not yet, or if you can't determine the specific environment of the system, its value is reflected. In addition, universal descriptions can make your business analysts can only see how the system works, rather than seeing content that contains many technical details they are difficult to understand.
Use case analysis Step 3: To find out the analysis class according to the RUP process, this step is to find out all the behavior of the use case. Because we have no classes yet, our main goal is to identify all analytical classes in the car rental system. This will lead to an interesting and important issue: What is the analysis class? There are two answers. First, an analysis class of a business level is a factor in the business sector, and is independent of implementation technology. For example, bank customers, accounts, account transactions in bank systems, and more. And it is independent of the implementation of the system, whether it is a new e-commerce system, or a lending system that starts using it from the 1980s.
Second, the RUP process extends this definition three different analytical classes: physical classes, control classes, and boundary classes. The entity class during the RUP process is generally equivalent to the previously mentioned analysis class. The control class is related to the business process, which controls the flow and execution of the entire business. It typically controls the execution of a business process in an example. The boundary class is between the system and the outside, exchanges various information and events for them. The input and output of the boundary class processing software system.
According to my teaching experience in object-oriented technology and object-oriented modeling, I found that developers always quickly entered the next design link from the solid class, control class and boundary class in the RUP process, and there is no problem. Carry enough analysis. In fact, it is clear that the control class and boundary are class-oriented, not a business-oriented class. They are part of the system design model defined in the design phase, not the analysis model. Therefore, in this step, I will focus on the business, and have nothing to do with technology. The part involved in the technology is discussed when discussing the design. Always remember that searching with business-related classes is conducted in the structure analysis section in the RUP process. If your project uses the RUP process.
Let us review the behavior described with examples, which is what services provide users with users. In the example description, there is no object-oriented content, but these descriptions are used to find objects and classes in the system. You can use a variety of ways to find classes in many places:
The common sense of the field is just the previous similar system enterprise model or for reference architecture CRC (class / responsibilities / partnership) method gap data mining
A simple way to find classes is gramatic analysis, here I will explain. We only need to find out the nouns in our needs, these nouns (some are adjectives nouns):
Some are classes. Some will become the properties of the class. Some irrelevant to our system.
Find these nations in the use case description of the appointment (synonymous, such as "he"), as follows:
Use case: Appointment for the customer (supplement)
This use case starts from the customer to our web page. This system displays the input box to prompt the customer to enter the location of the appointment and return the time of the appointment, and the date and time of the borrowing and returning. Customer enter the location and date. The system also provides a selection box to allow customers to limit the model classification of the car, such as miniature cars, SUVs, standard cars, and more. Customers can specify a car classification to search or specify multiple categories. The default settings are searching in all car classifications. If the customer participates in our rental prize, he needs to enter the number in his award-winning activity into a separate input box on the web page. If this input box fills in the content, the system will access the customer's profile, and the system will find the information you need in advance. If the customer expresses that you want to continue the appointment process, the system accesses the car database to find the location information and display all car information in a new web page. These cars are in the designated car classification and are idle in the designated location, date and time. For each car, the system will display a base rate. If the history of the customer rent is long, you can also play some discounts. If the customer wants to see more detailed information for a car, the system reads this information from the automotive database and display them to the customer. If the customer selected the car to make an appointment, the system displays a new web page, prompting the customer to enter personal information used to confirm the customer's identity, (name, phone, used email, credit card distributor). If the customer file already exists, the system reads all the information already filled out. Part of the input information is required, other (such as email) is the option. The customer fills in all necessary information. The system also displays information-related information (such as automotive damage insurance, passenger insurance, etc.) and single-day prices, and asks if the customer purchases these protective products. Customers give decisions. If the customer means accepting this appointment, the system gives a web page to display the summary information of the app, (the type, date and time of the car, all the purchased protective products and its cost, total rent), also display appointment for customers Confirm the page. If the system has a user's email, the system will send an appointment confirmation letter to this address. This use case is over when the appointment confirmation information appears in front of the customer. Pay attention to each noun, or the combination of adjectives noun is marked. There are many repetitions, so each word is listed separately in the vocabulary 1, sorted in alphabetical order:
Table 1: Candidates / Entity Class
How do we distinguish what candidate nouns are the true problem class? A common method is to test each word in some simple issues, as shown in Figure 5:
Is this candidate within the boundary of the system? If not, it may be a system of users. Does this candidate have some obvious behavior related to the business topic? (That is, can this candidate word can have or provide some system services or functions?) Is this candidate with a significant data structure? (That is, is this candidate word owned or managed?) Is there any relationship between this candidate word and other candidate words?
Figure 5: Problem for finding analysis
If a answer is "not", then this candidate is likely not a class. Continue to check the next word. If the answer is "Yes", continue to check the next question, if all the questions of all the questions are affirmative, this candidate is a class. Continue to check the next word.
We check each candidate word, it will get the results similar to Table 2:
Table 2: Noun check results
Please note that the rent site has been added, although it is not part of the use case. When talking to our business expert (SMES), we found that the location of the business will refer to an address, or a rental department. In order not to confuse, we uniformly uniformly use the word rental location to represent business locations, which is where rental and returning. From this list, we list the words checked by the problem, that is, the analysis class listed below:
Ah! In a total of more than 30 candidates, we only need to face the selected eight analysis classes. The four problems in front help us narrow the search range and is a very effective tool.
But have we made mistakes? Have you leaked a real class, or add a word that should be used as a class? This is not important. RUP iterative features will gradually expose our mistakes, and allow us to correct them with as small costs. The goal of analyzing and design is not perfect first, but when you need to confirm these things, you will confirm these. The beginning of the stage is often the most difficult, we now realize the object (or say) from an incompetent breakthrough! It is important that we have started, and we can make progress step by step by step according to object-oriented methods.
We have completed the first three steps in RUP's use case analysis activities:
For each use case
Establish a use case to achieve a supplementary example description (if needed) to use the routine, find out the analysis class
If we are in strict accordance with the RUP process, the next step should be:
Assign behavior to the analysis class
Based on the following reasons, I will make a small change to the RUP process: review our progress. We have just found eight entities, we think these are classes in our system. Before we do next, we need to add some content to these 8 entities, to confirm that they are classes.
There are three basic methods to enrich our analysis class:
Data-driven method behavior driven methods, and methods driven by responsibilities.
Data-driven methods are common for people engaged in database or those who are engaged in process language. They are using the relationship between data and data to describe the world, so it will first go to find data in the class - generally there is no standard method to find a function or function of the class. This looks good, but the data is only half of the work. In fact, accurate definitions of classes, including data and operations for data.
The behavioral driven method has a double settlement. First find out the operations of the class, which determines the data involved in these operations, which should be owned by this class. This is great, but how do we confirm that we can stay in the operations? How to distinguish between operations and classes, to clarify this operations belong to this class, but other operations belong to the same class, or other classes? We need some way to distinguish each operation. This is the method of responsibility to bring to us.
The method of responsibility is from the top, from the view from the overall class and its responsibilities. First define a "mission" in the business, this "mission" describes the services provided by this class. From military terminology, it is responsibility and strategy. Operation and data are tactical levels (for strategic services, obeying some objectives, strategies). 2
Once we identified our class's responsibilities, we can design an analytical class diagram to describe the overall structure of inter-class relationships. This structure is generally determined by the business domain. A UML analysis class can help us visualize the structure of this relationship.
Therefore, I suggest that the standard RUP process is modified as follows (order change): bold):
For each analysis class
The duties of the description are on the analysis class diagram, establish the connection between the analysis class to specify behavior to the analysis class (find operation) to describe the properties and relationships of each class.
Define the properties of the class description analysis class event
Use example analysis Step 4: Describe the responsibilities of the class here, we have to process each analytical class. The responsibilities of the class describe the services provided in the system, and other classes do not reuse these services. The duties of each class cannot overlap.
According to our understanding of the automotive rental area, work with the car rental experts, business analysis experts, we wrote our understanding of each analysis class in Table 3.
Table 3: Responsibilities of each analysis class
James Rumbaugh is defined an object, or a class, an abstraction, or a clear-defined thing [my focus] "for a concept, abstraction, or a clear definition. In the definition of class's responsibilities, you should first pay attention to "clear definition", that is, it is clear that you can do what you can do, what you can do.
What should I do if the duties we define? We repeat again, this is not a need. We have started and progressing in progress. When we know more about the system, we have made some adjustments to class's duties. This will help us make better work and software.
Use case analysis Step 5: The relationship between the establishment of the analysis class We have identified the responsibilities of the class, and the UML class map will be designed as a starting point to find out the relationship between the analysis class. Establishing a class diagram There are four simple steps:
Determine the class to be modeled (we have completed). Determine which analysis classes have a relationship between other classes. For any two classes, it has a relationship, the semantics of the relationship: Is it associated, aggregating, synthesis or inheritance? For non-inheritance relationships, confirm the diversity (pointing how many objects in another class can be associated with an object of this class, similar to the concept in the data modeling.)
Through the above steps, add the responsibilities of our previously determined classes, we get UML class diagrams, as shown in Figure 6:
Figure 6: Class diagram of car rental system
There are three UML relationships on this class diagram, which is divided into different lines. Simple solid lines indicate a relationship. Used to show the relationship between the point-to-point point between two classes, each class calls another type of operation.
Using solid rhizes on the line, it is a synthetic relationship between the appointment and protecting the product (or unable to share the aggregation). This is an overall / part of the relationship, or is an owned relationship. In this type of diagram, the synthetic relationship indicates that the appointment has 0 or more protection products, which are owned by the appointment. Furthermore, the synthetic relationship indicates that if the object is reserved, the protection products he have must also be destroyed, because when the protective product is no longer part of the appointment, it will lose the meaning of existence.
The online rhombus is represented on the line, which is a polymerization relationship between the car rental and the car (or a shared synthetic relationship). This is also a whole / part relationship, or is a relationship, but when we destroy the car rental, we will not destroy the car. This is in line with the common sense: because the car does not rent, the car object will temporarily become "orphan", but it is not destroyed, just provide it with another car rental.
The numbers and * symbols of the relationship are called diversity descriptions. These symbols indicate how many instances can be connected to an instance. For example, you can have the number of cars with a custom relationship with a customer. Alternatively, in turn, the number of customers who can be related to a car. In this class diagram, our diversity indicates "for each customer, there is no car booking, and there can be many automobiles". Conversely, "It is" for each car, there is no customer reservation, and there can be multiple customers ". In the analysis, we try to confirm that we can correctly express and understand the problem. For business experts and analysts, the analysis class is a useful tool to help them review the design with technicians and further advance.
Now we have class, responsibilities, and class diagrams that display the relationship between display classes. But so far, we have not involved in the interior - no operation and attributes. Moreover, the class diagram is static. How do we confirm that these classes can complete our business process in use? This is the purpose of the next step, this is a very important step because it will describe the use example to map the potential operation of the analysis class.
Sixth Step 6: Confirm that the behavior of the analysis class collaborates how these classes collaborate to complete this use case for booking a car? We use the UML to interact with each other to find these interactions between the analysis class. Recalling the sequential diagram and collaboration map mentioned earlier, it is two kinds of interactions, which are part of our use case implementation, as shown in Figure 7, this is a sequential diagram of an analysis level, describing a book for a book. Example.
Figure 7: Sequence diagram of the analysis stage of the booking of a car is scheduled to enlarge
You will see that in this figure I have introduced a non-business class-ECCONTROLLER. This use case control class represents a class that has not been further defined, and its responsibility is to receive events and messages there from the user. I have found that most readers will feel confused: a business class (such as rental location or appointment) to receive the user's message? So I usually give me an analytical interaction to add a general use case control class to represent this logic, and it is convenient for the reader's understanding. In the design phase, we will rename this class as ReserveavehicleController, but now I use this universal name uccontroller to represent.
The sequence diagram and interactive diagrams include almost the same content, they just represent different ways. Which type of picture is mainly depends on whether it is convenient and personal preferences. In the sequential diagram, the object is aligned in the vertical ride, and arranged in order from top to bottom. The horizontal line marked with numbers and text is called a message. In a sequential diagram, the order of the message is represented by their position: according to the time order from top to bottom, the number of pieces that are ranked below occur after the message is ranked. The message starts from an object's timeline, termination on a timeline (typically the timeline of another object), but sometimes terminates on the timeline of the same object, as shown in FIG.
Compared with the collaboration map, there is a very obvious advantage, which is the script on the left side of the figure. These texts are taken from the use case, or the description of the sequential diagram. These descriptions are a short description of this use case for the appointment. By putting these scripts on the map, the meaning of the message is very clear. Moreover, the message, object, and the original use case are combined. Each statement in the use case corresponds to one or more messages in the figure, on the sequence diagram, which is clear.
I want to emphasize that in the interaction map in the analysis phase is: the news indicates the intent, not the implementation, nor the interface on the appointment of the car sequence, the message is just simple, I want to receive the message. Object What do you do, the message does not mean a function call. The function calls these more specific information will be determined at the design phase. But now, we only need to be in this use case, and the class is responsible. How do we find these news? Just look at our duties definitions. For example, in the eighth step, the rental place is to be determined in this location and which cars are available. In the ninth step, the car rental is to provide all the car that meets the date and time of the user requirements in this place. In tenth step, each car in the rental needs to answer whether itself meets certain rented conditions. Please note that all of these knowledge is not in this object of rental places. We distribute these knowledge to all of our analytics classes, so each class can complete a part of work according to definitions.
UML Description: Object - Do you need to name? In the sequential diagram, the object box does not have the name ":
Account
If we build two instance objects of the two Account classes, Fredsstash and Ethelsmadmoney, they will be like this:
Fredsstash: Account Ethelsmadmoney: Account
Take the left one as an example, indicating that "FredSstash is an object of the Account Type". How do I decide whether to give an object? If one of the system in the system has a very clear name, you may want to get a name for its object. If you have an exemplary object in your figure (similar to a data sheet example in the data model), you can also use a named object. But for most situations, anonymous objects are sufficient. We only have the relationship between classes and objects, and the name of the object does not affect the behavior of the object.
Use case analysis Step 7: Describe attributes and relationships In the analysis, we will find that some properties are needed in order to complete their duties (that is, the class's attribute variable). From the list of responsibilities, we can determine some properties of the analysis class. Other properties are derived from common sense (for example, each car object should have a unique identification attribute, correspond to the standard car number of the car alliance on the actual car).
UML Description: The classes in the UML are divided into three sections on the graph, as an example of the Account class, as shown below:
The class diagram in Figure 8 shows the analysis class of the car rental, the relationship between them and some of the basic properties of each class. These attributes are some of the obvious properties obtained by the duties of the class. Note that these attributes do not indicate the data type because the data type is the problem of the design phase.
Figure 8: Starting point of class properties
In this step, we only need to indicate that the customer has a property called the address. As for the address of this property, it is necessary to do not need to be a separate address class, which will be determined in the later stage. You will find that the car rental category has no properties, which will become an external interface of the system. And which properties are needed, but there is no decision. These issues will be solved in the future stage.
Use case analysis Eight step eight: Verify that the analysis mechanism analysis mechanism refers to advanced system build components that provide some services that resolve specific domain issues, not technical. For example, in the insurance field, information, statements, and other content in the policy, are needed throughout the insurance management period. This demand is used for analytical mechanisms, it is called: persistence: Regardless of whether the program is running, the information and status of data have been maintained. Please note that we don't specify using Oracle SQL, or SQL Server's specific implementation environments, we just list persistence, and the design mechanisms and implementation mechanisms we have later later. The implementation mechanism will be related to a specific platform or software vendor. We tried the relationship between the table 4, the relationship between analysis, analysis, design, and implementation mechanisms:
Table 4: Relationship between explanation, analysis, design, and implementation mechanism
Some universal analysis mechanisms are:
Persistent communication (between processes, or application between applications) Accidental incident notification mechanism message security release (that is, the object being released) is left behind
In the car rental system, we need to specify the mechanism for these specified analytics:
Conclusion In the first part of "Used to Code", we started from one use case, so far, the relationship between classes used to implement the use case, and the properties they need. We also find some analytical mechanisms that will be used in future design and implementation.
If we repeat this whole process again for another use case, we will find that other analytics classes, define their duties, and their relationships. Maybe some new analysis mechanisms, draw new collaborative drawings or sequential diagrams, how to interact with these classes. This demonstrates the incremental feature of the RUP process: each task, each iteration, is made on the basis of the previous work.
We have completed a lot of work, but we can't start writing code. Below our focus will be placed in the design case, which is the topic of the second part of this article.
Thanks to IBM Rational's Peter Eles and Zoe Eason, they put a deep insights and suggestions for earlier versions of this article.
Reference Wirfs-Brock, Rebecca. Designing Object-Oriented Software. Prentice-Hall, 1990. A classic in object thinking and modeling. Introduces the significance of the responsibility-driven approach to software modeling and design.
Rumbaugh, Jim, et al. Object-oriented modeling and design. Prentice-Hall, 1991, Pg. 21. The defining book on the Object Model Influence on The Unified Modeling Language.
The Rational Unified Process, Version 2003.06.00.65. Rational Software Corporation.
Further Readings AMBLER, Scott. The Object Primer, 2nd Ed. Sigs, 2001. Covers end-to-end object-Oriented Development with a single case study.
Fowler, Martin UML Distilled, 3rd ed Addison-Wesley, 2004. Best introduction to UML (version 2.0) for those learning UML for the first time.Taylor, David Object Technology:.... A Manager's Guide Addison-Wesley, 1998. One of the best Introductions to Object-thinking Ever Written.
Bell, Donald. "UML Basics - An Introduction to the Unified Modeling Language," In The Rational Edge, June 2003: http://www.ibm.com/developerWorks/Rressional/Library/769.html
Bell, Donald. "UML Basics: The Activity Diagram," In The Rational Edge, September 2003: http://www.ibm.com/developerWorks/RATIONAL/SEP03/F_UMLBASICS_DB.PDF
Bell, Donald. "UML Basics: The Class Diagram," In The Rational Edge, November 2003: http://www.ibm.com/developerWorks/Rressional/LibraryContent/RATIONALEDGE/NOV03/T_ModelingUML_DB.PDF
Bell, Donald. "UML's Sequence Diagram," In The Rational Edge, January 2004: http://www.ibm.com/developerWorks/Rressional/Library/3101.html
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.
2 To learn more about responsibilities, please refer to Rebecca Wirfs-Brock's related booksigning Object-Oriented Software, Prentice-Hall, 1990.
3 Rumbaugh, Jim with other people in Object-Oriented Modeling and Design, Prentice-Hall, 1991, PG. 21.
Reference
You can see this article in our website on our world.
