Java Modeling: UML workbooks, part 4th

Most computer systems today are in some sort of network. Most systems provide some value or service to entities other than the group, in addition to serving the internal user community. In return, most systems also use services provided by other systems (for example, client-side operating systems, WEB browsers, external databases, and Third-party service providers). With the advent of WEB services, we will soon find that the systems we develop are serving a growing range of applications.

In this part of the UML workbook series, we will talk about the role of participants in the design of complex systems. For the sake of discussion, I'll cover two design patterns that are often used to develop complex systems that show you changes in the system model as it moves from requirements collection to analysis and design. This section will use the loan application cases that we developed in the first few parts of the UML workbook series throughout.

Modeling for external interactions

When it comes to modeling interactions between our systems and external elements, such as other systems, it is common practice to create classes that represent how these elements interact with our systems. The external entity is represented as a class, and such a design pattern is called the mirror image (Mirror image) pattern. When we invoke a mirror image pattern, we basically analyze the behavior characteristics of an external entity and then create its similarity in our own system. This similarity is usually simple because it simply wants to abstract the services we need (for a single use) or the services provided by the system (for example, the Java Networking class library). It does not attempt to implement these services in any way.

We illustrate how TCP/IP works in the Java SDK (package java.net). TCP/IP is the basic function of most operating systems. TCP/IP is a service that resides on the operating system, allowing traffic to flow across the network. If we are going to write a file transfer program in Java code, we may want to use the TCP/IP classes in the Java class Library to access the operating system services for this protocol. These classes will become part of our application, but they will eventually reside in the operating system, not in the application.

Figure 1 is a UML diagram that shows some classes that represent TCP/IP services that are intended for Java networking classes.

It is important to understand that the classes shown in the above illustration represent the services provided by the operating system. They are not the service itself. We incorporate these representations into our application design because they make it easier for us to interact with the operating system. We interact with these representations as if we were interacting with the service itself. These representations ensure that the interaction is transferred correctly to another system, and that any results of the interaction are returned in the way we expect. This is the role of the TCP/IP class in the Java class library.

Identify external interactions

Identifying interactions with external entities is performed during the requirements collection phase of building use case models. In the previous column, we built a use case model where participants represented external entities interacting with the system. In the previous column of the UML workbook series, we designed a system that interacts with both participants (loan applicants) and external system participants (credit).

Figure 2 shows the initial use case model of the loan processing system.

Figure 2. Loan processing use case model

When we first conceptualize a system, it is important to identify the participants who will affect the system. Understanding the interaction of requirements and services between the system and its participants, we can allocate system resources accordingly. The role of the participant in the system determines how much it affects the system.

Role of participants

We discussed the various roles that participants can play in the first article in the UML workbook series. You may recall that participants may play four roles in use cases: initiators (initiator), servers (server), receivers (receiver), and proxies (facilitator). If the role of a participant is to start a use case, its role is the initiator. If the participant provides one or more services needed to implement the use-case goal, it acts as a server. When a participant's role is to receive information from the system, we call it the receiver, and the Data warehouse is an example of the system receiver. Finally, when a participant performs an action on behalf of another participant in the system, we call it an agent.

Participants can play multiple roles at the same time. The participant may be a person or machine whose identity can be anonymous or known. If the participant is anonymous, its identity has no effect on the system. The end user may play multiple roles without being identified, and again, no matter which end user plays a role ―tom, Mike or judy― he or she will experience exactly the same function. Machines can also act as anonymous participants, especially in the realm of WEB services.

In contrast, to deal with things like security or quality of service, the system needs to identify information. In such a case, the participant must be known. Any time a system asks for information about a participant-whether the information is an exact identifier or an individual information of a scale claw-the participant is considered to be a known entity.