User interface logic on the model model
Granville Miller (RMiller@together@together@togethersoft.com) consultant, Together, Together, June 2001
content:
What is the use model model? Transaction Interconnect System Reverse Perspective Logic Application to User Interface Reference Information About The Author's Evaluation
related information:
Object-Oriented Design Process: Usage Introduction To establish a UML Series with Style Java Modeling Series All Articles
User interface logic on model modeling
Granville Miller (RMiller@together@together@togethersoft.com) consultant, Together, Together, June 2001
In this part of Java modeling, Granville leads you to enter the area between modeling and methods, and look at the needs collected by using the example model. He specially focused on the relationship between user interface, system interface, and use case description. Although it is now trying to include user interface logic, this is usually considered a bad form. Then, the Grancille tells you the specific reason with the sequence diagram and system interface. Please click on the top or bottom of the article
Discuss, participate in the discussion forum, share your ideas for this article and other readers.
Demand Collection is an indispensable step in any successful software development cycle. Although there are many demand collection methods, the most common method is to model them. In the previous two columns, we have completed a part of the work of the sequence diagram to model the examples. This time I will talk more about the theory after the method and add some of your modeling.
In this discussion, I am more concerned about clarifying the relationship between user interface, system interface and use case description. Because most systems established will be designed to be interactive, it is attracted to start running with user interfaces. However, in use, user interface logic is often considered a bad form. A simple explanation of this statement is that the user interface provides a system profile of a system perspective. The use case is always described with a participant (or user) perspective.
In order to truly understand why we do not include the UI logic in the use case description, I think we have to adopt a method of personal practices. We will use the example of the loan application in my first column, and you will see how the use case becomes complicated as the size increases. In particular, we have to pay attention to the role of the perspective in the use case. With our deeper, you will see how the perspective is used to work for you, or if it is incorrect, how it hinders you.
What is the use model model? A use case model consists of a chart and a set of descriptions of the use case. A use case is a possible interaction in a system, and its participants are done toward the same defined target. These descriptions describe the functionality of this use case in the system; this chart provides these descriptions of visualized roadmeters. UML specifies the standard for establishing an example drawing, but is not described in order to write. The results have produced many methods described in the examples, which are sometimes competing in each other.
The most popular preparation examples describe the idea of Ivar Jacobson (inventors who use case modeling). Jacobson's approach involves a series of guidelines that enter and exit, referred to as pre-condition and post-conditionation, and a core criterion called event stream. This event stream describes a series of participants (user or external systems) and interactions between the developed systems. This event stream represents a single path that passs through the system. This is the core part of the use example, but not all.
The alternation and exception of the event stream except for the central event stream, the use examples must be described in the interaction outside the normal event stream. For example, the main event stream (in simple case) of the tape leased use case can be said:
Videos rental store clerk scans customer membership card. The system has achieved the membership name and his current rental situation. A "Allow Rental" status indicates that this customer can rent a video tape. The tape rental store clerk scanned a tape per plate. By scanning each video tape, the system is added to the list of users visible, and the current rental tape list is displayed. The number of tape rental store clerk enters the amount of money that should be charged (if it is a cash) or scan the credit card. The system tag This video belt is a receipt that has been leased for a certain period of time and prints the transaction. But what if the customer owes overdue fee in the last rent? Before she rented her selected tape, she had to pay the overdue fees owed. The overdue interaction is shown as an alternate flow or exception stream. The alternation and exceptions of the event stream are normal. In some cases, they can be corrected to restart normal event streams, in other cases, they do not reach the target. In our example, if the customer pays overdue fees and this rent, then she has reached the purpose of continuing to lease the tape.
The transaction processing in an example model is accompanied by its alternation and exception, and the event stream consists of a series of transaction processing. Transaction processing is initiated by the participant, and interaction completed when the system waits from the participant's trigger signal (Note that the participant to complete the transaction is not necessarily the participant to initiate the transaction). Transaction processing allows us to divide the use cases into smaller elements and packet logically on each decision point. The decision point is the point that participants must make decisions or provide additional information in the description.
All transaction is composed of a participant and a system interactive. You will quite need to plan a system that does not start, even if this start is only based on time. When establishing a use case model, you must ensure that each startup is accessed by some type of system response. This call and response is complete for the use case.
The transaction processes in the sequence diagram are easily identified in the sequence diagram. In my first column, I introduced only two programs. When the applicant requests a new loan application, the first transaction is started. This transaction is ended by the system waiting for the applicant to fill in the request and submit request. When the applicant submits the loan application online, the second transaction is started. It is ended in the system requesting the credit report of the business credit advisory body.
Figure 1 Let's take a look at the sequence diagram for describing this program - submit loan requests and its two transactions. This chart establishes a model from the start to the end of the two transactions. You will remember that this is a general sequence diagram that allows us to add more options (thus adding more transaction). At least in the analysis phase of this development cycle, we will complete this use case when we add a program. However, when we turn to design, we may find that we need to add more transaction processing. For example, if we choose to confirm on the screen (instead of a single confirmation of the current commit), we must add a transaction to each step.
Take a look at Figure 1, carefully pay attention to the description of the transaction. Starting from the participant to a class or instance of the closer top portion in the direction of identification information. As you can see in the chart below, the first transaction is usually starting from the left. Along the order of the arrows until you reach another participant or the order. When the order is over, it returns to the original participant. This is a transaction. In Figure 1, you should see two complete transactions.
Figure 1. Partial sequence diagram of a submission of loan request usage
Like most of the other examples, submit loan request use cases use multiple transaction processing. To date, we only list two charts, but an ordinary use case uses approximately 3 to 15 transaction.
In order to understand the relationship between perspective and transaction processing, we can see how transaction processing is manifested when the two system communications. Some software systems are actually a series of interconnected smaller systems. These smaller systems cooperate with each other to provide the functionality of the entire system. Each smaller system only provides a subset of the entire system function. They communicate through a set of protocols and machine interfaces, which will increase our use model model to a new complexity.
The system modeling of the interconnect system is considering the interconnect system, which makes sense to establish a large system consisting of smaller interconnect systems. You can exchange a system and replace it with other systems. You can also establish each system independently. And you can use many sites or vendors to complete the entire system. The best example of such a system is a typical telephone network. Part of the telephone network provides the dial-in channel, and the other part transmits sound or data, and there is another part of the billing service, and there are many other parts to carry out services such as call forwarding and voicemail. The telephone network may be a largest example of the system consisting of interconnect systems, and its continuous work also proves the effectiveness of this system. Similarly, it is important to know how to conceive 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 an interconnect system. By now, we have established a model for submitting a loan request usage, but this use case is actually part of a larger loan processing system. Loan submission systems and their business credit consulting agencies are two systems that must work together to provide the necessary data to handle loan requests. In real life, there is also an additional system. However, our example only discusses two systems. Figure 2 shows two systems, loans submitting and commercial information consulting agencies and interactions we will focus on the remaining parts of this column. (Note that Figure 2 is not a UML chart; it is a real-world chart, the purpose is to simply illustrate these two systems and interactions between them.)
Figure 2. Interaction between the two systems
As in our previous chart description, Figure 3 shows a subset of submit loan request usage from the perspective of the loan submission system. This figure shows that the end of our second transaction is to start when the applicant is submitted to the loan request, ending when the loan submission system (CreditChecker) is given to the participant of the Business Communications Consultation Institution (Creditbureau).
Figure 3. Subsequence of a system part of a submission of loan request usage
Now let us pay attention to this request from the perspective of the business credit consulting agency system. We will start with the participants of an external system (CreditInstitude) requested by the request. From the perspective of the commercial credit advisory body, when the participant requests the report to end and end when the business credit consultor system returns to this report, as shown in the chart in Figure 4.
Figure 4. A sequence diagram of the commercial information consulting agency system
Go back to the loan submission system, we can now expand the submission of the loan request case to include the receipt of the report. When CreditReporter returns a report, a new transaction starts, and the report is added to the information associated with the application. Then we can notify the loan official (a new participant) new application has arrived. This will be the third transaction in our loan submission solution. In order to create an entire use case, we need to add a few transactions, but we leave the exercise to later.
The chart of the reverse perspective logic describes two important aspects in the system modeling of the interconnect system. First, from the information sequence perspective we can easily model the loan submission and the commercial information consulting agency system as a single system. Figure 5 shows how the two systems are built in a single chart into a system.
Figure 5. A single system credit report function view
This technology has always played in the analysis phase of our development cycle. However, when we enter the design phase, the need for communication mechanism in the two systems makes a single chart that is too complicated. Unless we use a communication technology such as CORBA (see Refer to Reference), once we enter the design phase, we must model these two systems. To separate them, we will insert some participants (as shown in Figures 3 and 4) to represent two systems, respectively.
The second observation is more subtle, and it is also the center of our discussion in this week: We can form a conceptual understanding of these services, which must be provided by the system through the need to observe other systems. In other words, we can determine the conceptual interface for each system by viewing the subset of transaction information in other systems. The second and third transaction processing of the loan submit system are then considered. In particular, let's see the second transaction processing system part and the participant part of the third transaction processing. If you are conceptually studying our business credit advisory agencies, Participant's part is a subset of the system part of the loan submission system. That is, the loan submission system use example means "the system sends a copy requesting the credit report to the commercial credit advisory body."
On the other hand, the commercial credit advisory authority system uses a copy of the "this credit participant to request the credit report." This, the participant part of the commercial information consulting agency transaction is part of the second transaction processing of the loan submission system. A subset of. This is also the same for third transactions, and the system part of the business credit consulting agency transaction is a subset of the participant part of the third transaction. In other words, the part of the transaction can be reversed in two systems.
Reverse transaction in two inter-system concept provides a concept of adhesion between two interconnect systems. For example, we know that we need an interface to enter the business credit consulting agency to provide a credit report from the loan submission system interface, and the loan submission system interface also requests these reports.
How to apply this to user interfaces. We don't often build an interconnect system. However, we do create user interfaces for most systems we have established. We conceptualize the machine interface between the two systems by reversing their use case transactions. This is also right if we replace a machine interface with a user interface.
As shown in the example of this article, we will become the reversal of the use case described by our system. That's why I can't rely on the user interface perspective to write our use case. The logic here is a user interface on the concept, but transaction will have to be reversed before the application.
That is, if you have written the UI-based use case and can be provided in this way, then you will stick to it. Your ability to provide far more important than those developing standard heads. However, if you use this method to fall into chaos, then you know why now.
Next time we will focus on capturing different mechanisms in flexible processing, and when and why you should use those features, users experience and use cases in a development project. Next!
Reference
