Clouds
Home

SQL Interview Questions 1
SQL Interview Questions 2
RUP Interview Questions
UML Interview Questions

UML Interview Questions


Why is UML important ?

The more complicated the underlying system, the more critical the communication among everyone involved in developing and deploying the software. UML is a software blueprint language for analysts, designers and developers. UML provides a common vocabulary for the business analysts, architects, developers etc. UML is applicable to the Object Oriented problem solving. UML begins with a model; A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes. The model consists of objects. The objects interact with each other by sending and receiving messages. The objects are characterized by attributes and operations (behaviors). The values of an objectís attributes determine its state. The classes are the blueprints (or like templates) for objects. A class wraps attributes and methods into a single distinct entity. The objects are the instances of classes.

What are the different types of UML diagrams ?

Use case diagrams:

Depicts the typical interaction between external users (i.e. actors) and the system. The emphasis is on what a system does rather than how it does it. A use case is a summary of scenarios for a single task or goal. An actor is responsible for initiating a task. The connection between actor and use case is a communication association.Capturing use cases is one of the primary tasks of the elaboration phase of RUP. In its simplest usage, you capture a use case by talking to your users and discussing the various things they might want to do with the system. When to use Ďuse caseí diagrams:
  • Determining user requirements. New use cases often generate new requirements.
  • Communicating with clients. The simplicity of the diagram makes use case diagrams a good way for designers and developers to communicate with clients.
  • Generating test cases. Each scenario for the use case may suggest a suite of test cases.
  • Class diagrams:

    Class diagram technique is vital within Object Oriented methods. Class diagrams describe the types of objects in the system and the various static relationships among them. Class diagrams also show the attributes and the methods. Class diagrams have the following possible relationships:
  • Association: A relationship between instances of 2 classes.
  • Aggregation: An association in which one class belongs to a collection (does not always have to be a collection. You can also have cardinality of "1"). This is a part of a whole relationship where the part can exist without the whole. For example: A line item is whole and the products are the parts. If a line item is deleted then the products need not be deleted.
  • Composition: An association in which one class belongs to a collection (does not always have to be a collection. You can also have cardinality of "1"). This is a part of a whole relationship where the part cannot exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole and the line items are the parts. If an order is deleted then all the line items should be deleted as well (i.e. cascade deletes).
  • Generalization: An inheritance link indicating that one class is a superclass of the other. The Generalization expresses the "is a" relationship whereas the association, aggregation and composition express the "has a" relationship.
  • Realization: Implementation of an interface.
  • Dependency: A dependency is a weak relationship where one class requires another class. The dependency expresses the "uses" relationship. For example: A domain model class uses a utility class like Formatter etc.

  • When to use class diagrams ?
  • Class diagrams are the backbone of Object Oriented methods. So they are used frequently.
  • Class diagrams can have a conceptual perspective and an implementation perspective. During the analysis draw the conceptual model and during implementation draw the implementation model.
  • Package diagrams:

    To simplify complex class diagrams you can group classes into packages.
    When to use package diagrams ?
  • Package diagrams are vital for large projects.
  • Object diagrams:

    Object diagrams show instances instead of classes. They are useful for explaining some complicated objects in detail about their recursive relationships etc. When to use object diagrams ?
  • Object diagrams are a vital for large projects.
  • They are useful for explaining structural relationships in detail for complex objects.
  • Sequence diagrams:

    Sequence diagrams are interaction diagrams which detail what messages are sent and when. The sequence diagrams are organized according to time. The time progresses as you move from top to bottom of the diagram. The objects involved in the diagram are shown from left to right according to when they take part.

    Collaboration diagrams:

    Collaboration diagrams are also interaction diagrams. Collaboration diagrams convey the same message as the sequence diagrams. But the collaboration diagrams focus on the object roles instead of the times at which the messages are sent. The collaboration diagrams use the decimal sequence numbers as shown in the diagram below to make it clear which operation is calling which other operation, although it can be harder to see the overall sequence. The toplevel message is numbered 1. The messages at the same level have the same decimal prefix but different suffixes of 1, 2 etc according to when they occur.When to use interaction diagrams?
  • When you want to look at behavior of several objects within a single use case. If you want to look at a single object across multiple use cases then use statechart diagram as described below.
  • State chart diagrams:

    Objects have behavior and state. The state of an object depends on its current activity or condition. This diagram shows the possible states of the object and the transitions that cause a change in its state. When to use statechart diagram ?
  • Statechart diagrams are good at describing the behavior of an object across several use cases. But they are not good at describing the interaction or collaboration between many objects. Use interaction and/or activity diagrams in conjunction with a statechart diagram.
  • Use it only for classes that have complex state changes and behavior. For example: the User Interface (UI) control objects, Objects shared by multi-threaded programs etc.

    Activity diagram:

    This is really a fancy flow chart. The activity diagram and statechart diagrams are related in a sense that statechart diagram focuses on object undergoing a transition process and an activity diagram focuses on the flow of activities involved in a single transition process. In domain modeling it is imperative that the diagram conveys which object (or class) is responsible for each activity. Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. The swimlanes are quite useful because they combine the activity diagramís depiction of logic with the interaction diagramís depiction of responsibility. A single transition comes out of each activity, connecting to the next activity. A transition may join or fork.
    When to use activity diagrams?
    The activity and statechart diagrams are generally useful to express complex operations. The great strength of activity diagrams is that they support and encourage parallel behavior. The activity and statechart diagrams are beneficial for workflow modeling with multi-threaded programming.

    Component and Deployment diagrams:

    A component is a code module. Component diagrams are physical diagrams analogous to a class diagram. The deployment diagrams show the physical configuration of software and hardware components. The physical hardware is made up of nodes. Each component belongs to a node.

    What is the difference between aggregation and composition ?

    Aggregation:

    An association in which one class belongs to another class or a collection. This is a part of a whole relationship where the part can exist without the whole. For example: A line item is whole and the products are the parts. If a line item is deleted then the products need not be deleted. (no cascade delete in database terms). Aggregations are not allowed to be circular.

    Composition:

    An association in which one class belongs to another class or a collection. This is a part of a whole relationship where the part cannot exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole and the line items are the parts. If an order is deleted then all the line items should be deleted as well (i.e. cascade deletes in database terms). In a garbage-collected language like Java, The whole has the responsibility of preventing the garbage collector to prematurely collect the part by holding reference to it.

    What is the difference between a collaboration diagram and a sequence diagram ?

  • Sequence Diagram: The emphasis is on the sequence.
  • Collaboration Diagram: The emphasis is on the object roles

  • SQL Interview Questions >>>




    Home Clouds