INTRODUCTION TO OOAD & ArgoUML

What is OOAD ?
Object-oriented analysis and design (OOAD) is a software engineering approach that models a
system as a group of interacting objects. Each object represents some entity of interest in the
system being modeled, and is characterized by its class, its state (data elements), and its
behavior. There are a number of different notations for representing these models, such as the
Unified Modeling Language (UML).

Object-Oriented analysis
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Implementation
constraints are dealt during object-oriented design (OOD).

Object-oriented design
Object-oriented design (OOD) transforms the conceptual model produced in object-oriented
analysis to take account of the constraints imposed by the chosen architecture and any non-
functional – technological or environmental – constraints, such as transaction throughput,
response time, run-time platform, development environment, or programming language.

ArgoUML
ArgoUML is an UML diagramming application written in Java and released under the open
source Eclipse Public License. By virtue of being a Java application, it is available on any
platform supported by Java SE.
ArgoUML is different: i) it makes use of ideas from cognitive psychology, ii) it is based on open
standards; iii) it is 100% pure Java; and iv) it is an open source project.

CASE Tools
Computer-aided software engineering (CASE) is the scientific application of a set of tools which
is meant to result in high-quality, defect-free, and maintainable software products.
ArgoUML
ArgoUML is an open source Unified Modeling Language (UML) modeling tool that includes
support for all standard UML 1.4 diagrams. It runs on any Java platform and is available in ten
languages.

FEATURES
• Support open standards extensively: UML, XMI, SVG, OCL and others. •
100% Platform independent thanks to the exclusive use of Java
• Open Source, which allows extending or customizing.
• Cognitive features like
• reflection-in-action
• Design Critics
• Corrective Automations (partially implemented)
• "To Do" List
• User model (partially implemented)

Supported Diagrams by ArgoUML

• Use Case Diagrams

• Class Diagrams
• Behavior Diagrams
• State chart Diagrams – Activity Diagrams
• Interaction Diagrams
» Sequence Diagrams
» Collaboration Diagrams
• Implementation Diagrams
– Component Diagrams
– Deployment Diagrams

Use Case Diagrams

 Present a high-level view of system usage

 These diagrams show the functionality of a system or a class and how

the system interacts with the outside world.
  During analysis to capture the system
requirements and to understand how the system should
work.
During the design phase, use-case diagrams specify the behavior of the system as
implemented.

Class Diagram
 Helps you visualize the structural or static view of a system.

 Class diagrams show the relationships among class.

 Foundation for component and deployment diagrams.

Sequence Diagram
 Illustrates object interacts arranged in a time sequence

 This shows step-by-step what has to happen to accomplish something in the

use case and emphasize the sequence of events.

Collaboration Diagram
 Provides a view of the interactions or structured relationships between objects
in current model.
 Emphasizes relation between objects.

 Used as the primary vehicle to describe interactions that express decision

about system behavior.

State Chart Diagram

 To model the dynamic behaviors of individual classes or objects  Used to model

the discrete stages of an objects lifetime.

Activity Diagram

 Model the workflow of a business process and the sequence of activities in

a process.
 Similar to a flowchart, l a workflow from activity to activity or from activity to state.

 It is help to understand the overall process.

Component Diagram
A physical view of the current model and Show the organization and dependencies of
software components, including source code, binary code, and executable components
Deployment Diagram

 Each model contains a single deployment diagram that shows the mapping
of processes to hardware.

THE ArgoUML USER INTERFACE

Overview of the Window

The title bar of the window shows the following 4 parts of information,

separated from each other by a dash.

• The current filename.

• The name of the currently active diagram.

• The name “ArgoUML”.

• An asterisk (*). This item is only present if the current project file is “dirty”, i.e.
it is altered, but not yet saved. In other words, if the asterisk is absent, then the
current file has not been altered.

The window comprises four sub-windows or panes namely,

  The Explorer pane,
 The Editing pane
 The Details Pane and
 The To-Do Pane.

INTRODUCTION TO SELENIUM TESTING

TOOL

Introduction

• Selenium is a robust set of tools that supports rapid development of test

automation for web-based applications.
• Works anywhere JavaScript is supported
• Hooks for many other languages - Java, Ruby, Python
• Can simulate a user navigating through pages and then assert for specific marks
on the pages.
• Selenium IDE is a plug-in to Firefox to record and playback tests (like
WinRunner, QTP).

Selenium Components

• Selenium-IDE
• Selenium-RC (Remote Control)
• Selenium-Grid

Steps to start with Selenium!

1) Begin: write and run tests in Firefox.
Selenium IDE is a Firefox add-on that records clicks, typing, and other actions to make a
test, which you can play back in the browser.
2) Customize: your language, your browser.
Selenium Remote Control (RC) runs your tests in multiple browsers and platforms.
Tweak your tests in your preferred language.
3) Deploy: scale out, speed up
Selenium Grid extends Selenium RC to distribute your tests across multiple servers,
saving you time by running tests in parallel.
EX.NO:01 IDENTIFITION A SOFTWARE SYSTEM THAT NEEDS TO BE DEVELOPED.

DINESH.R-8285

PROBLEM STATEMENT

Online Quiz system is to be designed for the students of XYZ college of

Technology. The questions should be of objective type with multiple options. The

system should be able to handle errors such as 2 options for one answer. After

answering the questions in the preliminary round, the system verifies whether

the student has answered the minimum number of questions in each level. If not,

a message is displayed to make the student answer the required number of

questions within an allotted time. If the student qualifies the prelims

, he/she can proceed to the finals in the same way. At the end of the quiz the users’

score along with information whether he has been selected or not has to be

displayed. The quiz system has two levels of questions.

EX.NO:2 DOCUMENTION OF THE SOFTWARE REQUIREMENTS SPECIFICATION (SRS) FOR THE

IDENTIFIED SYSTEM. DINESH.R-8285

Software requirements specification is a blueprint for the development team, providing all the
information they need to build the tool according to your requirements. But it also should outline
your product’s purpose, describing what the application is supposed to do and how it should
perform.

An SRS can vary in format and length depending on how complex the project is and the selected
development methodology. However, there are essential elements every good SRS document
must contain:

 Purpose of the digital product is a clear and concise statement that defines the intent

of the solution. This statement should address your needs, outlining what the app will

achieve once completed.

 Description of the product provides a high-level overview of the future tool, including

intended users, the type of environment it will operate in, and any other relevant

information that could impact the Software developmemt process.

 Functionality of the product describes the features, capabilities, and limitations or

constraints that might affect the tool’s performance.

 Performance of the product should include requirements related to its

performance in a production environment: speed, efficiency, reliability, and

scalability.

 Non-functional requirements address such factors as security, compatibility, and

maintainability.
 External interfaces include information about how the application will interact

with other systems it must connect to. So, here communication protocols and data

formats are described. Also, it outlines details of the screen layout, logic interface,

hardware interface, and design.

 Design constraints or environmental limitations that may impact the

development process or the software’s functionality.

 Assumptions and dependencies note the presuppositions made during the SRS

document formulation and any external or third-party dependencies critical for project

planning and risk assessment.

 Quality attributes define the standards for usability, reliability, and accessibility you

expect in terms of the software’s quality.

 Security protocols explain the security requirements to protect the software

against unauthorized access and ensure data privacy.

 Acceptance criteria specify the must-do list for the software to be considered

finished and ready to go live, including all the tests the software needs to pass and the

goals it must achieve.

EX.NO:3 IDENTIFICATION THE USE CASES AND DEVELOP THE USE CASE MODEL.

DINESH.R-8285

Description:

Guideline: To Find Use Cases

Use cases are defined to satisfy the goals of the primary actors. Hence, the basic

procedure is:

Step 1: Choose the system boundary. Is it just a software application, the

hardware and application as a unit, that plus a person using it, or an entire

organization?

Step 2: Identify the primary actors those that have goals fulfilled through using

services of the system.

Step 3:Identify the goalsfor each primary actor.

For example, use this table to prepare actor goal list

Step 4: Define Use Cases

In general, define one use case for each user goal. Name the use case similar to the user
goal. Start the name of use cases with a verb.

A common exception to one use case per goal is to collapse CRUD (create,retrieve,
update, delete) separate goals into one CRUD use case, idiomatically called Manage <X>. For
example, the goals "edit user," "deleteuser," and so forth are all satisfied by the Manage Users
use case.
UML Notation:

Actor : An Actor, as mentioned, is a user of the system, and is depicted using a

stick figure. The role of the user is written beneath the icon. Actors are not

limited to humans.

Use Case: AUse Case is functionality provided by the system, typically described

as verb+object (e.g. Register Car, Delete User). Use Cases are depictedwith an

ellipse. The name of the use case is written within the ellipse.

Association: Associations are used to link Actors with Use Cases, and indicate

that an Actor participates in the Use Case in some form. Associations are

depicted by a line connecting the Actor and the Use Case.

Actor Association Use case

Use-case Diagram :Quize System

3.1 Use cases

Display Score

The system will consist of Login screen to authenticate the participants whose

information is updated in the database. On starting the quiz , timer is started to

maintain the timings. In Level 1 /Level 2 Questions with four options are

displayed sequentially .User select the answer and move to the next question .

Finally he/she selects the Submit answers which updates the marks and displays

the score to the participants. If he is playing Level 1 and qualified for level 2 ,

then next level questions are displayed otherwise Not Qualified Message is

displayed. Functional Requirements

3.1.1. Use Case: Login

Brief Description

The use case describes how a Participant logs into the Quiz System
3.1.2. Use Case: Play Level 1 /Level 2 ( provide the content same

as above

3.1.3. Use Case: Display Questions ( provide the content same as above)

3.1.4. Use Case: Submit Answers ( provide the content same as above)

3.1.5. Use Case: Qualify to Level 2 ( provide the content same as above)

3.1.6. Use Case: Display Score ( provide the content same as above)

3.2. Non-functional requirements

Non-functional requirements are often called qualities of a system. Other

terms for non-functional requirements are "constraints", "quality attributes",

"quality goals", "quality of service requirements" and "non-behavioral

requirements".
Non-functional requirements, can be divided into two main categories:

1) Execution qualities, such as security and usability, which are

observable at run time.

2) Evolution qualities, such as testability, maintainability, extensibility

and scalability, which are embodied in the static structure of the software system.

3.2.1. Functionality :Multiple users must be able to perform their work

concurrently. If the participant has completed 30 Minutes allotted for

him/her, he or she should be notified with the message “your time slot is

over”.

3.2.2. Usability:The desktop user-interface shall be Windows

95/98/2000/xp compliant.

3.2.3. Reliability:The System should function properly for allotted time

slot and produces score card with no more than 10% down time.

3.2.4. Performance

1. The System shall support up to 100 simultaneous users against the

central database at any given time and up to 100 simultaneous users

against the local servers at any one time.

2. The System must be able to complete 80% of all transactions within

2 minutes.
EX.NO:4 UML CLASS DIAGRAM DINESH.R-8285

Description

A class diagram in the Unified Modeling Language (UML) is a type of static

structure diagram that describes the structure of a system by showing the system's classes,
their attributes, and the relationships between the classes.

The class diagram is the main building block in object oriented modeling.They are
being used both for general conceptual modeling of the systematic of the application, and for
detailed modeling translating the models into programming code. The classes in a class
diagram represent both the main objects and or interactions in the application and the objects
to be programmed. In the class diagram these classes are represented with boxes which
contain

three parts

A class with three sections.

 The upper part holds the name of the class

 The middle part contains the attributes of the class
 The bottom part gives the methods or operations the class can take or

undertake In the system design of a system, a number of classes are identified and

grouped together in a class diagram which helps to determine the statically relations

between those objects. With detailed modeling, the classes of the conceptual

design are often split in a number of subclasses.

Class Diagram
EX.NO:5 UML INTERACTION DIAGRAM DINESH.R-8285

Description

Sequence diagrams document the interactions between classes to achieve a result, such
as a use case. Because UML is designed for object- oriented programming, these
communications between classes are known as messages.The Sequence diagram lists objects
horizontally, and time vertically, and models these messages over time.

Notation :In a Sequence diagram, classes and actors are listed as columns, with

vertical lifelines indicating the lifetime of the object over time.

Object :Objects are instances of classes, and are arranged horizontally. The

pictorial representation for an Object is a class (a rectangle) with the name

prefixed by the object name (optional) and a semi-colon. : Object1

Actor: Actors can also communicate with objects, so they too can be listed as a

column. An Actor is modeled using the ubiquitous symbol, the stick figure.

Lifeline: The Lifeline identifies the existence

of the object over time. The

notation for a Lifeline is a vertical dotted

line extending from an object.

Activation: Activations, modeled as rectangular boxes on the lifeline, indicate

when the object is performing an action.

Message

Messages, modeled as horizontal arrows between Activations, indicate the

communications between objects.

SEQUENCE DIAGRAM

COLLABORATION DIAGRAM
Ex No : 6 UML STATE CHART DIAGRAM AND ACTIVITY DIAGRAM

DINESH.R-8285

State Chart Diagram Description

UML preserves the general form of the traditional state diagrams. The UML

state diagrams are directed graphs in which nodes denote states and connectors

denote state transitions. For example, Figure 1 shows a UML state diagram

corresponding to the computer keyboard state machine. In UML, states are

represented as rounded rectangles labeled with state names. The transitions,

represented as arrows, are labeled with the triggering events followed optionally

by the list of executed actions. The initial transition originates from the solid

circle and specifies the default state when the systemfirst begins. Every state

diagram should have such a transition, which should not be labeled, since it is

not triggered by an event. The initial transition can have associated actions.

The main purposes of using Statechart diagrams:

 To model dynamic aspect of a system.

 To model life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model states of an object

Steps to prepare state chart diagram

 Identify important objects to be analyzed.

 Identify the states.
 Identify the events.

State Notation:
State Chart Diagram

Activity Diagram Description

Activity diagrams are used to document workflows in a system, from the

business level down to the operational level. Activity diagram is a variation ofthe

state diagram where the "states" represent operations, and the transitions

represent the activities that happen when the operation is complete. The general

purpose of Activity diagrams is to focus on flows driven by internal processing

vs. external events.

Activity States
Activity states mark an action by an object. The notations for these states

are rounded rectangles, the same notation as found in State chart diagrams.

Transition: When an Activity State is completed, processing moves to

another Activity State. Transitions are used to mark this movement.

Transitions are modeled using arrows.

Swim lane: Swim lanes divide activities according to objects by arranging objects

in column format and placing activities by that object within that column. Objects

are listed at the top of the column, and vertical bars separatethe columns to

form the swim lanes.

Initial State: The Initial State marks the entry point and the initial Activity

State. The notation for the Initial State is the same as in State chart diagrams,

a solid circle. There can only be one Initial State on a diagram.

Final State: Final States mark the end of the modeled workflow. There can be multiple Final
States, and these are modeled using a solid circle surrounded by another circle.
Synchronization Bar: Activities often can be done in parallel. To split processing ("fork"), or
to resume processing when multiple activities have been completed ("join"), Synchronization
Bars are used. These are modeled as solid rectangles, with multiple transitions going in and/or
out.

Activity diagram : Quiz System

Participant Quiz System Database

EX.NO:7 IMPLEMENTATION THE SYSTEM AS PER THE DETAILED DESIGN
DINESH.R-8285
Logical Architecture and Layers
• Logical architecture: the large-scale organization of software classes
into packages, subsystems, and layers.

– “Logical” because no decisions about deployment are implied.

• Layer: a very coarse-grained grouping of classes, packages,
or subsystems Typical layers in an OO system:
• Application-independent, reusable across systems.
• Relationships between layers:
• Strict layered architecture: a layer only calls upon services of the
layer directly below it.
• Relaxed layered architecture: a higher layer calls upon several
lower layers.

Layersshown with UML package diagram.

Various UML notations for package nesting

Package Diagram : Quiz System
EX.NO:8 TESTING OF THE SOFTWARE SYSTEM FOR ALL THE SCENARIOS IDENTIFIED

DINESH.R-8285

Description:

In a quiz system we perform the following

1) Student registration

2) Quiz Participation

3) Result Processing

1) Student Registration

The inputs to the quiz system initially is the student details for the quiz which

involves the following details like

1) name

2) year

3) branch

4) college name

When a student enters these details it will be updated in a database. After that

the student will be allowed to participate.

2) Quiz Participation

When the participant begins to answer the questions, a clock is maintained to

keep track of the time.

The correct answers for the questions are stored in a separate database .After

answering the questions in the preliminary round, the system verifies whether the

student has answered the minimum number of questions in each level. If not, a

message is displayed to make the student answer the required number of questions

within an allotted time.

If the student qualifies the prelims, he/she can proceed to the finals in the

same way.

3) Result Processing

After all the students have participated in the quiz, the system processes the

marks scored by all the students. The system sorts the marks and generates

a final output, which displays the name and scores

SOFTWARE DEVELOPMENT AND

TESTING TECHNICAL SERVICES LAYER

Table Structure:

Student Registration
UI LAYER AND DOMAIN LAYER

Testing UI Layer & Domain

Layer Test case Template

Test case Id : Screen001

Product : Quiz System

Module : Enter Student details

Form 1: Student Registration.

EX.NO:9 IMPROVEMENT OF THE REUSABILITY AND MAINTAINABILITY OF
THE SOFTWARE SYSTEM BY APPLYING APPROPRIATE DESIGN PATTERNS.

DINESH.R-8285

1. Creational Patterns:

Singleton Pattern:

- Use the Singleton pattern to ensure that only one instance of a class exists
throughout the application.

- This can be useful for managing resources that should be shared across the
system, such as database connections or configuration settings.

Factory Method Pattern:

- Implement the Factory Method pattern to delegate the responsibility of

object instantiation to subclasses.

- This promotes loose coupling by allowing the creation of objects without

specifying their exact class.

2. Structural Patterns:

Adapter Pattern:

- Apply the Adapter pattern to allow incompatible interfaces to work together.

- This is useful when integrating existing components or libraries into the system
without modifying their interfaces.

Decorator Pattern:

- Use the Decorator pattern to add additional functionalities to objects dynamically.

- This promotes code reusability by allowing behaviors to be added or removed

without altering the original class.
3. Behavioral Patterns:

Observer Pattern:

- Implement the Observer pattern to establish a one-to-many dependency

between objects.

- This enables objects to automatically notify their observers about changes in

state, promoting loose coupling and reusability.

Strategy Pattern:

- Apply the Strategy pattern to define a family of algorithms, encapsulate each one,
and make them interchangeable.

- This allows algorithms to vary independently from clients that use them,
enhancing maintainability and flexibility.

4. Architectural Patterns:

Model-View-Controller (MVC):

- Adopt the MVC pattern to separate the presentation, business logic, and data layers
of the application.

- This enhances maintainability by isolating changes in one layer from affecting

the others.

Layered Architecture:

- Implement a layered architecture, such as Presentation, Business Logic, and

Data Access layers, to organize the system's components hierarchically.

- This promotes reusability by defining clear boundaries between different

functional areas of the application.
EX.NO:10 IMPLEMENTATION THE MODIFIED SYSTEM AND TEST IT FOR VARIOUS SCENARIOS.

DINESH.R-8285

Implementation:

1. Review Design Changes:

 Ensure that the design patterns identified for improving reusability

and maintainability have been properly implemented.

 Double-check that the changes align with the system's requirements

and architectural principles.

2. Code Refactoring:

 Refactor existing code to incorporate the new design patterns.

 Follow best practices for clean code, such as meaningful naming

conventions, proper code organization, and eliminating code smells.

3. Unit Testing:

 Write unit tests for individual components to validate their functionality

in isolation.

 Test edge cases, boundary conditions, and error scenarios to ensure robustness.

4. Integration Testing:

 Test the interaction between different modules or components to verify that

they work together as expected.

 Test data flow and communication channels between components.

5. System Testing:

 Conduct end-to-end testing to evaluate the system's behavior as a whole.

 Test various user scenarios to ensure that the system meets

functional requirements and user expectations.
Testing for Various Scenarios:

1. Normal Usage Scenario:

 Test the system's functionality under typical usage patterns to ensure that
it performs as expected.

2. Boundary Conditions:

 Test the system's behavior at the limits of its capabilities, such as maximum
input sizes or resource constraints.

3. Error Handling:

 Test how the system responds to invalid input, unexpected errors, or

exceptional conditions.

 Verify that appropriate error messages are displayed, and the system
gracefully handles failures.

4. Concurrency and Multi-user Scenarios:

 Test the system's behavior when multiple users access it simultaneously.

 Assess concurrency control mechanisms and transaction handling to ensure

data integrity.

5. Security Testing:

 Evaluate the system's security features, such as authentication,

authorization, and data encryption.

 Conduct penetration testing to identify potential vulnerabilities and

mitigate security risks.

6. User Acceptance Testing (UAT):

 Involve stakeholders or end-users in testing the system to validate its

compliance with their requirements and expectations.

 Gather feedback and incorporate any necessary changes before finalizing

the system for deployment.