Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

Project Communication and the Unified Modeling Language

One of the most important aspects of any architectural development effort is the communication between members of the development team. Careful examination and review of architectural alternatives is critical, and this can be done well only if all team members, both technical and in some cases nontechnical, can understand the design.

The analysis diagram is a visual presentation of a technical concept. As such, analysis diagrams have been around for some time; some have been formally standardized and others are merely arrows and circles used in a logical manner. The UML is an attempt to standardize diagramming for OOAD, which has become the de facto standard for OO analysis.

The UML is based on work done by Grady Booch, James Rumbaugh, and Ivar Jacobson. There are nine diagrams supported by UML, as listed in Table 3–1.

Table 3-1 Nine UML Diagrams

Diagram

Description

Use Case Diagram

Describes the operation of the system from the user's point of view.

Component Diagram

Defines how pobjects are grouped into packages.

Sequence diagram

Object interaction for a set of actions. Indicates order and flow of processing.

Deployment diagram

Details object deployment across hardware platforms.

State diagram

Creates a diagram describing object collaboration.

Activity diagram

Details the process flow of an event.

Object diagram

Describes instantiations of classes. (Not used often.)

Class diagram

Describes the design for a class, including class members, instance members, and methods.


Of these nine diagrams, seven are commonly used:

  1. use case diagram
  2. class diagram
  3. sequence diagram
  4. activity diagram
  5. state diagram
  6. component diagram
  7. deployment diagram

These diagrams represent the core set you will use to describe the development of the J2EE architecture you create. Additional diagrams may also be used (for example, the process flow diagram to show the flow of data, and an entity-relationship diagram to show the relationship of data entities), but these UML diagrams listed here represent the core, which the following sections will explain.

Use Case Diagram

Use case analysis is used to gather the functional requirements for a system. Consequently, the use case diagram helps to describe this process in a way that is easily understandable to the end user. The use case diagram uses a gender-neutral stick figure to represent the user. The stick figure is referred to as the actor, an individual outside of the system who must interact with the system. The actor initiates an event, and ovals are used to represent the event the actor is initiating. A rectangle can be used to represent an external system, and lines are used to represent relationships between the actors and events. In the example in Figure 3–1, a user initiates events for a login, for reading a message or for creating a new message.

Figure 1Figure 3-1 Use case diagram.

Each use case diagrammed should describe a discrete benefit for the actor. A well-focused use case should be expressed in 30 words or less, and the action taking place should happen within a single session for the actor. Excessive complexity in a use case is probably an indication that the use case should be subdivided into separate use cases. Describing complex use cases and managing these complexities is discussed in further detail in the following sections.

Class Diagram

The class diagram may be the most commonly used of UML diagrams. This diagram describes the composition of an object class, specifically the attributes and behaviors that comprise the class. Boxes are used to represent the class, with the top section reserved for the members of the class and the bottom section reserved for the methods (behaviors) of the class. Multiple classes can be described in the same diagram with lines between the classes used to represent the relationship of the classes, as shown in Figure 3–2.

Figure 2Figure 3-2 UML class diagram.

An arrow going from one class to another represents inheritance: The class to which the arrow points is the superclass, and the class where the arrow originated is the subclass.

A common representation, representing a technique that is an important part of Java object-oriented programming, is the UML stereotype. The UML stereotype indicates that the object will implement specific behavior, but the object diagrammed is not the implementation itself. In Java, the properties of the UML stereotype are provided using the Java interface. An example of this is the Runnable interface, which allows a program to start an independent thread of execution. The Runnable interface does not provide a thread implementation itself; it is up to the class that implements the interface to provide the implementation. This is shown in the UML class diagram with the << characters above the name, as shown in Figure 3–3.

Figure 3Figure 3-3 The UML stereotype.


From a development perspective, the use of interfaces provides a great deal of flexibility. They provide a very clear description of the implementation behavior expected of an object—a clear contract. An object implementing multiple interfaces can participate in multiple relationships for the interface, exhibiting a behavior similar to that of multiple inheritance (something not provided in Java).

The class diagram provides for the grouping of classes into packages, as shown in Figure 3–4. This is an important part of the design process, since the organization of these classes and how they interact can have a significant impact on a system. This is where optimizing cohesion and minimizing coupling are managed. By creating consistent diagrams throughout the development process, excessive coupling can be discerned earlier in the development process rather than later when it is difficult to correct. This topic will be revisited later in this chapter.

Figure xxxFigure 3-4 UML sequence diagram.


Sequence Diagram

Once again, it is critical that we understand how our objects interact, how they will work with each other. The UML sequence diagram is an excellent tool for visualizing these types of relationships. Sequence diagrams represent control flow across a series of objects or components and provide a useful visual medium for determining object relationships in the design phase. While the common terminology for the elements in this diagram are objects, with J2EE architectural analysis and design, these objects are more commonly J2EE components: JSPs, servlets, or EJBs.

Using sequence diagrams, it is easy to determine the amount of collaboration between two or more objects. This can help determine how to group objects and whether or not a given object is becoming too complex.

In the example in Figure 3–5, a sequence diagram is used to detail a user login process.

Figure 4Figure 3-5 UML sequence diagram.

As a user logs into the system, the login process in turn executes an authentication process, which then passes control to a flow control process that will decide what the user's next action will be based on his or her authentication.

Activity Diagram

Use case activities can be further analyzed using activity diagrams. Though these diagrams are frighteningly similar to the much maligned programming flow chart (sometimes called "flaw charts"), they are built on distinctly different rules and work at a higher level of detail than the flow chart. As one of the set of diagrams you will use to describe the design of your J2EE system, this is a useful tool for visualizing the processing of an event.

UML activity diagrams break down the activities into a series of events that help provide insights on the processing behind the event. These diagrams, coupled with more detailed textual documents, can help you facilitate discussions with stakeholders. The example shown here Figure 3–6) documents part of a user login.

Figure 6Figure 3-6 UML activity diagram.

As this diagram details, if the user login is valid, then a menu is displayed. If, however, the login is invalid, then a page describing the invalid login is displayed.

State Diagram

Some objects move through various states of activity, often in response to some set of events. The lifecycle of an EJB or servlet is an example of this. For these objects you may find it useful to use a UML state diagram that details the states of that object.

A state diagram shows the various states' existence for an object, thus providing a representation of the lifecycle of an object or component, as shown in Figure 3–7.

Figure 7Figure 3-7 UML state diagram.

This diagram details the lifecycle of an object that processes messages from a message queue. The message queue processor is in a ready state until it is awakened. When it is awakened, the contents of the queue are processed until there are no more contents to process. The queue processor is then put back to sleep until it is needed again.

Component Diagram

As it has no doubt become clear, J2EE involves creating distributed applications, applications where components will run on one or, more than likely, multiple servers on a network. Once you have identified the top-level objects or components of the system becomes clear, you then need to determine how the objects will be distributed across servers. Two UML diagrams help to visualize this process: the component diagram and the deployment diagram.

The UML component diagram represents the relationships of the physical implementation of components and so is sometimes referred to as an implementation diagram, as demonstrated in Figure 3–8.

Figure 8Figure 3-8 UML component diagram.

In this example, a shopping-cart user interface component is shown interacting with a database access component. As the diagram makes clear, both reside on separate network nodes (servers). As part of a more complex architecture, this diagram could help discern excessive coupling or potential bottlenecks between components residing on separate servers where interaction will require network communication and possibly create a performance bottleneck.

Deployment Diagram

Similar to the component diagram, the deployment diagram illustrates the physical deployment of system components. Three-dimensional boxes are drawn to illustrate servers, and components are drawn as boxes with connectors (vaguely similar to an electrical plug), as shown in Figure 3–9.

Figure 9Figure 3-9 UML deployment diagram.


This diagram shows the potential deployment of a shopping cart system across several servers. The lines between components represent associations. As with the component diagram, this visualization of distributed components can help identify potential bottlenecks and excessive coupling between components and modules (groups of components) in the system.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020