Object Oriented Software Engineering

Satvik Gupta

Object Oriented Software Engineering

Many of the images and tables used in this document have been taken from Object Oriented Software Engineering by Yogesh Singh,Ruchika Malhotra. Please support their efforts by buying a copy here.

It consists of two terms – object oriented, and software engineering.

Object Oriented

It is a collection of information that itself act as a singular entity. It allows the user to focus completely on the task rather than on the tools.

For example – C++, etc.

With the help of this, reusability as well as abstraction is possible.

The necessity of developing a maintaining a large-size, complex, and varied functionalities software system has caused us to look for new approaches of software design and development.

The conventional approaches like Waterfall Model may not be very useful due to non-availability of iterations, no provision of reuse, and difficulty in incorporating changing requirements.We may also build every software system from scratch that results into a costly software system, including very high maintenance cost.

An object oriented approach may address such issues, that’s why it has become very popular in designing,developing, and maintaining large size software systems. Object oriented approach’s modelling ability helps us to represent the real world situations and visualize them.

Software Engineering

It is a profession dedicated to designing, implementing and modifying so that the software is more affordable, maintainable, faster to build, and high quality.

OR

The establishment and use of some engineering principles in order to obtain economically developed software that is reliable and works efficiently on real machines.

Software

It is a combination of programs, documentation and operating manual.

Program

A certain set of instructions that are written for a specific purpose. It may contain statements to enhance the readability of the program.

Documentation

Documentation is created and used during development. It is used to explain the code, what it does, and why it has been coded in a certain way.

Operating Manual

Explains to the customer how the software is to be used. It is delivered along with the software to the customer, at the time of release.

The use of use cases was introduced in Object Oriented Methodology.

Characteristics of Software

Bathtub and software curve bs

Object Oriented Basic Concepts

  1. Classes
  2. Objects
  3. Data Abstraction
  4. Encapsulation
  5. Inheritance
  6. Polymorphism

Classes

A class represents a template for different objects and describes how these objects are structured internally. Objects of the same class have the same definition, both for the operations, and for the information structures.

OR

It is a collection of objects and it doesn’t take any space in memory. It is also called a blueprint, or a logical entity.

There are two types:

Objects

Fundamental entities used to model any system. Anything and everything can be an object. It contains data(attributes) and operations(behaviors).

Encapsulation

The wrapping up of data and functions into a single unit. It is also known as information hiding concept.

Data is hidden from the outside world. The only way to get and modify the data is through operations that are meant to operate on that data. This helps in minimizing impact of changes in the program.

Inheritance

Deriving a new class from existing class in such a way that the new class can access all the features and properties of the existing class.

The existing class is called parent class, super class, base class. The new class is called child class, subclass, derived class.

Polymorphism

The ability of an instruction,message,etc. to take many forms in an object oriented system is called polymorphism.

Sender of a stimulus (message) doesn’t need to know the receiver’s class. The receiver can belong to an arbitrary class.

Achieved through function overriding.

For eg - Superclass OutputDevice, with Subclasses Printer and Monitor. Both have a function called ShowData(). Both implement it differently, and a program calling obj.ShowData() doesn’t need to know whether obj is a Printer or Monitor. As long as it is an OutputDevice, the program can call the function. The behaviour of the function depends on which subclass is being used.

Data Abstraction

Hiding of complexity of data and operations. Irrelevant details are hidden and important details are amplified to the outside world.

Object Oriented Software Development (OOSD)

The major phases of software development using the object oriented methodology are:

  1. Object Oriented Analysis

    In this stage, problem is formulated. User Requirements are identified and then a model is built, based upon real world objects.

    The analysis produces models on how the desired system should function and how it must be developed.

    The models do not include any implementation details, so that it can be understood by any non-technical application expert.

  2. Object Oriented Design

    Object Oriented Design includes two main stages.

    1. System Design

      In this stage, the complete architecture of the desired system is designed. The system is conceived as a set of interacting subsystems, that in turn are composed of a hierarchy of interacting objects, grouped into classes.

      System Design is done according to both the system analysis model, and proposed system architecture.

      Here, the emphasis is on the objects comprising the system, rather than the processes in the system.

    2. Object Design

      In this phase, a design model is developed based on both the models in the system analysis phase and the architecture designed in the system design phase.

      All the classes required are identified. The designer decides where

      1. The new classes are to be created from scratch.

      2. Any existing classes can be used in their original form,or

      3. New classes should be inherited from the existing classes.

      4. The associations between the identified classes are established and the hierarchy of the classes are identified.

        Besides this, the developer designs the internal details of the classes, and their associations, i.e, the data structure for each attribute, and the algorithm for the operations

  3. Object Oriented Implementation + Testing

    In this stage, the design model developed in the object design is translated into code in an appropriate programming language or software tool. The databases are created and the specific hardware requirements are ascertained. Once the code is in shape, it is tested using different techniques in order to identify and remove errors from the code.

Object Oriented Software Development

Coad/Yourdon Methodology

Known as Object Oriented Analysis

  1. Identify classes and objects (study environment and document behaviours)
  2. Identification of Structures (identify is-a and whole-part relationships)
  3. Definition of Subjects (each structure is classified into a subject)
  4. Definition of Attributes
  5. Definition of Services (methods)

Rumbaugh Methodology

Known as Object Modelling Technique (OMT)

  1. Analysis Phase

    1. Object Model - Static aspects of system

    Classes and inheritance relationships are extracted from problem statement.

    1. Dynamic Model - Behavioural aspects of object model and describes state of the system

    Identifies states and events in classes identified by object model.

    1. Functional Model - Represents functional aspects of the system

    Depicts functionality of the system by creating data flow diagrams.

  2. Sys Design - HLD is developed taking implementation env., including DBMS,etc. into account.

  3. Object Design - Objects are defined in detail. Algorithms and operations defined.

  4. Implementation

Booch Methodology

Object Oriented Design - Combines analysis, design and implementation. Iterative and incremental.

Macro Process

High Level Process

  1. Establish requirements - Context diagram, prototypes
  2. Analysis Model - Use case model, identification and prioritization of risks.
  3. Design of Architecture
  4. Evolution in the form of refinements - Implementation
  5. Maintenance of delivered functionality - Post deployment activities

Micro Process

Lower level process.

  1. Identification of classes and objects
  2. Identification of semantics of classes and objects
  3. Identification of relationships btw classes and objects
  4. Specification of interfaces and implementation of classes and objects

Jacobson Methodology

OOSE methodology, 5 models:

  1. Requirement model - Gather s/w requirements. Use cases, actors, etc.
  2. Analysis model - Create robust and ideal structure of objects. Identify interface objects, DB related objects, control objects, etc.
  3. Design model - Refine the object w.r.t implementation environment. Objects become blocks.
  4. Implementation model - Implements the objects (blocks) into modules.
  5. Test model - Validate and verify the functionality of the system

OO Modelling and UML

Object oriented modelling - constructing visual models based on real world objects - Helps in understanding problems and developing documents and producing code. - Well understood requirements, robust designs, etc, etc.

Most popular methodologies - OOD (Booch), OMT (Rumbaugh), OOSE (Jacobson). All were combined into Unified Modelling Language (UML).

Class, Responsibility, Collaboration (CRC)

  1. Class - Template consisting of attributes and operations
  2. Responsibility - Attributes and operations included in a class
  3. Collab - Other classes that a class calls to achieve its functionality.

​

Traditional OO
The system is viewed as a collection of processes. The system is viewed as a collection of objects.
Data flow diagrams, ER diagrams, data dictionary and structured charts are used to describe the system. UML models including use case diagram, class diagram, sequence diagrams, component diagrams, etc. are used to describe the system.
Reusable source code may not be produced. The aim is to produce reusable source code.
Data flow diagrams depicts the processes and attributes. Classes are used to describe attributes and functions that operate on these attributes.
It follows a top-down approach for modelling the system. It follows a bottom-up approach for modelling the system.
It is non-iterative. It is highly iterative.

Process Framework

Software Process Framework is a foundation of complete software engineering process. It includes all the umbrella activities.

Process Framework

A generic process framework consists of 5 activities:

  1. Communication

    Requirement Gathering, extensive communication with customer

  2. Planning

    We discuss the technical related tasks, work schedule, risks, and required resources

  3. Modelling

    It is about building representations of things in the real world.

    In modelling, a product’s model is created in order to better understand requirements

  4. Construction

    In SE, construction is the application of set of procedures that are needed to assemble the product. In this activity, we generate the code and test the product in order to maintain better product.

  5. Deployment

    In this activity, a complete or a non-complete product or software, are presented to the customers to evaluate, and give feedback.

    On the basis of their feedback, we modify the products to supply a better product.

Umbrella Activities

Umbrella Activities are a set of steps or procedures that the SE team follows to maintain the progress, quality, change and risk of the overall development task.

SE is a collection of 4 related steps. These steps are presented or accessed in different approaches, in different software process models.

These steps of umbrella activities will evolve through the phases of the generic view of SE.

  1. Software Project Tracking and Control

    Before the actual development begins, a schedule for development of the software is created. Based on that schedule, the development will be done.

    However, after certain period of time, it is required to review the progress of the development and to find out the actions which are in need to be taken to complete the development,testing etc.

    The outcome of the review may require the software development to be rescheduled.

  2. FTR (Formal Technical Review)

    SE is done in clusters or modules. After completing each module, it is good practice to review the completed module and find out and remove errors so that the next module can be prevented.

  3. SQA

    The quality of software, such as UX, performance, load handling capacity, etc. should be tested, and make sure it matches predetermined milestones.

    This reduces the task at the end of the development process. It should be conducted by dedicated teams so that the development can keep going on.

  4. SCM (Software Config Mgmt)

    It’s a set of activities designed to control change by identifying the work products that are likely to change and establish relationships among them.

    Defining mechanisms for managing different versions of these work products.

  5. Document Preparation and Production

    All the project planning, and other activities, should be documented properly.

  6. Reusability Management

    This includes the packing up of each part of the software project. They can be connected, or any kind of support can be given to them, later to update or upgrade the software at user demand or time demand.

  7. Measurement and Metrics

    This will include all the measurement of every aspect of the software project.

  8. Risk Management

    It is a series of steps that helps a software team to manage and understand uncertainty. It’s a really good idea to identify, assess, estimate its impact, estimate probability of threats, and establish a plan for what to do in case the problem actually occurs.

Often combined in Object Oriented Analysis.

SDLCs

Waterfall

Advantages

Disadvantages

Prototyping

Advantages

Disadvantages

Iterative Enhancement

Waterfall stages in many cycles

Spiral Model

Risk-based.

Rounds

  1. Round 0 - Feasibility study
  2. Round 1 - Concept of operation
  3. Round 2 - Top level requirement analysis
  4. Round 3 - Software design
  5. Round 4 - Design, implementation and testing

XP - Extreme Programming

Agile methodology:

  1. Team cohesiveness
  2. Customer is part of the team
  3. Requirement changes are accepted
  4. Working software produced quickly
  5. Progress is measured by working software and not documents
  6. Iterative planning instead of iterative development. Plans are changed based on learnings.
  7. Distributed leadership

  1. User Stories - only contain estimate of time taken for the feature. Requirement details taken from customer at development time.
  2. Release planning -
    • Developers estimate story time, and customer selects the order of story development.
    • Large stories may be divided into substories.
    • Developer may do exploration (spike) of story
  3. Iteration Planning - Stories divided into tasks that are handed to developers. Working product released after each iteration.
  4. Dev and Unit tests -
    • Important tasks chosen by customers and implemented.
    • Pair Programming
    • Refactoring
    • Automated unit tests
  5. Acceptance Testing - Automated black box acceptance tests are created from user stories. Customer runs and verifies them.
  6. Working product Released.

Object Oriented SDLCs

Difference btw Conventional and OOP SDLCs

Conventional OO
Methodology Functional, process driven Object Driven
Requirement DFD, ER, Data dictionary Use-case approach
Analysis DFD, ER, Data dictionary Object identification and description, attribute and function determination
Design Structure chart, flowchart, pseudocode Class Diagram, Sequence Diagram, Object Diagram, UML
Implementation & Test Implement process, functions Implement objects and interactions among objects.
Documentation Many documents at the end of each stage Document may or may not be produced at the end of each stage

Phases of OOSDLC

  1. Object Oriented Requirement Analysis
  2. Object Oriented Analysis
  3. Object Oriented Design
  4. Object Oriented Programming and testing

Fountain Model

Rational Unified Process

Features

  1. Iterative Dev - Series of iterations, feedback after each. Helps monitoring schedule and budget.
  2. EFfective req. elicitation - Use case approach.
  3. Visual Modelling - Build (abstracted) models that portray different views of the system. Use UML.
  4. Reusable Components - Develop and use reusable components (independent subsystem that fulfills a clear goal).
  5. Ensure quality - Continuously assess quality. It becomes harder to maintain quality in later stages of development.
  6. Change control and management - Manage and track changes
  7. Automated Testing - Functional as well as non-functional automated testing.

Structure of RUP

Static Structure

Describes the process in terms of roles, activities, artifacts,disciplines and workflows.

Who(roles) does what (artifacts), when (workflows), and how(activities).

Roles perform activities to produce artifacts.

Roles - Manager, Analyst, Tester, Developer, Designer.

Activities - Review Requirement, Generate use case, Define class, Prepare test plan.

Artifacts - SRS, Use case model, Class model, Design document, Source code, Test plan, user manual.

Dynamic Structure

Organized along time. It has 4 phases.

  1. Inception
  2. Elaboration
  3. Construction
  4. Transition

These 4 phases run iteratively. Each iteration produces a new version of the software.

Inception

Essential Activities:

Artifacts produced:

Elaboration

Essential Activities:

Artifacts produced:

Construction

Essential Activities:

Artifacts produced:-

Transition

Artifacts produced:

Software Requirements

A requirement is defined as a condition or capability to which a system must conform. It describes the “what” of the system, not “how”.

Characteristics of a Good Requirement

Identification of Stakeholders

Every person who is affected by the system (directly or indirectly) is a stakeholder.

Internal People of Customer’s Organization

This can be both customers and users. Customers are those who ask for the software to be developed, request changes, approve the software, and also pay for the system. Users are those who use the system after it has been deployed. Customer’s preferences are given more importance compared to user.

External People of Customer’s Organization

Includes consultants, domain experts, maintenance people, etc.

Internal People of Developer’s Organization

Everyone involved in the development of the system - developers, programmers, testers, project managers, graphic designers, etc.

External People of Developer’s Organization

Any external people involved in the development of the software. Domain experts, consultants, third party testers, etc.

Functional vs Non-Functional Requirements

Functional

Non-Functional

Requirement Elicitation Techniques

Techniques to understand what exactly the customer wants, i.e, to translate vague wants of customers into concrete requirements that can be formalized and written down.

Interviews

Brainstorming

Facilitated Application Specification Technique (FAST)

Guidelines

Preparation

Each member needs to create the following things

Activities

Prototyping

Use Case Approach

Terms

Relationships between Use Cases

Extend Relationship

Used in the following way

For e.g, a student returns a book to the library. It is possible that the book is late. In that case, we will need to calculate the fine for the book. Therefore, the Return Book use case will be extended by Calculate Fine Use case.

Include Relationship

Repeated functionalities in many use cases can be modelled into include relationship, using a singe use case.

For e.g, many use cases may require the Print function, so it can be converted into a separate use case and included in the other use cases.

Use Case Description

Should contain :

Scenario Diagrams

Scenario is a particular path through the use case. In scenario diagrams:

Scenario Diagram

Object Oriented Analysis

Identifies and defines the real world objects that are involved in interaction with the system.

Classes

Class is a collection of objects with common attributes and operations. It is a template that groups attributes and operations together.

Entity Classes

Entity Class

Interface Classes

Interface Class

Control Class

Control Class

Relationships between Classes

Name and Description Notation
Association is a structural connection, usually bidirectional. Shows that two classes are linked in some way. May also have a name associated with it. For e.g, IssueBookController manages Transaction. manages is an association with a name. Association
Aggregation shows a whole-part relationship, i.e, class B is part of class A. E.g - Book is part of Library. In the notation, the diamond should represent the library, i.e, the whole part. Aggregation
Composition is strong aggregation. In composition, class B is part of Class A, and only Class A. It cannot belong to another class, say C. In aggregation, a class can belong to/be part of 2 classes. For e.g, book can be part of Library as well as Computer Department. But Computer Department can belong to only one University. Composition
Dependency - represents that a class depends on another class. Unidirectional. It means that one class is affected by changes in the other class, because it uses that class. If class A depends on class B, we show dependency through a dotted arrow from A to B. Dependency
Generalization - Relationship between parent and child class. Represents inheritance (is a) relationships. For example, Professor is an Employee, SecurityGuard is an Employee, Clerk is an Employee, etc. Represented by an arrow from child class towards parent class. Generalization

Class Diagram

Class diagrams should contain details about each classes as well as the relationships between them. For each class, we need to write:

Sequence Diagrams

Centralized vs Decentralized Control Structures

Centralized Decentralized
Controlling object responsible for flow of messages and order of events. Participating objects can communicate with each other without any controlling object.
Better because any change means only controller needs to be changed. Better when messages are strongly coupled with each other.
Allows new operations to be added easily
Parts of functionality can be reused
Centralized Decentralized

Extended use cases can also be added to sequence diagrams easily.

Sequence Diagram Example - Return Book
Sequence Diagram of Return Book with another use case (calculate fine) added to it

Collaboration Diagrams

They are similar to sequence diagrams. Objects are shown as rectangles, and actors using stick figures. Classes are shown using the representation for that particular type of class (entity, interface,control).They don’t show events being time ordered. Messages are shown using arrows. Objects that interact with each other are connected by links (straight lines). One link can be used to pass many messages.

The time for which the object is alive, or till when it’s participating in some event, is not shown.

Events are ordered using numbers written next to the message.

Return messages are shown using dotted arrows.

Collaboration Diagram for Return book

OO-Design

Consists of the following steps.

  1. Sequence and Collaboration Diagrams
  2. Refinement of classes and relationships - if we need additional features, or need to change existing features, we should do so here.
  3. Identify operations
  4. Create detailed class diagram - Use the refined classes, relationships and identified operations to create a new detailed class diagram.
  5. Detailed design
  6. Software Design Document
  7. Generation of test cases from use cases

Identification of Operations

We create a table for our system. It includes:

For example,

Identification of Operations

Detailed Design and Software Design Document

We create a detailed design for each class separately. It should include:

Generation of Test Cases from Use Cases

It is a five step process

  1. Create use case scenario matrix
  2. Identify variables in a use case
  3. Identify different input states of each variable
  4. Design test case matrix
  5. Assign actual values to input variables.

Terminology

For each test case, we need to show:

When we get to step 5 (assigning actual values), the input state (Valid/invalid) is replaced with actual values.

On running the test, we also add another column - Actual Output. This should be the same as the Expected Output.

For e.g, for the use case issue book:

This is the scenario diagram. Scenario matrix will be as shown:

Scenario Matrix

Test Case Matrix will be as shown:

Putting actual values, it will look like:

OO Design Principles for Software Quality

Good Programming Practices

Software Testing

Testing is the process of executing a program with the intent of finding faults. It’s the process of verifying the outcomes of every phase of development and validating the program by executing it with the intention of finding faults.

Verification Validation
Process of reviewing documents and programs with the intention of finding faults. Process of evaluating a system at the end of development to see if it satisfies the requirements.
Static Testing Dynamic testing
Program Not Executed Program is executed
Inspections, walkthroughs, reviews. Black/White box testing, non-functional testing
Before validation After verification
Prevention of Errors Detection of Errors
Are we building the product right? Are we building the right product
About the process About the product.

Verification Techniques

Peer Reviews

Walkthrough

Inspections

Checklist

Checklist contains important information that a particular document must contain. We can verify the document against our checklist.

It helps identifying duplicate information, missing information, and wrong information.

Every document may have a different checklist.

E.g.

etc.

Functional Testing

Boundary Value Analysis

For e.g, for two inputs \(100 \le a \le 1000\) and \(200 \le b \le 1200\), boundary value test cases are:

S.No a b
1 100 700
2 101 700
3 550 700
4 999 700
5 1000 700
6 550 200
7 550 201
8 550 1199
9 550 1200

Only tests a single fault at once. i.e, a and b both won’t simultaneously have boundary conditions. Total number of cases = \(4n+1\).

Robustness Testing

Also tests just below minimum and just above maximum, as well as all the test cases tested in boundary value. The program should identify these values as invalid.

Total number of cases = \(6n+1\)

Reference : Object Oriented Software Engineering - Yogesh Singh,Ruchika Malhotra.

Worst Case Testing

We don’t assume single fault here. Many failures can occur together. Any combination of inputs may have:

Total number of cases = \(5^n\)

Robust Worst Case

We add just below min and just above max to worst case testing. Total number of cases = \(7^n\).

Equivalence Class Testing

Structural Testing

The entire program is evaluated. We go into the internal structure of the program to test it. This is white box testing.

Path Testing

Eg:

Code:

1. int a;
2. input(a);
3. print("you entered",a);
4. if (a%2==0)
5. {
6.   print("a is even");
7. }
8.else
9. {
10. print("a is odd");
11. }
12. print("Goodbye")

The graph will look like:

      1
      |
      v 
      2
      |
      v
      3
      | 
      v
      4
    /   \
   5     8
   |     |
   v     v
   6     9
   |     |
   v     v
   7     10
   |     |
   v     v
   12<--11

Remove sequential nodes.

    S
    |
    v
    N1
    |   
    v
    N2
  /   \
 N3   N4
  \   /
    N5
    |   
    v
    N6

This is the final DD graph

Independent Paths in DD graphs are paths that introduces at least one new node or edge in its sequence.

Cyclomatic number= max number of independent paths.

It depends only on the decision structure of G. Addition/removal of functional statements doesn’t affect cyclomatic number.

V(G) = Cyclomatic Number = e-n+2P

e = edges

n= nodes

P = number of connected components

V(G)= number of regions of program graph.

For activity diagrams,

V(G) = Transitions - activities/branches + 2P

Class Testing

Mutation Testing

Levels of Testing

Unit Test

Integration Test

System Testing

Acceptance Testing