UML Interview Questions in Java

We have compiled most frequently asked Java J2EE Interview Questions which will help you with different expertise levels.

Java J2EE Interview Questions on UML

Question 1.
What do you understand by an Object Model?
Answer:
In Object-Oriented Programming, all real-world things are modeled as a collection of Objects with relationships amongst them. This representation is known as the Object Model. This model plays the same role in software development that sitemaps, elevations, and blueprints play in the construction of skyscrapers.

Question 2.
What do you understand by UML?
Answer:
UML or Unified Modeling Language, as it is called, is used for designing object models in software development and applications. The language helps to specify, visualize, and document the models of software systems.

Question 3.
Enumerate the various UML diagrams.
Answer:
In general, UML defines twelve types of diagrams which can be classified into three categories:-

1. Structural: Class diagrams, Object diagrams, Component diagrams, and Deployment diagrams;
2. Behavioral: Use Case diagrams (very handy to have in requirements gathering), Sequence diagrams, Activity Diagrams, and Collaboration diagrams; and,
3. Model Management diagrams inclusive of Packages, Subsystems, and Models.

Question 4.
What does a UML class element comprise of?
Answer:
A UML class element comprises class_name, attributes/data, and methods, (note that class_name cannot be blank or empty while attributes and methods can be)

Question 5.
Enumerate the various relationships between classes in UML. Answer: In general, UML defines five types of relationships between classes:-

• Association;
• Aggregation;
• Composition;
• Inheritance/Generalization; and,
• Realization

Question 6.

• Who is an actor? Explain with the help of suitable examples wherever necessary.
• What are Use Cases? Explain with reference to the case of a vending machine.
• What are Use Case Diagrams? Explain with reference to the Use Case in (b).
•  What guidelines would you suggest for use case models? Elaborate.

Answer:

(a) An actor is an external user of a system – an object or set of objects that communicate directly with the system but that is not part of the system. Each actor represents those objects that behave in a particular way towards the system, e.g. customer and repair technician are different actors of a vending machine. Similarly, for a travel agency system, actors might include travelers, agents, and airlines. And, for a computer database system, actors might include users and administrators. Actors can be persons, devices, and other systems – anything that interacts directly with the system. An object can be bound to multiple actors if it has different facets to its behavior, e.g. Varun, Arun, and Mukesh may be customers of a vending machine; Arun may also be a repair technician for the vending machine.

(b) # Buy a Beverage: The vending machine delivers a beverage after a customer selects and pays for it.

#Perform Scheduled Maintenance: A repair technician performs the periodic -service on 
the vending machine necessary to keep it in good condition.

#Make Repairs: A repair technician performs the unexpected service on the vending machine necessary to 
repair a problem in its operation.

#Load Items: A stock clerk adds items into the vending machine to replenish its stock of beverages.

The various interactions of actors with a system are quantized into use cases. A use case is a coherent piece of functionality that a system can provide by interacting with actors, e.g. a customer actor can “buy a beverage” from a vending machine. The customer inserts money into the machine, makes a selection, and finally receives the beverage. Similarly, a repair technician can perform “scheduled maintenance” on the vending machine. Figure 20 summarizes several use cases for a vending machine. Each use case involves one or more actors as well as the system itself.

A use case involves a sequence of messages among the system and it1- actors, e.g. in the “buy a beverage” use case, the customer first inserts a coin and the vending machine indicates the amount deposited. This can be repeated several times over. Then, the customer pushes a button to indicate a selection; and, the vending machine dispenses the beverage and issues change, if necessary.

A system involves a set of use cases and a set of actors. Each use case represents a slice of functionality the system provides. The set of use cases shows the complete functionality of the system at some level of detail. Similarly, each actor represents one kind of object for which the system can perform the behavior. The set of actors represents the complete set of objects that the system can serve. Objects accumulate behavior from all the systems with which they interact as actors.

The UML has a graphical notation (use case diagrams) for summarizing use cases and Figure 21 shows an example. A rectangle contains the use cases for a system with the actors listed on the outside. The name of the system may be written near a side of the rectangle. A name within an ellipse denotes a use case. A “stick man” icon denotes an actor, with the name being placed below or adjacent to the icon. Solid lines connect use cases to participating corresponding actors. In the figure, the actor repair technician participates in two use cases, the others in one each. Multiple actors can participate in a use case, even though the example has only one actor per use case.

(d) The main purpose of a system is almost always found in use cases, with the traditional requirements lists supplying additional implementation constraints. Here are some guidelines for constructing use case models:-

(1) First determine the system boundary; It is impossible to identify use cases or actors if the system boundary is vague or unclear.

(2) Ensure that the actors are focused: Each actor should have a single, coherent purpose. If a real-world object embodies multiple purposes, capture them with separate actors, e.g. the owner of a personal computer may install software, set up a database, and send an email. These functions differ greatly in their impact on the computer system and the potential for system damage. They might be broken into three actors, viz. system administrator, database administrator, and computer user. Remember that an actor is defined w.r.t a system, not as a free-standing concept.

(3) Each use case must provide value to users: A use case should represent a complete transaction that provides value to users and should not be defined too narrowly, e.g. “dial a telephone number” is not a good use case for a telephone system. This is because it does not represent a complete transaction of value by itself; it is merely part of the use case “make telephone call”. The latter use case involves placing the call, talking, and terminating the call. By dealing with complete use cases, we focus on the functionality provided by the system, rather than jumping into implementation decisions. The details come later. Often there is more than one way to implement the desired functionality.

(4) Relate use cases and actors: Ever}’ use case should have at least one actor, and every actor should participate in at least one use case. A. use case may involve several actors, and an actor may participate in several use cases.

(5) Remember that use cases are informal: It is important not to be obsessed by formalism in specifying use cases. They are not intended as a formal mechanism but as a way to identify and organize system functionality from a user-centric point of view. It is acceptable if use cases are a bit loose at first. Detail can come later as use cases are expanded and mapped into implementations.

(6) Use cases can be structured: For many applications, the individual use cases are completely distinct. For large systems, use cases can be built out of smaller fragments using relationships (refer to next question in this context).

Question 7.
(a) What do you understand by Use Case Relationships? Explain with the help of suitable examples wherever necessary.
(b) What guidelines would you suggest for use case relationships? Elaborate.

Answer:
(a) Independent use cases suffice for simple applications. However, it can be helpful to structure use cases for large applications. Complex use cases can be built from smaller pieces with the include, extend, and generalization relationships:-

(1) Include Relationship: The include relationship incorporates one use case within the behavior of another use case. An included use case is like a subroutine – it represents behavior that would otherwise have to be described repeatedly. Often the fragment is a meaningful unit of behavior for the actors, although this is not required. The included use case may or may not be usable on its own.

The UML notation for an include relationship is a dashed arrow from the source (including) use case to the target (included) use case with the keyword «include» annotating the arrow. Figure 22 shows an example from an online stock brokerage system. Part of establishing a secure session is validating the user password. In addition, the stock brokerage system validates the password for each stock trade. Use cases “secure session” and “make trade” both include use case “validate password”.

(2) Extend Relationship: The extended relationship adds incremental behavior to a use case. It is like an include relationship looked at from the opposite direction, in which the extension adds itself to the base, rather than the base explicitly incorporating the extension. It represents the frequent situation in which some initial capability is defined, and later features are added modularly, e.g. a stock brokerage system might have the base use case “trade stocks”, which permits a customer to purchase stocks for cash on hand in the account. The extension use case “margin trading” would add the ability to make a loan on purchase stocks when the account doesn’t contain enough cash.

Figure 23 shows the base use case “trade stocks” for the said system. The UML notation for an extended relationship is a dashed arrow from the extension use case to the base use case with the keyword «extend» annotating the arrow.

(3) Generalization: Generalization can show specific variations on a general use case, analogous to generalization among classes. A parent use case represents a general behavior sequence. Child use cases specialize the parent by inserting additional steps or by refining steps. The UML indicates generalization by an arrow with its tail on the child use case e.g. an online brokerage system (Figure 24) might specialize the general use case “make trade” into the child use cases “trade bonds”, “trade options”. The parent use case contains steps that are performed for any kind of trade, such as entering the password. Each child use case contains the additional steps particular to a specific kind of trade, such as entering the expiration date of an option.

(b) One of the basic guidelines for use case relationships is not to carry them to extremes and lapse into programming. There can be many ways to implement
requirements and you should not commit to an approach before fully understanding the problem. Here are some additional guidelines:-

(1) Use Case generalization: If a use case comes in several variations, model the common behavior with an abstract use case and then specialize each of the variations. Don’t use generalizations simply to share a behavior fragment; use the include relationship for that purpose.

(2) Use Case inclusion: If a use case includes a well-defined behavior fragment that is likely to be useful in other situations, define a use case for the behavior fragment and include it in the original use case. In most cases, you should think of the included use case as a meaningful activity but not as an end in itself, e.g. validating a password is meaningful to users but has a purpose only within a broader context.

(3) Use Case extension: If you can define a meaningful use case with optional features, then model the base behavior as a use case and add features with the extended relationship. This permits the system to be tested and debugged without the extensions, which can be added later. Use the extended relationship when a system might be deployed in different configurations, some with the additional features and some without them.

(4) Include Relationship vs. Extend Relationship: The include relationship and the extended relationship can both factor behavior into smaller pieces. The include relationship, however, implies that the included behavior is a necessary part of a configured system (even if the behavior is not executed every time), whereas the extended relationship implies that a system without the added behavior would be meaningful (even if there is no intention to configure it that way).

Question 8.
Can we have a combination of Use Case Relationships? If yes, elaborate with the help of a suitable example.
Answer:
A single diagram may combine several kinds of use case relationships. Figure 25 shows a use case diagram from a stock brokerage system. The “secure session” use case includes the behavior of the “validate password”, “make trade”, and “manage account” use cases. “Make trade” is an abstract parent with the children – “trade bonds”, “trade stocks”, and “trade options”. Use case “make trade” also includes the behavior of “validate password”. The brokerage system validates the password per session and additionally for every trade.

The use case “margin trading” extends both “trade bonds” and “trade stocks” – a customer may purchase stocks and bonds on margin, but not options. Use case “limit order” extends abstract use case “make trade” – limit orders apply to trading bonds, stocks, and options. We assume that a “short sale” is only permitted for stocks and not for bonds or options.

Note that the customer actor connects only to one secure session per use case. The brokerage system invokes all the other use cases indirectly by inclusion, specialization, or extension. The securities exchange actor connects to the “make trade” use case. This actor does not initiate a use case but is invoked during execution.