OOSE by Prof Buddhadev

Software Engineering Concepts Slide 1

Object Oriented Software Engineering Concepts & Best Practices

Prof. B V BuddhadevProf. B V Buddhadev

Professor in Computer EngineeringProfessor in Computer Engineering

& PG In charge& PG In charge

L D College of EngineeringL D College of Engineering

AHAMEDABAD , GUAJARATAHAMEDABAD , GUAJARAT

(M) 9825046179(M) 9825046179


Why Software Engineering?

• Software development is hard !• Important to distinguish “easy” systems (one

developer, one user, experimental use only) from “hard” systems (multiple developers, multiple users, products)

• Experience with “easy” systems is misleading– One person techniques do not scale up

• Analogy with bridge building:– Over a stream = easy, one person job

– Over River Severn … ? (the techniques do not scale)


Why Software Engineering ?

• The problem is complexity

• Many sources, but size is key:– UNIX contains 4 million lines of code– Windows 2000 contains 108 lines of code

Software engineering is about managing this complexity.


FAQs about software engineering

• What is – software?– software process?– software engineering?– software process model?

• What is software engineering?• What is the difference

– between software engineering and computer science?– between software engineering and system engineering?


What is software?

• Computer programs and associated documentation

• Software products may be developed for a particular customer or may be developed for a general market

• Software products may be– Generic - developed to be sold to a range of different

customers– Bespoke (custom) - developed for a single customer

according to their specification


What is software engineering?

Software engineering is an engineering discipline which is concerned with all aspects of software production

Software engineers should – adopt a systematic and organised approach to their work – use appropriate tools and techniques depending on

• the problem to be solved,

• the development constraints and

• the resources available


What is the difference between software engineering and computer science?

Computer Science Software Engineeringis concerned with

Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering

theory fundamentals

the practicalities of developing delivering useful software


What is the difference between software engineering and system engineering?

• Software engineering is part of System engineering• System engineering is concerned with all aspects of

computer-based systems development including – hardware, – software and – process engineering

• System engineers are involved in system specification, architectural design, integration and deployment


What is a software process?

• A set of activities whose goal is the development or evolution of software

• Generic activities in all software processes are:– Specification - what the system should do and its

development constraints– Development - production of the software system– Validation - checking that the software is what the

customer wants– Evolution - changing the software in response to

changing demands


What is a software process model?

A simplified representation of a software process,presented from a specific perspective

• Examples of process perspectives: Workflow perspective represents inputs, outputs and dependencies Data-flow perspective represents data transformation activities Role/action perspective represents the roles/activities of the

people involved in software process

• Generic process models– Waterfall– Evolutionary development– Formal transformation– Integration from reusable components


What are the costs of software engineering?

• Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs

• Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability

• Distribution of costs depends on the development model that is used


What are the attributes of good software?

• Maintainability– Software must evolve to meet changing needs

• Dependability– Software must be trustworthy

• Efficiency– Software should not make wasteful use of system resources

• Usability– Software must be usable by the users for which it was designed

The software should deliver the required functionality and performance to the user and should be maintainable,

dependable and usable


What are the key challenges facing software engineering?

Software engineering in the 21st century faces three key challenges:

• Legacy systems– Old, valuable systems must be maintained and updated

• Heterogeneity– Systems are distributed and include

a mix of hardware and software

• Delivery– There is increasing pressure

for faster delivery of software


Object-Oriented Software Engineering


What is Object Orientation?• Procedural paradigm:

– Software is organized around the notion of procedures – Procedural abstraction

• Works as long as the data is simple

– Adding data abstractions • Groups together the pieces of data that describe some entity

• Helps reduce the system’s complexity. – Such as Records and structures

• Object oriented paradigm: – Organizing procedural abstractions in the context of data

abstractions


OO Concepts - 1• Object

– encapsulates both data (attributes) and data manipulation functions (called methods, operations, and services)

• Class– generalized description (template or

pattern) that describes a collection of similar objects

• Superclass– a collection of objects

• Subclass– an instance of a class

public class Student {

int Id ;

String Name;

getStudentInfo() {

}

} // end class

Student s1,s2;


OO Concepts - 2

• Class hierarchy– attributes and methods of a superclass are inherited by its

subclasses

• Messages– the means by which objects exchange information with one

another

• Inheritance– provides a means for allowing subclasses to reuse existing

superclass data and procedures

– provides mechanism for propagating changes


OO Concepts - 3

• Polymorphism– mechanism that allows several objects in an class

hierarchy to have different methods with the same name

– instances of each subclass will be free to respond to messages by calling their own version of the method


Advantages of OO Architectures

• Implementation details of data and procedures hidden from the outside world– reduces propagation of side effects after changes

• Data structures and operators are merged in single entity or class– this facilitates reuse

• Interfaces among encapsulated objects are simplified– reduces system coupling


Class Construction Options - 1

• Build new class from scratch without using inheritance• Use inheritance to create new class from existing class

contains most of the desired attributes and operations• Restructure the class hierarchy so that the required

attributes and operations can be inherited by the newly created class


Class Construction Options - 2

• Override some attributes or operations in an existing class and use inheritance to create a new class with (specialized) private versions of these attributes and operations.


Object-Oriented Evolutionary Process Model

• Customer communication

• Planning

• Risk analysis

• Engineering construction and analysis

• Customer evaluation


Object-Oriented Software Construction

• Identify candidate classes• Look-up classes in library• Extract classes if available• Engineer classes if not available

– Object-oriented analysis (OOA)– Object-oriented design (OOD)– Object-oriented programming (OOP)– Object-oriented testing (OOT)

• Put new classes in library• Construct Nth iteration of the system


Class Candidates

• External Entities– devices or people

• Things in Problem Domain– Reports, displays, signals

• Events– completion of some task

• Roles– manager, engineer, salesperson

• Organizational Units– divisions, groups, teams

• Structures– sensors, vehicles, computers


Criteria for Including Objects

• Does object information need to be retained?

• Does object provide a set of needed services that can change its attributes?

• Does object have major (important) attributes?

• Can you identify common attributes for all object instances?

• Can you identify common operations for all object instances?

• Is it an external entity that produces or consumes information?


Object-Oriented Life Cycle Model


Management of OO Projects

• Establish a common process framework (CPF).• Use CPF & historic data to eliminate time &

effort.• Specify products & milestones.• Define Q.A. checkpoints.• Manage changes.• Monitor project.


OO Project Milestones

• Contracts completed.

• OO Analysis completed.

• OO Design completed.

• OO Programming completed.

• OO Testing completed.


OO Project Metrics

• Number of scenario scripts.

• Number of key classes.

• Number of support classes.

• (# key classes)/(# support classes).

• Number of major iterations (around spiral model).

• Number of completed contracts.


OO Estimation - 1

1. Use some effort decomposition technique (e.g. FP) to determine size estimates.

2. Use O.O.A. to develop scenario scripts and count them.

3. Use O.O.A. to get the number of key classes.

4. Categorize types of the user interfaces to determine support class multiplier:

NoUI = 2.0 TextUI = 2.25 GUI = 2.5 Complex GUI = 3.0


OO Estimation - 2

5. Estimate the number of support classes# support classes = (# of key classes) * (UI #)

6. Estimate total effortTotal effort =

(key + support) * (average # of work units per class)

7. Cross check class based estimate (6) usingTotal effort =

(avg. # of work units per script) * (# of scenario scripts)

Note: takes 15-20 days to complete each class.


1.0 Introduction to Patterns

• The recurring aspects of designs are called design patterns. – A pattern is the outline of a reusable solution to a general problem

encountered in a particular context

– Many of them have been systematically documented for all software developers to use

– A good pattern should• Be as general as possible

• Contain a solution that has been proven to effectively solve the problem in the indicated context.

Studying patterns is an effective way to learn from the experience of others


Pattern descriptionContext:

• The general situation in which the pattern applies

Problem: • A short sentence or two raising the main difficulty.

Forces: • The issues or concerns to consider when solving the problem

Solution: • The recommended way to solve the problem in the given context.

—‘to balance the forces’

Antipatterns: (Optional)• Solutions that are inferior or do not work in this context.

Related patterns: (Optional) • Patterns that are similar to this pattern.

References:• Who developed or inspired the pattern.


2.0 The Abstraction-Occurrence Pattern

– Context: • Often in a domain model you find a set of related objects

(occurrences).

• The members of such a set share common information– but also differ from each other in important ways.

– Problem: • What is the best way to represent such sets of occurrences in a class

diagram?

– Forces: • You want to represent the members of each set of occurrences

without duplicating the common information


Abstraction-Occurrence

– Solution:



• Antipatterns:



• Square variant


3.0 The General Hierarchy Pattern– Context:

• Objects in a hierarchy can have one or more objects above them (superiors),

– and one or more objects below them (subordinates).

• Some objects cannot have any subordinates

– Problem: • How do you represent a hierarchy of objects, in which some

objects cannot have subordinates?

– Forces: • You want a flexible way of representing the hierarchy

– that prevents certain objects from having subordinates

• All the objects have many common properties and operations


General Hierarchy

– Solution:


– Solution:

General Hierarchy


General Hierarchy

• Antipattern:


4.0 The Player-Role Pattern

– Context: • A role is a particular set of properties associated with an

object in a particular context.

• An object may play different roles in different contexts.

– Problem: • How do you best model players and roles so that a player

can change roles or possess multiple roles?


Player-Role

– Forces: • It is desirable to improve encapsulation by capturing the

information associated with each separate role in a class.

• You want to avoid multiple inheritance. • You cannot allow an instance to change class

– Solution:


Player-Role

• Example 1:


Player-Role

• Example 2:


Player-Role

• Antipatterns:

– Merge all the properties and behaviours into a single «Player» class and not have «Role» classes at all.

– Create roles as subclasses of the «Player» class.


5.0 The Singleton Pattern– Context:

• It is very common to find classes for which only one instance should exist (singleton)

– Problem: • How do you ensure that it is never possible to create more

than one instance of a singleton class?

– Forces: • The use of a public constructor cannot guarantee that no

more than one instance will be created.

• The singleton instance must also be accessible to all classes that require it


Singleton

– Solution:


6.0 The Observer Pattern– Context:

• When an association is created between two classes, the code for the classes becomes inseparable.

• If you want to reuse one class, then you also have to reuse the other.

– Problem: • How do you reduce the interconnection between classes,

especially between classes that belong to different modules or subsystems?

– Forces: • You want to maximize the flexibility of the system to the

greatest extent possible


Observer

– Solution:


Observer

• Antipatterns:– Connect an observer directly to an observable so

that they both have references to each other. – Make the observers subclasses of the observable.

OOSE by Prof Buddhadev

Documents

Transcript of OOSE by Prof Buddhadev