Software Engineering Principles

Ajit K Nayak, Ph.D.

ajitnayak@soauniversity.ac.in

Object oriented Software design

using UML

Acknowledgements• Slides of Prof. Rajib Mall, IIT, KGP

Introduction• Object-oriented (OO) design techniques are extremely

popular:

– Inception in early 1980’s and nearing maturity.

– Widespread acceptance in industry and

academics.

– Unified Modelling Language (UML) already an ISO

standard (ISO/IEC 19501).

Object Oriented• A system is designed as a set of interacting objects:

– Often, real-world entities: e.g. an employee, a book

etc.

– Can be conceptual objects also: e.g. Controller,

manager, etc.

• Objects consists of data (attributes) and functions (methods) that operate on data.

– Encapsulation

• Hides organization of internal information

– Data abstraction

Model of an Object

Data

Class

m8 m7

m6

m5

m4m3

m2

m1

mi are methodsof the class

Components of Object Model• Class

• Methods & Messages

• Relations

– Inheritance

– Association

– Aggregation/composition

– Dependency

• Polymorphism

• Genericity

Advantages of Object-Oriented Development

• Code and design reuse

• Increased productivity

• Ease of testing and maintenance

• Better understandability

• Elegant design: – Loosely coupled, highly cohesive objects:

– Essential for solving large problems.

• Initially incurs higher costs– After completion of some projects reduction in cost

become possible

• Using well-established OO methodology and environment:– Projects can be managed with 20% -- 50% of traditional

cost of development.

Object modelling using UML• Unified Modeling Language is a modelling language

– Not a system design or development methodology

• Used to document object-oriented analysis and design

• Independent of any specific design methodology

• UML developed in early 1990s

– To standardize the large number of object-oriented

modelling notations that existed.

• Current version is UML2.0

• Adopted by Object Management Group (OMG) in 1997

– OMG an association of industries that promotes

consensus notations and techniques

Object Modelling Techniques

UMLBooch’s

Methodology [Booch 1991]

OOSE[Jacobson 1992]

OMT [Rumbaugh 1991]

Flash Back• Grady Booch was

working as Chief Scientist of Rational Software Corporation

• Rational Software Corporation hired James Rumbaugh from General Electric in 1994

• Ivar Jacobson joined them at Rational in 1995

• And the History is made

Booch

Rumbaugh

Jacobson

When you want to build a house!

What is UML• UML a graphical modelling tool, easy to understand

and construct

• It provides many diagrams to capture different views of a system

– Model is required to capture only important aspects

– Helps in managing complexity

UML 1.x Diagrams• 9 diagrams supporting 5 views

User’s View-Use CaseDiagram

Structural View- Class Diagram- Object Diagram

Implementation View- Component Diagram

Environmental View- Deployment Diagram

Behavioural View- Sequence Diagram- Collaboration Diagram

- State-chart Diagram- Activity Diagram

UML 2.0 Diagrams

UML 2.0

Diagram

Behavior

Diagram

Structure

Diagram

Class

Diagram

Composite

Structure Diagram

Object

Diagram

Activity

Diagram

Use Case

Diagram

State Machine

Diagram

Interaction

Diagram

Component

Diagram

Deployment

Diagram

Package

Diagram

Sequence

Diagram

Communication

Diagram

Interaction

Overview

Diagram

Timing

Diagram

Use Case Modelling

Use Case Model • Consists of a set of “use cases”• It is the central model:

– Other models must conform to this model

– Not really an object-oriented model

– A functional model of the system

• Use Cases are the main tasks performed by the users of the system.

• Use Cases describe the behavioral aspects of the system. • Use Cases are used to identify how the system will be

used. • Use Cases are a convenient way to document the

functions that the system must support. • Use Cases are used to identify the components (classes)

of the system.

Use Cases• Normally, use cases are independent of each other

• Implicit dependencies may exist

• Example: In Library Automation System, renew-book and reserve-book are independent use cases.– But in actual implementation of renew-book--- A check is

made to see if any book has been reserved using reserve-book.

• Other Possible Use Cases in Library information system– issue-book

– query-book

– return-book

– create-member

– add-book, etc.

Representation of Use Cases• Represented in a use case diagram

– A Use Case is represented by an ellipse

– System boundary is represented by a rectangle

– Users are represented by stick person icons (actor)‏

– Communication relationship between actor and

Use Case by a line

• External system by a stereotype

Tic-tac-toe game

Play Move

Ex1: Draw a Use Case Model• Video Store Information System supports the

following business functions:

– Recording information about videos the store owns

• This database is searchable by staff and all customers

– Information about a customer’s borrowed videos

• Access by staff and also the customer. It involves video database

searching.

– Staff can record video rentals and returns by

customers. It involves video database searching.

– Staff can maintain customer, video and staff

information.

– Managers of the store can generate various reports.

Ex1: Solution

Maintain Customers

Staff

Rent/Return Videos

Maintain Videos

Generate Reports

Customer

Manager

Search for Videos

«include»

«include»

Video Store Information System

Development of a Use Case Diagram• Identify all of the actors who will use the system.

• Interview these actors to identify the functions that they need to perform. (use cases)

• Identify scenarios (sequence of steps to accomplish a use case).

• Identify common steps within the different scenarios. Separate them into different use cases so that they can easily be included in other scenarios.

• Identify relationships between use cases.

Actors• Actor - an entity external to the system that in some

way participates in the use case. Actor represents a role that a user can play.

• An actor typically stimulates the system with input events or receives outputs from the system or does both.

• Actors are treated like classes and can be generalized.

• Primary actor: Use the system to achieve a goal. (found in left side of the use case diagram)

• Secondary actor: plays a supporting role to facilitate the primary actor to achieve their goal. (right side)

Identification of Use Cases• Actor-based:

– Identify the actors related to a system or

organization.

– For each actor, identify the processes they initiate or

participate in.

• Event-based

– Identify the external events that the system must

respond to.

– Relate the events to actors and use cases.

Factoring Use Cases• Two main reasons for factoring:

– Complex use cases need to be factored into simpler

use cases

– To represent common behaviour across different

use cases

• Three ways of factoring:

– Generalization

– Include

– Extend

Generalization• The child use case inherits the behaviour of the parent

use case.

– The child may add to or override some of the

behavior of its parent.

parent

child

Registration

Graduateregistration

Under-graduateregistration

Include• When you have a piece of behaviour that is similar

across many use cases

– Break this out as a separate use-case and let the

other ones “include” it

• Examples of use case include

– Validate user interaction

– Sanity check on sensor inputs

– Check for proper authorization

Base use case Commonuse case

<<include>>

Issue Book

Check Reservation

Renew Book

<<include>>

<<include>>

Extends• Use when a use-case optionally can do a little bit

more:

– Capture the normal behaviour

– Capture the extra behaviour in a separate use-case

– Create extends dependency

• Makes it a lot easier to understand

OrderItem

ShowCatalog

<<extend>>

Example

Place Order

Supply Customer Data

Order Product

Arrange Payment

Request Catalog

<<include>>

<<include>>

<<include>>

<<extend>>Salesperson asks for catalog

Sales PersonCash

PaymentCredit

Payment

Ex2: Course Management Software• At the beginning of each semester,

– Each professor shall register the courses that he is going to teach.

• A student can select up to four-course offerings.– During registration a students can request a course

catalogue showing course offerings for the semester.

– Information about each course such as professor, department and prerequisites would be displayed.

– The registration system sends information to the billing system so the students can be billed for the semester.

• For each semester, there is a period of time during which dropping of courses is permitted.

• Professors must be able to access the system to see which students signed up for each of their course offerings.

Register offering

Show registration

Register course

Drop Course

Student

Calendar

Course Management Software

Ex 2: Solution

See Course List

Professor

<<Extend>>

<<External>>Billing System

Use-Case Model using Packaging

UML Class Diagrams

Thank You

Class• A class represents a set of objects having similar

attributes, operations, relationships and behaviour.

• Instances are objects

• Template for object creation

• Considered as abstract data type (ADT)‏

– Examples: Employees, Books, etc.

• Sometimes not intended to produce instances:

– Abstract classes

Methods & Messages• Operations supported by an object:

– Means for manipulating the data of other objects.

– Invoked by sending a message (method call).

– Examples: calculate_salary, issue-book,

member_details, etc.

Inheritance• Allows to define a new class

(derived class) by extending or modifying existing class (base class).

• Represents generalization-specialization relationship.

• Allows redefinition of the existing methods (method overriding).

• Types

– Single/Simple; multilevel

– Multiple

LibraryMember

ResearchPostGradUnderGrad

StaffStudentsFaculty

Base Class

DerivedClasses

Association• Enables objects to communicate with each other:

– Thus one object must “know” the address of the

corresponding object in the association.

• Usually binary:

– But in general can be n-ary.

Library Member Book1 *borrowed by

Aggregation• Represents whole-part relationship

• Represented by a diamond symbol at the composite end

• Cannot be reflexive(i.e. recursive)‏

• Not symmetric

• It can be transitive

Document Line* Paragraph 1 *

Composition

• A stronger form of aggregation

– The whole is the sole owner of its part.

• A component can belong to only one whole

– The life time of the part is dependent upon

the whole.

• The composite must manage the creation and

destruction of its parts.

Order1 *

Item

Dependency• Dependency relationship can arise due to a variety of

reasons:

– Stereotypes are used to show the precise nature of

the dependency.

Type of dependency

Stereotype Description

Abstraction «abstraction» Relates two model elements, that represent the same concept at different levels of abstraction

Binding «bind» Connects template arguments to template parameters to create model elements from templates.

Realization «realize» Indicates that the client model element is an implementation of the supplier model element

Substitution «substitute» Indicates that the client model element takes place of the supplier.

Polymorphism• Denotes poly (many) morphism (forms).

• Under different situations:

– Same message to the same object can result in

different actions:

• Static binding

• Dynamic binding

Genericity Ability to parameterize class definitions.

Example: class stack of different types of elements: Integer stack

Character stack

Floating point stack

Define generic class stack:

Later instantiate as required

Thank You