OOSE Unit-1

CSEN2091
OOSE Based Application

Development
DR. GANESHKUMAR N, DEPT. OF CSE 1
Course Introduction
 Object Oriented Software Engineering course builds on Object-Modelling concepts.
 Object Oriented analysis and design methodology is introduced and is compared
with function oriented design approach.
 In this course students learn to model analysis and design using UML in the context
of an iterative, use case-driven, architecture-centric process. A case tool for
development of UML diagrams is introduced.
 Design Patterns are discussed for development standardization.
 The course takes the student through Unified Software Development Process using
Object Oriented methodologies.

Course Objectives
 Develop models using UML Notation
 Analyse Requirements with Use cases
 Relate Analysis to Design
 Design Solutions with patterns and architectural layers
 Apply concepts to semester long software project

Syllabus
UNIT 1 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, Events, Messages. Object- Oriented Modelling- Falsification and Prototyping
UNIT 2 UML & Analysis
A Deeper View into UML: Static Modelling, Dynamic Modelling, Logical Architecture. Dynamic Modelling: Use Case Diagrams,
Class Diagrams, Interaction Diagrams, State Machine Diagrams, Activity Diagrams, Diagram Organization, Diagram Extensions.
Analysis Concepts: Object Models and Dynamic Models. Entity, Boundary, Control Objects. Generalization and Specialization
Analysis Activities: Requirements Model: From Use Cases to Objects Identifying Entity Objects, Boundary Objects, Control Object.
Mapping Use Cases to Objects with Sequence Diagrams, Modelling Interactions among Objects with CRC Cards. Identifying
Associations, Aggregates, Attributes, Modelling State- Dependent Behaviour of Individual Objects, Modelling Inheritance
Relationships between Objects. Reviewing the Analysis Model, Analysis Summary
Syllabus
UNIT 3 System Design and Static Modelling
System Design: Decomposing the System. System Design Concepts: Subsystems and Classes, Services and Subsystem Interfaces,
Coupling and Cohesion, Layers and Partitions, Architectural Styles. System Design Activities: From Objects to Subsystems, Analysis
Model for a Route Planning System, Identifying Design Goals, Identifying Subsystems. Static Modelling: Package Diagrams, Composite
Structures, Component Diagrams, Deployment Diagrams. System Design Activities: Addressing Design Goals: Mapping Subsystems to
Processors and Components, Identifying and Storing Persistent Data, Providing Access Control, Designing the Global Control Flow,
Identifying Services, Boundary Conditions, Reviewing System Design
UNIT 4 Object Design
Object Design: Design Patterns, Reusing Pattern Solutions. Reuse Concepts. Reuse Activities: Selecting Design Patterns and Components,
Encapsulating Data Stores with the Bridge Pattern, Encapsulating Legacy Components with the Adapter Pattern, Encapsulating Context
with the Strategy Pattern, Encapsulating Platforms with the Abstract Factory Pattern, Encapsulating Control Flow with the Command
Pattern, Encapsulating Hierarchies with the Composite Design Pattern, Heuristics for Selecting Design Patterns, Identifying and Adjusting
Application Frameworks Object Design: Specifying Interfaces. Interface Specification Concepts: Class Implementer, Class Extender, Class
User, Types, Signatures, Visibility. Contracts: Invariants, Preconditions, Post conditions, Object Constraint Language. OCL Collections :
Sets, Bags, and Sequences. OCL Quantifiers: for All and exists
Syllabus
UNIT 5 Implementation: Coding & Testing
Mapping Models to Code. Mapping Concepts: Model Transformation, Refactoring, Forward Engineering, Reverse Engineering,
Transformation Principles. Mapping Activities : Optimizing the Object Design Model, Mapping Associations to Collections,
Mapping Contracts to Exceptions, Mapping Object Models to a Persistent Storage Schema. Testing: An Overview of Testing.
Testing Concepts: Faults, Erroneous States, and Failures, Test Cases, Test Stubs and Drivers, Corrections. Testing Activities:
Component Inspection, Usability Testing, Unit Testing, Integration Testing, System Testing. Managing Testing: Planning Testing
activities, Documenting Testing, Assigning Responsibilities, Regression Testing, Automating Testing. Documenting Architecture:
Architectural views: logical, deployment, security, data, behavioural.

Course outcomes
After successful completion of the course the student will be able to:
 Describe the OOAD paradigm (Unified Processes)
 Employ the UML diagramming standards.
 Demonstrate use of a software tool to support the planning, analysis and design phases
 Use a case tool for all UML diagrams.
 Develop prototypes of the system design, code, and Testing

Course material and References
Text Books(s)
T1: Bernd Bruegge and Allen H. Dutoit, Object-Oriented Software Engineering Using UML,
Patterns, and Java, Prentice-Hall.
T2: Michael R. Blaha and James R Rumbaugh, Object-Oriented Modelling and Design with
UML, Prentice Hall
T3: Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and the Unified Process, Prentice-Hall.

Introduction
Definition of Software
 Software is more than just a program code.
 Software is considered to be collection of executable programming code,
associated libraries and documentations. Software, when made for a specific
requirement is called software product.
Definition of Engineering
 Process of solving the problems by applying the knowledge of science and math.
 Engineering is a process of designing and building something that serves a
particular purpose and find a cost effective solution to a problem.

Introduction
Definition of “Software Engineering
 The IEEE definition: “The application of systematic,

disciplined, quantifiable approach to the development,
operation, and maintenance of software product”.

Review of Software life cycle stages
 Software Development life cycle: series of steps /
phases, through which software is produced
 Goals of each phase:

 mark out a clear set of steps to perform
 produce a tangible item
 allow for review of work
 specify actions to perform in the next phase

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 (SRS).

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 Processes
 Software process: organized set of activities aimed at building a software system
 Software process model: an abstract representation of a software process
 Fundamental software process activities:
 Software specification
 Software design and implementation
 Software validation
 Software evolution

Generic software process models
 The waterfall model
 Separate and distinct phases of specification and development
 Evolutionary / Incremental development
 Specification and development are interleaved
 Spiral Model
 Agile Model
 V Model
 RAD Model
 Reuse-based development
 The system is assembled from existing components

The waterfall model
This model takes the fundamental process activities
of specification, development, validation, and
evolution and represents them as separate process
phases such as requirements specification, software
design, implementation, testing, and so on.
Main characteristics:
 Also called classic software life cycle or sequential
model
 Process activities (phases/stages) are clearly
separated
 After a number of iterations, phases of the life
cycle (such as specification and design) are “frozen”

The waterfall model
Advantages:
 Organized approach, provides robust separation of phases
 Reflects common engineering practice
Disadvantages:
 Doesn’t cope well with changes required by the client
 Development teams might wait for each other
 A working version of the product is available only late
Applicability:
 When requirements are well known and few changes are likely to be needed
 Can be used also for parts of larger software systems
Incremental development model
 The system is developed as a series of
versions (increments), with each version
adding functionality to the previous version.
Main characteristics:
 The phases of the software construction are
interleaved
 Feedback from the user is used throughout
the entire process
 The software product is refined through
many versions

Incremental development model
Advantages:
 Deals constantly with changes
 Provides quickly an initial version of the system
 Involves all development teams
Disadvantages:
 Quick fixes may be involved
 “Invisible” process, not well-supported by documentation
 The system’s structure can be corrupted by continuous change
 Special tools and techniques may be necessary
Applicability:
 When requirements are not well understood
 When the client and the developer agree on a “rapid prototype” that will be thrown away
 Good for small and medium-sized software systems
Reuse-oriented Development model
 This approach is based on the existence of a significant number of reusable components.
 The system development process focuses on integrating these components into a system
rather than developing them from scratch.

Reuse-oriented Development model
Advantages:
 Reduces considerably the software to be developed “in-house”
 Allows faster delivery
 In principle, more reliable systems, due to using previously tested components
Disadvantages:
 Compromises in requirements are needed
 Less control over the system’s evolution
Applicability:
 When there is a pool of existing components that could satisfy the requirements of the
new product
Spiral Model
 Spiral Model is a SDLC model which is highly used for
risk-driven models. Based on the risk patterns of a
given project, the spiral model helps developers to
increase the efficiency of the model as most risks are
already handled. It consists of a number of loops
which are forming a spiral shape where each loop is
called the phase of the software development cycle.
 The Spiral model is mostly used in large projects.
 The spiral model was defined by Barry Boehm in his
article “A Spiral Model of Software Development and
Enhancement” (1985).
 The spiral model is an evolutionary version of
incremental prototyping.
Spiral Model
Each phase of the Spiral Model is divided into four quadrants and its functions are:
 Objectives determination and identify alternative solutions: Requirements are gathered
from the customers and the objectives are identified, elaborated, and analyzed at the start of
every phase. Then alternative solutions possible for the phase are proposed in this quadrant.
 Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution are
identified and the risks are resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.
 Develop the next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next version
of the software is available.
 Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-
far developed version of the software. In the end, planning for the next phase is started.
Spiral Model
Advantages
 Spiral Life Cycle Model is a very flexible model. Development phases can be determined by the project
manager, according to the complexity of the project.
 Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses because important issues are
discovered earlier.
 Good for large and mission-critical projects.
 The software is produced early in the software lifecycle.
Disadvantages
 Doesn’t work well for smaller projects.
 Evaluating the risks involved in the project can shoot up the cost and it may be higher than the cost of
building the system.
 The spiral model is much customized for every project.
 Risk analysis requires highly specific expertise.
RAD (Rapid Application Development) Model
 RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element-based construction approach. If the requirements are
well understood and described, and the project scope is a constraint, the RAD process
enables a development team to create a fully functional system within a concise time
period.
 RAD (Rapid Application Development) is a concept that products can be developed faster
and of higher quality through:
 Gathering requirements using workshops or focus groups
 Prototyping and early, reiterative user testing of designs
 The re-use of software components
 A rigidly paced schedule that refers design improvements to the next product version
 Less formality in reviews and other team communication

 Business Modelling: The information flow
among business functions is defined by
answering questions like what data drives the
business process, what data is generated, who
generates it, where does the information go,
who process it and so on.
 Data Modelling: The data collected from
business modeling is refined into a set of data
objects (entities) that are needed to support
the business. The attributes (character of each
entity) are identified, and the relation between
these data objects (entities) is defined.

 Process Modelling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a data
object.
 Application Generation: Automated tools are used to facilitate construction of the

software.
 Testing & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall testing time. But the new part must be
tested, and all interfaces must be fully exercised.

Advantages
 This model is flexible for change.
 In this model, changes are adoptable.
 Each phase in RAD brings highest priority functionality to the customer.
 It reduced development time.
 It increases the reusability of features.
Disadvantages
 It required highly skilled designers.
 All application is not compatible with RAD.
 For smaller projects, we cannot use the RAD model.
 On the high technical risk, it's not suitable.
 Required user involvement.
V-Model
 The V-model is a type of SDLC model where the process executes
sequentially in a V-shape. It is also known as the Verification and
Validation model. It is based on the association of a testing phase for
each corresponding development stage.
 The development of each step is directly associated with the testing
phase. The next phase starts only after completion of the previous
phase i.e., for each development activity, there is a testing activity
corresponding to it.
 Verification: It involves a static analysis method (review) done
without executing code. It is the process of evaluation of the product
development process to find whether specified requirements meet.
 Validation: It involves dynamic analysis method (functional, non-
functional), testing is done by executing code. Validation is the
process to classify the software after the completion of the
development process to determine whether the software meets the
customer expectations and requirements.

V-Model
Various phases of Verification Phase of V-model:
 Business requirement analysis: This is the first step where product requirements understood from the
customer's side. This phase contains detailed communication to understand customer's expectations and exact
requirements.
 System Design: In this stage system engineers analyze and interpret the business of the proposed system by
studying the user requirements document.
 Architecture Design: The baseline in selecting the architecture is that it should understand all which typically
consists of the list of modules, brief functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology detail, etc. The integration testing model is carried out in a
particular phase.
 Module Design: In the module design phase, the system breaks down into small modules. The detailed design of
the modules is specified, which is known as Low-Level Design
 Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable programming
language is decided. There are some guidelines and standards for coding. Before checking in the repository, the
final build is optimized for better performance, and the code goes through many code reviews to check the
performance.
V-Model
Various phases of Validation Phase of V-model:
 Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase.
These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity
which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity can
function correctly when isolated from the rest of the codes/ units.
 Integration Testing: Integration Test Plans are developed during the Architectural Design Phase. These
tests verify that groups created and tested independently can coexist and communicate among
themselves.
 System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and
Integration Test Plans, System Tests Plans are composed by the client?s business team. System Test
ensures that expectations from an application developer are met.
 Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It includes
testing the software product in user atmosphere. Acceptance tests reveal the compatibility problems
with the different systems, which is available within the user atmosphere. It conjointly discovers the
non-functional problems like load and performance defects within the real user atmosphere.
V-Model
Advantages
 Easy to Understand.
 Testing Methods like planning, test designing happens well before coding.
 This saves a lot of time. Hence a higher chance of success over the waterfall model.
 Avoids the downward flow of the defects.
 Works well for small plans where requirements are easily understood.
Disadvantages
 Very rigid and least flexible.
 Not a good for a complex project.
 Software is developed during the implementation stage, so no early prototypes of the software are produced.
 If any changes happen in the midway, then the test documents along with the required documents, has to be
updated.

Agile Model
 The Agile Software Development Life Cycle (SDLC) is an iterative and incremental software
development methodology that prioritizes flexibility, collaboration, and customer feedback.
 Unlike traditional SDLC models, such as the waterfall model, which completes each step
sequentially, the agile SDLC divides the development process into smaller iterations or
increments.
 The major factors of agile are:
 Early customer involvement
 Iterative development
 Self-organizing teams
 Adaptation to change

Agile Model
Phases of Agile Model:
 Requirement Gathering: In requirement Gathering
collaboration takes place with stakeholders to understand
and prioritize needs for the project, that focus on delivering
value. In this step, techniques like user stories and workshops
for effective communication.
 Design the Requirements: In this step the gathered

requirements are translated into actionable tasks, breaking
them down into smaller, manageable chunks. In this step,
developers develop visual representations of the solution,
such as wireframes or prototypes, to get early feedback and
ensure alignment with stakeholder expectations.
Agile Model
 Coding: During this step, the development team implements the software in short, iterative cycles known as sprints.
Each sprint focuses on delivering small, functional increments of the product. Developers write code, continuously
integrate it into the main codebase, and regularly commit changes to detect and address issues early.
 Testing / Quality Assurance: Testing is an integral part of each iteration, ensuring the quality and functionality of the
software. Unit tests are written to verify individual components, while integration tests check that different parts of
the system work together as intended. User Acceptance Testing (UAT) involves end-users testing the software in real-
world scenarios to ensure it meets their needs.
 Deployment: Deployment involves releasing the software increments to production frequently and reliably.
Automated deployment tools makes the process, allowing for quick and consistent releases. Monitoring the
deployment process and system performance helps identify and resolve any issues promptly.
 Feedback: Feedback is crucial for continuous improvement in Agile. Stakeholders and end-users provide feedback
through surveys, direct communication, and usage analytics. This feedback is used to refine requirements, prioritize
changes, and identify areas for improvement.

Agile Model
Advantages
 Frequent Delivery
 Face-to-Face Communication with clients.
 Efficient design and fulfils the business requirement.
 Anytime changes are acceptable.
 It reduces total development time.
Disadvantages
 Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
 Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.
Object-Oriented Analysis and Design (OOAD)
 Object-Oriented Analysis and Design (OOAD) is a systematic methodology for analyzing,
modeling, and designing software systems based on the principles of the Object-Oriented
Paradigm.
 It focuses on representing a system as a collection of interacting objects, each encapsulating
data and behavior, and emphasizes concepts such as classes, inheritance, encapsulation, and
polymorphism.
Components:
 Objects: Instances of classes that encapsulate both data (attributes) and behavior (methods).
 Classes: Blueprints or templates defining the structure and behavior of objects.
 Encapsulation: The bundling of data and methods within a class to promote information hiding
and reduce complexity.
Object-Oriented Analysis and Design (OOAD)
 Inheritance: The mechanism that allows a class to inherit properties and behaviors from another class,
promoting code reuse and hierarchy.
 Polymorphism: The ability of objects of different classes to be treated as objects of a common base class,
supporting flexibility and adaptability.
 Abstraction: Simplifying complex systems by focusing on essential characteristics while ignoring unnecessary
details.
 Use Case Modeling: Identifying and defining interactions between users (actors) and the system to capture
functional requirements.
 Unified Modeling Language (UML): A standardized visual modeling language providing diagrams to represent
various aspects of a system's architecture and behavior.
 Object-Oriented Analysis (OOA): Defining requirements and constraints for the system based on the
identification and analysis of objects.
 Object-Oriented Design (OOD): Translating requirements into a design plan encompassing classes,
relationships, and interactions.
Comparison with Functional approach to software development

Benefits and uses of Object oriented concepts

COMPARISON FUNCTION ORIENTED DESIGN OBJECT ORIENTED DESIGN
FACTORS
The basic abstractions, which are given to the user, are real world The basic abstractions are not the real world functions but are the data
Abstraction
functions. abstraction where the real world entities are represented.
Functions are grouped together by which a higher level function is Function are grouped together on the basis of the data they operate
Function
obtained. since the classes are associated with their methods.
carried out using structured analysis and structured design i.e, data
execute Carried out using UML
flow diagram
In this approach the state information is not represented in a

State In this approach the state information is often represented in a
centralized memory but is implemented or distributed among the
information centralized shared memory.
objects of the system.
Approach It is a top down approach. It is a bottom up approach.
Begins basis Begins by considering the use case diagrams and the scenarios. Begins by identifying objects and classes.
In function oriented design we decompose in function/procedure
Decompose We decompose in class level.
level.
This approach is mainly used for evolving system which mimics a
Use This approach is mainly used for computation sensitive application.
business or business case.

An Overview of UML
 UML stands for Unified Modeling Language, is a standardized general-purpose visual modeling
language in the field of Software Engineering used for specifying, visualizing, constructing, and
documenting the primary artifacts of the software system
 UML is a notation that resulted from the unification of OMT-Object Modeling Technique and
OOSE-Object-Oriented Software Engineering.
 UML provides a set of graphical notations and diagrams that help developers, analysts, and
stakeholders to communicate and understand the 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.

System development focuses on three different models of the system:
 The functional model, represented in UML with use case diagrams, describes the functionality of the system from the
user’s point of view.
 The object model, represented in UML with class diagrams, describes the structure of the system in terms of objects,
attributes, associations, and operations.
 The dynamic model, represented in UML with interaction diagrams, state machine diagrams, and activity diagrams,
describes the internal behavior of the system.
 Interaction diagrams describe behavior as a sequence of messages exchanged among a set of objects, whereas state
machine diagrams describe behavior in terms of states of an individual object and the possible transitions between
states.
Use Case Diagrams
Use cases are used during requirements elicitation and analysis to
represent the functionality of 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 are used to describe the structure of the system.
 Classes are abstractions that specify the common structure and behavior of a set of objects.
 Objects are instances of classes that are created, modified, and destroyed during the execution of the
system. An object has state that includes the values of its attributes and its links with other objects.
 Class diagrams describe the system in terms of objects, classes, attributes, operations, and their
associations
 The numbers on the ends of associations denote the number of links each SimpleWatch object can have with
an object of a given class. For example, a SimpleWatch has exactly two PushButtons, one Display, two
Batteries, and one Time. Similarly, all PushButton, Display, Time, and Battery objects are associated with
exactly one SimpleWatch object. DR. GANESHKUMAR N, DEPT. OF CSE 56
Example

Interaction Diagrams
 Interaction diagrams are used to formalize the dynamic behavior of the system and to
visualize the communication among objects.
 An interaction diagram represents the interactions that take place among these objects.
 Following are the different types of interaction diagrams defined in UML:
 Sequence diagram
 Collaboration diagram
 The sequence diagram is used primarily to show the interactions between objects in the
sequential order that those interactions occur.
 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”

Example
SEQUENCE DIAGRAM FOR NEW REGISTRATION COLLABORATION DIAGRAM FOR NEW REGISTRATION

A UML sequence diagram for the Watch
The left-most column represents the

timeline of the WatchUser actor who
initiates the use case.
The other columns represent the timeline
of the objects that participate in this use
case.
Object names are underlined to denote
that they are instances (as opposed to
classes).
Labeled arrows are stimuli that an actor or
an object sends to other objects.

State Machine Diagrams
 State machine diagrams describe the dynamic button1Pressed
behavior of an individual object as a number of states

and transitions between these states.
 A state represents a particular set of values for an
object.
 Given a state, a transition represents a future state the
object can move to and the conditions associated with
the change of state.
 The sequence diagram focuses on the messages
exchanged between objects as a result of external
events created by actors. The state machine diagram
focuses on the transitions between states as a result of
external events for an individual object.
Activity Diagrams
 An activity diagram describes the behavior of a system in terms of activities.
 Activities are modeling elements that represent the execution of a set of operations.
 The execution of an activity can be triggered by the completion of other activities, by the
availability of objects, or by external events.
 Activity diagrams are similar to flowchart diagrams which can be used to represent control
flow (i.e., the order in which operations occur) and data flow (i.e., the objects that are
exchanged among operations).

Examples
Activity diagram representing Activity diagram for an
activities related to managing an emotion based music
incident player
• Rounded rectangles represent

activities;
• Arrows between activities represent
control flow;
• Thick bars represent the
synchronization of the control flow.
Modeling Concepts

Systems, Models, and Views
SYSTEM
 A system is an organized set of communicating parts.
Ex:
 A car, composed of four wheels, a chassis, a body, and an engine, is designed to transport
people.
 A watch, composed of a battery, a circuit, wheels, and hands, is designed to measure time.
 Parts of a system can in turn be considered as simpler systems called subsystems.

 The engine of a car, composed of cylinders, pistons, an injection module, and many other parts,
is a subsystem of the car.
 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. Complex systems are generally
described by more than one model, each focusing on a different aspect or level of
accuracy.
 Modeling means constructing an abstraction of a system that focuses on interesting
aspects and ignores irrelevant details.
 If we did not use models, but instead started coding the system right away, we would have
to specify all the details of the user interface before the client could provide us with
feedback. Thus we would lose much time and resources when the client then introduces
changes.
 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.

 For example, assume we want to build an airplane. Even with the help of field experts,
we cannot build an airplane from scratch and hope that it will function correctly on its
maiden flight.
 Instead, we first build a scale model of the air frame to test its aerodynamic properties. In
this scale model, we only need to represent the exterior surface of the airplane. We can
ignore details such as the instrument panel or the engine.
 In order to train pilots for this new airplane, we also build a flight simulator. The flight
simulator needs to accurately represent the layout and behavior of flight instruments. In
this case, however, details about the exterior of the plane can be ignored.
 Both the flight simulator and the scale model are much less complex than the airplane
they represent.

 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.
 Notations are graphical or textual rules for
representing views.
 A UML class diagram is a graphical view of the
object model.
Data Types, Abstract Data Types, and
Instances
 A data type is an abstraction 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 that are members of the data type (i.e., the instances of the data
type) and defines the structure and the operations valid in all instances of the data type.

Data Types, Abstract Data Types, and
Instances
 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.
 Examples of abstract data types are sets and sequences, which can be mathematically
defined.
 For example, the abstract data type Person may define the operations getName(),
getSocialSecurityNumber(), and getAddress().
 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
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
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.
For example, an event can be a stimuli from an actor (e.g., “the WatchUser presses the left button”), a
time-out (e.g., “after 2 minutes”), or the sending of a message between two objects.
Sending a message is the mechanism by which the sending object requests the execution of an operation
in the receiving object.
The message is composed of a name and a number of arguments. The receiving object matches the name
of the message to one of its operations and passes the arguments to the operation. Any results are returned
to the sender.
Events and messages are instances: they represent concrete occurrences in the system. Event classes are
abstractions describing groups of events for which the system has a common response

Object-Oriented Modeling
The application domain represents all aspects of the user’s problem. This includes the
physical environment, the users and other people, their work processes, and so on. It is critical
for analysts and developers to understand the application domain for a system to accomplish
its intended task effectively.
The solution domain is the modeling space of all possible systems. Modeling in the solution
domain represents the system design and object design activities of the development process.
The solution domain model is much richer and more volatile than the application domain
model. This is because the system is usually modeled in much more detail than the application
domain.
Object-oriented analysis is concerned with modeling the application domain.
Object-oriented design is concerned with modeling the solution domain. Both modeling
activities use the same representations (i.e., classes and objects).
Falsification and Prototyping
Falsification is the process of demonstrating that relevant details have been incorrectly
represented or not represented at all; that is, the model does not correspond to the reality it is
supposed to represent.
The process of falsification is well known in other sciences:
for example, it was discovered that the orbit of the planet Mercury did not exactly match the
orbit predicted by Newton’s theory of gravity. Later, Einstein’s general theory of relativity
predicted a slightly different orbit that better matched the results. In other words, Newton’s
theory was falsified in favor of Einstein’s. Note, however, that we still use Newton’s theory
for practical applications on Earth, because the differences predicted by both theories are
small in these situations and Newton’s theory is much simpler.
We can apply falsification to software system development as well.

Technique for developing a system is prototyping: when designing the user interface,
developers construct a prototype that only simulates the user interface of a system. The
prototype is then presented to potential users for evaluation—that is, falsification—and
modified subsequently.
In the first iterations of this process, developers are likely to throw away the initial
prototype as a result of feedback from the users. In other terms, users falsify the initial
prototype, a model of the future system, because it does not accurately represent relevant
details.

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. )

OOSE Unit-1

Uploaded by

Copyright:

Available Formats

OOSE Unit-1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOSE Unit-1

Uploaded by

Copyright:

Available Formats

CSEN2091

OOSE Based Application

DR. GANESHKUMAR N, DEPT. OF CSE 2

 Develop models using UML Notation

 Analyse Requirements with Use cases

 Relate Analysis to Design

 Design Solutions with patterns and architectural layers

 Apply concepts to semester long software project

DR. GANESHKUMAR N, DEPT. OF CSE 3

UNIT 2 UML & Analysis

UNIT 4 Object Design

DR. GANESHKUMAR N, DEPT. OF CSE 6

 Describe the OOAD paradigm (Unified Processes)

 Employ the UML diagramming standards.

 Use a case tool for all UML diagrams.

 Develop prototypes of the system design, code, and Testing

DR. GANESHKUMAR N, DEPT. OF CSE 8

DR. GANESHKUMAR N, DEPT. OF CSE 9

 The IEEE definition: “The application of systematic,

DR. GANESHKUMAR N, DEPT. OF CSE 10

 Goals of each phase:

DR. GANESHKUMAR N, DEPT. OF CSE 11

Deliverables: Requirements document (SRS).

DR. GANESHKUMAR N, DEPT. OF CSE 12

Deliverables: System architecture, design specifications.

Deliverables: Executable code.

DR. GANESHKUMAR N, DEPT. OF CSE 14

Deliverables: Test plans, test cases, defect reports.

DR. GANESHKUMAR N, DEPT. OF CSE 15

Deliverables: Deployed software, user manuals.

DR. GANESHKUMAR N, DEPT. OF CSE 16

Deliverables: Software updates, documentation updates.

DR. GANESHKUMAR N, DEPT. OF CSE 17

DR. GANESHKUMAR N, DEPT. OF CSE 19

DR. GANESHKUMAR N, DEPT. OF CSE 20

DR. GANESHKUMAR N, DEPT. OF CSE 21

DR. GANESHKUMAR N, DEPT. OF CSE 23

DR. GANESHKUMAR N, DEPT. OF CSE 25

DR. GANESHKUMAR N, DEPT. OF CSE 30

DR. GANESHKUMAR N, DEPT. OF CSE 31

 Application Generation: Automated tools are used to facilitate construction of the

DR. GANESHKUMAR N, DEPT. OF CSE 32

DR. GANESHKUMAR N, DEPT. OF CSE 34

DR. GANESHKUMAR N, DEPT. OF CSE 37

DR. GANESHKUMAR N, DEPT. OF CSE 38

 Design the Requirements: In this step the gathered

DR. GANESHKUMAR N, DEPT. OF CSE 40

DR. GANESHKUMAR N, DEPT. OF CSE 45

DR. GANESHKUMAR N, DEPT. OF CSE 49

In this approach the state information is not represented in a

Approach It is a top down approach. It is a bottom up approach.

DR. GANESHKUMAR N, DEPT. OF CSE 50

DR. GANESHKUMAR N, DEPT. OF CSE 51

DR. GANESHKUMAR N, DEPT. OF CSE 54

DR. GANESHKUMAR N, DEPT. OF CSE 55

DR. GANESHKUMAR N, DEPT. OF CSE 57

DR. GANESHKUMAR N, DEPT. OF CSE 58

DR. GANESHKUMAR N, DEPT. OF CSE 59

The left-most column represents the

DR. GANESHKUMAR N, DEPT. OF CSE 60