OOSE Based Application Developmet

Dr. MRUDULA OWK

Assistant Professor
Department of Computer Science and Engineering
GITAM Institute of Technology
GITAM University
 The objectives of the course
1.Understand software engineering concepts a long with their
applicability contexts.

2.Given a problem, identify domain objects, their properties and

relationships among them.

3. Identify and model/represent domain constraints on the objects and (or)

on their relationships

4. Develop design solutions for problems on various O-O concepts

5.Learn various modelling techniques to model different perspectives of

object-oriented software design (UML)
2
 COURSE OUTCOMES

1. Describe the OOAD paradigm (Unified Processes)

2. Employ the UML diagramming standards.
3. Demonstrate the use of a software tool to support the
planning, analysis and design phases
4. Use a case tool for all UML diagrams.
5. Develop prototypes of the system design, code, and Testing

3
 SYLLABUS

Module I: Introduction to Software Engineering

Introduction: Review of Software life cycle stages, Software Processes. Introduction to OOAD,
comparison with Functional approach to software development.
Overview of UML: Use Case Diagrams, Class Diagrams, Interaction Diagrams, State Machine
Diagrams, Activity Diagrams.
Modelling Concepts: Systems, Models, and Views. Data Types - Abstract Data Types, Instances.
Classes - Abstract Classes, Objects, Event Classes,, Messages. Objects, Oriented Modelling-
Falsification and PrototypingEvents
Learning Outcomes:
• After completion of this unit, the student will be able to:
• 1. Understands the basics of software engineering(L1)
• 2. Familiarize with usage of UML(L2)
• 3. Illustrate modelling concepts(L2)
4
 Software Engineering
• It is a Systematic approach to develop a software.
• In this process we analyzing the user needs and Designing and
Constructing and Testing the end user Applications/Sofware.

• The software is a collection of integrated programs and carefully-

organized instructions and code written by developers on any of various
particular computer languages.

• Engineering is the application of scientific and practical knowledge to

invent, design, build, maintain, and improve frameworks, processes,
etc.

• Software Engineering is an engineering branch related to the evolution of

software product using well-defined scientific principles, techniques,
and procedures.
 Software Engineering:
Definition
• Software Engineering is a layered technology.

• Software Engineering is a collection of techniques,methodologies

and tools that help with the production of

• a high quality software system

• with a given budget
• before a given deadline
while change occurs.

20
 What is Software Engineering?
• The IEEE Computer Society defines software
engineering as:

– The application of a systematic, disciplined,

quantifiable approach to software development,
operation, and maintenance; that is, the application of
engineering to software.
Software life cycle stages:
 Review of Software life cycle stages:
1.Requirements Analysis:
• Understand and document the requirements of the software.
Activities:
Gather and analyze requirements from stakeholders.
Define system functionalities and constraints.
Document user expectations and system specifications.
Deliverables: Requirements document.
2. System Design:
Create a blueprint for the software based on the gathered requirements.
Activities:
Design the overall architecture of the system.
Define data structures, software modules, and interfaces.
Create detailed specifications for components.
Deliverables: System architecture, design specifications.
There are two diagrams 1.ER Diagrams(Structural Programming Languages )
2.UML Diagrams(Object Oriented Programming Languages )
3.Implementation (Coding):
Translate the design into actual code.
Activities:
Write code based on the design specifications.
Conduct unit testing to ensure individual components work correctly.
Integrate components into a complete system.
Deliverables: Executable code.
4.Testing:
Verify that the software meets the specified requirements.
Activities:
Conduct various testing levels (unit, integration, system, acceptance).
Identify and fix defects.
Validate that the software meets user expectations.
Deliverables: Test plans, test cases, defect reports.
5.Deployment (Installation):
Release the software for actual use.
Activities:
Plan and execute the installation of the software.
Train end-users and support personnel.
Monitor and troubleshoot any issues during initial use.
• Deliverables: Deployed software, user manuals.
6.Maintenance and Support:
Address issues, improve functionality, and ensure the software's continued usability.
Activities:
Fix defects and address user-reported issues.
Enhance features or add new features based on user feedback.
Update documentation.

Deliverables: Software updates, documentation updates.

SOFTWARE PROCESS
 SOFTWARE PROCESS

A process is a collection of activities, actions and tasks that are performed when
some work product is to be created.

• A GENERIC PROCESS FRAMEWORK (elements of a software process):

five activities:

•Communication
–Involves communication among the customer and other stake holders;
requirements gathering.

•Planning
–Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule.
 Modelling (Analyze, Design)
• Creation of models to better
under the requirements and the
design.

Construction (Code, Test):

• –Combines code generation
and testing to uncover errors.

Deployment:
• –Involves delivery of software
to the customer for evaluation
and feedback.
 The umbrella activities in a software development life cycle
processinclude the following:

1.Software project tracking and control: Compare the progress of the project with
the plan.
2.Formal technical reviews: This includes reviewing the techniques that have been
used in the project.
3.Software quality assurance: This is very important to ensure the quality
measurement of each part to ensure them.
4.Software configurationmanagement:
managing different versions of these work products.
5.Document preparation and production:
All the project planning and other activities should be hardly copied and the
production gets started here.
6.Re-usability management:
This includes the backing up of each part of the software project

7.Risk management:
Risk management is a series of steps that help a software team
to understand and manage uncertainty.
Object-Oriented Analysis and
Design (OOAD):
Benefits and uses of Object oriented concepts
 Comparison with Functional approach to
Software development.

Function Oriented Design (FOD):

• In FOD, the primary focus is on functions or procedures that manipulate data.

• The system is divided into functions, and data is shared among these functions.

Object Oriented Design (OOD):

• OOD is centered around objects, which encapsulate data and the functions that
operate on that data.
• Objects are instances of classes, which define the properties (attributes) and
behaviors (methods) shared by the objects
comparison with Functional approach to software
development .
 Overview of UML
• Unified Modeling Language (UML) is a standardized modeling
language used in software engineering to visually represent a
system's design.

• UML provides a set of graphical notations and diagrams that help

developers, analysts, and stakeholders to communicate and
understand the architecture, structure, behavior, and functionality of
a system.

• It was developed by the Object Management Group (OMG) and

has become a widely adopted standard in the field of software
development.
 Use Case Diagrams
• Use case diagrams represent the functionality of the system from a user’s point of
view. They define the boundaries of the system.
¨ Use Case Diagrams Use cases and actors Actors are external entities that interact
with the system.
Elements:
Actor:
• Represents an external entity that interacts with the system.
• Can be a user, another system, or any external element.
• Shown as stick figures or blocks outside the system boundary.
Use Case:
• Represents a specific functionality or behavior of the system.
• Describes a set of interactions between the system and external entities (actors).
• Shown as ovals inside the system boundary.
System Boundary:
• Represents the boundary of the system being modeled.
• Contains actors and use cases.
Association:

• Represents a relationship between an actor and a use case.

• Indicates that the actor is involved in the described functionality.

Include Relationship:

• Describes the inclusion of one use case by another.

• Represents the fact that the behavior of the included use case is
incorporated into the behavior of the base use case.

Extend Relationship:

• Describes optional or exceptional behavior that can extend the behavior

of a base use case.
Example:
Consider a simple library management system:
 Class Diagrams

• Class Diagrams Classes and objects Class diagrams describe the

structure of the system in terms of classes and objects.
• Classes are abstractions that specify the attributes and behavior of
a set of objects.
• A class is a collection of objects that share a set of attributes that
distinguish the objects as members of the collection.
• Objects are entities that encapsulate state and behavior. Each
object has an identity: it can be referred individually and is
distinguishable from other objects.
Example
 Interaction Diagrams
• Interaction diagrams are models that describe how a group of
objects collaborate in some behavior - typically a single use-case.

• Interaction Diagram are used in UML to establish communication

between objects

Notation of an Interaction Diagram

Following are the different types of interaction diagrams
defined in UML:
• Sequence diagram
• Collaboration diagram
 Sequence diagram example

The following sequence diagram example represents ordering system:

 The ordered sequence of events in a given sequence
diagram is as follows:

1.Place an order.
2.Pay money to the cash counter.
3.Order Confirmation.
4.Order preparation.
5.Order serving.
Collaboration Diagram:
Collaboration Diagram depicts the relationships and interactions
among software objects. They are used to understand the object
architecture within a system rather than the flow of a message as in a
sequence diagram. They are also known as “Communication
Diagrams.”
 Collaboration diagram Example

Following diagram represents the sequencing over student management system:

 State Machine Diagrams
• State machine diagram typically are used to describe state-dependent behavior
for an object.
• An object responds differently to the same event depending on what state it is
in. State machine diagrams are usually applied to objects but can be applied to
any element that has behavior to other entities such as: actors, use cases,
methods, subsystems systems and etc. and they are typically used in
conjunction with interaction diagrams (usually sequence diagrams).
For example:
• Consider you have $100,000 in a bank account. The behavior of the withdraw
function would be: balance := balance - withdrawAmount; provided that the
balance after the withdrawal is not less than $0; this is true regardless of how
many times you have withdrawn money from the bank. In such situations, the
withdrawals do not affect the abstraction of the attribute values, and hence the
gross behavior of the object remains unchanged.
 Activity Diagrams
• An activity diagram is a type of Unified Modeling Language (UML) flowchart
that shows the flow from one activity to another in a system or process.

• It's used to describe the different dynamic aspects of a system and is referred to
as a 'behavior diagram' because it describes what should happen in the modeled
system.
Activity Diagrams
PART -II
 Modelling Concepts
Systems

A system is an organized set of communicating parts and a collection

of elements or components that work together to achieve a
common set of objectives.
• A system can refer to a software application, and it includes
components like databases, user interfaces, and other modules.
• Parts of a system can in turn be considered as simpler systems
called subsystems and described by a set of models.
• when each piece is simple enough that we can fully comprehend it
without further decomposition.
 Models

• Many systems are made of numerous subsystems

interconnected in complicated ways, often so complex that no
single developer can manage its entirety.
• Modeling is a means for dealing with this complexity, described
by more than one model, each focusing on a different aspect or
level of accuracy.
• Modeling - is a simplified representation or constructing an
abstraction of a system that focuses on interesting aspects and
ignores irrelevant details, and system to facilitate understanding,
analysis, and decision-making.
• Models can be graphical representations or mathematical
abstractions of a software system.
• Modeling allows us to deal with complexity through a divide-and-
conquer approach:
 For each type of problem we want to solve,
 we build a model that only focuses on the issues relevant to the
problem.
• We first build a model of the environment and functionality that the
system must provide, at a level that is understandable by the client.
• Refine model, adding more details about the forms that the system
should display, the layout of the user interface, and the response of
the system to exceptional cases.
• The set of all models built during development is called the system
model.
View:
• A view is a projection of a system’s model from a
specific perspective to make it understandable.
• Views are different perspectives or representations of
a system or a model.
• They help stakeholders understand specific aspects
of a system based on their roles or interests.
• Views may overlap, notations are graphical or textual
rules for representing views.
• A UML class diagram is a graphical view of the object
model.
• A line between two rectangles represents a relationship
between the two corresponding classes. Different notations
can be used to represent the same view.
 Data Types, Abstract Data Types, and Instances

DataTypes:
• A data type is an abstraction that define the kind of data that a
variable can hold in the context of a programming language. A
data type has a unique name that distinguishes it from other
data types.
• Examples include integers, floats, strings, and custom data
types.
• It denotes a set of values, defines the structure and the
operations valid in all instances of the data type.
• Data types are used in typed languages to ensure that only
valid operations are applied to specific instances.
Abstract Datatype (ADT):
• An abstract data type is a data type defined by an
implementation-independent specification, enable developers to
reason about a set of instances without looking at a specific
implementation of the abstract data type.

• A developer using a set only needs to understand its semantics

and need not be aware of the internal representation of the set.

• The fact that the social security number of the person is stored
as a number or as a string is not visible to the rest of the system.
Such decisions are called implementation decisions.
• ADTs are high-level descriptions of data types that specify
operations but not the implementation details.
Instances:
• Instances are individual occurrences of a class in object-
oriented programming.
• For example, if "Car" is a class, a specific car object is an
instance of that class.
 Classes, Abstract Classes, and
Classes: Objects
• A class is an abstraction in object-oriented modeling and in object-
oriented programming languages.
• Like abstract data types, a class encapsulates both structure and
behavior.
• Classes are blueprints or templates for creating objects in object-
oriented programming.
• They define the properties (attributes) and behaviors (methods) that
objects of the class will have.
• Classes can be defined in terms of other classes by using
inheritance.
Superclass / Parent Class:
• A superclass is a class that is extended or inherited by one or
more subclasses. It provides a common set of attributes and
methods that can be reused by its subclasses.

Subclass / Child Class:

• A subclass is a class that inherits from a superclass. It can reuse
the attributes and methods of the superclass and may also have
its own additional attributes and methods.
Example1: Vehicle is the superclass with a brand attribute and start
and stop methods.
‘Car’ is a subclass of Vehicle. It inherits the brand attribute and the
start and stop methods from the Vehicle superclass, and it adds its
own numDoors attribute, overrides the start method, and introduces
a new honk method.
Example2: we have a watch that also can function as a calculator.
 The class CalculatorWatch can then be seen as a refinement of the
class Watch.
 This type of relationship between a base class and a refined class is
called inheritance.
 The generalization class (e.g., Watch) is called the superclass, the
specialized class (e.g., CalculatorWatch) is called the subclass.
 In an inheritance relationship, the subclass refines the superclass by
defining new attributes and operations.
 CalculatorWatch defines functionality for performing simple
arithmetic that regular Watches do not have.
 Superclass and subclass are relative terms. The same class can be a
subclass with respect to one class and a superclass with respect to
another class.
Abstract Classes:

• Abstract classes cannot be instantiated and may contain abstract

methods (methods without implementation).
• They serve as a blueprint for other classes and are meant to be sub
classed.
• Inheritance relationship serves only to model shared attributes and
operations, i.e, if the generalization is not meant to be instantiated,
the resulting class is called an abstract class.
• Abstract classes often represent generalized concepts in the
application domain, and their names are italicized.
• Aabstract classes - do not correspond to an existing
application domain concept, but rather are introduced to
reduce complexity in the model or to promote reuse.
• A class defines the operations that can be applied to its
instances. Operations of a superclass can be inherited and
applied to the objects of the subclass.
Example: SetDate(), setting the current date of a Watch, is
also applicable to CalculatorWatches. The operation
EnterCalcMode(), however, defined in the CalculatorWatch
class, is not applicable in the Watch class.
• A class defines the attributes that apply to all its instances. An
attribute is a named slot in the instance where a value is
stored.
• Attributes have a unique name within the class and the type.
Watches have a time and a date attribute.
• CalculatorWatches have a calculatorState attribute.
• An object is an instance of a class. An object has an identity
and stores attribute values. Each object belongs to exactly
one class.
• In UML, an instance is depicted by a rectangle with its name
underlined.
• Simplewatch is an instance of Watch, and calculatorWatch is
an instance of CalculatorWatch.
• The operations of Watch are applicable to calculatorWatch,
calculatorWatch is not an instance of the class Watch.
 Event Classes, Events, and
Messages
• In event-driven programming, an event class defines a
type of event, and events are instances of these
classes.
• Events can trigger specific actions or reactions in a
program.
• Event classes are abstractions representing a kind of
event for which the system has a common response.
An event, an instance of an event class, is a relevant
occurrence in the system.
 An event object contains whatever properties are
pertinent to the event.

 You can identify the source object of the event using

the getSource() instance method in the EventObject
class.

 The subclasses of EventObject deal with special types

of events, such as button actions, window events,
component events, mouse movements, and
keystrokes
Object oriented modeling
• Falsification: Proving an existing model to be false,
thereby producing a better model.

• Prototyping: Creating a quick and simple version of

a product to be built, for the purposes of evaluation
(and falsification).
THANK YOU