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*.
8/13/2019 Ooad Unit i Notes
2/19
III CSE B Prepared by: VINOTHA S R
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
8/13/2019 Ooad Unit i Notes
3/19
3
III CSE B Prepared by: VINOTHA S R
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*.
8/13/2019 Ooad Unit i Notes
4/19
;
III CSE B Prepared by: VINOTHA S R
!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 )
8/13/2019 Ooad Unit i Notes
5/19
?
III CSE B Prepared by: VINOTHA S R
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
8/13/2019 Ooad Unit i Notes
6/19
B
III CSE B Prepared by: VINOTHA S R
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*
8/13/2019 Ooad Unit i Notes
7/19
E
III CSE B Prepared by: VINOTHA S R
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/13/2019 Ooad Unit i Notes
8/19
F
III CSE B Prepared by: VINOTHA S R
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.
8/13/2019 Ooad Unit i Notes
9/19
G
III CSE B Prepared by: VINOTHA S R
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.
8/13/2019 Ooad Unit i Notes
10/19
1D
III CSE B Prepared by: VINOTHA S R
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
8/13/2019 Ooad Unit i Notes
11/19
11
III CSE B Prepared by: VINOTHA S R
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 //=
8/13/2019 Ooad Unit i Notes
12/19
1
III CSE B Prepared by: VINOTHA S R
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$
8/13/2019 Ooad Unit i Notes
13/19
13
III CSE B Prepared by: VINOTHA S R
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.
8/13/2019 Ooad Unit i Notes
14/19
1;
III CSE B Prepared by: VINOTHA S R
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.
8/13/2019 Ooad Unit i Notes
15/19
1?
III CSE B Prepared by: VINOTHA S R
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
8/13/2019 Ooad Unit i Notes
16/19
1B
III CSE B Prepared by: VINOTHA S R
!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(
8/13/2019 Ooad Unit i Notes
17/19
1E
III CSE B Prepared by: VINOTHA S R
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
8/13/2019 Ooad Unit i Notes
18/19
1F
III CSE B Prepared by: VINOTHA S R
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
8/13/2019 Ooad Unit i Notes
19/19
1G
III CSE B Prepared by: VINOTHA S R
0he following diagram illustrates use case Include relationship
9"ample of Use 8ase 9"tend relationship
Top Related