ooad unit i notes

8/13/2019 Ooad Unit i Notes

1/19

1

III CSE B Prepared by: VINOTHA S R

DHANALAKSHMI COLLEGE OF ENGINEERINGCOMPUTER SCIENCE AND ENGINEERING

CS233!OB"ECT ORIENTED ANAL#SIS AND DESIGN

UNIT!I

I$%r&d'(%)&$ %& OOAD:

Cr)%)(a* ab)*)%y &+ a$ Ob,e(% Or)e$%ed Sy-%e.:

A critical ability of Ob,e(% Or)e$%ed de/e*&p.e$%is to skillfully a--)0$

re-p&$-)b)*)%)e-to -&+%1are &b,e(%-. It is one activity that must be performed either while

drawing a UML diagram or programming and it strongly influences the robustness,

maintainability, and reusability of software components.

A$a*y-)- a$d De-)0$:

A$a*y-)- emphasies an investigationof the pr&b*e. a$d re')re.e$%-, rather than a

-&*'%)&$!or e"ample, if a new online trading system is desired, Analysis answers the following

#uestions $

%ow will it be used& 'hat are its functions&

(Analysis( is a broad term, and it is referred as requirements analysis)an investigation of the

re#uirements* or object-oriented analysis)an investigation of the domain ob+ects*.

De-)0$ emphasies a conceptual solution)in software and hardware* that fulfills there')re.e$%-, rather than its ).p*e.e$%a%)&$. !or e"ample, a description of a da%aba-e

-(4e.aand -&+%1are &b,e(%-. esign ideas often e"clude low-level or (obvious( details obvious

to the intended consumers. Ultimately, designs can be implemented, and the ).p*e.e$%a%)&$

)such as (&de* e"presses the true and complete realied design. As with analysis, the term is best#ualified, as in object-oriented designor database design.

Useful analysis and design have been summaried in the phrase do the right thing(analysis),

anddo the thing right(design).

54a% )- Ob,e(% Or)e$%ed A$a*y-)- a$d De-)0$6

uring &b,e(%!&r)e$%ed a$a*y-)- there is an emphasis on finding and describing the ob+ects orconcepts in the problem domain. !or e"ample, in the case of the flight information system, some

of the concepts includePlane, Flight, andPilot.

uring &b,e(%!&r)e$%ed de-)0$ )or simply, ob+ect design* there is an emphasis on defining

software ob+ects and how they collaborate to fulfill the re#uirements. !or e"ample, aPlane

software ob+ect may have a tailNumber attribute and agetFlightHistory method )see !igure 1.1*.


2/19


Figure 1.1. Object-orientation emphasizes representation of objects.

D&.a)$ M&de*:

/b+ect-oriented analysis is concerned with creating a description of the domain from the

perspective of ob+ects. 0here is an identification of the concepts, attributes, and associations that

are considered noteworthy. 0he result can be e"pressed in a d&.a)$ .&de* that shows the noteworthy domain

concepts or ob+ects. !or e"ample, a partial domain model is shown in !igure 1..

. It can be noted that a domain model is not a description of software ob+ects it is avisualiation of the concepts or mental models of a real-world domain and it is also called a

(&$(ep%'a* &b,e(% .&de*.

!igure 1.. 2artial domain model of the dice game


3/19

3


54a% )- %4e UML6

0he Unified Modeling Language)UML* is a visual language for specifying, constructing

and documenting the artifacts of systems.

0he word visual in the definition is a key point - the UML is the de facto standarddiagramming notation for drawing or presenting pictures )with some te"t* related to software

primarily // software

T4ree 1ay- %& app*y UML:

78 UML a- -9e%(4 Informal and incomplete diagrams )often hand sketched on whiteboards*

created to e"plore difficult parts of the problem or solution space, e"ploiting the power of visuallanguages.

28 UML a- b*'epr)$% 4elatively detailed design diagrams used either for

1* reverse engineering to visualie and better understanding e"isting code in UML

diagrams, or for * code generation )forward engineering*. If reverse engineering, a UML tool reads the source or binaries and generates )typically*

UML package, class, and se#uence diagrams. 0hese (blueprints( can help the reader understandthe bigpicture elements, structure, and collaborations.

5efore programming, some detailed diagrams can provide guidance for code generation )e.g.,

in 6ava*, either manually or automatically with a tool. It7s common that the diagrams are used forsome code, and other code is filled in by a developer while coding )perhaps also applying UML

sketching*.

38 UML a- pr&0ra..)$0 *a$0'a0e ! 8omplete e"ecutable specification of a software system

in UML. 9"ecutable code will be automatically generated, but is not normally seen or modifiedby developers one works only in the UML (programming language.( 0his use of UML re#uires

a practical way to diagram all behavior or logic )probably using interaction or state diagrams*,

and is still under development in terms of theory, tool robustness and usability.

A0)*e .&de*)$0 emphasies UML as sketh this is a common way to apply the UML, often with

a high return on the investment of time )which is typically short*.

T4ree per-pe(%)/e- %& app*y UML:

7 C&$(ep%'a* per-pe(%)/e the diagrams are interpreted as describing things in a situation of thereal world or domain of interest.

2 Spe()+)(a%)&$ -&+%1are8 per-pe(%)/e the diagrams )using the same notation as in the

conceptual perspective* describe software abstractions or components with specifications andinterfaces, but no commitment to a particular implementation )for e"ample, not specifically a

class in 8: or 6ava*.

3 I.p*e.e$%a%)&$ -&+%1are8 per-pe(%)/e the diagrams describe software implementations in aparticular technology )such as 6ava*.


4/19

;


!igure 1.3. ifferent perspectives with UML.

C*a-- )$ d)++ere$% per-pe(%)/e:C&$(ep%'a* (*a-- ! real-world concept or thing. A conceptual or essential perspective. 0he

U2 omain Model contains conceptual classes.

S&+%1are (*a-- ! a class representing a specification or implementation perspective of a

software component, regardless of the process or method.

I.p*e.e$%a%)&$ (*a-- ! a class implemented in a specific // language such as 6ava.

U$)+)ed Pr&(e-- UP8:

A -&+%1are de/e*&p.e$% pr&(e-- describes an approach to building, deploying, and

possibly maintaining software.

0he U$)+)ed Pr&(e-- has emerged as a popular iterative software development process forbuilding ob+ect-oriented systems. In particular, the Ra%)&$a* U$)+)ed Pr&(e-- or RUP, a detailed

refinement of the Unified 2rocess, has been widely adopted. 0he U2 is very fle"ible and open, and encourages including skillful practices from other

iterative methods, such as from E;%re.e Pr&0ra..)$0 )


5/19

?


I%era%)/e a$d E/&*'%)&$ary De/e*&p.e$%:

A key practice in both the U2 and most other modern methods is )%era%)/ede/e*&p.e$%. In this lifecycle approach, development is organied into a series of short,

fi"ed-length )for e"ample, three-week* mini-pro+ects called )%era%)&$- the outcome of eachis a tested, integrated, and e"ecutable!artial system. 9ach iteration includes its own

re#uirements analysis, design, implementation, and testing activities.

0he iterative lifecycle is based on the successive enlargement and refinement of a system

through multiple iterations, with cyclic feedback and adaptation as core drivers to converge

upon a suitable system. 0he system grows incrementally over time, iteration by iteration, and

thus this approach is also known as )%era%)/e a$d )$(re.e$%a* de/e*&p.e$% )!igure 1.;*.5ecause feedback and adaptation evolve the specifications and design, it is also known as

)%era%)/e a$d e/&*'%)&$ary de/e*&p.e$%. 9arly iterative process ideas were known as spiral

development and evolutionary development @5oehm

Figure 1.4. Iterative and evolutionary development.

.

Be$e+)%- &+ )%era%)/e de/e*&p.e$%:

less pro+ect failure, better productivity, and lower defect rates shown by research into

iterative and evolutionary methods early rather than late mitigation of high risks )technical, re#uirements, ob+ectives,

usability, and so forth* early visible progress

early feedback, user engagement, and adaptation, leading to a refined system that more

closely meets the real needs of the stakeholders

managed comple"ity the team is not overwhelmed by (analysis paralysis( or very long

and comple" steps


6/19

B


the learning within an iteration can be methodically used to improve the development

process itself, iteration by iteration

54y 5a%er+a** )- -& +a)*'re pr&$e6

0here isn7t one simple answer to why the waterfall is so failure-prone, but it is stronglyrelated to a key false assumption underlying many failed software pro+ects that the

specifications are predictable and stable and can be correctly defined at the start, with low

change rates. 0his turns out to be far from accurate and a costly misunderstanding. A studyby 5oehm and 2apaccio showed that a typical software pro+ect e"perienced a ?C change in

re#uirements. And this trend was corroborated in another ma+or study of thousands of

software pro+ects, with change rates that go even higher3?C to ?DC for large pro+ects asillustrated in !igure 1.?.

!igure 1.? 2ercentage of change on software pro+ects of varying

sies.

Need +&r +eedba(9 a$d adap%a%)&$:

In comple", changing systems )such as most software pro+ects* feedback and adaptation are

key ingredients for success.

!eedback from early development, programmers trying to read specifications, andclient demos to refine the re#uirements.

!eedback from tests and developers to refine the design or models.

!eedback from the progress of the team tackling early features to refine theschedule and estimates.

!eedback from the client and marketplace to re-prioritie the features to tackle in

the ne"t iteration

U$)+)ed Pr&(e-- C4ara(%er)-%)(-

I%era%)/e a$d I$(re.e$%a*


7/19

E


0he Unified 2rocess is an iterative and incremental development process. 0he 9laboration,

8onstruction and 0ransition phases are divided into a series of timebo"ed iterations. )0he

Inception phase may also be divided into iterations for a large pro+ect.* 9ach iteration results inan inrement, which is a release of the system that contains added or improved functionality

compared with the previous release.

Although most iterations will include work in most of the process disciplines )e.g. 4e#uirements,esign, Implementation, 0esting* the relative effort and emphasis will change over the course of

the pro+ect.

U-e Ca-e Dr)/e$

In the Unified 2rocess, use cases are used to capture the functional re#uirements and to define

the contents of the iterations. 9ach iteration takes a set of use cases or scenarios from

re#uirements all the way through implementation, test and deployment.

Ar(4)%e(%'re Ce$%r)(

0he Unified 2rocess insists that architecture sit at the heart of the pro+ect team7s efforts to shape

the system. =ince no single model is sufficient to cover all aspects of a system, the Unified2rocess supports multiple architectural models and views.

/ne of the most important deliverables of the process is the e"ecutable architecture baselinewhich is created during the 9laboration phase. 0his partial implementation of the system serves

and validate the architecture and act as a foundation for remaining development.

R)-9 F&('-ed

0he Unified 2rocess re#uires the pro+ect team to focus on addressing the most critical risks early

in the pro+ect life cycle. 0he deliverables of each iteration, especially in the 9laboration phase,

must be selected in order to ensure that the greatest risks are addressed first.

Pr&,e(% L)+e(y(*e

0he Unified 2rocess divides the pro+ect into four phases$Inception

9laboration

8onstruction

0ransition

I$(ep%)&$ P4a-e

Inception is the smallest phase in the pro+ect, and ideally it should be #uite short. If the Inception2hase is long then it may be an indication of e"cessive up-front specification, which is contrary

to the spirit of the Unified 2rocess.

0he following are typical goals for the Inception phase. 9stablish a +ustification or business case for the pro+ect

9stablish the pro+ect scope and boundary conditions

/utline the use cases and key re#uirements that will drive the design tradeoffs

/utline one or more candidate architectures

Identify risks

2repare a preliminary pro+ect schedule and cost estimate


8/19

F


0he Lifecycle /b+ective Milestone marks the end of the Inception phase.

E*ab&ra%)&$ P4a-e

uring the 9laboration phase the pro+ect team is e"pected to capture a healthy ma+ority of thesystem re#uirements. %owever, the primary goals of 9laboration are to address known risk

factors and to establish and validate the system architecture. 8ommon processes undertaken in

this phase include the creation of use case diagrams, conceptual diagrams )class diagrams withonly basic notation* and package diagrams )architectural diagrams*.

0he architecture is validated primarily through the implementation of an 9"ecutable Architecture

5aseline. 0his is a partial implementation of the system which includes the core, most

architecturally significant, components. It is built in a series of small, timebo"ed iterations. 5ythe end of the 9laboration phase the system architecture must have stabilied and the e"ecutable

architecture baseline must demonstrate that the architecture will support the key system

functionality and e"hibit the right behavior in terms of performance, scalability and cost.

0he final 9laboration phase deliverable is a plan )including cost and schedule estimates* for the8onstruction phase. At this point the plan should be accurate and credible, since it should be

based on the 9laboration phase e"perience and since significant risk factors should have beenaddressed during the 9laboration phase.

0he Lifecycle Architecture Milestone marks the end of the 9laboration phase.

C&$-%r'(%)&$ P4a-e

8onstruction is the largest phase in the pro+ect. In this phase the remainder of the system is built

on the foundation laid in 9laboration. =ystem features are implemented in a series of short, time

bo"ed iterations. 9ach iteration results in an e"ecutable release of the software. It is customary towrite full te"t use cases during the construction phase and each one becomes the start of a new

iteration. 8ommon UML )Unified Modelling Language* diagrams used during this phase include

Activity, =e#uence, 8ollaboration, =tate )0ransition* and Interaction /verview diagrams. 0heInitial /perational 8apability Milestone marks the end of the 8onstruction phase.

Tra$-)%)&$ P4a-e

0he final pro+ect phase is 0ransition. In this phase the system is deployed to the target users.

!eedback received from an initial release )or initial releases* may result in further refinements to

be incorporated over the course of several 0ransition phase iterations. 0he 0ransition phase also

includes system conversions and user training. 0he 2roduct 4elease Milestone marks the end ofthe 0ransition phase.


9/19

G


A0)*e .e%4&d-:

A0)*e de/e*&p.e$% methods usually apply time bo"ed iterative and evolutionary

development, employ adaptive planning, promote incremental delivery, and include othervalues and practices that encourage agility, rapid and fle"ible response to change.

A0)*e .e%4&d- share best practices like evolutionary refinement of plans, re#uirements,

and design. In addition, they promote practices and principles that reflect an agile sensibilityof simplicity, lightness, communication, self-organiing teams, and more.

F)/e a0)*e pr)$()p*e-:

=atisfy the customer through early and continuous delivery of valuable software.

Agile processes harness change for customerHs competitive advantage.

eliver working software fre#uently

Agile software promote sustainable development

0he best,architecture,re#uirements,and designs emerge from self-organiingteams

A0)*e M&de*)$0:

0he very act of modeling can and should provide a way to better understand theproblem or solution space. 0he purpose of doing UML is to #uickly e"plore )more #uickly than

with code* alternatives and the path to a good // design. Many agile methods, such as feature-

driven evelopment, =M, and =crum include significant modeling sessions, the purpose ofmodeling is primarily support understanding and communication, not documentation. efer

simple or straightforward design problems until programming solve them while programming

and testing. Model and apply the UML for the smaller percentage of unusual, difficult, tricky

parts of the design space. 2refer sketching UML on white boards, and capturing the diagramswith a digital camera.

Model in pairs )or traids* at the whiteboard 0he purpose of modeling is to discover,

understand and share the understanding. 8reate models in parallel. !or e"ample, start sketching in one whiteboard, ynamic

Jiew UML Interaction diagram, and in another whiteboard, the static view, the UML 8lass

iagram.


10/19

1D


All prior diagrams are incomplete hints throw-away e"plorations only tested code

demonstrates the true code.

O%4er Cr)%)(a* UP pra(%)(e-:

0he idea for U2 practice is short time bo"ed iterative, evolutionary, and adaptive

development. =ome additional best practices and key ideas in U2 are 0ackle high-risk and high-value issue in early iterations

8ontinual evaluation, feedback and re#uirements from users

5uild cohesive, core architecture in early iterations

8ontinuously verify #uality test early, often and realistically

2ractice 8hange 4e#uest and 8onfiguration Management

D)++ere$% UP P4a-e-:

An U2 2ro+ect organies work and iterations across four ma+or phases$1* I$(ep%)&$ appro"imate Jision, 5usiness case, =cope, vague estimates* E*ab&ra%)&$ 4efined Jision, iterative implementation of the core architecture,

resolution of high risks, identification of most re#uirements and scope, more realistic

estimates

3* C&$-%r'(%)&$ Iterative implementation of the remaining lower risk and easierelements, and preparation for deployment

;* Tra$-)%)&$ beta tests, deployment

UP d)-()p*)$e-:

In the U2, an artifact is the general term for any work product$ 8ode, 'eb Kraphics,

=chema, 0est ocuments, diagrams, model and so on.=ome of the artifacts in the following isciplines are$

a* 5usiness Modeling 0he omain Model artifact, to visualie noteworthy

concepts in the application domain

b* 4e#uirements 0he Use 8ase Model and =upplementary specificationartifacts to capture functional and non-functional re#uirements

c* esign 0he esign Model artifact, to design the software artifacts

d* Implementation 2rogramming and building the system, not deploying it

Ca-e S%'dy: Ne;% POS -y-%e.

0he case study is the e"tKen point-of-sale )2/=* system. In this apparently straightforward

problem domain, we shall see that there are very interesting re#uirement and design problems tosolve. In addition, it is a realistic problem organiations really do write 2/= systems using

ob+ect technologies.

A 2/= system is a computeried application used )in part* to record sales and handle payments

it is typically used in a retail store. It includes hardware components such as a computer and barcode scanner, and software to run the system. It interfaces to various service applications, such as


11/19

11


a third-party ta" calculator and inventory control. 0hese systems must be relatively fault-tolerant

that is, even if remote services are temporarily unavailable )such as the inventory system*, they

must still be capable of capturing sales and handling at least cash payments )so that the businessis not crippled*.

Ar(4)%e(%'ra* Layer- a$d Ca-e S%'dy E.p4a-)-

A typical ob+ect-oriented information system is designed in terms of several architectural layers

or subsystems )see !igure 3.1*. 0he following is not a complete list, but provides an e"ample$ U-er I$%er+a(eNgraphical interface windows.

App*)(a%)&$ L&0)( a$d D&.a)$ Ob,e(%->software ob+ects representing domain concepts )for

e"ample, a software class named "ale) that fulfill application re#uirements.

Te(4$)(a* Ser/)(e-Ngeneral purpose ob+ects and subsystems that provide supporting technicalservices, such as interfacing with a database or error logging. 0hese services are usually

application-independent and reusable across several systems.

//A> is generally most relevant for modelling the application logic and technical service

layers.0he e"tKen case study primarily emphasies the problem domain ob+ects, allocating

responsibilities to them to fulfill the re#uirements of the application./b+ect-oriented design is also applied to create a technical service subsystem for interfacing with

a database.

In this design approach, the UI layer has very little responsibility it is said to be thin. 'indowsdo not contain code that performs application logic or processing. 4ather, task re#uests are

forwarded on to other layers.

!ig.3.1 sample layers and ob+ects in an //=


12/19

1


I$(ep%)&$:

9nvision the product scope, vision, and business case.o the stakeholders have basic agreement on the vision of the pro+ect, and is it worth investing

in serious investigations&

0he purpose of inception stage is not to define all the re#uirements. 0he Up is not thewaterfall and the first phase inception is not the time to do all re#uirements or create believable

estimates or plans. 0hat happens during elaboration.

0he intent of inception is to establish some initial common vision for the ob+ectives of thepro+ect, determine if it is feasible, and decide if it is worth some serious investigation in

elaboration. It can be brief.

Re')re.e$%-:

4e#uirements are capabilities and conditions to which the system and more broadly, the

pro+ect must conform.

0he U2 promotes a set of best practices, one of which is to manage re#uirements. In the conte"t of changing and unclear stakeholderHs wishes Managing re#uirements

means a systematic approach to finding, documenting, organiing, and tracking the

changing re#uirements of a system. A prime challenge of re#uirements analysis is to find, communicate, and remember )0o

write down* what is really needed, in a form that clearly speaks to the client and development

team members.Types and categories of requirements:

In the U2, re#uirements are categoried according to the !U42=O model @KradyG, a useful

mnemonic with the following meaning$


13/19

13


F'$(%)&$a* ! features, capabilities, security.

U-ab)*)%y ! human factors, help, documentation.

Re*)ab)*)%y ! fre#uency of failure, recoverability, predictability.

Per+&r.a$(e ! response times, throughput, accuracy, availability, resource usage.

S'pp&r%ab)*)%y ! adaptability, maintainability, internationaliation,

configurability.

0he (O( in !U42=O indicates ancillary and sub-factors, such as$

I.p*e.e$%a%)&$ resource limitations, languages and tools, hardware, ...

I$%er+a(e constraints imposed by interfacing with e"ternal systems.

Opera%)&$- system management in its operational setting.

Pa(9a0)$0 for e"ample, a physical bo".

Le0a* licensing and so forth.

It is helpful to use !U42=O categories )or some categoriation scheme* as a checklist for

re#uirements coverage, to reduce the risk of not considering some important facet of the system.

=ome of these re#uirements are collectively called the 'a*)%y a%%r)b'%e-= 'a*)%y

re')re.e$%-, or the (- ilities( of a system. 0hese include usability, reliability, performance, and

supportability. In common usage, re#uirements are categoried as +'$(%)&$a* )behavioral* or

$&$!+'$(%)&$a* )everything else* some dislike this broad generaliation @58PGF, but it is very

widely used.

Key requirement artifacts:

U-e!Ca-e M&de*- A set of typical scenarios of using a system. 0here are primarily for

functional )behavioral* re#uirements.

S'pp*e.e$%ary Spe()+)(a%)&$- 5asically, everything not in the use cases. 0his artifact isprimarily for all non-functional re#uirements, such as performance or licensing. It is also the

place to record functional features not e"pressed )or e"pressible* as use cases for e"ample, a

report generation.

G*&--ary- In its simplest form, the Klossary defines noteworthy terms. It also encompasses theconcept of the data dictionary, which records re#uirements related to data, such as validation

rules, acceptable values, and so forth. 0he Klossary can detail any element$ an attribute of an

ob+ect, a parameter of an operation call, a report layout, and so forth.

V)-)&$ - =ummaries high-level re#uirements that are elaborated in the Use-8ase Model and

=upplementary =pecification, and summaries the business case for the pro+ect. A short

e"ecutive overview document for #uickly learning the pro+ect7s big ideas.

B'-)$e-- R'*e-- 5usiness rules )also called omain 4ules* typically describe re#uirements orpolicies that transcend one software pro+ect they are re#uired in the domain or business, and

many applications may need to conform to them. An e"cellent e"ample is government ta" laws.omain rule details maybe recorded in the =upplementary =pecification, but because they are

usually more enduring and applicable than for one software pro+ect, placing them in a central

5usiness 4ules artifact )shared by all analysts of the company* makes for better reuse of the

analysis effort.


14/19

1;


U-e Ca-e-:

Informally, '-e (a-e-are text storiesof some a(%&rusing a -y-%e.to meet 0&a*-.

Use Case Example:

Pr&(e-- Sa*e$ A customer arrives at a checkout with items to purchase. 0he cashier uses

the POSsystem to record each purchased item. 0he system presents a r'$$)$0 %&%a*and*)$e!)%e.details. 0he customer enters pay.e$%information, which the system validates

and records. 0he system updates i$/e$%&ry. 0he customer receives a re(e)p%from the

system and then leaves with the items.otice that use cases are not diagrams they are text!ocusing on secondary-value UML

use case diagrams rather than the important use case te"t is a common mistake for use

case novices.

Use cases often need to be more detailed or structured than this e"ample, but the essence

is d)-(&/er)$0 a$d re(&rd)$0 +'$(%)&$a* re')re.e$%- by 1r)%)$0 -%&r)e-of using a

system to fulfill user goals that is, ases o# use.


15/19

1?


De+)$)%)&$: 54a% are A(%&r-= S(e$ar)&-= a$d U-e Ca-e-6

I$+&r.a* de+)$)%)&$-:

A$ a(%&ris something with behavior, such as a person )identified by role*, computer

system, or organiation for e"ample, a cashier.

A -(e$ar)&is a specific se#uence of actions and interactions between actors and thesystem it is also called a use case instance. It is one particular story of using a system, or

one path through the use case for e"ample, the scenario of successfully purchasing items

with cash, or the scenario of failing to purchase items because of a credit payment denial.

Informally then, a '-e (a-eis a collection of related success and failure scenarios that

describe an actor using a system to support a goal


16/19

1B


!efinition of a use case provided by the "U#:

A set of use-case instances, where each instance is a se#uence of actions a system

performs that yields an observable result of value to a particular actor @4U2.

U-e!(a-e M&de*)$0:U-e!Ca-e M&de*is the set of all written use cases it is a model of the system7s

functionality and environment. U-e (a-e-are %e;% d&('.e$%-= $&% d)a0ra.-, and use-

case modeling is primarily an act of 1r)%)$0 %e;%, not dra1)$0 d)a0ra.-.

0he Use-8ase Model is not the only re#uirement artifact in the U2. 0here are also the

S'pp*e.e$%ary Spe()+)(a%)&$= G*&--ary= V)-)&$= a$d B'-)$e-- R'*e-. 0hese are all

useful for re#uirements analysis, but secondary at this point.

0he Use-8ase Model may optionally include a UML '-e (a-e d)a0ra.to show the

$a.e- of '-e (a-e- a$d a(%&r-= a$d %4e)r re*a%)&$-4)p-0his gives a nice (&$%e;%

d)a0ra.of a system and its environment. It also provides a #uick way to list the usecases by name.

0here is nothing ob+ect-oriented about use cases we7re not doing // analysis when

writing them. Use cases are a key re#uirements input to classic //A>.

Three Kinds of $ctors:

A(%&r- are roles played not only by people, but by organiations, software, and

machines. 0here are three kinds of e"ternal actors in relation to the =u$

78 Pr).ary a(%&r has user goals fulfilled through using services of the =u. !ore"ample, the cashier.

'hy identify& 0o find user goals, which drive the use cases

28 S'pp&r%)$0 a(%&rprovides a service )for e"ample, information* to the =u. 0heautomated payment authoriation service is an e"ample. /ften a computer system,

but could be an organiation or person.

'hy identify& 0o clarify e"ternal interfaces and protocols.

38 O++-%a0e a(%&r has an interest in the behavior of the use case, but is not primary

or supporting for e"ample, a government ta" agency.

'hy identify& 0o ensure that all necessary interests are identified and satisfied.

Three Common use case formats:

1* Br)e+!0erse one-paragraph summary, usually of the main success scenario.

* Ca-'a*-Informal paragraph format. Multiple paragraphs that cover variousscenarios.

3* F'**y dre--ed-All steps and variations are written in detail, and there are

supporting sections, such as preconditions and success guarantees.

#reconditions and %uccess &uarantees '#ostconditions(


17/19

1E


Pre(&$d)%)&$-state what must alwaysbe true before a scenario is begun in the use case.

2reconditions are not tested within the use case rather, they are conditions that are

assumed to be true. 0ypically, a precondition implies a scenario of another use case, suchas logging in, that has successfully completed.

S'((e-- 0'ara$%ee- &r p&-%(&$d)%)&$-8state what must be true on successfulcompletion of the use case either the main success scenario or some alternate path. 0he

guarantee should meet the needs of all stakeholders.

9


18/19

1F


F)0're 7 Par%)a* '-e (a-e (&$%e;% d)a0ra.

I$(*'de Re*a%)&$-4)p:Use cases can be related to each other.

It is common to have some partial behavior that is common across several use cases. !ore"ample, the description of paying by credit occurs in several use cases, includingProess "ale,

Proess $ental, %ontribute to Lay&away Plan, and so forth. 4ather than duplicate this te"t, it is

desirable to separate it into its own sub function use case, and indicate its inclusion. 0his issimply refactoring and linking te"t to avoid duplication.

0he include relationship can be used for most use case relationship problems.

0o summarie$!actor out sub function use cases and use the'nlude relationship when$

0hey are duplicated in other use cases.

A use case is very comple" and long, and separating it into subunits aids comprehension.

E;%e$d Re*a%)&$-4)p

9"tend puts additional behavior in a use case that does not know about it.

It is shown as a dotted line with an arrow point and labeled QQe"tendRR

In this case, a customer can re#uest a catalog when placing an order


19/19

1G


0he following diagram illustrates use case Include relationship

9"ample of Use 8ase 9"tend relationship

ooad unit i notes

Documents