PRDV410: Introduction to Java and Object-Oriented Programming

By the mid-1990s, the best-known methodologies were those invented by Ivar Jacobson, James Rumbaugh and Grady Booch. Each had his own consulting company using his own methodology and his own notation. By 1996, Jacobson and Rumbaugh had joined Rational Corporation, and they had developed a set of notations which became known as the Unified Modeling Language (UML). The „three amigos‟, as they have become known, donated UML to the Object Management Group (OMG) for safekeeping and improvement. OMG is a not-for-profit industry consortium, founded in 1989 to promote open standards for enterprise-level object technology; their other well-known work is CORBA [1].

A use case is a static description of some way in which a system or a business is used, by its customers, its users or by other systems. A use case diagram shows how system use cases are related to each other and how the users can get at them. Each bubble on a use case diagram represents a use case and each stick person represents a user. Figure 2 depicts a car rental store accessible over the Internet. From this picture, we can extract a lot of information quite easily. For example, an Assistant can make a reservation; a Customer can look for car models; Members can log on; users must be logged on before they can make reservations; and so on [1, 3].

A class diagram shows which classes exist in the business (during analysis) or in the system itself (during subsystem design). Figure 3 shows an example of an analysis-level class diagram, with each class represented as a labeled box. As well as the classes themselves, a class diagram shows how objects of these classes can be connected together. For example, Figure 3 shows that a CarModel has inside it a CarModelDetails, referred to as its details.U3: View Car Model Details. (Extends U2, extended by U7.) Preconditions: None.

Nonfunctional Requirements: r1. Adverts should be displayed using a streaming protocol rather than requiring a download [1, 5].

A communication diagram, as its name suggests, shows collaborations between objects. The one shown in Figure 4 describes the process of reserving a car model over the Internet: A Member tells the MemberUI to reserve a CarModel; the MemberUI tells the ReservationHome to create a Reservation for the given CarModel and the current Member; the MemberUI then asks the new Reservation for its number and returns this to the Member [1].


A deployment diagram shows how the completed system will be deployed on one or more machines. A deployment diagram can include all sorts of features such as machines, processes, files and dependencies. Figure 5 shows that any number of HTMLClient nodes (each hosting a Web Browser) and GUIClient nodes communicate with two server machines, each hosting a WebServer and a CootBusinessServer; each Web Server communicates with a CootBusinessServer; and each CootBusinessServer communicates with a DBMS running on one of two DBServer nodes [1].

 The class diagram shown in Figure 6 uses the same notation as the one introduced in Figure 3. The only difference is that design-level class diagrams tend to use more of the available notation, because they are more detailed. This one expands on part of the analysis class diagram to show methods, constructors and navigability [1, 3].

A sequence diagram shows interactions between objects. Communication diagrams also show interactions between objects, but in a way that emphasizes links rather than sequence. Sequence diagrams are used during subsystem design, but they are equally applicable to dynamic modeling during analysis, system design and even requirements capture. The diagram in Figure 7 specifies how a Member can log off from the system. Messages are shown as arrows flowing between vertical bars that represent objects (each object is named at the top of its bar). Time flows down the page on a sequence diagram. So, Figure 7 specifies, in brief: a Member asks the AuthenticationServlet to logoff; the AuthenticationServlet passes the request on to the AuthenticationServer, reading the id from the browser session; the AuthenticationServer finds the corresponding Member object and tells it to set its session id to 0; the Member passes this request on to its InternetAccount; finally, the Member is presented with the home page [1, 5].