Slides

James Nowotarski

18 September 2008

SE 325/425Principles and

Practices of Software Engineering

Autumn 2008

2

Topic Duration

Key models/frameworks (cont.) 60 minutes

Requirements process 30 minutes

*** Break

Requirements process (cont.) 90 minutes

Wrap-up

Today’s Agenda

3

“Why write your own application for word processing or e-mail or, for that matter, supply-chain management when you can buy a ready-made, state-of-the-art application for a fraction of the cost?”

“…more companies [are] replac[ing] customized applications with standardized ones”

Source: Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review, 81(5), 41-49.

Does SE Matter?

4

Who is Fritz Bauer?

• Chairman of 1968 NATO Software Engineering Conference

• Credited with coining the term “software engineering”

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 5

What is software engineering?

l Software engineering is an engineering discipline that is concerned with all aspects of software production.

l Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.

6

Software Engineering Body of Knowledge

Software requirementsSoftware designSoftware constructionSoftware testingSoftware maintenanceSoftware configuration managementSoftware engineering managementSoftware engineering processSoftware engineering tools and methodsSoftware quality

Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.org

What is SE?

tonight

7

IT OutsourcingBest jobs in America

1. Software engineer

2. College professor

3. Financial adviser

4. Human resources manager

5. Physician’s assistant

6. Market research analyst

7. Computer/IT analyst

8. Real estate appraiser

9. Pharmacist

10. Psychologist

Source:Kalwarski, T., Mosher, D., Paskin, J. & Rosato, D. (2006, May). 50 best jobs in America. Money. Retrieved September 8, 2008, from http://money.cnn.com/magazines/moneymag/bestjobs/2006/

8

Technology

ProcessPeople

The software engineering discipline consists of people, process, and technology components

Core Concepts

9

Technology1

ProcessPeople

The focus of SE 425 is the process component of software engineering

Core Concepts

Technology1

ProcessPeople

… for the delivery of technology-enabled business solutions

1 SE is primarily concerned with the software subset of technology

10

Systems development life cycle (SDLC) A description of the phases of an

information system

Planning Modeling Construction Deployment

Example

Core Concepts

SDLC is another synonym for software process

11

SDLC model

• The iteration and control strategy adopted by a systems development initiative

• Examples- Waterfall- Iterative/Evolutionary/Spiral- Incremental- Agile

Core Concepts

12

The waterfall model is the granddaddy of life cycle models

Core Concepts

Planning

Modeling

Construction

Deployment

13

Protracted integration and late breakage

Conventional application of the waterfall model typically results in late integration and performance showstoppers

Dev

elop

men

t p

rogr

ess

(% c

oded

)

100%Late designbreakage

Original target date

Source: Royce, W. (1998). Software project management: A unified framework. Addison-Wesley.

Integrationbegins

What’s wrong with waterfall?

14

Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

15

Incremental life cycle models advocate delivering the end product piecemeal

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

16

Waterfall model

Systemrequirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

Source: Royce, W. (1970). "Managing the Development of Large Software Systems."

17

Rational Unified Process (RUP)

18

RUP Guiding Principles

IterativeDevelopment

QualityCustomerValue

Attack riskAccommodatechange

Work togetherExecutablesoftware

Architecturebaseline

Component-baseddevelopment

Objectives

Strategies

Tactics

19

In RUP, end product is the result of development cycles

Version 1

Development CycleVersion 2

Development CycleVersion 3

Development Cycle

Product delivered to users

20

Development cycle consists of phases

Development Cycle

Inception Elaboration Construction Transition

21

Phase consists of IterationsDevelopment Cycle

Elaboration

Iterationn Iterationn+1

22

Iteration consists of ActivitiesDevelopment Cycle

Elaboration

Iterationn+1IterationnR

A&D

C

T

R

A&D

C

T

Each phase contains one or more iterations

23

Each Iteration is a mini-waterfall

R

A&D

C

T

R

A&D

C

T

R

A&D

C

T

24

Iterative Advantages/Disadvantages

Advantages

Disadvantages

26Copyright © 1997 by Rational Software Corporation

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Time

Risk Profile: Iterative vs. Waterfall

Iterative

27

Is RUP = Waterfall in disguise?

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Inception

Elaboration

Construction

Transition

28

Phase boundaries in waterfall are activities

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

29

Phase boundaries in RUP are milestones

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

30








Objectives

Strategies

Tactics

31

Why focus on risk and change?

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

32








Objectives

Strategies

Tactics

33

Why emphasis on executable software?

“Without this first pass, the project manager is at the mercy of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design . . . is invariably and seriously optimistic”

34

RUP Artifacts by Phase and Discipline

Discipline Inception Elaboration Construction TransitionBusiness Modeling

RequirementsVisionUse Cases (20-80%)ActorsSoftware Req SpecGlossary

Analysis & Design Software Arch Doc

Implementation

Build PlanBuildTest Results

Test

Test PlanTest ScriptTest DataTest Results

Test Strategy

DeploymentDeployment Plan Training Materials

Support MaterialsAcceptance Test ResultsChange Requests

Product

Executable ArchitectureUser Interface PrototypeUser Interface DesignUse Case RealizationDesign ModelDatabase Design

Business Architecture

35

RUP Artifacts by Phase and Discipline

Discipline Inception Elaboration Construction Transition

Configuration and Change Management

Project Management Risk ListRisk Mgmt PlanBusiness CaseQA PlanSoftware Dev Plan

Environment

Dev Case (Process)ToolsGuidelinesTemplatesSupport

CM PlanCM EnvironmentChange Requests

36

Agile/Light/Lean Methods

Agile Software Development “Manifesto”

“We have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan”

-- Agile Software Development Alliance, February 11-12, 2001, meeting at Snowbird ski resort

37

Approach References

XP www.extremeprogramming.org

www.xprogramming.com

M. Marchesi et al, Extreme Programming Perspectives, Addison-Wesley, 2002.

Crystal A. Cockburn, Agile Software Development, Addison-Wesley, 2001

SCRUM K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.

Adaptive Software Development

J. Highsmith, Adaptive Software Development, Dorset House, 2000.

FDD S. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall, 2002.

Agile - General http://www.agilealliance.org/home

http://www.agilemodeling.com

Agile/Light/Lean Methods

39








Objectives

Strategies

Tactics

40

XP Conceptual Framework







Objectives

Strategies

Practices

41

Phase boundaries in waterfall are activities

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

42

Phase boundaries in RUP are milestones

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

43

XP winds the RUP model more tightly

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Each day on an XP project

FunctioningCode

44

What is XP

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

RUP – “In general, as the project progresses, you should be more careful about introducing change”

45

What is XP

Time

Co

st

of

ch

an

ge

XP purports to change the curve so that the cost to find and repair software problems does not rise dramatically over time

46

What is XP

Quality is assumedExcellent, orInsanely excellent

Quality Work

47

What is XP

Test all the time Continuous integration Pair programming Coding standards Collective ownership Do simplest thing that will work today

“design tomorrow for tomorrow’s problems” Metaphor to aid in understanding the architecture Refactoring and evolutionary design

Key Practices/Features

48

What is XP

Customer on-site as integral part of team Incremental planning

learning to driveprogrammers provide estimates

Short iterations, small releases2 month releases, 2 week iterations

40-hour week

Key Practices/Features (cont.)

49

What is XP

Start design with a test Start coding with a test Test things that might break Testing is isolated Testing is integrated Testing is automated At least one dedicated tester

Begin with the end in mind . . .

50

“Cruft is not allowed to accumulate”

DefinitionAn unpleasant substance, e.g., the dust

that accumulates under your bedResults of shoddy constructionExcess, superfluous junk, e.g., redundant

or superseded code Which XP practice(s) does this pertain

to?

51

RUP vs. XP

Attribute RUP (“Heavyweight”) XP (“Lightweight”)

Time and Effort Allocation 2 weeks-6 months 2 weeks - 2 months

Architecture Stabilized during Elaboration phase

Just enough to support functionality

Scope of Activities and Artifacts

Broad Narrow

Few, simple. Omits: Business modeling Deployment

Project size Small to Very Large Small to Medium

Artifacts 25-30 in small project roadmap

roughly 30

Roles ~ 30 (5 in small project roadmap)

7

52

Topic Duration

Key models/frameworks (cont.) 60 minutes

Requirements process 30 minutes

*** Break

Requirements process (cont.) 90 minutes

Wrap-up

Today’s Agenda

53

Quote

“The hardest single part of building software is deciding what to build” – Fred Brooks

54

Areas of most disruptive change

Software requirements Program design

- Winston W. Royce

55

Context

Communication project initiation requirements

Modeling analysis design

Construction code test

Deployment delivery support

Planning & Managing

56

Context





Planning & Managing

elicitation Requirementsengineeringtasks (Ch. 7-8)

57

Context





Planning & Managing

elicitationRequirementsengineeringtasks (Ch. 7-8)

elaborationspecification

Chapter 7

Chapter 8

58

Context





Planning & Managing

elicitationRequirementsengineeringtasks (Ch. 7-8)

elaborationspecification

Primarydeliverables

functional reqtsnon-functional reqts(aka quality reqts)

analysis modelsoftware reqts spec(SRS)

IT project failure rates are high

59

Source: Standish Group, 2007

60

Requirements failures #1 root cause (missing and incomplete)

Dr. Dobb’s Portal (www.ddj.com)

Users expect functionality they did not initially ask for (93%)

Requirements are incomplete (89%)

Requirements are unclear or ambiguous (85%)

61

Requirements failures #1 root cause (missing and incomplete)

“[t]he focus on—and availability of—tools that manage requirements during the software development process is detracting attention from the far larger problem of whether or not requirements are accurate in the first place.” Schwaber, C. & Leganza, G. (2006, September 1). The root of the problem: Poor requirements. Forrester

Corroborated by other sources: Gartner, SEI, Standish

62

What is a requirement?

A requirement can be defined simply as a property of a system, or a constraint upon the product or process by which the system is to be created

IEEE Std 610.12-1990 defines a requirement as

A condition or capability needed by a user to solve a problem or achieve an objective.

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

63

Functional vs. Quality Requirements

A functional requirement (FR) describes what the system needs to do.

Example: ‘The system shall display the current customer balance’.

64

Functional vs. Quality Requirements

A quality requirement describes a constraint upon the solution space.

Examples: Performance, flexibility, reliability, usability, portability, maintainability, safety, and security.Also called “non-functional” requirements, “ilities”, or even “systemic” requirements. Emergent Properties: A quality requirement that is realized through the careful implementation of other requirements on which it depends. Example: “The query must return its results in less than three seconds” is only realizable once the architecture and much of the system functionality has been implemented.

65

Quote

“It’s not enough to do good. It must be done well” – St. Vincent de Paul

66

The Requirements Process

Elicitation: Proactively working with stakeholders to discover their needs, identify potential conflicts, and establish a clear scope and boundaries for the project.

Elaboration (Analysis): Gaining a deeper understanding of the product and its interactions.

Specification: Production of a series of documents that capture the system and software requirements in order to support their systematic review, evaluation, and approval.

Validation: Inspecting requirements to ensure their correctness.

Management: Issues such as software configuration management, traceability, impact analysis, and version control.

67

Key Question: Deliverables

Steps Techniques

What does the system need to do?How well does it need to do it?

Systems requirements spec, incl:- Functional requirements- Quality requirements

1. Review as-is system2. Identify requirements of

to-be system

Re-engineering AHPInterviewing PrototypingObservationSurveys/Focus GroupsJoint Application Design (JAD)Benchmarking

Elicitation

Roles Estimating guidelines

Business analyst

Begin with the end in mind - Sample SRSOverviewRevision HistoryTable of Contents1.0 Introduction

1.1 Purpose1.2 Scope1.3 References1.4 Assumptions and Dependencies

2.0 Use-Cases3.0 Requirements

3.1 Functional Requirements3.2 Quality Requirements

3.2.1 Usability3.2.2 Reliability3.2.3 Performance3.2.4 Supportability

4.0 Online User Documentation and Help System

Requirements5.0 Design Constraints6.0 Purchased Components7.0 Interfaces

7.1 User Interfaces7.2 Hardware

Interfaces7.3 Software Interfaces7.4 Communication

Interfaces8.0 Licensing Requirements9.0 Legal, Copyright, and Other

notices10.0 Applicable StandardsIndexGlossary

69

Elicitation Techniques

Collaborative sessions are useful for brainstorming and problem solving activities.

A Joint Application Design (JAD) can bring together a small group of stakeholders to form initial goals and requirements.

Helps to avoid ambiguity

Helps to reduce scope creep

70

Joint Application Design (JAD)

71


Interviewing techniques are simple yet effective.

Structured around a specific set of questions

Closed ended

Open ended

Can be conducted in stages, so that responses from the first round can be used to generate a deeper set of more focused questions for the second round.

Can be expensive

72


Observation involves observing the way users interact with an existing system.

Useful when users are unable to fully articulate their needs, or are too busy to attend other types of elicitation meetings. Observe how tasks are executed, problems, shortcuts, & areas for improvement. Sometimes referred to as “going to the gemba”Especially good for uncovering unstated requirements

“Exciting requirements” – Exceed user’s initial expectations

73


Prototyping – taking an early set of requirements and using them to elicit further requirements.

Low fidelity models useful because for very little cost you can obtain useful feedback from the user. Higher fidelity prototypes enable the user to interact with something closer to the finished product.

74


Analytic Hierarchy Process (AHP) – a mathematically-based prioritization technique

Represents the elements of any problem hierarchicallyGuides decision makers through a series of pairwise comparisonsResults in quantitative assessment of relative strength of requirements Developed by Dr. Thomas Saaty of the University of Pittsburgh

75

Elicitation Techniques: AHP

Develop QualitySoftware Goal

ArchitectureChoice 1

ArchitectureChoice 2 Alternatives

Performance Usability FlexibilityQualityreqts

76

Elicitation Techniques: AHP

Develop Software

Performance Usability Flexibility



Goal

Alternatives

Qualityreqts

.08 .64 .28

.41.59

77

Context ModelsDetermine the boundaries of the system.

What is the system?What is the system’s environment?

Develop a context model that shows the context of the system within its environment.

Auto-TellerSystem

SecuritySystem

MaintenanceSystem

Branchaccounting

System

BranchcounterSystem

AccountDatabase

UsageDatabase

78

Context Models

Understand the types of interaction the software system has with its adjacent systems.

Some adjacent systems cooperate with your system through two-way communication. Consider them black-box components of your system.

Some adjacent systems initiate events and interact with your system (i.e., people).

Some adjacent systems have one way communication but otherwise work autonomously.

Trigger events that must be specified.

Incoming communication may trigger an event to be specified. Also don’t forget TIMED events

79

Model these interactions as Use Cases

Identify actors

Model their interactions with the system.

Through elicitation fully explore all the ways each actor may interact with the system.

Banking Software Product

Withdraw Money

Customer Teller

80

Use Cases Typical interaction between a user and a computer

system Example: Word use cases

Make some text bold Create an index

Content: A few paragraphs of description Essential tool in requirements capture during Inception

and (mostly) during Elaboration Characteristics

Captures some user-visible function May be small or large Achieves a discrete goal for the user

81

Requirement Qualities

Each individual requirement should be:

Concise

Correct

Non-ambiguous

Feasible

Verifiable

Traceable

Manageable

82

Concise

A requirement should describe a single property of the desired system and should include no information beyond that necessary to describe the intended property.

It should be stated in clear, simple, and understandable terms.

Note the need to define terms such as “Emergency calls” and “Public” in the requirements definition document.

Emergency calls from the public shall be answered in the order in which they are received.

83

Correct

A requirement should accurately describe the intended property of the intended system.

No information missing that is needed to define or implement the system.

The following requirement is obviously (or at least probably should be) incorrect:

When an ambulance crew is dispatched to pick-up a patient more than 2 miles away, they shall wait three minutes before departing in order to give the dispatch operator the chance to locate a closer crew.

84

Non-ambiguous A requirement should be stated clearly and

understandably, in order to avoid ambiguous interpretations.

The following requirement is OBVIOUSLY ambiguous. Why?

How could you fix it?

When a call is received the dispatcher assigns the job to the best crew.

Shoes mustbe worn!

Dogs mustbe carried!

85

Recurring patterns in missing/incomplete requirements

Example use case: (from RAVENFLOW)

User types in a login or a validation request. The system performs the Validate User process or the Verify Password process or the Login Bypass process

If the system determines that the account is pending parental consent, (what if false?) then the system alerts the user. (how?) Note: See the “Request Parental Consent” use case for information on how the system handles this

The system displays the calling application to the user

86

Visualization

Example use case (from RAVENFLOW)

User types in a login or a validation request. The system performs the Validate User process or the Verify Password process or the Login Bypass process

If the system determines that the account is pending parental consent, (what if false?) then the system displays error #146 to the user Note: See the “Request Parental Consent” use case for information on how the system handles this

The system displays the calling application to the user

87

What is wrong with this requirement?

“The same display shall also be able to generate a visible or audible caution/warning sign for the attention of the ambulance driver or medic.”

88

Conjunctions are dangerous…

Disambiguate what the ‘and’ means…

The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or input data shall be saved.

We can separate the requirement into multiple parts…

The battery low warning lamp shall light up when the voltage drops below 3.6 Volts.

When the battery low warning lamp lights up the current workspace shall be saved.

The battery low warning lamp shall remain lit until the voltage rises above 3.7 Volts.

?? Go back to the stakeholder

89


Problems arise when readers try to puzzle out which part applies.

The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace shall be saved.

Or disambiguate…

The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and then the current workspace shall be saved.

90


What about this requirement?

An aircraft that is non-friendly and has an unknown mission or the potential to enter restricted airspace within 5 minutes shall raise an alert.

Again – disambiguate and/or precedence. Two options:

An aircraft that is non-friendly and (has an unknown mission or the potential to enter restricted airspace within 5 minutes) shall raise an alert.

If [an aircraft is non-friendly] and [has an unknown mission or the potential to enter restricted airspace within 5 minutes], the system shall <raise> <an alert>.

91

Feasible

A requirement should be feasible from a technical, financial, and managerial perspective.

The following requirement is INFEASIBLE except possibly in a James Bond movie!

This is just overly optimistic wishful thinking because we didn’t specify anything about traffic congestion, location of the patient, distance to the hospital etc.

All patients shall be delivered to a hospital within 5 minutes of their pick-up.

92

Verifiable

A requirement should be written in such a way as to provide a clear and testable acceptance criterion.

For example, it is not sufficient to specify that:

Instead, the requirement should be written in a verifiable form such as:

The dispatcher must be able to quickly identify the closest open emergency room.

The dispatcher must be able to identify the closest open emergency room within 1 second.

93

Traceable

A requirement is traceable if it has been assigned a unique ID and if it is focused on one property.

For example a requirement stating that:

creates traceability problems because it involves tracking the implementation of crew allocations and ambulance allocations.

A driver and medic shall be assigned to an ambulance crew and the crew shall be assigned to an ambulance.

Never build in let-out or escape clauses(if, when, but, except, unless, although)

The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is deployed.

The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has suppressed the alarm.

Don’t ramble

Provided that the designated input signals from the specified devices are received in the correct order where the system is able to differentiate the designators, the output signal shall comply with the required framework of section 3.1.5 to indicate the desired input state.

Refrain from designing the system

The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof hardened rubber shield.

Avoid mixing different kinds of requirements Do not speculate

Users normally require early indication of intrusion into the system.

Do not play on ambiguous requirementsAlways make requirements as clear as possible

Do not use vague undefinable termsThe print dialog shall be versatile and user-friendly

Do not express possibilitiesThe reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed building.

Avoid wishful thinkingThe gearbox shall be 100% safe in normal operationThe network shall handle all unexpected errors without crashing.

96

Manageable

Attributes should be used to support requirements management.

For example:

Date created

Date last edited

Priority (High, Mid, Low etc)

Status (Completed, Undergoing Change, Scheduled, Unassigned).

97

Qualities of a Good Set of Requirements

Realistic: The requirements should represent realistic goals at both the product and project level.

Concise: The requirements as a whole should concisely describe the system that is to be developed. Long-winded requirements create greater opportunity for ambiguity and errors.

Complete: The requirements should collectively describe the entire system to be implemented with no information missing.

Consistent: Inconsistencies between requirements lead to conflicts that prohibit all of the requirements being implemented successfully. Inconsistencies should be identified and conflicts negotiated.

98

Short demo

RAVEN (from RAVENFLOW)

Acts as central repository

Recorded demonstrations

www.ravenflow.com

www.requirementsdevelopment.com

99

Visual Modeling Using UML

Actor A

Use Case 1

Use Case 2

Actor B

user : »ç¿ëÀÚ

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

Window95

¹®¼ °ü¸® Å¬¶óÀÌ¾ðÆ®.EXE

WindowsNT

¹®¼ °ü¸® ¿£Áø.EXE

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

Alpha

UNIX

IBM

Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼ ¹ö

Windows95

¹®¼ °ü¸® ¾ÖÇÃ¸´Document

FileManager

GraphicFile

File

Repository DocumentList

FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼ ¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È ̧é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close fileUse Case 3

Use casediagram Class diagram

Collaboration diagram

Sequence diagram

Component diagram

Statechartdiagram

Deployment diagram

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

100

Read Pressman Chapter 9 Assignment 5 – First presenters

For September 25

Slides

Documents

Transcript of Slides