2-Lecture II

(1)

Farhan Aadil

Assistant Professor

COMSATS Institute of Information Technology

Lecture 2

(2)

Lecture overview

Introduction to:

• Object oriented analysis • Object oriented design • UML

(3)

Introduction to OOAD

• The proverb “owning a hammer doesn’t make one an

architect” is especially true with respect to object technology • Knowing an object language is necessary but insufficient to

create object systems

• Its about analyzing system requirements in terms of objects and allocating responsibilities to class objects

(4)

OOA

• It emphasizes on finding requirements and problems rather than solutions

• Object oriented analysis is a process of analyzing requirements in an object oriented paradigm

• It approves some of the requirements while discards others • The requirements are represented in the form of Use cases

(5)

Use Case

• Use case consists of a paragraph or so text that presents a scenario of a single system requirement

• It is written in simple English that would help realize the

importance of the requirement and its contribution to the over all system

• There can be many use cases for a system representing its various requirements

(6)

Use Case

• Example

– Use Case “Login to System”

(7)

Persona

• Persona is an imaginary story in which the importance of the required system is highlighted.

• It is in the form of a short story

• It assumes a person with certain personal details whom the writer know

• The writer explains the problems of the person in the

persona with the current system and how it is lagging him behind

(8)

OOD

• It emphasizes on the conceptual solution in software or hardware that fulfills the requirements

• It does not give any implementation details

• Design ideas normally exclude low level details that are obvious to the intended customers

(9)

OOA vs OOD

• In OOA there is an emphasis on finding and describing objects or concepts in the problem domain

• For example in flight information system some of the objects are flights, planes and pilot

• During OOD there is emphasis on defining software objects and how they collaborate with each other to fulfill

requirements

• For example a flight object may have attributes like flight

(10)

Assigning responsibilities to objects

• It is the most critical activity

• This activity has to be performed either while drawing UML diagrams or programming

• It strongly influences the robustness, maintainability and reusability of the software components

(11)

UML

• UML is a standard diagramming notation

• UML is not OOAD or a method it is just a diagramming notation

• It is useless to learn UML but not really know how to create an excellent OO design or evaluate and improve an existing one

(12)

UML Diagrams

• Use case diagram • Activity diagram • Sequence diagram • Partial domain model • Domain model

• Class diagram

(13)

UML perspectives

• Conceptual perspective

– The diagrams are interpreted as describing things in a situation of the real world or domain of interest

• Specification perspective

– The diagrams (using same notations) describe software

abstraction or components with specifications and interfaces but no commitment to a particular implementation

• Implementation perspective

(14)

Development Process

• Given the requirements and possible activities that are to be implemented the question is how to proceed

• In this case, an agile (light, flexible) approach is used as sample of iterative development process

(15)

Iterative development process

• Iterative development process is an agile development process

• During this process development is organized in to a series of short, fixed-length mini-projects called iterations

• The outcome of each iteration is tested, integrated as executable partial system

• Each iteration includes its own requirements analysis, design, implementation and testing activities

• It is also called iterative and incremental development

(16)

Requirement Engineering Introduction

• Requirements form the basis for all software products

• Requirements engineering is the process, which enables us to systematically determine the requirements for a software product

(17)

Requirement

• Something required, something wanted or needed

– Webster’s dictionary

• There is a huge difference between wanted and needed and it should be kept in mind all the time

(18)

REQUIREMENT

1. I ‘‘hope’’ to have a car (The capability to posses a car is absent but hope exists that someday it might be possible)

2. I ‘‘wish’’ to have a car (The capability to posses a car is distinctly possible but not feasible yet)

3. I ‘‘desire’’ to have a car (The capability to posses a car exists. But there are other competing demands to cater to.)

4. I ‘‘need’’ a car (The capability exists and it is feasible. Having a car surpassed other competing demands)

5. I ‘‘require’’ a car (Possessing a car can no longer be postponed. It is essential now)

(19)

Software Requirements - 1

• A complete description of what the software system will do

describing how it will do it is represented by the software requirements

(20)

Software Requirements - 2

• Software requirements are complete specification of the

desired external behavior of the software system to be built

• They also represent External behavior of the system

(21)

Software Requirements - 3

• Software requirements may be:

– Abstract statements of services and/or constraints – Detailed mathematical functions

(22)

Software Requirements - 4

• Software requirements may be:

– Part of the bid of contract – The contract itself

– Part of the technical document, which describes a product

(23)

IEEE Definition

• A condition or capability that must be met or possessed by a system...to satisfy a contract, standard, specification, or other formally imposed document

– IEEE Std 729

(24)

Sources of Requirements

• Stakeholders

– People affected in some way by the system

• Documents

• Existing system

• Domain/business area

(25)

Levels of Software

Requirements

• Stakeholders describe requirements at different levels of detail

– “What versus How”

– “One person’s floor is another person’s ceiling”

(26)

What Versus How

26

User needs

Product space

Actual product’s behavior

(27)

Importance of Software Requirements

• The hardest single part of building a software system is

deciding what to build...No other part of the work so cripples the resulting system if done wrong. No other part is difficult to rectify later

– Fred Brooks

(28)

Examples of Requirements - 1

• The system shall maintain records of all payments made to employees on accounts of salaries, bonuses, travel/daily allowances, medical allowances, etc.

(29)

Examples of Requirements - 2

• The system shall interface with the central computer to send daily sales and inventory data from every retail store

(30)

• The system shall maintain records of all library materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, CD-ROMs, DVDs, etc.

(31)

Examples of Requirements - 4

• The system shall allow users to search for an item by title, author, or by International Standard Book Number (ISBN)

• The system’s user interface shall be implemented using a web browser

(32)

• The system shall support at least twenty transactions per second

• The system facilities which are available to public users shall be demonstrable in ten minutes or less

(33)

(34)

Kinds of Software Requirements

• Functional requirements

• Non-functional requirements • Domain requirements

• Inverse requirements

• Design and implementation constraints

(35)

(36)

Functional Requirements - 1

• Statements describing what the system does

• Functionality of the system

(37)

• Statements of services the system should provide

– Reaction to particular inputs – Behavior in particular situations

(38)

Functional Requirements - 3

• Sequencing and parallelism are also captured by functional requirements

• Abnormal behavior is also documented as functional requirements in the form of exception handling

(39)

• Functional requirements should be complete and consistent

• Customers and developers usually focus all their attention on functional requirements

(40)

Functional Requirements Example # 1

• The system shall solve a quadratic equation using the following formula

x = (-b+sqrt(b

2

– 4*a*c))/2*a

(41)

Functional Requirements Example # 2

• The user shall be able to search either the entire database of patients or select a subset from it (admitted patients, or

patients with asthma, etc.)

(42)

• The system shall provide appropriate viewers for the user to read documents in the document store

(43)

Functional Requirements Example # 4

• Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall use to access that order

(44)

• The system shall allow customers to return non-perishable items within fifteen days of the purchase. A customer must present the original sale receipt to return an item

(45)

Comments on Examples

• Notice the level of detail in different requirements described above. Some are very detailed compared to others

(46)

Comments on Examples

• Notice the ambiguity in the requirement, which uses the term ‘appropriate viewers’

• This requirement does not mention the formats of documents and types of viewers, which can be used

(47)

Comments on Examples

• Notice the ambiguity in the requirement for solving the

quadratic equation. The requirement does not speak about the possibility when the value of ‘a’ is zero

x = (-b+sqrt(b

2

– 4*a*c))/2*a

(48)

Comments on Examples

• Incomplete and ambiguous requirements are open to multiple interpretations and assumptions

• This can lead to the development of poor quality, or faulty, software products

(49)

Summary

• Requirements form the basis of all software engineering projects

• Functional requirements capture the behavioral

aspects/functions of the proposed automated system

• Functional requirements are the backbone of all software products

(50)

References

• ‘Requirements Engineering: Processes and

Techniques’ by G. Kotonya and I.

Sommerville, John Wiley & Sons, 1998

• Software Requirements: Objects, Functions,

and States by A. Davis, PH, 1993

• Software Engineering 6

th

Edition, by I.

Sommerville, 2000

• Software Engineering 5

th

Edition, by R.

Pressman