END TERM EXAMINATION- Sample Paper (2)
FORTH SEMESTER [MCA]
Code: MCA208 Subject: Object-Oriented Analysis and Design
Time: 3 Hours Maximum Marks: 60
Note: Attempt five questions including Q.no. 1 which is compulsory. Select one question from each unit.
|
Q1 (a) Attempt the following:- (2 x 10 = 20)
-
What is the Object Modeling Techniques (OMT)..
The object-modeling technique (OMT) is an object modeling approach for software modeling and designing. It was developed around 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object-oriented systems and to support object-oriented programming. Describes Object model or static structure of the system.
OMT was developed as an approach to software development. The purposes of modeling according to Rumbaugh are:
-
Testing physical entities before building them (simulation),
-
Communication with customers,
-
Visualization (alternative presentation of information), and
-
Reduction of complexity.
OMT has proposed three main types of models:
-
Object Model
-
Dynamic Model
-
Functional Model
-
What is the role of Swim lanes & Guard condition in Activity diagram.
Swimlanes:
-
Swimlanes (or activity partitions) indicate where activities take place.
-
Swimlanes can also be used to identify areas at the technology level where
activities are carried out
-
Swimlanes allow the partition an activity diagram so that parts of it appear in
the swimlane relevant to that element in the partition
Guard Conditions:
You can add a guard condition to an activity edge between two nodes, where the guard condition defines a condition that must be satisfied before the target activity node can be invoked. You can define the guard condition in the following ways:
-
name [guard condition] - The guard condition is created and is assigned a name.
-
[guard conditon] - The guard condition is created, but is not assigned a unique name.
In the following figure, one activity node called OpaqueAction is connected to a second activity node, called OpaqueAction2. A guard condition, called Guard1, specifies that the value of g coming from OpaqueAction must be greater than 10 for OpaqueAction2 to be invoked.
iii. Explain the different among Bidirectional, Unidirectional & Reflexive Association.
An association is a relationship between two classes represented by a solid line. Associations are bi-directional by default, so both classes know about each other and about the relationship between them. Either end of the line can have a role name and multiplicity. In the example, Student has the role of "tenant" in relation to Apartment and Apartment has the role of "accommodation" in relation to Student. Also, any instance of Apartment can be associated with up to four students and any student could be associated with 0 or 1 Apartment (a student either has an apartment to live in or does not).
Associations can also be unidirectional, where one class knows about the other class and the relationship but the other class does not. Such associations require an open arrowhead to point to the class that is known and only the known class can have a role name and multiplicity. In the example, the Customer class knows about any number of products purchased but the Product class knows nothing about any customer. The multiplicity "0..*" means zero or more.
An alternative to using role names is to provide a single name for an association centered between the two classes. A direction indicator can also be used to show the direction of the name, but is not necessary if the direction is obvious:
An association can also link a class to itself. Such an association is reflexive:
iv. Compare OOAD & SSAD.
SSAD (Structured Analysis): In Structured Analysis, the focus is only on process and procedures. Modeling techniques used in it are DFD(Data Flow Diagram), Flowcharts etc.
This approach is old and is not preferred. OOAD (Object Oriented Analysis ): Whereas in Object Oriented Analysis, the focus is more on capturing the real world objects in the current scenario that are of importance to the system. It stresses more on data structure and less on procedural structure. Without actually identifying objects, what are you going to interact with, and whose state will you change. In this approach, objects are identified, their relationships among each other, possible states that each object can be in, and finally how all objects collaborate with each other to achieve a broader system goal are identified.
v. Explain the term OORASS & HOOD.
The Object Oriented Role Analysis and Modeling (OOram) is a method, based on the concept of role, for performing object-oriented modeling. Originally (1989) coined Object Oriented Role Analysis, Synthesis and Structuring (OORASS), the method focuses on describing patterns of interaction without connecting the interaction to particular objects/instances. OOram was originally developed by Trygve Reenskaug (1996), a professor at the University of Oslo and the founder of the Norwegian IT company Taskon.
HOOD:
Hierarchical Object-Oriented Design (HOOD) has been developed for the European Space Agency as a design/notation method for Ada. Robinson introduces it in this way: "The top-down hierarchical decomposition approach is not new. After all, this is the method used with data flow diagrams starting from a context diagram which shows all the external interfaces with one central process. This process is then decomposed into other processes with data flows and control flows interacting between them, with consistency checks between levels. In the same way, the purpose of HOOD is to develop the design as a set of objects which together provide the functionality of the program."
The phases can be summarized as follows:
-
Problem definition.
-
Statement of the problem - the designer states the problem in correct sentences which provides:
-
Analysis and structuring of requirement data
-
Development of solution strategy.
-
Formalization of the strategy.
-
Objet identification.
-
Operation identification.
-
Grouping objects and operations (object operation table).
-
Graphical description.
-
Justification of design decisions.
-
Formalization of the solution.
vi. Discuss different goals of UML.
A picture is worth a thousand words, this absolutely fits while discussing about UML. Object oriented concepts were introduced much earlier than UML. So at that time there were no standard methodologies to organize and consolidate the object oriented development. At that point of time UML came into picture.
There are a number of goals for developing UML but the most important is to define some general purpose modeling language which all modelers can use and also it needs to be made simple to understand and use.
UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. The system can be a software or non software. So it must be clear that UML is not a development method rather it accompanies with processes to make a successful system.
At the conclusion the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment.
-
Difference between class notation and object notation in UML.
Class Notation:
UML class is represented by the diagram shown below. The diagram is divided into four parts.
-
The top section is used to name the class.
-
The second one is used to show the attributes of the class.
-
The third section is used to describe the operations performed by the class.
-
The fourth section is optional to show any additional components.
Classes are used to represent objects. Objects can be anything having properties and responsibility.
Object Notation:
The object is represented in the same way as the class. The only difference is the name which is underlined as shown below.
As object is the actual implementation of a class which is known as the instance of a class. So it has the same usage as the class.
-
Difference between test strategy and test plan.
Test Strategy: A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.
Components of the Test Strategy document
-
Scope and Objectives
-
Business issues
-
Roles and responsibilities
-
Communication and status reporting
-
Test deliverability
-
Industry standards to follow
-
Test automation and tools
-
Testing measurements and metrics
-
Risks and mitigation
-
Defect reporting and tracking
-
Change and configuration management
-
Training plan
Test Plan: The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents.
The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.
-
Generalization & Specialization
Generalization is the process of extracting shared characteristics from two or more classes, and combining them into a generalized super class. Shared characteristics can be attributes, associations, or methods.
In contrast to generalization, specialization means creating new subclasses from an existing class. If it turns out that certain attributes, associations, or methods only apply to some of the objects of the class, a subclass can be created. The most inclusive class in a generalization/specialization is called the super class The more specific classes are called subclasses and are generally placed below the super class.
-
Difference between sequence diagram and collaboration diagram
Sequence Diagram: A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some sequences, which are the sequence of messages flowing from one object to another. Interaction among the components of a system is very important from implementation and execution perspective. So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality. Collaboration Diagram: Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural organization consists of objects and links. The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.
UNIT – I
Q2(a). What is Unified Process Model? Explain the iterations, outcomes & Workflow in unified Process Model with neat diagram. (6)
Unified process (UP) is an architecture-centric, use-case driven, iterative and incremental development process that leverages unified modeling language and is compliant with the system process engineering meta model. Unified process can be applied to different software systems with different levels of technical and managerial complexity across various domains and organizational cultures. UP is also referred to as the unified software development process.
Iteration:
A typical iteration crosses all five of the workflows discussed in the previous section, to a greater or lesser extent. For instance, an iteration during the Elaboration phase might focus heavily on activities of the Requirements and Analysis workflows, whereas an iteration during Construction is more likely to involve Design, Implementation, and Test activities. Each iteration results in an increment. This is a release of the system that contains added or improved functionality compared with the previous release.
Figure below shows the essence of the iterative and incremental approach to software
development.
Then the team follows these steps:
1. Define the first iteration, addressing the most critical and difficult risks.
2. Map out a plan for the iteration to a suitable level of detail.
3. Perform the appropriate activities; for the Unified Process, these are activities associated with the Requirements, Analysis, Design, Implementation, and Test workflows.
4. Do a postmortem on the increment that results from the iteration.
5. Discard the risks that the increment has sufficiently addressed. Then update the ongoing risk list.
6. Revise the overall project plan in response to the relative success or failure of the iteration.
7. Proceed with the next iteration.
The Five Workflows: Within the Unified Process, five workflows cut across the set of four phases: Requirements, Analysis, Design, Implementation, and Test.
The primary activities of the Requirements workflow are aimed at building the use case model, which captures the functional requirements of the system being defined. This model helps the project stakeholders reach agreement on the capabilities of the system and the conditions to which it must conform.
The primary activities of the Analysis workflow are aimed at building the analysis model, which helps the developers refine and structure the functional requirements captured within the use case model. This model contains realizations of use cases that lend themselves to design and implementation work better than the use cases.
The primary activities of the Design workflow are aimed at building the design model, which describes the physical realizations of the use cases from the use case model, and also the contents of the analysis model. The design model serves as an abstraction of the implementation model
The primary activities of the Implementation workflow are aimed at building the implementation model, which describes how the elements of the design model are packaged into software components, such as source code files, dynamic link libraries (DLLs), and EJBs.
Q 2(b). Write a short note on “Object-Oriented Software Life Cycle. (4)
The software life-cycle: -
Analysis -- Conceptual Model, System Requirements
-
Design -- System Design, Detailed Design
-
Implementation -- Coding, Testing
Software development models
The software engineering literature abounds with descriptions of failing software projects and remedies proposed to solve the problem of software not meeting user expectations.
Software development models -
rapid throwaway prototyping -- quick and dirty
-
incremental development -- slowly evolving
-
evolutionary prototyping -- evolving requirements
-
reusable software -- reduces cost and time
-
automated software synthesis -- one level of abstraction higher
Requirements -- user needs are constantly evolving -
Reliability -- incremental development, reuse, synthesis
-
Adaptability -- evolutionary prototyping
-
Maintainability -- incremental development, synthesis
-
Performance -- incremental development, reuse
Q3(a). Write a short note on Object-Oriented Modeling Technique. (5)
Modeling as a set of techniques for expressing the target system before the target system has been complete. Using these techniques, we will build a model of the target system. The model will express various aspects of the system to be developed. The representation chosen for communicating the model is a notation. The necessity of building models may be rationalized in a number of ways. One reason for modeling is to support the building of software systems whose complexities exceed our mental capacities. For example, most of us are unable to multiply multi-
digit numbers together in our heads, but with the aid of a pencil and paper the task is trivial. Our unaided mental capacity has limitations, which can be augmented by techniques that allow us to record previous thinking. Such augmentation permits the shifting of our mental focus to unsolved portions of the problem. We will use a software engineering notation to record previous analysis and design decisions so that we may focus on new areas of the software system.
Model building addresses the complexity of the system to be developed by facilitating the creation of a series of models. The first model begins with an abstract representation of the system. Later models contain progressively more detail. Subsequent models are made to contain more detail than their predecessor models by focusing on a smaller portion of the system and extending the analysis to produce additional depth in that portion. The process of model building, therefore parallels the system developers’ understanding of the system. As the system analysts begin their study of the target system, their understanding is very general. During the model-building process, the models become increasingly detailed, and the system developers’ understanding also increases. Modeling software systems also creates concise and unambiguous representations, which facilitate communication between collaborating system developers. These precise representations can also be evaluated, verified, and corrected before significant time is invested in programming a poorly conceptualized system.
Q3(b). Discuss the qualities of Object-Oriented techniques. (5)
The primary objective of applying good software engineering practices to a software project is to produce quality software in a timely, predictable manner. The second question is “Are the objectives of object-oriented software engineering any different from those of the process-oriented software approach?” A feature that distinguishes object-oriented software development projects from process-oriented projects is that object-oriented development emphasizes the ability of the software to evolve smoothly over each software release. This emphasis implies that the software is easily extensible. The Object-oriented development also emphasizes modularity, but the modules must also evolve easily. Extensibility of modules is, therefore, an objective of object-oriented development and is a quality of a good software system.
.
The desire for reusable software modules transcends the particular choice of software development approach. Certain mechanisms, however, are particularly conducive to the creation of reusable code. Many of these mechanisms are available in object-oriented programming languages. In particular, the inheritance mechanism, unique to object-oriented systems, suggests a strategy for software module reuse. The common code in the parent classes is used over and over (as inherited methods and attributes) in the child classes. Thinking of inheritance in this manner suggests that optimal
use of inheritance hierarchies is another quality of a good object-oriented software
system.
UNIT- II
Q 4(a). The goal of Analysis model is to develop a model of what of the system will do? Draw a Analysis model for Banking System. (5)
The analysis model describes the structure of the system or application that you are modeling. It consists of class diagrams and sequence diagrams that describe the logical implementation of the functional requirements that you identified in the use case model.
The analysis model identifies the main classes in the system and contains a set of use case realizations that describe how the system will be built. Class diagrams describes the static structure of the system by using stereotypes to model the functional parts of the system. Sequence diagrams realize the use cases by describing the flow of events in the use cases when they are executed. These use case realizations model how the parts of the system interact within the context of a specific use case.
Q 4(b). Draw Use case diagram for Online Shopping . (5)
Q5 (a). Explain the software development life cycle of object-oriented approach. (5)
Object Oriented Systems Development Life Cycle -
System development can be viewed as a process
-
The development itself, in essence, is a process of change, refinement, transformation, or addition to existing product.
-
The process can be divided into small, interacting phases – sub processes. Each sub process must have the following:
-
A description in terms of how it works
-
Specification of the input required for the process
-
Specification of the output to be produced
-
The software development process can be viewed as a series of transformations, where the output of one transformation becomes the input of the subsequent transformation.
-
Transformation 1 (analysis) – translates the users’ needs into system requirements and responsibilities.
Transformation 2 (design) – begins with a problem statement and ends with a detailed design that can be transformed into an operational system.
Transformation 3 (implementation) – refines the detailed design into the system deployment that will satisfy users’ needs.
-
An example of the software development process is the waterfall approach, which starts with deciding what is to be done. Once the requirements have been determined, we next must decide how to accomplish them. This is followed by a step in which we do it, whatever “it” has required us to do. We then must test the result to see if we have satisfied the users’ requirements. Finally, we use what we have done.
-
To achieve high quality in software we should be able to answer the following questions:
-
How do we determine that the system is ready for delivery?
-
Is it now an operational system that satisfies users’ needs?
-
Is it correct and operating as we thought it should?
-
Does it pass an evaluation process?
-
Blum describes a means of system evaluation in terms of four quality measures:
-
Correspondence – measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statement.
-
Validation – task of predicting correspondence.
-
Correctness – measures the consistency of the product requirements with respect to the design specification.
-
Verification – exercise of determining correctness.
-
Verification: Am I building the product right?
Validation: Am I building the right product?
-
Validation begins as soon as the project starts, but verification can begin only after a specification has been accepted.
-
The object-oriented software development life cycle (SDLC) consists of three macro processes:
-
object-oriented analysis
-
object-oriented design
-
object-oriented implementation.
Q 5(b). What do you mean by object-oriented design model. Also discuss the input and output of object-oriented design. (5)
Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.
Input (sources) for object-oriented design: The input for object-oriented design is provided by the output of object-oriented analysis. Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design; analysis and design may occur in parallel, and in practice the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.
Some typical input artifacts for object-oriented design are:
-
Conceptual model: The result of object-oriented analysis, it captures concepts in the problem domain. The conceptual model is explicitly chosen to be independent of implementation details, such as concurrency or data storage.
-
Use case: A description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into use case diagrams. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform.
-
System sequence diagram: A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.
-
User interface documentations (if applicable): Document that shows and describes the look and feel of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end-product and therefore helps the designer.
-
Relational data model (if applicable): A data model is an abstract model that describes how data is represented and used. If an object database is not used, the relational data model should usually be created before the design, since the strategy chosen for object-relational mapping is an output of the OO design process. However, it is possible to develop the relational data model and the object-oriented design artifacts in parallel, and the growth of an artifact can stimulate the refinement of other artifacts.
Output (deliverables) of object-oriented design: -
Sequence diagram: Extend the system sequence diagram to add specific objects that handle the system events. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.
-
Class diagram: A class diagram is a type of static structure UML diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system.
UNIT- III
Q6(a). Discuss object-oriented testing stretegies in detail. (6)
-
Object-Oriented Testing Strategies:
-
Unit testing in the OO context:
-
Smallest testable unit is the encapsulated class or object
-
Similar to system testing of conventional software
-
Do not test operations in isolation from one another
-
Driven by class operations and state behavior, not algorithmic detail and data flow across module interface
-
Complete test coverage of a class involves
-
Design of test for a class uses a verity of methods:
-
fault-based testing
-
random testing
-
partition testing
-
each of these methods exercises the operations encapsulated by the class
-
test sequences are designed to ensure that relevant operations are exercised
-
state of the class (the values of its attributes) is examined to determine if errors exist
-
Integration testing in the OO context
-
focuses on groups of classes that collaborate or communicate in some manner
-
integration of operations one at a time into classes is often meaningless
-
thread-based testing (testing all classes required to respond to one system input or event)
-
use-based testing (begins by testing independent classes first and the dependent classes that make use of them)
-
cluster testing (groups of collaborating classes are tested for interaction errors)
-
regression testing is important as each thread, cluster, or subsystem is added to the system
-
Levels of integration are less distinct in object-oriented systems
-
Validation testing in the OO context
-
focuses on visible user actions and user recognizable outputs from the system
-
validation tests are based on the use-case scenarios, the object-behavior model, and the event flow diagram created in the OOA model
-
conventional black-box testing methods can be used to drive the validation tests
Q6(b). Write a short note on “OO testing strategies” and “OO test design issues”. (4)
Object-Oriented Testing Activities:
-
Review OOA and OOD models
-
Class testing after code is written
-
Integration testing within subsystems
-
Integration testing as subsystems are added to the system
-
Validation testing based on OOA use-cases
OO Test Design Issues:
-
White-box testing methods can be applied to testing the code used to implement class operations, but not much else
-
Black-box testing methods are appropriate for testing OO systems
-
Object-oriented programming brings additional testing concerns
-
classes may contain operations that are inherited from super classes
-
subclasses may contain operations that were redefined rather than inherited
-
all classes derived from an previously tested base class need to be thoroughly tested
Q7(a). Draw the sequence diagram of login page. (5)
Q 7(b). Draw the activity diagram of ATM Machine system (5)
UNIT-IV
Q8(a). What do you mean by class diagram? Where it is used and also discuss the steps to draw the class diagram with any one example. (7)
The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application.
The purpose of the class diagram is to model the static view of an application. The class diagrams are the only diagrams which can be directly mapped with object oriented languages and thus widely used at the time of construction.
How to draw Class Diagram:
Class diagrams are the most popular UML diagrams used for construction of software applications. So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will be considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application. So a collection of class diagrams represent the whole system.
The following points should be remembered while drawing a class diagram:
-
The name of the class diagram should be meaningful to describe the aspect of the system.
-
Each element and their relationships should be identified in advance.
-
Responsibility (attributes and methods) of each class should be clearly identified.
-
For each class minimum number of properties should be specified. Because unnecessary properties will make the diagram complicated.
-
Use notes when ever required to describe some aspect of the diagram. Because at the end of the drawing it should be understandable to the developer/coder.
-
Finally, before making the final version, the diagram should be drawn on plain paper and rework as many times as possible to make it correct.
Now the following diagram is an example of an Order System of an application. So it describes a particular aspect of the entire application.
-
First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have multiple orders.
-
We would keep Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder.
-
The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive ().
So the following class diagram has been drawn considering all the points mentioned above:
Where to use Class Diagrams:
Class diagram is a static diagram and it is used to model static view of a system. The static view describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams. Class diagrams are not only used to visualize the static view of the system but they are also used to construct the executable code for forward and reverse engineering of any system.
Generally UML diagrams are not directly mapped with any object oriented programming languages but the class diagram is an exception.
Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So from practical experience class diagram is generally used for construction purpose.
Q 8(b). Consider the application is assumed to be a web based application which is deployed in a clustered environment using server 1, server 2 and server 3. The user is connecting to the application using internet. The control is flowing from the caching server to the clustered environment. So draw the deployment diagram of order management system. (3)
Q 9(a). Discuss the 4+1 view architecture of UML (4)
Any real world system is used by different users. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewer’s perspective. The better we understand the better we make the system.
UML plays an important role in defining different perspectives of a system. These perspectives are:
-
Design
-
Implementation
-
Process
-
Deployment
And the centre is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with use case.
-
Design of a system consists of classes, interfaces and collaboration. UML provides class diagram, object diagram to support this.
-
Implementation defines the components assembled together to make a complete physical system. UML component diagram is used to support implementation perspective.
-
Process defines the flow of the system. So the same elements as used in Design are also used to support this perspective.
-
Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is used to support this perspective.
Q 9(b). Discuss different notation of UML diagram in detail. (6) Class Notation: UML class is represented by the diagram shown below. The diagram is divided into four parts. -
The top section is used to name the class.
-
The second one is used to show the attributes of the class.
-
The third section is used to describe the operations performed by the class.
-
The fourth section is optional to show any additional components.
Classes are used to represent objects. Objects can be anything having properties and responsibility.
Object Notation: The object is represented in the same way as the class. The only difference is the name which is underlined as shown below.
As object is the actual implementation of a class which is known as the instance of a class. So it has the same usage as the class.
Interface Notation: Interface is represented by a circle as shown below. It has a name which is generally written below the circle.
Interface is used to describe functionality without implementation. Interface is the just like a template where you define different functions not the implementation. When a class implements the interface it also implements the functionality as per the requirement.
Collaboration Notation: Collaboration is represented by a dotted eclipse as shown below. It has a name written inside the eclipse.
Collaboration represents responsibilities. Generally responsibilities are in a group.
Use case Notation: Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.
Use case is used to capture high level functionalities of a system.
Actor Notation: An actor can be defined as some internal or external entity that interacts with the system.
Actor is used in a use case diagram to describe the internal or external entities.
Initial State Notation: Initial state is defined to show the start of a process. This notation is used in almost all diagrams.
The usage of Initial State Notation is to show the starting point of a process.
Final State Notation: Final state is used to show the end of a process. This notation is also used in almost all diagrams to describe the end.
The usage of Final State Notation is to show the termination point of a process.
Active class Notation: Active class looks similar to a class with a solid border. Active class is generally used to describe concurrent behaviour of a system.
Active class is used to represent concurrency in a system.
Component Notation: A component in UML is shown as below with a name inside. Additional elements can be added wherever required.
Component is used to represent any part of a system for which UML diagrams are made.
Node Notation: A node in UML is represented by a square box as shown below with a name. A node represents a physical component of the system.
Node is used to represent physical part of a system like server, network etc.
Share with your friends: |
