UNIT-4

Software testing
Software testing is an investigation conducted to provide stakeholders with information about the quality of the
product or service under test. Software testing can also provide an objective, independent view of the software to allow
the business to appreciate and understand the risks of software implementation. Test techniques include, but are not
limited to, the process of executing a program or application with the intent of finding software bugs (errors or other
defects).
It involves the execution of a software component or system to evaluate one or more properties of interest. In general,
these properties indicate the extent to which the component or system under test:
 meets the requirements that guided its design and development,
 responds correctly to all kinds of inputs,
 performs its functions within an acceptable time,
 is sufficiently usable,
 can be installed and run in its intended environments, and
 Achieves the general result its stakeholders desire.
Fundamental principles in testing
Five fundamental test activities and tasks
Software testing is a process. The fundamental test process consists of five important parts that encompass all aspects
of testing:
1. Planning and control
2. Analysis and design
3. Implementation and execution
4. Test closure activities
1. Planning and control activities:
Test Planning activity is determine what is going to be tested, and how this will be achieved.
At this stage, we plan and decide on how activities will be done and who will do them. Here, we also define the test
completion criteria.
Test Control activity is what we do when the activities do not match up with the plans. It is the ongoing activity where
we compare the progress against the plan. As progress takes place, we may need to adjust plans to meet the targets, if
this is possible.
Therefore, we need to undertake both planning and control tasks throughout the testing activities.
We plan at the outset, but as testing progresses, we undertake monitoring and control activities. We monitor to
measure what has happened; we control to adjust future activities in the light of experience. Monitoring and control
feedback into the continual activity of planning.
2. Analysis and Design activities:
Analysis and design are concerned with the fine detail of what to test (test conditions), and how to combine test
conditions into test cases, so that a small number of test cases can cover as many of the test conditions as possible. The
analysis and design stage is the bridge between planning and test execution.
The design process needs to consider the test data that will be required for the test conditions and test cases that have
been drawn up. Test design involves predicting how the software under test should behave in a given set of
circumstances. We must design test cases in such a way that we cover all necessary conditions in detail
3. Important points of this activity:
 Reviewing requirements, architecture, design, interface specifications and other parts, which collectively
comprise the test basis.
 Analysing test items, the specification, behaviour, and structure to identify test conditions and test data
required.
 Desinging the tests, including assigning priority.
 Determining whether the requiremnts and the system are testable.
 Detailing what the test environment should look like, and whether there are any infrastructure and tools
required.
 Highlighting the test data required for the test conditions and test cases.
 Creating bi-directional traceability between test basis and test cases.
4. Test Closure Activities:
Psychological factors of software testing
Psychological factors can influence the success of software testing.
The total testing effort may involve a effort from a variety of different people drawn from a broad set of backgrounds
(development, user-experience, etc.) and skills (acceptance testing, performance testing, etc.). To make an effective
 contribution to the overall testing effort, at least some understanding of the skills and techniques of software testing is
required.
Always remember that, testing of software can be more effective if it is not undertaken by the individual (s) who wrote
the code (because a creator of anything has a special relationship with the created object that is flaws in the created
object are rendered invisible to the creator).
Therefore, it is important that someone other than the creator should test the object. Of course, developers who build
components or a system can debug and even attempt to test it, but such testing done by the developers cannot be
assumed to be complete.
Developers can test their own code, but it requires a mindset change, from that of a developer (to prove it works) to
that of a tester (trying to show that it does not work). Hence, software must be tested by someone who was not
involved in the creation of the software; this approach is called Test Independence.
List of people who could test software in the order of increasing test independent:
 Those who wrote the code (developers)
 Members of the same development team
 Members of a different group (independent test team)
 Members of a different company (a testing consultancy/outsourced)
Remember, it is much more expensive to use a testing consultancy than to test a program oneself.
Testing Fundamentals
The entire site is dedicated to the basics of software testing. However, you need to first master the basics of the
basics before you begin. We strongly recommend you to go through the following fundamental articles if you are just
starting the journey into the world of software testing.
 Software Quality: Software quality is the degree of conformance to explicit or implicit requirements
and expectations.
 Dimensions of Quality: Software quality has dimensions such as Accessibility, Compatibility,
Concurrency, Efficiency …
 Software Quality Assurance: Software Quality Assurance is a set of activities for ensuring quality in
software engineering processes.
 Software Quality Control: Software Quality Control is a set of activities for ensuring quality in
software products.
 SQA and SQC Differences: SQA is process-focused and prevention-oriented but SQC is product-
focused and detection-oriented.
 Software Development Life Cycle: Software Development Life Cycle defines the steps/stages/phases
in the building of software.
 Definition of Test: Merriam Webster defines Test as “a critical examination, observation, or
evaluation”.
Once you are clear on these basic terms and concepts, you are ready to move ahead and start conquering the software
testing world.
Functional testing Functional testing is a quality assurance (QA) process[1] and a type of black box testing that
bases its test cases on the specifications of the software component under test. Functions are tested by feeding them
input and examining the output, and internal program structure is rarely considered (not like in white-box
testing).[2] Functional Testing usually describes whatthe system does.
Functional testing differs from system testing in that functional testing "verifies a program by checking it against ...
design document(s) or specification(s)", while system testing "validate[s] a program by checking it against the
published user or system requirements"
Black Box Testing
The technique of testing without having any knowledge of the interior workings of the application is Black Box
testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, when
performing a black box test, a tester will interact with the system's user interface by providing inputs and examining
outputs without knowing how and where the inputs are worked upon.
Advantages Disadvantages
  Limited Coverage since only a
 Well suited and efficient for large code selected number of test scenarios are
segments. actually performed.
 Code Access not required.  Inefficient testing, due to the
 Clearly separates user's perspective from the fact that the tester only has limited
developer's perspective through visibly defined roles. knowledge about an application.
 Large numbers of moderately skilled testers  Blind Coverage, since the tester
can test the application with no knowledge of cannot target specific code segments or
implementation, programming language or operating error prone areas.
systems.  The test cases are difficult to
design.

Structural testing Structural testing is the type of testing carried out to test the structure of code. It is also known
as White Box testing or Glass Box testing. This type of testing requires knowledge of the code, so, it is mostly done by
the developers. It is more concerned with how system does it rather than the functionality of the system. It provides
more coverage to the testing. For ex, to test certain error message in an application, we need to test the trigger
condition for it, but there must be many trigger for it. It is possible to miss out one while testing the requirements
drafted in SRS. But using this testing, the trigger is most likely to be covered since structural testing aims to cover all
the nodes and paths in the structure of code.
It is complementary to Functional Testing. Using this technique the test cases drafted according to system
requirements can be first analyzed and then more test cases can be added to increase the coverage. It can be used on
different levels such as unit testing, component testing, integration testing, functional testing etc. Its helps in
performing a thorough testing on software. The structural testing is mostly automated.
White Box Testing
White box testing is the detailed investigation of internal logic and structure of the code. White box testing is also
called glass testing or open box testing. In order to perform white box testing on an application, the tester needs to
possess knowledge of the internal working of the code.
The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving
inappropriately.
Advantages Disadvantages

 As the tester has knowledge of the source code,


it becomes very easy to find out which type of data can Due to the fact that a skilled tester is needed to
help in testing the application effectively. perform white box testing, the costs are increased.

 It helps in optimizing the code.  Sometimes it is impossible to look into every nook
and corner to find out hidden errors that may create
 Extra lines of code can be removed which can problems as many paths will go untested.
bring in hidden defects.
 It is difficult to maintain white box testing as the
 Due to the tester's knowledge about the code, use of specialized tools like code analyzers and debugging
maximum coverage is attained during test scenario tools are requir
writing.

Functional Testing
This is a type of black box testing that is based on the specifications of the software that is to be tested. The application
is tested by providing input and then the results are examined that need to conform to the functionality it was intended
for. Functional Testing of the software is conducted on a complete, integrated system to evaluate the system's
compliance with its specified requirements.
ALPHA TESTING
This test is the first stage of testing and will be performed amongst the teams (developer and QA teams). Unit testing,
integration testing and system testing when combined are known as alpha testing. During this phase, the following will
be tested in the application:
 Spelling Mistakes
 Broken Links
 Cloudy Directions
 The Application will be tested on machines with the lowest specification to test loading times and any latency
problems.
BETA TESTING
This test is performed after Alpha testing has been successfully performed. In beta testing a sample of the intended
audience tests the application. Beta testing is also known as pre-release testing. Beta test versions of software are
ideally distributed to a wide audience on the Web, partly to give the program a "real-world" test and partly to provide a
preview of the next release. In this phase the audience will be testing the following:
 Users will install, run the application and send their feedback to the project team.
 Typographical errors, confusing application flow, and even crashes.
 Getting the feedback, the project team can fix the problems before releasing the software to the actual users.
 The more issues you fix that solve real user problems, the higher the quality of your application will be.
 Having a higher-quality application when you release to the general public will increase customer satisfaction.
Difference between alpha testing and beta testing.

 In IT, alpha testing is commonly defined as a form of internal testing that happens while a product is still being
developed, albeit at the end of that process. Beta testing, on the other hand, is a type of testing that delivers a new
product to a new user base, often customers or a public user audience, in an attempt to elicit feedback on the product
and catch any remaining issues.
 The idea behind beta testing, and what separates it fundamentally from alpha testing, is the idea that when a
program gets released to a “public” or end-user audience, it gets tested differently – not by the standards and
viewpoints of internal teams, but from an end-user standpoint. There is the assumption that in beta, users will be
testing in a more “real-world” way – for instance, that while internal alpha testers may be looking at code and
underlying design, beta testers will be primarily testing through use, and that therefore, they will find different bugs
and issues.
 There are many different types of alpha testing, where engineers or others “put the finishing touches” on
software, and there are many kinds of beta testing as well. Beta tests differ according to the chosen user set, their
focus, and their overall response. Experts often point out that it makes a big difference what tools users have to report
problems, and how they are recruited. Some industry insiders complain that many beta testing processes do not offer
tools for feedback, so that they seem to be built as a formality and not to add value. Another big issue is whether agile
development precludes the necessity of beta testing – many argue that even though new development processes have
emerged, beta testing should still happen, not just to help find problems, but to introduce a product to an audience in an
incremental way.
 In the end, beta testing and how it is done has much to do with whoever is handling the development process.
The same cannot be said for alpha testing, which is still internal and housed under a conventional engineering
workflow. That said, there is an element of beta testing that is more “PR” or consumer-facing than exclusively focused
on testing criteria. This can be seen in the gaming world, where a “beta phase” may function as a way to let audiences
play around with game mechanics, get used to characters and preview other features.
Comparison Testing – Comparing the Software with Other Products
In simple words, comparison testing is a type of testing, where testers compare a software product’s strengths and
weaknesses with other software that are currently available in the market. Comparison test is a very good indicator of
how competitive and useful the software product will be to the end users soon after its commercial release.
In fact, comparison test will let you know whether the software project is marketable or not. You can perform
comparison testing to ensure that the software has a fair chance to be profitable; good software will provide an
innovative competitive advantage over other software products.
Advantages of Comparison Testing
Comparison tests are the most useful tests that one can conduct to compare a particular software product with another
one that is selling in the market today. It is very important that software developers look at the external environment, to
find out whether their products and services can compete with other products or not. This opinion holds well in case of
a software test too. The main goal of creating software product is to ensure its eventual profitability. Ultimately,
customer will decide whether they will want to purchase the product or not.
By using comparison test, you can easily determine the perceived weakness and strengths of the software. This will
also help you know all the important features of the product that need check before its commercial release to the
market. Comparison testing will also help you understand the design structure of competing products and you can use
them as a reliable benchmark for making future improvements and enhancements. Comparison testing is a useful
process designed to make the product competitive enough to perform well in the market.
 Disadvantages of Comparison Testing
The practical advantages of conducting comparison test are undeniable. However, some significant pitfalls make
comparison testing process somewhat difficult to operate. Competitors and end users will come to know about any
deficiencies or weakness of your product and this can work against it. It is very difficult to introduce any changes or
modifications, as the software product would have passed through a majority of developmental stages right before the
test. If the product lacks some important features at the testing phase then introducing additional features becomes very
difficult and tedious. It is always risky to modify a software product in smaller increments, as it may affect the
functionality of the entire product. Hence, conducting all other tests like the black box testing, the white box testing,
and integration testing makes sense.
Testing Object Oriented Programs
Once a program code is written, it must be tested to detect and subsequently handle all errors in it. A number of
schemes are used for testing purposes.
Another important aspect is the fitness of purpose of a program that ascertains whether the program serves the purpose
which it aims for. The fitness defines the software quality.

Testing Object-Oriented Systems

Testing is a continuous activity during software development. In object-oriented systems, testing encompasses three
levels, namely, unit testing, subsystem testing, and system testing.
 Whenever large scale systems are designed, object oriented testing is done rather than the conventional testing
strategies as the concepts of object oriented programming is way different from that of conventional ones.
 The whole object oriented testing revolves around the fundamental entity known as “class”.
 With the help of “class” concept, larger systems can be divided into small well defined units which may then
be implemented separately.
 The object oriented testing can be classified as like conventional systems. These are called as the levels for
testing.
1. Class Testing
 Class testing is also known as unit testing.
 In class testing, every individual classes are tested for errors or bugs.
 Class testing ensures that the attributes of class are implemented as per the design and specifications. Also, it
checks whether the interfaces and methods are error free of not.
2. Inter-Class Testing
 It is also called as integration or subsystem testing.
 Inter class testing involves the testing of modules or sub-systems and their coordination with other modules.
3. System Testing
 In system testing, the system is tested as whole and primarily functional testing techniques are used to test the
system. Non-functional requirements like performance, reliability, usability and test-ability are also tested.
Level of Testing
A level of software testing is a process where every unit or component of a software/system is tested. The main goal of
system testing is to evaluate the system's compliance with the specified needs.
There are many different testing levels which help to check behavior and performance for software testing. These
testing levels are designed to recognize missing areas and reconciliation between the development lifecycle states. In
SDLC models there are characterized phases such as requirement gathering, analysis, design, coding or execution,
testing, and deployment.
All these phases go through the process of software testing levels. There are mainly four testing levels are:
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
1) Unit testing:
A Unit is a smallest testable portion of system or application which can be compiled, liked, loaded, and executed. This
kind of testing helps to test each module separately.
The aim is to test each part of the software by separating it. It checks that component are fulfilling functionalities or
not. This kind of testing is performed by developers.
2) Integration testing:
Integration means combining. For Example, In this testing phase, different software modules are combined and tested
as a group to make sure that integrated system is ready for system testing.
Integrating testing checks the data flow from one module to other modules. This kind of testing is performed by
testers.
3) System testing:
System testing is performed on a complete, integrated system. It allows checking system's compliance as per the
requirements. It tests the overall interaction of components. It involves load, performance, reliability and security
testing.
System testing most often the final test to verify that the system meets the specification. It evaluates both functional
and non-functional need for the testing.
4) Acceptance testing:
Acceptance testing is a test conducted to find if the requirements of a specification or contract are met as per its
delivery. Acceptance testing is basically done by the user or customer. However, other stockholders can be involved in
this process.
 CASE tools
CASE stands for Computer Aided Software Engineering. It means, development and maintenance of
software projects with help of various automated software tools.
CASE tools are set of software application programs, which are used to automate SDLC activities. CASE
tools are used by software project managers, analysts and engineers to develop software system.
There are number of CASE tools available to simplify various stages of Software Development Life Cycle
such as Analysis tools, Design tools, Project management tools, Database Management tools, Documentation
tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and helps to uncover
flaws before moving ahead with next stage in software development.
Central Repository - CASE tools require a central repository, which can serve as a source of common,
integrated and consistent information. Central repository is a central place of storage where product
specifications, requirement documents, related reports and diagrams, other useful information regarding
management is stored. Central repository also serves as data dictionary.
 Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of SDLC.
 Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from
Requirement gathering to Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process activities and capability of
getting integrated with other tools.

CBSE
Component-based software engineering (CBSE), also called components-based development (CBD), is
a branch of software engineering that emphasizes the separation of concerns with respect to the wide-ranging
functionality available throughout a given software system. It is a reuse-based approach to defining,
implementing and composing loosely coupled independent components into systems. This practice aims to
bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the
software itself and for organizations that sponsor such software.
Software engineering practitioners regard components as part of the starting platform for service-orientation.
Components play this role, for example, in web services, and more recently, in service-oriented
architectures (SOA), whereby a component is converted by the web service into a service and subsequently
inherits further characteristics beyond that of an ordinary component.
Components can produce or consume events and can be used for event-driven architectures (EDA).
 UNIT 5
An overview of UML
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software
systems.
UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the
OMG in January 1997.
OMG is continuously making efforts to create a truly industry standard.
 UML stands for Unified Modeling Language.
 UML is different from the other common programming languages such as C++, Java, COBOL, etc.
 UML is a pictorial language used to make software blueprints.
 UML can be described as a general purpose visual modeling language to visualize, specify, construct, and
document software system.
 Although UML is generally used to model software systems, it is not limited within this boundary. It is also
used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.
UML is not a programming language but tools can be used to generate code in various languages using UML
diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has
become an OMG standard.
UML notations
UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying, constructing and
documenting the components of software and non-software systems. Hence, visualization is the most important part
which needs to be understood and remembered.
UML notations are the most important elements in modeling. Efficient and appropriate use of notations is very
important for making a complete and meaningful model. The model is useless, unless its purpose is depicted properly.
Hence, learning notations should be emphasized from the very beginning. Different notations are available for things
and relationships. UML diagrams are made using the notations of things and relationships. Extensibility is another
important feature which makes UML more powerful and flexible.
Structural Things
Graphical notations used in structural things are most widely used in UML. These are considered as the
nouns of UML models. Following are the list of structural things.
 Classes
 Object
 Interface
 Collaboration
 Use case
 Active classes
 Components
 Nodes
 Class Notation
UML class is represented by the following figure. 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 in the following figure.

As the object is an actual implementation of a class, which is known as the instance of a class. Hence, it has
the same usage as the class.
Interface Notation
Interface is represented by a circle as shown in the following figure. It has a name which is generally written
below the circle.

Interface is used to describe the functionality without implementation. Interface is 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 requirement.
Collaboration Notation
Collaboration is represented by a dotted eclipse as shown in the following figure. 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.

An 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 the
concurrent behavior of a system.

Active class is used to represent the concurrency in a system.

Component Notation
A component in UML is shown in the following figure 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 in the following figure with a name. A node
represents the physical component of the system.

Node is used to represent the physical part of a system such as the server, network, etc.
Behavioral Things
Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to
represent the dynamic part of software and non-software systems. These features
include interactions and state machines.
Interactions can be of two types −
 Sequential (Represented by sequence diagram)
 Collaborative (Represented by collaboration diagram)

Interaction Notation
Interaction is basically a message exchange between two UML components. The following diagram
represents different notations used in an interaction.

Interaction is used to represent the communication among the components of a system.

State Machine Notation
State machine describes the different states of a component in its life cycle. The notations are described in
the following diagram.

State machine is used to describe different states of a system component. The state can be active, idle, or any
other depending upon the situation.
Grouping Things
Organizing the UML models is one of the most important aspects of the design. In UML, there is only one
element available for grouping and that is package.
Package Notation
Package notation is shown in the following figure and is used to wrap the components of a system.
 Annotational Things
In any diagram, explanation of different elements and their functionalities are very important. Hence, UML
has notes notation to support this requirement.
Note Notation
This notation is shown in the following figure. These notations are used to provide necessary information of
a system.

Relationships
A model is not complete unless the relationships between elements are described properly.
The Relationship gives a proper meaning to a UML model. Following are the different types of relationships
available in UML.
 Dependency
 Association
 Generalization
 Extensibility

Dependency Notation
Dependency is an important aspect in UML elements. It describes the dependent elements and the direction
of dependency.
Dependency is represented by a dotted arrow as shown in the following figure. The arrow head represents
the independent element and the other end represents the dependent element.

Dependency is used to represent the dependency between two elements of a system

Association Notation
Association describes how the elements in a UML diagram are associated. In simple words, it describes how
many elements are taking part in an interaction.
Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two
associated elements as shown in the following figure. The multiplicity is also mentioned at the ends (1, *,
etc.) to show how many objects are associated.

Association is used to represent the relationship between two elements of a system.

Generalization Notation
Generalization describes the inheritance relationship of the object-oriented world. It is a parent and child
relationship.
Generalization is represented by an arrow with a hollow arrow head as shown in the following figure. One
end represents the parent element and the other end represents the child element.
Generalization is used to describe parent-child relationship of two elements of a system.
Extensibility Notation
All the languages (programming or modeling) have some mechanism to extend its capabilities such as
syntax, semantics, etc. UML also has the following mechanisms to provide extensibility features.
 Stereotypes (Represents new elements)
 Tagged values (Represents new attributes)
 Constraints (Represents the boundaries)

Extensibility notations are used to enhance the power of the language. It is basically additional elements used
to represent some extra behavior of the system. These extra behaviors are not covered by the standard
available notations.
 UML Class diagrams
Class diagrams are the main building blocks of every object oriented methods. The class diagram can be used to show
the classes, relationships, interface, association, and collaboration. UML is standardized in class diagrams. Since
classes are the building block of an application that is based on OOPs, so as the class diagram has appropriate structure
to represent the classes, inheritance, relationships, and everything that OOPs have in its context. It describes various
kinds of objects and the static relationship in between them.
The main purpose to use class diagrams are:
 This is the only UML which can appropriately depict various aspects of OOPs concept.
 Proper design and analysis of application can be faster and efficient.
 It is base for deployment and component diagram.
There are several software available which can be used online and offline to draw these diagrams Like Edraw max,
lucid chart etc. There are several points to be kept in focus while drawing the class diagram. These can be said as its
syntax:
 Each class is represented by a rectangle having a subdivision of three compartments name, attributes and
operation.
 There are three types of modifiers which are used to decide the visibility of attributes and operations.
 + is used for public visibility(for everyone)
 # is used for protected visibility (for friend and derived)
 – is used for private visibility (for only me)
Below is the example of Animal class (parent) having two child class as dog and cat both have object d1, c1 inheriting
properties of the parent class.

import java.io.*;
class GFG {
public static void main(String[] args)
{
dog d1 = new dog();
d1.bark();
d1.run();
cat c1 = new cat();
c1.meww();
}
}
class Animal {
public void run()
{
String name;
String colour;
System.out.println("animal is running");
}
}
class dog extends Animal {
public void bark()
{
System.out.println("wooh!wooh! dog is barking");
}
public void run()
{
System.out.println("dog is running");
}
}
 class cat extends Animal {
public void meww()
{
System.out.println("meww! meww!");
}
}
What is Class?
A Class is a blueprint that is used to create Object. The Class defines what object can do.
What is Class Diagram?
Class Diagram gives the static view of an application. A class diagram describes the types of objects in the system and
the different types of relationships that exist among them. This modeling method can run with almost all Object-
Oriented Methods. A class can refer to another class. A class can have its objects or may inherit from other classes.
UML Class Diagram gives an overview of a software system by displaying classes, attributes, operations, and their
relationships. This Diagram includes the class name, attributes, and operation in separate designated compartments.
Class Diagram helps construct the code for the software application development.
Benefits of Class Diagram
 Class Diagram Illustrates data models for even very complex information systems
 It provides an overview of how the application is structured before studying the actual code. This can easily
reduce the maintenance time
 It helps for better understanding of general schematics of an application.
 Allows drawing detailed charts which highlights code required to be programmed
 Helpful for developers and other stakeholders.
Essential elements of A UML class diagram
Essential elements of UML class diagram are:
1. Class Name
2. Attributes
3. Operations

Class Name
The name of the class is only needed in the graphical representation of the class. It appears in the topmost
compartment. A class is the blueprint of an object which can share the same relationships, attributes, operations, &
semantics. The class is rendered as a rectangle, including its name, attributes, and operations in sperate compartments.
Following rules must be taken care of while representing a class:
1. A class name should always start with a capital letter.
2. A class name should always be in the center of the first compartment.
3. A class name should always be written in bold format.
4. An abstract class name should be written in italics format.
Attributes:
An attribute is named property of a class which describes the object being modeled. In the class diagram, this
component is placed just below the name-compartment.
A derived attribute is computed from other attributes. For example, an age of the student can be easily computed from

his/her birth date.

Association
Association is a relationship between classifiers which is used to show that instances of classifiers
could be either linked to each other or combined logically or physically into some aggregation.
UML specification categorizes association as semantic relationship. Some other UML sources also
categorize association as a structural relationship. Wikipedia states that association is instance
level relationship and that associations can only be shown on class diagrams. Not sure where they got
that information from but it is not based on UML specification. Association could be used on different
types of UML structure diagrams:
Association

OR
If two classes in a model need to communicate with each other, there must be a link between them,
and that can be represented by an association (connector).
Association can be represented by a line between these classes with an arrow indicating the
navigation direction. In case an arrow is on both sides, the association is known as a bidirectional
association.
We can indicate the multiplicity of an association by adding multiplicity adornments to the line
denoting the association. The example indicates that a Student has one or more Instructors:
A single student can associate with multiple teachers:
Aggregation
In UML models, an aggregation relationship shows a classifier as a part of or subordinate to another
classifier.
An aggregation is a special type of association in which objects are assembled or configured together to
create a more complex object. An aggregation describes a group of objects and how you interact with them.
Aggregation protects the integrity of an assembly of objects by defining a single point of control, called the
aggregate, in the object that represents the assembly. Aggregation also uses the control object to decide how
the assembled objects respond to changes or instructions that might affect the collection.
Data flows from the whole classifier, or aggregate, to the part. A part classifier can belong to more than one
aggregate classifier and it can exist independently of the aggregate. For example, a Department class can
have an aggregation relationship with a Company class, which indicates that the department is part of the
company. Aggregations are closely related to compositions.
You can name an association to describe the nature of the relationship between two classifiers; however,
names are unnecessary if you use association end names.
As the following figure illustrates, an aggregation association appears as a solid line with an unfilled
diamond at the association end, which is connected to the classifier that represents the aggregate.
Aggregation relationships do not have to be unidirectional.
 Interfaces
In UML modeling, interfaces are model elements that define sets of operations that other model elements,
such as classes, or components must implement. An implementing model element realizes an interface by
overriding each of the operations that the interface declares.
You can use interfaces in class diagrams and component diagrams to specify a contract between the interface
and the classifier that realizes the interface. Each interface specifies a well-defined set of operations that have
public visibility. The operation signatures tell the implementing classifiers what kind of behavior to invoke,
but not how they should invoke that behavior. Many classifiers can implement a single interface, each one
providing a unique implementation.
Interfaces support the hiding of information and protect client code by publicly declaring certain behavior or
services. Classes or components that realize the interfaces by implementing this behavior simplify the
development of applications because developers who write client code need to know only about the
interfaces, not about the details of the implementation. If you replace classes, or components that implement
interfaces, in your model, you do not need to redesign your application if the new model elements implement
the same interfaces.
You can specify the following types of interfaces:
 Provided interfaces: these interfaces describe the services that instances of a classifier (supplier) offer
to their clients
 Required interfaces: these interfaces specify the services that a classifier needs to perform its
functions and to fulfill its own obligations to its clients
An interface typically has a name that reflects the role that it plays in an application. A common convention
is to prefix the name of the interface with a forward slash to indicate that a model element is an interface.
As the following figures illustrate, the diagram editor displays an interface in the following ways:
 Class rectangle symbol that contains the keyword «interface». This notation is also called the internal
or class view.