Object-oriented approaches to software development are an important expansion of procedural approaches. Java explicitly supports both approaches, but you should focus on the object-oriented approach. This article compares the two approaches and explains the fundamentals of each.
4. Object-Oriented Approach
4.4. Object-Oriented Approach: UML
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].
1) Use Case Diagram
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].
2) Class Diagram (Analysis Level)
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.
a) Customer selects one of the matching Car Models.
b) Customer requests details of the selected Car Model.
c) iCoot displays details of the selected Car Model (make, engine size, price, description, advert and poster).
d) If Customer is a logged-on Member, extend with U7. Postconditions: iCoot has displayed details of selected Car Models.

2) Class Diagram (Design Level)
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].
3) Sequence Diagram
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].