Java Modeling: UML workbook, part 1

Java Modeling: UML workbook, part 1		Original ENGLISH

Content: What is a case model? Transaction Processing Interconnect System Reverse perspective Logic Application to user interface References About the author Comments on this article Related content: Object-Oriented Design Process: Case Introduction Create a UML sequence diagram with a style All articles in the Java modeling Series User interface logic in case Modeling Granville Miller (rmiller@togethersoft.com) Consultant, togethersoft June 2001 In this section of Java modeling, Granville leads you into a region between modeling and methods, and looks at the requirements collected through case modeling. He particularly focused on the relationship between user interfaces, system interfaces, and case descriptions. Although we are trying to include user interface logic in use cases, this is generally considered a bad form. Next, grancille uses the sequence diagram and system interface to tell you the specific reason. ClickArticleTop or bottomDiscussionTo participate in the Forum and share your thoughts on this article with the authors and other readers. Requirement collection is an indispensable step in any successful software development cycle. Although many collection methods are required, the most common method is case modeling. In the previous two columns, we have completed part of the work of associating sequence diagrams with case modeling. This time I will talk more about the theory after the method and add some words for your modeling. In this discussion, I am more concerned with clarifying the relationships between user interfaces, system interfaces, and use case descriptions. Because most of the systems created will be designed to be interactive on adult machines, it is tempting to design case descriptions to start running with user interfaces. However, the user interface logic in use cases is generally considered a bad form. A simple explanation of this statement is that the user interface provides a system overview of the system perspective. Use Cases are always described in the participant (or user) perspective. To really understand why we do not include the UI logic in the case description, I think we have to use hands-on methods in any case. We will use the loan application example in my first column, and you will see how the use case becomes complex as the size increases. In particular, we should pay attention to the role of the perspective in case modeling. As we go deeper, you will see how the perspective is used to work for you, or how it hinders your work if it is incorrectly applied. What is a case model? A Use Case Model consists of a chart and a set of descriptions describing the use case. A use case is a set of possible interactions in a system, and its participants are directed at the same defined goal. These descriptions describe the functionality of the use case in the system. This chart provides visual roadmap for these descriptions. UML specifies the criteria for creating Use Case charts, but it is not intended to write use case descriptions. The results generate many methods for writing case descriptions, which sometimes compete with each other. The most popular method for writing case descriptions reflects the idea of Ivar Jacob son (inventor of case modeling. The Jacob son method involves a series of inbound and outbound rules calledPrerequisitesAndPost Condition, AndEvent stream. This event stream describes the interaction between a series of participants (users or external systems) and the developed system. This event stream represents a single path to successful output through the system. This is the core part of the case description, but not all. Event stream alternation and exceptions In addition to the description center event stream, the case description must describe the interactions that occur outside the normal event stream. For example, the main event stream (in simple cases) of the videotape lease case can be expressed as follows: The video rental store clerk scans the customer's membership card. The system obtains the member name and his current lease status. A "allowed lease" status indicates that this customer can rent a video. The store clerk scans each disk of the rented videotape. By scanning each videotape, the system adds the record that can be rented to the user's visible list and displays the current record list that can be rented. The clerk of the videotape rental store enters the amount of money to be charged (in cash) or scans the credit card. The system marked this videotape as rented for a certain period of time and printed the receipt for the transaction. But what if the customer owes the overdue payment in the last lease? She needs to pay off the overdue payment before she can rent the selected videotape again. The interaction of the overdue payment is as follows:AlternateStream orExceptionsStream. It is normal to alternate event streams with exceptions. In some cases, they can be corrected to re-start normal event streams. In other cases, they cannot reach the target. In our example, if the customer pays the peak fee and the rent, she will continue to rent the video. Transaction Processing in case Modeling With its alternation and exceptions, the event stream is composed of a series of transactions.Transaction ProcessingIt is the interaction initiated by the participant and the system waits for the trigger signal from the participant. (Note that the participant who completes the transaction is not necessarily the participant who initiates the transaction ). Transaction processing allows us to divide use cases into smaller elements and logically group them at each decision point.Decision PointThe point where the participant must make a decision or provide additional information in the description. All transactions are composed of one participant and one system interaction. You rarely need to plan a system that is not started, even if it is only time-based. When creating a use case model, you must ensure that each startup is accessed by a certain type of system response. This call and response are complete for use cases. Transaction Processing in the sequence diagram Transaction processing is easy to recognize in sequence diagrams. In my first column, I introduced only two transaction processing solutions. When the applicant requests a new loan application, the first transaction is started. This transaction is completed after the system waits for the applicant to fill in the request and submit the request. When the applicant submitted a loan application online, the second transaction was started. It is based on the credit report sent by the system to the Business Credit Consulting Institution. Figure 1. Let's take a look at the sequence diagram created to describe this solution-Submit a loan request and its two transactions. This chart creates two transaction processing models from the beginning to the end. You will remember that this is a general sequence diagram, which allows us to add more solutions (to add more transaction processing) in the future ). At least in the analysis phase of this development cycle, when we add a solution, we will complete this use case. However, when we move to design, we may find that we need to add more transactions. For example, if we choose to confirm the screen to the screen (instead of the single confirmation currently at the time of submission), we must add a transaction processing at each step of confirmation. Now let's take a look at 1. Pay attention to the description of transaction processing. Starts with identifying the information from the participant to a class or instance that appears closest to the top. As you can see in the chart below, the first transaction usually starts from the left. Follow the arrow until you reach another participant or the sequence ends. When the order ends, it returns to the initial participant. This is a transaction processing. In Figure 1, you should be able to see two complete transactions. Figure 1. Partial Sequence Diagram of a loan request case As in most other use cases, loan request submission uses multiple transactions. So far, we have only listed two of the charts, but a common use case uses about 3 to 15 transactions for processing. To understand the relationship between the perspective and transaction processing, we can look at how the two systems communicate with current affairs. Some software systems are actually a series of small interconnected systems. These smaller systems work together to provide the functionality of the entire system. Each small system provides only one subset of the entire system function. They communicate with machine interfaces through a set of protocols, which will increase the complexity of our case model. System Modeling of Interconnected Systems When considering the Interconnection System, this makes sense for establishing a large system composed of smaller interconnection systems. You can switch a system and replace it with another system. You can also establish each system independently. In addition, you can use many sites or vendors to complete the entire system. The best example of such a system is a typical telephone network. One part of the telephone network provides dial-in channels, the other part transmits sound or data, the other part provides the bill service, and many other parts carry out services such as call transfer and voice mail. A telephone network may be the largest example of a system composed of Interconnected Systems, and its continuous operation proves the effectiveness of such a system. Similarly, it is important to understand how to design and establish such a system model. A similar example We will use a similar loan processing application to create a model of a system consisting of Interconnected Systems. Now, we have created a model for submitting loan request use cases, but this use case is actually part of a large loan processing system. The loan Submission System and the Business Credit consultation institution that interact with it are two systems that must cooperate to provide necessary data to handle loan requests. In real life, additional systems are also involved. However, our example only discusses two systems. Figure 2 shows the two systems, loan submission and commercial credit consultation systems, and the interaction we will focus on in the rest of this column. (Note: Figure 2 is not a UML chart; it is a real-world chart, which is used to show the interaction between the two systems .) Figure 2. Interaction between two systems As shown in the preceding figure, Figure 3 shows a subset of the loan request submission cases from the perspective of the loan submission system. This figure shows that the end of our second transaction is when the applicant submits a loan request, in the loan submission system (CreditcheckerTo the representative Business Credit Consulting Institution (Creditbureau. Figure 3. subset of the system section of a loan request case submitted Now, let's take note of this request from the perspective of the Business Credit consultation system. We will represent an external system requesting a credit report (Creditinstitution. From the perspective of the Business Credit Consulting Institution, when the participant requests to report the current affairs, and the system of the Business Credit Consulting Institution (Creditreporter) Return to the end of the report, as shown in figure 4. Figure 4. A Sequence diagram of the Business Credit Consultation System Back to the loan submission system, we can now extend the submission of loan request cases to include receipt of reports. WhenCreditreporterWhen a report is returned, a new transaction starts processing and the report is added to the information associated with the application. Then we can notify the loan officer (a new participant) that the new application has arrived. This will be the third transaction in our loan submission plan. In order to create the entire use case, we need to add a few more transactions, but we will leave that exercise for later. Reverse perspective Logic The figure above illustrates two important aspects of system modeling for Interconnected Systems. First, from the perspective of information order, we can easily Model Loan submission and commercial credit consulting institution systems as a single system. Figure 5 shows how the two systems are modeled into a system in a single chart. Figure 5. Credit report function view of a single system This technology has always worked in the analysis phase of our development cycle. However, when we enter the design stage, the necessity of Communication Mechanism Modeling in the two systems makes a single chart too complicated. Unless we use a communication technology like CORBA (see references), once we enter the design stage, we must model the two systems separately. To separate them, we will insert some participants (as shown in figure 3 and figure 4) to represent each other's two systems. The second observation is more subtle and at the center of our discussion this week: we can form a conceptual understanding of these services, these services must be provided by the system by observing the needs of other systems. In other words, we can determine the conceptual interface for each system by viewing the subset of transaction processing information in other system use cases. Next we will consider the second and third transactions of the loan submission system. In particular, let's look atSystem SectionAnd the third transactionParticipants. If we study our Business Credit Consulting Institutions, the participants section (Creditreporter) Is a subset of the loan submission system. That is to say, the loan submission system case indicates that "the system sends a copy of the request for credit report to the commercial credit consulting institution ." On the other hand, the system use case of the business credit advisory institution indicates that "this credit institution participant requests a copy of the credit report ." In this way, the transaction processing participant part of the Business Credit Consulting Institution is a subset of the second transaction processing system part of the loan submission system. This is also true for the third transaction. The transaction processing system of the Business Credit Consulting Institution is a subset of the participants of the third transaction. In other words, the transaction processing part can be reversed between two systems. Conceptual reversal of transaction processing between two systems provides conceptual bonding between two interconnected systems. For example, we know that we need an interface to enter the business credit consultation institution to provide credit reports from the loan submission system interface. The loan submission system interface also requests these reports. How to apply this to user interfaces We do not often establish interconnection systems. However, we do create user interfaces for most of the systems we have created. We generalize the machine interfaces between two systems by reversing their case transaction processing. This is also true if we replace a machine interface with a user interface. As shown in the example in this article, the user interface we create for our system will be a reversal of the case description we draw from the perspective of the corresponding participants. This is why we cannot compile our use cases using the user interface perspective. The logic here is to create a conceptual user interface, but the transaction processing will have to be reversed before the application. That is to say, if you are writing a UI-based use case and can provide it in this way, stick to it. Your ability to provide is far more important than the standards set by the standards-making headers. However, if this method is confusing, you now know why. Next we will focus on capturing different mechanisms of requests in flexible processing, and when and why you should use those features, user experiences, and use cases in a development project. See you next time! References ClickDiscussionTo participate in the Forum on this article. For more information about modeling systems of Interconnected Systems, seeThe road to the uniied software development process(Cambridge University Press, 2000 ). For more information about using case modeling, seeObject-Oriented Software Engineering: A Use Case Driven Approach(Addison Wesley, 1992 ). Allen Holub elaborated on case modeling as part of the object-oriented design process (developerworks, January 2001 ). Scott Ambler from his bookThe object PrimerI figured out the case modeling skills (developerworks, January 2001 ). For more information about transaction processing and user interfaces, see Frank armour and Granville Miller'sAdvanced use case Modeling: Software Systems(Addison Wesley, 2001 ). For more information, see the WebSphere Application Server guide. IBM and other industry leaders have created XML Metadata Interchange (XMI), a new industry standard that combines XML and UML advantages. Find more java references in the developerworks Java technology area. About the author Granville has been in the object-oriented community for 13 years. He is a co-author of the Advanced use case modeling series and has introduced tutorials at various object-oriented technical conferences around the world. His practical method of object-oriented development comes from his experience working in a number of companies, including various companies from startups to well-developed software giants. He is currently teaching workshops, tutorials, and courses on flexible processes, methods, and Java technologies, as well as coaching and helping implement some active projects. Granville can be contacted through a rmiller@togethersoft.com.