object oriented software engineering

OBJECT ORIENTED SOFTWARE ENGINEERING

RITIKA CHUGH ASSISTANT PROFESSOR CSE DEPARTMENT
OBJECT ORIENTED SOFTWARE ENGINEERING 1

Outline of Syllabus
UNIT-1: OO Software Engineering Development Activities, Modeling Concepts and UML  UNIT-2: Analysis  UNIT-3: System Design  UNIT-4: Object Design: Reusing Pattern Solutions  UNIT-5: Mapping Models to Code

OBJECT ORIENTED SOFTWARE ENGINEERING 2

BOOKS
Text Books: 1. Bernd Bruegge and Allen H. Dutoit,“Object oriented Software Engineering, using UML, Pattern and Java” 2. Michael R. Blaha and James R Rumbaugh, Object-Oriented Modeling and Design with UML, Prentice Hall
OBJECT ORIENTED SOFTWARE ENGINEERING 3

UNIT - 1
OO Software Engineering Development Activities  Software Modeling Concepts  Introduction to Unified Modeling Languages (UML)


OBJECT ORIENTED SOFTWARE ENGINEERING

4

Software Engineering
It is a process of solving customer’s problem by the systematic development and evolution of large, high quality software systems within cost, time and other constraints.

OBJECT ORIENTED SOFTWARE ENGINEERING

5

Object-Oriented Software Development
Three key words
◦ Software ◦ Development ◦ Object Orientation

OBJECT ORIENTED SOFTWARE ENGINEERING

6

Software is Set of Instructions that when executed provide desired features, function and performance.

OBJECT ORIENTED SOFTWARE ENGINEERING

7

Software Development
 

Software is developed using a life cycle model. Software Development Paradigm: - Provides a general approach to work during each phase of the life cycle model. - A broad philosophy. - Not a specific model.
OBJECT ORIENTED SOFTWARE ENGINEERING 8

Object Orientation
Most recent paradigm.  Treats a problem as a collection of objects.  Becoming very popular now.  The object-oriented paradigm is an approach to the solution of problems in which all computations are performed in the context of objects Object A thing or entity that makes sense within the context of the problem


For example, a student, a car, time, date
OBJECT ORIENTED SOFTWARE ENGINEERING 9

Object Orientation (cont..)
Object-Oriented view is an abstraction that models the world in ways that help us to better understand and navigate it  OO approach was first proposed in the late 1960s  As time passes, object technologies are replacing classical software development approaches. Why? Object technologies lead to reuse, OO software is easier to maintain, to adapt, and to scale.

OBJECT ORIENTED SOFTWARE ENGINEERING 10

Object Oriented Software Engineering Development Activities
Requirement Elicitation  Analysis  System Design  Object Design  Implementation  Testing


OBJECT ORIENTED SOFTWARE ENGINEERING

11

An overview of Object-Oriented Software engineering development activities

OBJECT ORIENTED SOFTWARE ENGINEERING

12

REQUIREMENTS ELICITATION
   



During requirements elicitation, the clients and developers define the purpose of the system. The result of this activity is a description of the system in terms of actors and use-cases. Actors represents the external entities that interact with the system. Actors include roles such as end users, other computers the system needs to deal with, and the environment. Use-cases are general sequences of events that describe all the possible actions between an actor and the system for a given piece of functionality.
OBJECT ORIENTED SOFTWARE ENGINEERING 13

Example of a Use Case for a TicketDistributor
  

Use Case Name : PurchaseOneWayTicket Participating Actor : Initiated by Traveler Flow of Events : 1. Traveler selects the destination zone. 2. TicketDistributor displays the price of ticket. 3. Traveler inserts the amount of money atleast as much as the price of ticket. 4. TicketDistributor issues the specified ticket to the traveler and returns the
OBJECT ORIENTED SOFTWARE ENGINEERING

14

Example of a Use Case for a TicketDistributor(cont..)
Entry Condition: Traveler will communicate with the TicketDistributor.  Exit Condition: Traveler holds the valid ticket or changes his decision of travelling and do not require any ticket now.  Quality Requirements: If the transaction is not completed after one minute of inactivity, the TicketDistributor returns all inserted amount.

OBJECT ORIENTED SOFTWARE ENGINEERING

15

ANALYSIS
During Analysis, aim is to produce a model of the system that is correct, complete, consistent and unambiguous.  Use cases produced during requirements elicitation are transformed into an Object model (class diag.) that completely describes the system.  Ambiguities and inconsistencies (if discovered) are resolved with the client.  The result of this analysis is a System Model (Dynamic model eg. State chart diag., Sequence diag.) .

OBJECT ORIENTED SOFTWARE ENGINEERING 16

Dynamic Model

OBJECT ORIENTED SOFTWARE ENGINEERING

17

Object Model

OBJECT ORIENTED SOFTWARE ENGINEERING

18

SYSTEM DESIGN






Design goals of the project are defined by the developers, Strategies and the hardware/software platforms are also selected. System is decomposed into smaller subsystems that can be realized by individual teams. System design Object model (Deployment diag.) is made representing the hardware/software mapping of the system.
OBJECT ORIENTED SOFTWARE ENGINEERING 19

Subsystem decomposition

TravelerInterface

Updater

LocalTariff

CentralTeriff

OBJECT ORIENTED SOFTWARE ENGINEERING

20

OBJECT DESIGN
During Object Design solution domain objects are defined to bridge the gap between the analysis model and hardware/software platform defined during system design.  In it, the objects and the subsystem interfaces are precisely described, to restructure the object model(class diag.).  The result of this activity is a detailed object model with constraints and descriptions of each element.

OBJECT ORIENTED SOFTWARE ENGINEERING 21

IMPLEMENTATION
During Implementation developers translate the solution domain model into source code.  This includes implementing the attributes and methods of each object and then integrating all the objects such that they function as a single system.

OBJECT ORIENTED SOFTWARE ENGINEERING

22

TESTING
Unit Testing  Integration testing  System testing


The goal of testing is to discover as many faults as possible such that they can be repaired before the delivery of the system.
OBJECT ORIENTED SOFTWARE ENGINEERING 23

Introduction to UML

OBJECT ORIENTED SOFTWARE ENGINEERING

24

UML
UML stands for Unified Modeling Language.  UML is different from the other common programming languages like C++, Java, COBOL etc.  UML is a pictorial language used to make software blue prints.


OBJECT ORIENTED SOFTWARE ENGINEERING

25

Introduction
System development using UML focuses on three different models of the system: FUNCTIONAL MODEL: represented in UML using use case diagrams, describes the functionality of the system. OBJECT MODEL: represented in UML using class diagram, describes the structure of a system in terms of objects, attributes, associations and operations. DYNAMIC MODEL: represented in UML with interaction diagrams, statechart diagrams, activity diagrams, describes the internal behaviour of the system
OBJECT ORIENTED SOFTWARE ENGINEERING 26

UML Notations:
UML provides a wide variety of notations for representing many aspects of software development. Mostly these few notations are used in software development:  Use Case Diagram  Class Diagram  Interaction Diagrams  State-chart Diagram  Activity Diagram
OBJECT ORIENTED SOFTWARE ENGINEERING

27

Use Case Diagrams
 The

use case diagram for any system consists of a set of “use cases”.  A use case is a sequence of
interactions between an actor and the system.  Actors represents the external entities that interact with the system.
OBJECT ORIENTED SOFTWARE ENGINEERING 28

Use case diagram of a simple Watch

OBJECT ORIENTED SOFTWARE ENGINEERING

29

Class diagrams


A class diagram describes the types of classes in the system and the various kinds of static relationships that exist among them. A class is the description of a set of objects having similar attributes, operations, relationships and behavior

OBJECT ORIENTED SOFTWARE ENGINEERING

30

Class diagram describing elements of a Simple watch

OBJECT ORIENTED SOFTWARE ENGINEERING

31

Interaction Diagrams


Interaction diagrams are used to represent the dynamic behavior of a system and to visualize the communication among objects. For example – Sequence Diagram

OBJECT ORIENTED SOFTWARE ENGINEERING

32

Sequence diagram of a simple watch

OBJECT ORIENTED SOFTWARE ENGINEERING

33

StateChart Diagrams

It describes the dynamic behavior of an individual object as a number of states and transitions between these states.

OBJECT ORIENTED SOFTWARE ENGINEERING

34

State Diagram for SetTime Use Case of a SimpleWatch

OBJECT ORIENTED SOFTWARE ENGINEERING

35

Activity Diagram
It describes the behavior of a system in terms of activities.  Activities are the elements that represent the execution of a set of operations.  The completion of these operations triggers a transition to another activity.  In activity diagram, Activities are represented by rounded rectangles; Transitions are represented by arrows between the activities; and Synchronization of the control flow is represented by thick bars.

OBJECT ORIENTED SOFTWARE ENGINEERING 36

The diagram represent activities related to managing an Incident. In it:  AllocateResources, CoordinateResources, and DocumentIncident can be initiated only after the OpenIncident activity has been completed.  Similarly, the ArchieveIncident activity can be initiated only after the completion of AllocateResources, CoordinateResources, and DocumentIncident . And these three activities can occur concurrently.
OBJECT ORIENTED SOFTWARE ENGINEERING 37

Software Modeling Concepts

OBJECT ORIENTED SOFTWARE ENGINEERING

38

Systems, Models, and Views
A SYSTEM is an organized set of communicating parts. Parts of a system can be considered as simpler systems called subsystems.  A MODEL is an abstraction describing system or a subset of a system focusing on the important aspects. Modeling is a means of dealing with the complexity, when one system is decomposed into numerous subsystems interconnected in complicated ways.

OBJECT ORIENTED SOFTWARE ENGINEERING 39

Systems, Models, and Views(cont..)
SYSTEM MODEL – The set of all models built during development is called the System model.  A VIEW focuses on a subset of a model to make it understandable (when a model become so complex that it is not easily understandable).  NOTATIONS are graphical or textual rules for representing views.

OBJECT ORIENTED SOFTWARE ENGINEERING 40

Systems, Models, and Views(cont..)

OBJECT ORIENTED SOFTWARE ENGINEERING

41

Modeling
 

Modeling means constructing an abstraction of a system that focuses on interesting aspects and ignore irrelevant details. Deals with the complexity of building numerous high level subsystems.

Modeling Concept
• •

Modeling concepts are used to describe the relationship between programming languages and a system model. Focuses on building an abstraction of the system environment as the basis of a system model.

Data Types






Denotes a set of values that are members of a particular type of data. For example 1,2,3 are integers. So we denote integers as int in Java, C++ etc. Defines the structure of operations that are valid. For example : Random() in C# accepts floating numbers and hence you cannot pass integer data as parameter. Has a unique name and is used to distinguish a set of members of particular data type.

Abstract Data Types
 

  



Abstraction is the process by which data and programs are defined with a representation similar in form to its meaning. An abstract data type is defined as a mathematical model of the data objects that make up a data type as well as the functions that operate on these objects It specifies every thing you need to know in order to use the data type. It makes absolutely no reference to the manner in which the data type will be implemented. The Application: The part that uses the abstract data type. The Implementation: The part that implements the abstract data type. These two pieces are completely independent.

Instances
 ◦

In object-oriented programming an instance is an occurrence or a copy of an object whether currently executing or not. Member of a specific type

Class
• • •

•
•

In OOP a group of similar objects is known as a class. An abstraction in object oriented modeling. Like an abstract data type, a class encapsulates both state (variables) and behavior (methods) Usually represents a noun, such as a person, place or thing, or something nominalized. For example, a "Banana" class would represent the properties and functionality of bananas in general

Name TarifSchedule float zone2price int getZones() int getPrice() Signature Attributes

Operations

Abstract Class

• • •

An abstract class will always be a base class in a hierarchical relationship and require that other classes inherit from it. An abstract class may have one or more implementation/concrete class, that specialize behaviour. The class BankAccount is abstract class and the method: withdrawal is abstract.

Object
 

 

Simple an object is a real world entity. In the domain of object-oriented programming an object is usually taken to mean an ephemeral set of attributes (object elements) and behaviors (methods or subroutines) encapsulating an entity. In a language where each object is created from a class, an object is called an instance of that class. A real-world example of an object would be "my dog", which is an instance of a type (a class) called "dog", which is a subclass of a class "animal"

Event Class


Event classes are abstractions representing a kind of event for which the system has a common response.

Events and Messages
• •

Events and Messages are instances which represent concrete occurrences in the system.. Messages are composed of name and one of its operations. For example : Start()

Application and Solution Domain

Application Domain Application Domain Model TrafficControl

Solution Domain System Model

UML Package

SummaryDisplay

MapDisplay

Aircraft

TrafficController Airport

FlightPlanDatabase
TrafficControl

FlightPlan

Application and Solution Domain


Application Domain (Requirements Analysis):
◦ The environment in which the system is operating



Solution Domain (System Design, Object Design):
◦ The available technologies to build the system