slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Engineering PowerPoint Presentation
Download Presentation
Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 64

Software Engineering - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

Object Oriented Analysis. Software Engineering. 1. Requirements and specifications goal techniques testing and metrics case studies 2. OOA : main activities and UML 3. OOA : Use-case modeling 4. OOA : Class modeling 5. OOA : Interaction modeling 6. OOA : Testing and Metrics.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Engineering' - leilani-john


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Object Oriented Analysis

Software

Engineering

  • 1. Requirements and specifications
    • goal
    • techniques
    • testing and metrics
    • case studies
  • 2. OOA : main activities and UML
  • 3. OOA : Use-case modeling
  • 4. OOA : Class modeling
  • 5. OOA : Interaction modeling
  • 6. OOA : Testing and Metrics
requirements engineering
Requirements engineering

1. Requirement engineering

User

Feedback

User

requirements

User

validation

specification

elicitation

Domain

knowledge

Domain

knowledge

Problem Domain

requirement elicitation goal

Structure communication between

client and developer

Requirement Elicitation Goal

1. Requirement engineering

= find out what the client needs + limitations

 what the client wants

  • Basic techniques
  • interviews
  • scenarios
  • rapid prototypes
requirement elicitation techniques
Requirement Elicitation techniques

1. Requirement engineering

interview

  • structured -> fixed set of close-ended questions are posed
  • unstructured-> use of open-ended questions
  • questionnaire given to group of employees-> no interaction between interviewer and interviewee possible
  • use of camera’s to find out problems at client side
requirement elicitation techniques1
Requirement Elicitation techniques

1. Requirement engineering

scenarios

= a set of “if … then”-clauses

  • Representations
  • list actions associated with scenario
  • give a sequence of expected screen shots in response to action
requirement elicitation techniques2

put together a working product, implementing a

  • subset of the expected functionality
    • include functionality visible to the usere.g. input screens, reports, ...
    • omit complexity not eliciting needse.g. input checks, file updates, consistency checks, layout, ...

modify prototype until client and developer agree

that all client needs are incorporated

Requirement Elicitation techniques

1. Requirement engineering

Rapid prototype

 build-and-fix for the prototype !

requirement elicitation techniques3

Combine with interview for optimal results !

Requirement Elicitation techniques

1. Requirement engineering

Rapid prototype

  •  replacement for specification
    • too informal
    • no written documentation !
  •  version 1 of the product
    • build-and-fix problems !!!
    • not built to host complete functionality
    • not built for (good) performance
elicitation techniques taxonomy
Elicitation techniquesTaxonomy

1. Requirement engineering

Dominant information source

Users

Domain

Ethnography

Form analysis

Natural language

Reqs of existing system

Domain analysis

Interview

Delphi technique

Task analysis

Scenario analysis

Current situation

Business Process

Redesign (BPR)

Brainstorming session

Prototyping

Future safe

requirement specification
Requirement specification

1. Requirement engineering

  • Introduction
    • Purpose
    • Scope
    • Definitions, acronyms and abbreviations
    • References
    • Overview
  • Overall Description
    • Product Perspective
    • Product Functions
    • User characteristics
    • Constraints
    • Assumptions and dependencies
    • Requirement subsets
  • Specific Requirements
requirement specification1
Requirement specification

1. Requirement engineering

3. Specific Requirements

3.1 External interface requirements

3.1.1 User interfaces

3.1.2 Hardware interfaces

3.1.3 Software interfaces

3.1.4 Communication interfaces

3.2 Functional requirements

3.2.1 User class 1

3.2.1.1 Functional Requirement 1.1

3.2.1.2 Functional Requirement 1.2

3.2.2 User class 2

3.3 Performance requirements

3.4 Design constraints

3.5 Software system attributes

3.6 Other requirements

testing metrics
Testing & Metrics

1. Requirement engineering

Testing

  • role of SQA :
    • “test” that relevant client personnel is involved
    • are requirements consistent ?
    • extract tests out of requirements (“validation tests”)

Metrics

  • number of new/changed requirements per unit of time
  • number of new/changed requirements AFTER completion of requirement phase
  • rapid prototyping : keep track of user interaction
case i home alarm system

Describe a set of scenario’s

?

?

Case I Home alarm system

1. Requirement engineering

Problem description

  • We want to make a system to give warnings (alarm goes
  • off) in case of emergency. Emergencies can be :
  • fire
  • flooding
  • illegal entry
  • ...

Problem

case ii the in famous elevator problem

Describe a set of scenario’s

?

?

Case II The (in)famous elevator problem

1. Requirement engineering

Problem description

?

  • Software to control an elevator is requested. The elevator
  • is to serve N floors, and has two types of control buttons :
  • buttons in the elevator : to select destination floor
  • buttons in the hall : to request an “elevator service”

Problem

case iii courses students and professors

Describe a set of scenario’s

?

?

Case III Courses, Students and Professors

1. Requirement engineering

Problem description

?

A software tool to manage courses, students and lecturers

is to be built. A student can (de)register to any course, and

each course is given by a specific lecturer. The specific

lecturer for a course is entered by an administrator. Any

lecturer must be able to get

- an overview of the courses he’s supposed to organize and

- a list of students attending a specific course he/she is responsible for.

Problem

goal of ooa
Goal of OOA

2. OOA-activities

  • specify the externals of the product precisely (= specification technique)
  • architectural design (class and object identification)

How to do it ?

(1) formalize basic requirements (user-developer)

(2) identification of classes

(3) identification of class hierarchy

(4) find connections between objects

(5) modeling of object behavior

slide16

Several diagrams to model different aspects

of the software under construction

Use-case diagrams

(CRC-modeling)

Class diagrams

Interaction diagrams

State diagrams

UML ?

2. OOA-activities

Visual modeling of software

(1) formalize basic requirements

(2) identification of classes

(3) identification of class hierarchy

(4) find connections between objects

(5) modeling of object behavior

concept
Concept

3. Use-case diagram

Goal

Present requirements as seen from the user

in a diagram, unambiguously

= user model view

  • define functional requirements of the system
  • describe clear and unambiguously interaction between user and system
  • provide basis for validation testing

Use-case diagram =

Actor + use-cases

actors
Actors

3. Use-case diagram

= a role any external “user” plays interacting

with the system

  • Single physical person can play many roles
  • User can be a physical person or other (external) software/hardware system

THE SYSTEM

case iii courses students and professors1
Case IIICourses, Students and Professors

3. Use-case diagram

Problem

?

?

Find the actors !

CourseAdministration

case iii courses students and professors2
Case IIICourses, Students and Professors

3. Use-case diagram

Solution

?

CourseAdministration

use case

Scenarios helpful to find use-cases

Identify external events and deduce use-cases

Use-case

3. Use-case diagram

  • = externally required functionality (usually required by a -set of- actors)
  • typically describes a goal/objective of an actor

How to find use-cases ?

Scenario is implementation of use-case

System responds to external events

use case diagram
Use-case diagram

3. Use-case diagram

Actor 2 requires

functionality of use-case 4

case iii courses students and professors3
Case IIICourses, Students and Professors

3. Use-case diagram

Problem

?

?

Find use-cases !

case iii courses students and professors4
Case IIICourses, Students and Professors

3. Use-case diagram

Solution

?

extends
<<extends>>

3. Use-case diagram

use-case A has more functionality than

use-case B

(i.e. use-case A = use-case B + modifications)

Used to express variation on normal behavior

slide26
<<uses>>

3. Use-case diagram

Use-cases A and B need functionality of use-case C

Used to avoid repetition of same functionality

UML 2.0 : <<include>> replaces <<uses>>

use case and scenarios
Use-caseand scenarios

3. Use-case diagram

+

Use-case diagram

Scenario’s

Use case 1

Use case 2

Use case 3

use case and scenarios1
Use-caseand scenarios

3. Use-case diagram

Use case title

Main Success Scenario

1. Step 1

2. Step 2

Extensions

<MSS-step> [condition for alternative]

.1 : Step 1

.2 : Step 2

. : …

.X : return to MSS step …

<MSS-step> [ …]

Pre-conditions

Post-conditions

Triggers

Use case 1

concept1

Techniques

  • noun extraction
  • CRC-cards
  • UML class diagram
Concept

4. Class modeling

Goal

  • find essential classes and attributes
  • find structure and hierarchy of classes

= static “data oriented” view

class identification
Class identification

4. Class modeling

Major class categories

  • External entities producing/consuming information
  • Things part of the problem domain
  • Occurrences/events during system operation
  • Roles played by people interacting with the system
  • Organizational units relevant to the application
  • Places
  • Structures aggregating objects or defining relations between objects
class identification1

class-candidates

Class identification

4. Class modeling

Noun extraction

  • Make a small text describing the problem, together with major requirements (10-20 lines).
  • Isolate all nouns from this text.
  • Remove :
  • nouns relating to non-physical, abstract entities
  • nouns relating to physical entities outside the problem domain
  • Only first indication !
class identification2
Class identification

4. Class modeling

CRC-cards

= Class-Responsibility-collaboration card

For each class fill in form

Class name :

Class type :

Class characteristic :

responsibilities :

collaborations :

Describe the functionality

of the class

List other classes needed

to achieve this functionality

class identification3
Class identification

4. Class modeling

CRC-cards

Show collaborations in diagram

Find new

classes/collaborations/responsibilities

by “role play” (based on scenario’s)

case iii courses students and professors5
Case IIICourses, Students and Professors

4. Class modeling

Problem

?

  • Include password based authentication.
  • All users identified by a unique number.
  • Update use-case diagram !
  • Identify classes by :
  • writing small text (10-20 lines)
  • noun extraction
case iii courses students and professors6
Case IIICourses, Students and Professors

4. Class modeling

Solution

Original Use-case diagram

?

case iii courses students and professors7
Case IIICourses, Students and Professors

4. Class modeling

Solution

Updated Use-case diagram

?

case iii courses students and professors8
Case IIICourses, Students and Professors

4. Class modeling

Solution

?

Descriptive text (10-20 lines)

A system to administrate courses is to be constructed. A user

requesting/supplying information from/to the system must

identify himself using a password, which is checked. If found OK,

the user gets access to the system and sees a menu.Each user has a unique identification number.

The administrator of the system is responsible for defining the

course-instructor relationship, and has essentially access to all

information in the system (read and write).

Students can register or deregister for any course. A professor can

get a list of students for a specific course he teaches, and can also

get a list of courses he teaches.

case iii courses students and professors9
Case IIICourses, Students and Professors

4. Class modeling

Solution

?

Extract nouns

A system to administrate courses is to be constructed. A user

requesting/supplying information from/to the system must

identify himself using a password, which is checked. If found OK,

the user gets access to the system and sees a menu.

Each user has a unique identification number.

The administrator of the system is responsible for defining the

course-instructorrelationship, and has essentially access to all

information in the system (read and write).

Students can register or deregister for any course. A professorcan

get a listof students for a specific course he teaches, and can also

get a list of courses he teaches.

case iii courses students and professors10

CourseAdministration

IDNumber

SAME

Case IIICourses, Students and Professors

4. Class modeling

Solution

Candidate classes

?

System

Course

User

Information

Password

Access

Administrator

Instructor

Relationship

Student

Professor

List

Number

Menu

Abstract

Abstract

Abstract

Existing class (Vector or [ ])

case iii courses students and professors11
Case IIICourses, Students and Professors

4. Class modeling

Solution

?

Candidate classes

CourseAdministration

Course

User

Password

Administrator

Student

Professor

IDNumber

Menu

attributes

Fundamental question

What items are needed to uniquely and

completely define an object of the class ?

Attributes

4. Class modeling

For each class find its (essential) attributes

Sources ?

  • problem description used for class extraction
  • CRC-card functionality description
case iii courses students and professors12
Case IIICourses, Students and Professors

4. Class modeling

Problem

?

Make a CRC-card for the Course candidate class

and find attributes.

case iii courses students and professors13
Case IIICourses, Students and Professors

4. Class modeling

Solution

?

Course

Class name :

responsibilities :

collaborations :

Store/change/give course title

Administrator

Store/change/give instructor

Administrator, Professor

Store/change/give subscribed Students

Administrator, Professor, Student

case iii courses students and professors14
Case IIICourses, Students and Professors

4. Class modeling

Solution

?

Student

Class name :

responsibilities :

collaborations :

Manage password

Password

Store/change/give first name& family name

Store/give unique ID number

IDNumber

(De)register to course

Course

Give list of courses to attend

Course

case iii courses students and professors15
Case IIICourses, Students and Professors

4. Class modeling

Solution

?

Professor

Class name :

responsibilities :

collaborations :

Manage password

Password

Store/change/give first name& family name

Store/give unique ID number

IDNumber

Give list of own courses to give

Course

Give student list for own course

Course, Student

case iii courses students and professors16
Case IIICourses, Students and Professors

4. Class modeling

Problem

?

Draw class diagram.

Add navigability, composition, aggregation.

Golden Rule of software engineering applies :

Don’t use all possible features !

KEEP IT SIMPLE

concept2
Concept

5. Interaction Diagrams

Goal

  • to find out how objects interact as a function of time
  • to combine scenario’s (dynamic) and class structure (static)

Two types of diagrams

  • sequence diagram
  • collaboration diagram

UML notation for objects

Object named c from class B

Any object from class B

sequence diagram

Possible JAVA-implementation

...

b.f();

c.g();

Sequence Diagram

5. Interaction Diagrams

  • show message passing between objects
  • drawn as a function of time
  • creation of new objects indicated
  • can contain messages to actors

class C {

...

public void g() {

D d = new D();

d.h();

}

...

}

class D {

public D() {

h();

}

public void h() {…}

}

Object lifeline

Return optional

sequence diagram1
Sequence Diagram

5. Interaction Diagrams

Adding control information

Possible JAVA-implementation

condition

if (OK==true) b.f( );

iteration

B[ ] b = new B[size];

for(int i=0;i<size;i++) b[i].f( );

case iii courses students and professors17
Case IIICourses, Students and Professors

5. Interaction Diagrams

Problem

?

Make a scenario for password authentication

Transform into a sequence diagram.

List consequences to CRC-card for Password class.

case iii courses students and professors18
Case IIICourses, Students and Professors

5. Interaction Diagrams

Solution

?

Authentication scenario

0. System starts up, CourseAdministration object created

1. Password object created

2. Password object asks user for login ID and password

3. Password object checks validity -> not valid

4. Password object asks user for login ID and password

5. Password object checks validity -> valid

6. Password object returns

case iii courses students and professors19
Case IIICourses, Students and Professors

5. Interaction Diagrams

Solution

?

sequence diagram2
Sequence Diagram

5. Interaction Diagrams

Activation bars

Show which entities are active (“running”)

= at least 1 object method on call stack

a:A

b:B

c:C

Self call

Call

Back

sequence diagram3
Sequence Diagram

5. Interaction Diagrams

Found messages

= first message from causing the sequence diagram to “start”

a:A

b:B

Destruction

b:B

b:B

implicit

explicit

sequence diagram4
Sequence Diagram

5. Interaction Diagrams

UML 2.0

  • no objects are represented in sequence diagrams (hence no underlining)
  • completely new syntax to show control information (using interaction frames)
  • method calls represented differently

UML 1.4

UML 2.0

Synchronous call

Asynchronous call

collaboration diagram
Collaboration Diagram

5. Interaction Diagrams

  • shows messages between objects
  • messages numbered to show sequence
  • more layout freedom (used to clarify relation between objects)
  • messages can be labeled with control info (condition and iteration)

UML 2.0 : “Communication Diagrams”

collaboration diagram1
Collaboration Diagram

5. Interaction Diagrams

Alternative numbering scheme to show hierarchy of messages

goal concept
Goal & Concept

5. State Diagram

To view the state of an object during the lifetime of the system

  • Diagram consists of :
    • object states
    • transitions (due to events)

Not interruptible

Transitions are labeled

Event [Guard] / Action

States are labeled

do / activity

Can be interrupted

specification

Specification document

Specification

6. Metrics & Testing

iterating

use-case

static modeling

dynamic modeling

= diagrams + rigorous description

testing

Walk through

  • team size : typically 4-6 : - specification team representative - specification manager - client - design team representative - SQA-representative [chair]
  • goal : find important faults (expertise required !)
  • documents distributed before meeting
  • reviewer makes two lists : - items not understood - items incorrect
  • document driven or driven by lists
Testing

6. Metrics & Testing

  • Nonexecution-based techniques
  • Basic idea : review by other people (experts) than specification team
testing1

for formally specified (sub)products

  • requires mathematical skills !

Prove correctness

Testing

6. Metrics & Testing

Inspection

  • team of 4 : moderator + designer + implementer + tester (SQA)
  • checklist of possible faults
  • 5 formal steps
  • 1. Overview by specification team member
  • 2. Preparation to understand to document
  • 3. Inspection : detailed discussion of document to find faults (aid : lists of typical/past faults)
  • 4. Rework to resolve all problems
  • 5. Follow-up (+checking of rework)
  • if rework > 5 % -> restart !
  • Fault statistics recorded ! (gravity, number, type)
metrics

Fundamental unknowns

metrics

Size

# pages specification document

Cost

# classes, # class methods, ...

Fault statistics

(also measure of inspection efficiency)

Duration

Effort

Quality

Past (comparable) projects

Metrics

6. Metrics & Testing

summary
Summary

Use-case identification

Dynamic modeling

Static modeling

  • sequence diagram
  • collaboration diagram
  • state diagram
  • class identification (CRC)
  • static structure (hierarchy)