Q) What is UML?
A) UML stands for unified modeling language. It is a graphical language which is used to document and share Use Cases, High Level Design, Low Level Design, Flow Sequences and even Collaboration using blocks and shapes.

Q) What is the purpose of UML?
A) UML communicates things visually which is easy to understand and grasp. When you represent things graphically, you will be able to think of more ideas and also to work out the consequences of your decisions. People think in pictures and a picture can express a lot of ideas in a quick way. UML is a standard way to draw various views of a piece of software: the user's view, the architecture, the internal structure of the software, the source code, and the hardware involved.

Q) What are the different views that are commonly used when developing Software in Java?
A) 1) Use Case View - Describes the system from the User's point of view, Describes the various functionalities expected from the system to be developed and how user is going to interact with those features.
2) Class Diagram - Shows graphically the relationships between classes and packages.
3) Sequence Diagram - Shows the sequence of method calls and interactions between classes.
4) Component Diagram - Shows the components within the system and the interaction between components.

Q) Explain Use Case View?
A) Use Case views or diagrams describe the system from the User's point of view, and the various functionalities expected from the system to be developed and how user is going to interact with those features. A use case diagram mainly consists of an actor (the user) and other use case diagrams and use cases. Use case view is the first activity in UML; from use case view other views like class diagram and sequence diagrams are derived. This makes it easy to map user requirements to implementation details like classes and flows.

Q) What is a Use Case ?
A) A use case names a type of user (actors) and something that they want to do (use case). The use case describes how an actor achieves a specific tangible goal. The important part of a use case is the description of the steps that the actors take to achieve their goals and how the system appears to respond to the actor's actions.

Q) What is an Actor?
A) An actor is the person or entity who is going to use the software. An actor can be a human, a device, or a piece of software but it must not be part of the system we are producing.

Q) What are the rules for defining an Actor?
A) The actors must not be part of the software that you are describing. They are outside it and only use it. They can be people, machines, or other software. Usecase names must describe some activity that an actor wants to do. A simple rule is to start each use case name with a strong verb: "Review grade", "update record", "Get money from ATM", and "Control nuclear reactor" are good names. "Grades" and "do email" are bad ones. Avoid having a large number of overly simple use cases that can be covered by one simple one: Instead of "add record", "change record", "delete record", "print record",.... etc use "Access and update record", for example . We can use scenarios to show more details.

Q) What is a Class Diagram?
A) Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations/functions and attributes/member variables of the classes.

Q) How are classes represented in a class diagram?
A) Class is basically a prototype which helps us create objects. Class defines the static structure of the project. A class represents family of an object. By using Class we can create uniform objects.
In the below figure you can see how the class diagram looks. Basically there are three important sections which are numbered as shown in the below. Let's try to understand according to the numbering:
* Class name: This is the first section or top most section of the Class which represents the name of the Class .
* Attributes: This is the second section or the middle section of the class which represents the properties of the system.
* Methods: This section carries operation or method to act on the attributes.

   

Q) What are the different kinds of relationships in Class diagram?
A) 1) Instance Level Relationships
a. Association
b. Aggregation
c. Composition

2) Class Level Relationships
a. Generalization
b. Realization

3) General Relationships
a. Dependency
b. Multiplicity

Q) What is Association?
A) Association defines a relationship between classes of objects which allows one object instance to cause another to perform an action on its behalf. When two objects are associated, one object will be having a variable that points to the other object. In bi directional association both the objects will be using each other. Binary associations are represented by a line with each end connected to a class block.

   

Q) What is Aggregation?
A) Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association. It is an association that represents a part-whole relationship which means that one object contains another object. Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container--essentially, if the container is destroyed, its contents are not. In UML, it is graphically represented as a clear diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

   

Q) What is Composition?
A) Composition is a stronger variant of the "has a" or association relationship; composition is more specific than aggregation. It is represented with a solid diamond shape. Composition has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, every instance that it contains is destroyed as well. The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

    In the above picture the relationship between Car and Carburetor is Composition, The Carburetor cannot be used without a Car. But the relationship between Pond and Duck is Aggregation i.e. Pond has many ducks but ducks can be associated with more than one pond.

Q) What are activation boxes in a sequence diagram?
A) Activation boxes are the opaque rectangular boxes drawn over the lifelines at points where a method is called. They are also called method call boxes.

Q) What is Generalization?
A) The generalization relationship is also known as the inheritance or "is a" relationship. When one class inherits or extends another class, it is called Generalization. Formally, The Generalization relationship indicates that one of the two related classes (the subtype) is considered to be a specialized form of the other (the super type) and super type is considered as Generalization of subtype.
In UML diagrams generalization is shown as a Closed but unfilled arrow pointing from the child class to the parent class.

   

Q) What is Realization?
A) In java when one class implements and interface it is called realization, the class realizes the interface. Formally, realization relationship is a relationship between two model elements, in which one model element (the client) realizes the behavior that the other model element (the supplier) specifies. A realization is displayed in a UML diagram as a dashed line with an unfilled arrowhead towards the supplier.

   

Q) What is a Sequence Diagram?
A) Sequence diagram is used to represent the interactions that happen between objects during an activity or process. The objects are represented as vertical lines called lifelines and the messages exchanged between them are represented as horizontal arrows. This allows the specification of simple runtime scenarios in a graphical manner. The object names will be written on a box above the lifelines and the name of the method/ message called is written on the top of the arrow, The direction of the arrow indicated the direction of method call or message flow.

   

Q) What is modeling?What are the advantages of creating a model?
A) Modeling is a proven and well-accepted engineering technique which helps build a model. Model is a simplification of reality; it is a blueprint of the actual system that needs to be built. Model helps to visualize the system. Model helps to specify the structural and behavior of the system. Model helps make templates for constructing the system. Model helps document the system.

Q) What are the different views that are considered when building an object-oriented software system?
A) Normally there are 5 views. Use Case view - This view exposes the requirements of a system. Design View - Capturing the vocabulary. Process View - modeling the distribution of the systems processes and threads. Implementation view - addressing the physical implementation of the system. Deployment view - focus on the modeling the components required for deploying the system.

Q) What are diagrams?
A) Diagrams are graphical representation of a set of elements most often shown made of things and associations.

Q) When one method call to a class results in several method calls to other classes how is it represented?
A) When a method is called there it will be from a method call box on the caller's life line and will be connected to a method call box on the called object's life line. The method box of the called method's lifeline will make multiple calls to one or several other classes.

   

Q) What are the major three types of modeling used?
A) Major three types of modeling are structural, behavioral, and architectural.

Q) Mention the different kinds of modeling diagrams used?
A) Modeling diagrams that are commonly used are, there are 9 of them. Use case diagram, Class Diagram, Object Diagram, Sequence Diagram, statechart Diagram, Collaboration Diagram, Activity Diagram, Component diagram, Deployment Diagram.

Q) What is Architecture?
A) Architecture is not only taking care of the structural and behavioral aspect of a software system but also taking into account the software usage, functionality, performance, reuse, economic and technology constraints.

Q) What is SDLC?
A) SDLC is Software Development Life Cycle. SDLC of a system included processes that are Use case driven, Architecture centric and Iterative and Incremental. This Life cycle is divided into phases. Phase is a time span between two milestones. The milestones are Inception, Elaboration, Construction, and Transition. Process Workflows that evolve through these phase are Business Modeling, Requirement gathering, Analysis and Design, Implementation, Testing, Deployment. Supporting Workflows are Configuration and change management, Project management.

Q) What are Relationships?
A) There are different kinds of relationships: Dependencies, Generalization, and Association. Dependencies are relations ships between two entities that that a change in specification of one thing may affect another thing. Most commonly it is used to show that one class uses another class as an argument in the signature of the operation. Generalization is relationships specified in the class subclass scenario, it is shown when one entity inherits from other. Associations are structural relationships that are: a room has walls, Person works for a company. Aggregation is a type of association where there is a has a relation ship, That is a room has walls, ?o if there are two classes room and walls then the relation ship is called a association and further defined as an aggregation.

Q) What are Messages?
A) A message is the specification of a communication, when a message is passed that results in action that is in turn an executable statement.

Q) How are the diagrams divided?
A) The nine diagrams are divided into static diagrams and dynamic diagrams.
Static Diagrams (Also called Structural Diagram): Class diagram, Object diagram, Component Diagram, Deployment diagram.
Dynamic Diagrams (Also called Behavioral Diagrams): Use Case Diagram, Sequence Diagram, Collaboration Diagram, Activity diagram, Statechart diagram.

Q) What is an Use Case?
A) A use case specifies the behavior of a system or a part of a system, ?se cases are used to capture the behavior that need to be developed. It involves the interaction of actors and the system.

Q) Can you explain use case diagrams?
A) Use case diagram answers what system does from the user point of view. Use case answer 'What will the system do?'. Use cases are mainly used in requirement document to depict clarity regarding a system. There are three important parts in a use case scenario, actor and use case.

Scenario: A scenario is a sequence of events which happen when a user interacts with the system.
Actor: Actor is the who of the system, in other words the end user.
Use Case: Use case is task or the goal performed by the end user. Below figure 'Use Case' shows a simple scenario with 'Actor' and a 'Use Case'. Scenario represents an accountant entering accounts data in the system. As use case's represent action performed they are normally represented by strong verbs.

Actor's are represented by simple stick man and use case by oval shape as shown in figure 'Use Case' below.    

Q) Can you explain primary and secondary actors?
A) Actors are further classified in to two types primary and secondary actors. Primary actors are the users who are the active participants and they initiate the user case, while secondary actors are those who only passively participate in the use case.

Q) Can you explain 'Extend' and 'Include' in use cases?
A) 'Extend' and 'Include' define relationships between use cases. Below figure 'Extend and Include' shows how these two fundamentals are implemented in a project. The below use case represents a system which is used to maintain customer. When a customer is added successfully it should send an email to the admin saying that a new customer is added. Only admin have rights to modify the customer. First lets define extend and include and then see how the same fits in this use case scenario.
Include: Include relationship represents an invocation of one use case by the other. If you think from the coding perspective its like one function been called by the other function.
Extend: This relationship signifies that the extending use case will work exactly like the base use case only that some new steps will inserted in the extended use case.
Below figure 'Extend and Include' shows that 'add customer' is same as the 'add discounted customer'. The 'Add discounted customer' has an extra process, to define discount for the discounted customer which is not available for the simple customer. One of the requirements of the project was that when we add a customer, the system should send an email. So after the customer is added either through 'Add simple customer' use case or 'Add discounted customer' use case it should invoke 'send a email' use case. So we have defined the same with a simple dotted line with << include>> as the relationship.     Note: One of the points to be noted in the diagram 'Extend and Include' is we have defined inheritance relationship between simple and admin user. This also helps us defining a technical road map regarding relationships between simple and admin user.

Q) What is a Scenario?
A) Each use case will need to be described in more detail how to implement it. A scenario describes, step by step, how a particular user gets what they want from the computer. It says what the user does and what the computer does as a result. However it does not spell out all the details -- things like whether there is a tool bar or the color of the screen is best left out.

Q) How do we represent private, public and protected in class diagrams?
A) In order to represent visibility for properties and methods in class diagram we need to place symbols next to each property and method as shown in figure 'Private, Public and Protected'. '+' indicates that it's public properties/methods. '-'indicates private properties which means it can not be accessed outside the class. '#' indicate protected/friend properties. Protected properties can only be seen within the component and not outside the component.

   

Q) What are composite structure diagram and reflexive association in class diagrams?
A) Composite structure diagram : When we try to show Aggregation and Composition in a complete project the diagram becomes very complicated so in order to keep it simple we can use Composite structure diagram. In the below figure we have shown two diagrams one is normal diagram other is Composite structure diagram and the simplicity can easily be identified. In the composite diagram the aggregated classes are self contained in the main class which makes it simpler to read.

    Reflexive associations : In many scenarios you need to show that two instances of the same class are associated with each other and this scenario is termed as Reflexive Association. For instance in the below figure shows Reflexive Association in the real project. Here you can see customer class has multiple address class and addresses can be a Head office, corporate office or Regional office. One of the address objects is Head office and we have linked the address object to show Reflexive Association relationship. This is the way we can read the diagram Regional address object is blocked by zero or one instance of Head office object.

   

Q) Can you explain business entity and service class?
A) Business entity objects represent persistent information like tables of a database. Just making my point clearer they just represent data and do not have business validations as such. For instance below figure 'Business entity and service' shows a simple customer table which with three fields 'Customer Code',' Customer Address' and 'Phone Number'. All these fields are properties in 'ClsCustomer' class. So 'ClsCustomer' class becomes the business entity class. The business entity class by itself can not do anything it's just a place holder for data. In the same figure we have one more class 'ClsServiceCustomer'. This class aggregates the business entity class and performs operations like 'Add',' Next' (Move to next record), 'Prev' (Move to previous record) and 'GetItem' (get a customer entity depending on condition).
With this approach we have separated the data from the behavior. The service represents the behavior while the business entity represents the persistent data.

   

Q) Can you explain System entity and service class?
A) System entity class represents persistent information which is related to the system. For instance in the below figure 'System entity and service class' we have a system entity class which represents information about 'loggedindate' and 'loggedintime' of the system registry. System service class come in two flavors one is it acts like a wrapper in the system entity class to represent behavior for the persistent system entity data. In the figure you can see how the 'ClsAudit' system entity is wrapped by the 'ClsAuditSytem' class which is the system service class. 'ClsAuditSystem' adds 'Audit' and 'GetAudit' behavior to the 'ClsAudit' system entity class.

   

The other flavor of the system service class is to operate on non-persistent information. The first flavor operated on persistent information. For instance the below figure 'Non-persistent information' shows how the class 'ClsPaymentService' class operates on the payment gateway to Check is the card exists , Is the card valid and how much is the amount in the card ?. All these information are non-persistent. By separating the logic of non-persistent data in to a system service class we bring high reusability in the project.

   

Q) How can we represent an abstract class and interface UML?
A) Interface is represented by <<;type>> in the class diagram. Below figure 'Interface in action' shows we have defined an interface 'IContext'. Note the '<<;type>>' represents an interface. If we want to show that the interface is used in a class we show the same with a line and a simple circle as shown in figure below.

   

   

Abstract classes are represented by '{abstract}' as shown in figure 'Abstract classes in action'.

   

Q) How do we achieve generalization and specialization?
A)By using inheritance.

Q) Can you explain object diagrams in UML?
A) Class represents shows the static nature of the system. From the previous question you can easily judge that class diagrams shows the types and how they are linked. Classes come to live only when objects are created from them. Object diagram gives a pictorial representation of class diagram at any point of time. Below figure 'Object diagram' shows how a class looks in when actual objects are created. We have shown a simple student and course relationship in the object diagram. So a student can take multiple courses. The class diagram shows the same with the multiplicity relationship. We have also shown how the class diagram then looks when the objects are created using the object diagram. We represent object with Object Name: Class Name. For instance in the below figure we have shown 'Shiv : ClsStudent' i.e 'Shiv' is the object and 'ClsStudent' the class. As the objects are created we also need to show data of the properties, the same is represented by 'PropertyName=Value' i.e. 'StudentName=Shiv'.

    The diagram also states that 'ClsStudent' can apply for many courses. The same is represented in object diagram by showing two objects one of the 'Computer' and the other of 'English'.
Note: Object diagrams should only be drawn to represent complicated relationship between objects. It's possible that it can also complicate your technical document as lot. So use it sparingly.