Explore topic-wise InterviewSolutions in .

An ASPECT of the behaviour that defines a class; an ELEMENT of the services that are provided by a class; a specification of an element of system FUNCTIONALITY that will be implemented as a METHOD of an object.

An aspect of the behaviour that defines a class; an element of the services that are provided by a class; a specification of an element of system functionality that will be implemented as a method of an object.

MULTIPLICITY is a CONSTRAINT that SPECIFIES the range of permitted CARDINALITIES, for example in an association role or in a composite class.

Multiplicity is a constraint that specifies the range of permitted cardinalities, for example in an association role or in a composite class.

Link: A connection between OBJECTS; an instance of an association.
Association: A logical connection, usually between different CLASSES ALTHOUGH in some circumstances a class can have an association with itself. An association describes possible links between objects, and MAY correspond EITHER to logical relationship in the application domain or to message paths in software.

Link: A connection between objects; an instance of an association.
Association: A logical connection, usually between different classes although in some circumstances a class can have an association with itself. An association describes possible links between objects, and may correspond either to logical relationship in the application domain or to message paths in software.

Boundary OBJECTS model interaction between the SYSTEM and actors. Entity objects represent INFORMATION and BEHAVIOUR in the application domain. CONTROL objects co-ordinate and control other objects.

Boundary objects model interaction between the system and actors. Entity objects represent information and behaviour in the application domain. Control objects co-ordinate and control other objects.

A stereotype is a specialized UML modelling ELEMENT. It has a SPECIAL MEANING and purpose in UML diagrams. The stereotype name is contained within matched guillemets <<…&GT;. For example an interface is denoted as <<interface>>.

A stereotype is a specialized UML modelling element. It has a special meaning and purpose in UML diagrams. The stereotype name is contained within matched guillemets <<…>. For example an interface is denoted as <<interface>>.

USABILITY requirement are those that will enable us to ENSURE that there is a good match between the SYSTEM that is developed and both the users of that system and the TASKS that they will undertake when using it.

Usability requirement are those that will enable us to ensure that there is a good match between the system that is developed and both the users of that system and the tasks that they will undertake when using it.

Non-functionality requirements are those that describe aspects of the SYSTEM that are concerned with how WELL it PROVIDES the functional requirements.

Non-functionality requirements are those that describe aspects of the system that are concerned with how well it provides the functional requirements.

Functional requirements describe what a SYSTEM does or is expected to do, OFTEN REFERRED to as its functionality.

Functional requirements describe what a system does or is expected to do, often referred to as its functionality.

There are three TYPES of requirements these are as FOLLOWS:
• FUNCTIONAL
• Non-functional
• USABILITY

There are three types of requirements these are as follows:
• Functional
• Non-functional
• Usability

The EXISTING system may a manual one, BASED on paper documents, FORMS and files; it may already be computerized; or it may be a combination of both manual and computerized elements is called CURRENT system.

The existing system may a manual one, based on paper documents, forms and files; it may already be computerized; or it may be a combination of both manual and computerized elements is called current system.

A variation of a statechart diagram that FOCUSES on a flow of ACTIVITY driven by internal PROCESSING within an object rather than by events that are EXTERNAL to it. In an activity diagram most (or all) states are action states, each of which represents the EXECUTION of an operation.

A variation of a statechart diagram that focuses on a flow of activity driven by internal processing within an object rather than by events that are external to it. In an activity diagram most (or all) states are action states, each of which represents the execution of an operation.

An object is a DEPENDENCY between an object and an ACTIVITY that results in a CHANGE to the STATE of that object.

An object is a dependency between an object and an activity that results in a change to the state of that object.

A GUARD condition is a Boolean expression associated with a TRANSITION that is evaluated at the time the EVENT fires. The transition is take PLACE if the condition is true.

A guard condition is a Boolean expression associated with a transition that is evaluated at the time the event fires. The transition is take place if the condition is true.

An ACTIVITY is some BEHAVIOUR that may persist for the DURATION of a state.

An activity is some behaviour that may persist for the duration of a state.

A package is a mechanism for GROUPING UML elements, USUALLY classes, into groups. Packages can be NESTED within other packages.

A package is a mechanism for grouping UML elements, usually classes, into groups. Packages can be nested within other packages.

A PART of a SYSTEM that can be REGARDED as a system in its own RIGHT.

A part of a system that can be regarded as a system in its own right.

ELEMENTS are:
• ICONS
• Two-dimensional SYMBOLS
• PATHS
• STRINGS

Elements are:
• Icons
• Two-dimensional symbols
• Paths
• strings

SUBCLASS: a specialized class that acquires GENERAL features from its ancestor super-classes in a generalization HIERARCHY, but that ALSO adds one or more specialized characteristics of its own.
Superclass: a generalized class that is an abstraction of the common characteristics of its subclasses in a generalization hierarchy.

Subclass: a specialized class that acquires general features from its ancestor super-classes in a generalization hierarchy, but that also adds one or more specialized characteristics of its own.
Superclass: a generalized class that is an abstraction of the common characteristics of its subclasses in a generalization hierarchy.

determined by the OPERATION’s name, the NUMBER and TYPE of its parameters and the type of the RETURN value if any. Polymorphically redefined operations have the same SIGNATURE.

determined by the operation’s name, the number and type of its parameters and the type of the return value if any. Polymorphically redefined operations have the same signature.

It is a metaphor for the way that objects interact in object-oriented system by SENDING each other messages that REQUEST SERVICES or supply information. In a system, several objects may COLLABORATE to FULFIL an action. These objects communicate by sending each other message. Since objects interact only through messages they exchange, their internal detail can remain hidden from each other.

It is a metaphor for the way that objects interact in object-oriented system by sending each other messages that request services or supply information. In a system, several objects may collaborate to fulfil an action. These objects communicate by sending each other message. Since objects interact only through messages they exchange, their internal detail can remain hidden from each other.

The ability of different METHODS to implement the same operation, and THUS to respond same messages in different WAYS that are APPROPRIATE to their class is called POLYMORPHISM.

The ability of different methods to implement the same operation, and thus to respond same messages in different ways that are appropriate to their class is called polymorphism.

The mechanism by which object-oriented PROGRAMMING languages implement a relationship of generalization and specialization between CLASSES is called inheritance. When we extend a class from an existing class – the existing class is the superclass and the extended class is SUBCLASS. By the RULES of inheritance the subclass inherits all the FEATURES from its superclass.

The mechanism by which object-oriented programming languages implement a relationship of generalization and specialization between classes is called inheritance. When we extend a class from an existing class – the existing class is the superclass and the extended class is subclass. By the rules of inheritance the subclass inherits all the features from its superclass.

Generalization: Generalization is the abstraction of COMMON FEATURE among elements by the creation of a hierarchy of more general elements that encapsulate common features. For example, in animal world a cat and a dog SHARE some common features and we create a common general class “MAMMAL” which encapsulates common their common feature. A cat, a dog – both are consistent with mammal class.
Specialization: The other face of generalization is specialization. A class is said to be specialized when it has a set of characteristics that uniquely distinguish it from its SUPER class. For example, a cat is a mammal but it is more specialized

Generalization: Generalization is the abstraction of common feature among elements by the creation of a hierarchy of more general elements that encapsulate common features. For example, in animal world a cat and a dog share some common features and we create a common general class “Mammal” which encapsulates common their common feature. A cat, a dog – both are consistent with mammal class.
Specialization: The other face of generalization is specialization. A class is said to be specialized when it has a set of characteristics that uniquely distinguish it from its super class. For example, a cat is a mammal but it is more specialized

Object: A single THING or concept, either in a model of an application domain or in a software system that can be REPRESENTED as an encapsulation of state, BEHAVIOR and identity, a member of a class that defines a SET of similar objects.
Class: A class is a descriptor for a collection of objects that are logically similar in terms of their behavior and the STRUCTURE of their data.
Instance: A single object, usually called an instance in the context of its membership of a particular class or type.

Object: A single thing or concept, either in a model of an application domain or in a software system that can be represented as an encapsulation of state, behavior and identity, a member of a class that defines a set of similar objects.
Class: A class is a descriptor for a collection of objects that are logically similar in terms of their behavior and the structure of their data.
Instance: A single object, usually called an instance in the context of its membership of a particular class or type.

The four phases of UNIFIED SOFTWARE Development PROCESS are as FOLLOWS:
• Inception.
• Elaboration.
• Construction.
• Transition.

The four phases of Unified Software Development Process are as follows:
• Inception.
• Elaboration.
• Construction.
• Transition.

CASE stands for Computer Aided SOFTWARE Engineering. CASE tools have been categories in various ways according to the phase in the life CYCLE which they should be used. Upper-CASE tools provide SUPPORT for the analysis and design while lower-CASE tools are concerned with the construction and MAINTENANCE of software. These two categories of tools directly support the overall development process.

CASE stands for Computer Aided Software Engineering. CASE tools have been categories in various ways according to the phase in the life cycle which they should be used. Upper-CASE tools provide support for the analysis and design while lower-CASE tools are concerned with the construction and maintenance of software. These two categories of tools directly support the overall development process.

Inception is concerned with DETERMINING the SCOPE and PURPOSE of the project.

Inception is concerned with determining the scope and purpose of the project.

TRANSITION DEALS with PRODUCT INSTALLATION and ROLLOUT.

Transition deals with product installation and rollout.

Construction’s MAIN AIM is to build the SOFTWARE SYSTEM.

Construction’s main aim is to build the software system.

Elaboration FOCUSES REQUIREMENTS capture and determining the STRUCTURE of the SYSTEM.

Elaboration focuses requirements capture and determining the structure of the system.

The MAIN STAGES required to PREPARE a prototype are as FOLLOWS:
• Perform initial analysis.
• Define prototype objectives.
• Specify prototype.
• Construct prototype.
• Evaluate prototype and RECOMMEND changes.

The main stages required to prepare a prototype are as follows:
• Perform initial analysis.
• Define prototype objectives.
• Specify prototype.
• Construct prototype.
• Evaluate prototype and recommend changes.

The main phases of PROBLEM solving model are GIVEN below:
• Data GATHERING.
• Problem redefining.
• Finding ideas.
• Finding SOLUTIONS.
• Implementation.

The main phases of problem solving model are given below:
• Data gathering.
• Problem redefining.
• Finding ideas.
• Finding solutions.
• Implementation.

There are five types of association but importance is GIVEN to only two they are Bidirectional and unidirectional. It represents a family of links. Binary associations are represented by two ends and they are connected to CLASS box. HIGHER order associations can have more than two ends.

There are five types of association but importance is given to only two they are Bidirectional and unidirectional. It represents a family of links. Binary associations are represented by two ends and they are connected to class box. Higher order associations can have more than two ends.

Aggregation GIVES a much more detail than association. In aggregation you can name it and it can have same adornments. It may not be INVOLVED with more than two classes. It can have a collection of classes but its classes are not DEPENDENT on the LIFE cycle. It's contents are not DESTROYED even when its classes are destroyed.

Aggregation gives a much more detail than association. In aggregation you can name it and it can have same adornments. It may not be involved with more than two classes. It can have a collection of classes but its classes are not dependent on the life cycle. It's contents are not destroyed even when its classes are destroyed.

This form of RELATIONSHIP exists when a change to a CERTAIN element changes the DEFINITION and structure of the other element as well. This is indicated by a pointing arrow from the dependent side to the independent side. This form of relationship can EXIST between classes and INHERITANCE.

This form of relationship exists when a change to a certain element changes the definition and structure of the other element as well. This is indicated by a pointing arrow from the dependent side to the independent side. This form of relationship can exist between classes and inheritance.

Some of the BENEFITS offered by iterative development are as FOLLOWS:

1. Mitigation of RISKS in an earlier stage.
2. Visibility of PROGRESS.
3. Feedback, adaptation and engagement.
4. COMPLEXITY management.
5. Iteration management can improve the overall process of the project because it details and explains the various steps present in it.

Some of the benefits offered by iterative development are as follows:

XML standard should allow interchange of UML models but it is not the case scenario PRACTICALLY. Portability of the language from one FORMAT to ANOTHER format is not possible and lack of information can be possible in the course. It also lacks sufficient details which make it impossible for interchange between modeling tools.

XML standard should allow interchange of UML models but it is not the case scenario practically. Portability of the language from one format to another format is not possible and lack of information can be possible in the course. It also lacks sufficient details which make it impossible for interchange between modeling tools.

Executable does not use full functionality and STANDARDS as present in UML. ALTHOUGH there are MANY constructs present in UML all of them are not used for designing, executable UML uses only LIMITED number of constructs.

Executable does not use full functionality and standards as present in UML. Although there are many constructs present in UML all of them are not used for designing, executable UML uses only limited number of constructs.

A message is the specification of a communication, when a message is passed that results in action that is in turn an EXECUTABLE STATEMENT.

A message is the specification of a communication, when a message is passed that results in action that is in turn an executable statement.

Diagrams are GRAPHICAL REPRESENTATION of a SET of elements most often shown MADE of things and ASSOCIATIONS.

Diagrams are graphical representation of a set of elements most often shown made of things and associations.

• ACTIVITY diagram: captures the process flow. They are used for functional MODELING.
• Sequence diagram: the track the INTERACTION between the objects. They are used for dynamic modeling.

The FOLLOWING are the difference between Activity and SEQUENCE DIAGRAMS:
A sequence diagram shows the way of processes EXECUTE in a sequence. For example, the order of operations and the parameters.
► An activity diagram depicts the operational workflows.
► A sequence diagram is focused to represent interactions between different objects.
► Activity diagram shows the actions for various objects.

The following are the difference between Activity and Sequence Diagrams:
A sequence diagram shows the way of processes execute in a sequence. For example, the order of operations and the parameters.
► An activity diagram depicts the operational workflows.
► A sequence diagram is focused to represent interactions between different objects.
► Activity diagram shows the actions for various objects.

Use case diagram is a subset of various behaviour diagrams. Use case diagrams are USED to provide concrete examples of the elements which are supposed to implement. It is used to analyze objects.

The following are the elements of the use case diagrams:

Actors: An actor is one of the entities who perform certain actions. These roles are the actual business roles of the users in GIVEN system. An actor interacts with a use case of the system. For example, for a banking system, a customer is one of the actors.

Use Case: A use case is a use case diagram of UML represents a business functionality that is distinct. The use case should list the discrete business functionality that is specified in the problem statement. Every business functionality is a potential use case.

System BOUNDARY: A system boundary defines the scope of the system. The SYSTEMS that use cases also need to be defined in the limits of the system. The system boundary is shown as a rectangle that spans all use cases of the system.

Use case diagram is a subset of various behaviour diagrams. Use case diagrams are used to provide concrete examples of the elements which are supposed to implement. It is used to analyze objects.

The following are the elements of the use case diagrams:

Actors: An actor is one of the entities who perform certain actions. These roles are the actual business roles of the users in given system. An actor interacts with a use case of the system. For example, for a banking system, a customer is one of the actors.

Use Case: A use case is a use case diagram of UML represents a business functionality that is distinct. The use case should list the discrete business functionality that is specified in the problem statement. Every business functionality is a potential use case.

System boundary: A system boundary defines the scope of the system. The systems that use cases also need to be defined in the limits of the system. The system boundary is shown as a rectangle that spans all use cases of the system.

• ACTIVITIES: An activity indicates an action that performed in the SYSTEM.
• Transitions: Transitions are represented by open arrow HEADS. Transitions are used to indicate the flow among elements in the DIAGRAM.
• Decision Points: The logical branching is depicted by the decision points.
• States: A state is shown in a rounded rectangle. States are indicated to MENTION the mile stones of processing in the activity diagrams.

• Object: The interaction between OBJECTS takes PLACE in a system. An object is depicted by a rectangle with the name of the object, preceded by a colon and underline.
• Relation/Association: Association among objects is linked by CONNECTING them. The cardinality can be depicted by placing qualifiers on either ends.
• Messages: An ARROW that commencing from ONE object to the destination object. This depicts the interaction between objects. The sequence or order of the interaction is depicted by the number.

• INITIAL State: The first or the default state the object is in. It is denoted by a SOLID circle.
• State: All the STATES an object can go in are mentioned in this. It is REPRESENTED by a rectangle with rounded edges.
• Transitions: DEPICTED by arrow from the source state to destination state.
• Final State: Depicts the end of the. It is shown by a bull's eye symbol.

• INITIAL State: This state shows the first activity of the flow.
• State: A state represents the state of an OBJECT at a particular given point of TIME.
• Transition: The transition from one state to another state of objects is represented by an arrow.
• Event and ACTION: A trigger that causes a transition to occur.
• Signal: When a MESSAGE or a trigger caused by an event to a state, which causes a transition, this message is called as a signal.
• Final State: The state diagram ends with a diagram that depicts a bulls eye is known as Final State.

• Nodes: A node represents any hardware component. The configuration of hardware is represented by attributes of nodes.
• Components: A component represents software. Each component straightly represents a class or object that in turn represents METHODS.
• Dependencies: The reliability of one component with that of ANOTHER is depicted by dependencies.
• Links: To TIE up tow nodes, the links are utilized. The links are IMPLEMENTED by using nodes and their ASSOCIATIONS.

• ACTOR: Actor REPRESENTS an external user / end user who interact with the SYSTEM.
• Object: Object is represented by one of COMPONENTS of the system.
• Unit: A unit is a subsystem, or a sub component or other entity within the system.
• Separator: Separator represents a BOUNDARY among sub systems, components or units.
• Group: Represents different header elements in the subsystem.

A component diagram is particularly useful with teams of larger size. UML COMPONENTS are great to perform architectural landscape for a specific system. The component diagram allows to model high level SOFTWARE components and interfaces to those components. The sub teams EFFORT is very less, once the interfaces are PERFECTLY designed and accepted by the team MEMBERS.

A component diagram is particularly useful with teams of larger size. UML components are great to perform architectural landscape for a specific system. The component diagram allows to model high level software components and interfaces to those components. The sub teams effort is very less, once the interfaces are perfectly designed and accepted by the team members.