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