1 III CSE B Prepared by: VINOTHA S R

DHANALAKSHMI COLLEGE OF ENGINEERING

COMPUTER SCIENCE AND ENGINEERING CS23 3!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-)- emphasi es an investigation of the pr&b*e. a$d re2')re.e$%-, rather than a -&*'%)&$3 !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$ emphasi es a conceptual solution )in software and hardware* that fulfills the re2')re.e$%-, rather than its ).p*e.e$%a%)&$. !or e"ample, a description of a da%aba-e -(4e.a and -&+%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 reali ed design. As with analysis, the term is best #ualified, as in object-oriented design or database design. Useful analysis and design have been summari ed in the phrase do the right thing (analysis), and do 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 or concepts in the problem domain. !or e"ample, in the case of the flight information system, some of the concepts include Plane, Flight, and Pilot. ,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, a Plane software ob+ect may have a tailNumber attribute and a getFlightHistory method )see !igure 1.1*.

. 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+ects1 it is a visuali ation 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 III CSE B 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 standard diagramming 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 visual languages. 28 UML a- b*'epr)$% 4elatively detailed design diagrams used either for 1* reverse engineering to visuali e 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 understand the 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 for some 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 modified by developers1 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 emphasi es UML as sket h1 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: 73 C&$(ep%'a* per-pe(%)/e the diagrams are interpreted as describing things in a situation of the real world or domain of interest. 23 Spe()+)(a%)&$ :-&+%1are8 per-pe(%)/e the diagrams )using the same notation as in the conceptual perspective* describe software abstractions or components with specifications and interfaces, but no commitment to a particular implementation )for e"ample, not specifically a class in 8: or 6ava*. 33 I.p*e.e$%a%)&$ :-&+%1are8 per-pe(%)/e the diagrams describe software implementations in a particular technology )such as 6ava*. Prepared by: VINOTHA S R

; 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 for building 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 )<P*, S(r'., and so forth. !or e"ample, <27s %e-%!dr)/e$ de/e*&p.e$%= re+a(%&r)$0 and (&$%)$'&'- )$%e0ra%)&$ practices can fit within a U2 pro+ect. =o can =crum7s common pro+ect room )(war room(* and daily =crum meeting practice. 0he U2 combines commonly accepted best practices, such as an iterative lifecycle and riskdriven development, into a cohesive and well-documented process description. I.p&r%a$(e &+ %4e U$)+)ed Pr&(e-- :UP8: 1* 0he U2 is an iterative process. Iterative development influences how to introduce //A>, , and to understand how it is best practiced. 28 U2 practices provide an e"ample stru ture for how to do and thus how to e"plain //A>,. 38 0he U2 is fle"ible, and can be applied in a lightweight and agile approach that includes practices from other agile methods )such as <2 or =crum*.

? III CSE B 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%)/e de/e*&p.e$%. In this lifecycle approach, development is organi ed into a series of short, fi"ed-length )for e"ample, three-week* mini-pro+ects called )%era%)&$-1 the outcome of each is 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 @5oehmA Prepared by: VINOTHA S R

Figure 1.4. Iterative and evolutionary development.

. Be$e+)%- &+ )%era%)/e de/e*&p.e$%: less pro+ect failure, better productivity, and lower defect rates1 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"ity1 the team is not overwhelmed by (analysis paralysis( or very long and comple" steps

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 strongly related 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 study by 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 as illustrated in !igure 1.?.

!igure 1.? 2ercentage of change on software pro+ects of varying si es. 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, and client 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 the schedule and estimates. !eedback from the client and marketplace to re-prioriti e the features to tackle in the ne"t iteration U$)+)ed Pr&(e-- C4ara(%er)-%)(I%era%)/e a$d I$(re.e$%a*

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 in an in rement, 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 Unified 2rocess supports multiple architectural models and views. /ne of the most important deliverables of the process is the e"ecutable architecture baseline which 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 Inception 2hase 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

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 the system 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 with only 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. 5y the end of the 9laboration phase the system architecture must have stabili ed 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 the 8onstruction 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 been addressed 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 to write 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. 0he Initial /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 of the 0ransition phase.

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 other values 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 sensibility of simplicity, lightness, communication, self-organi ing 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-organi ing teams A0)*e M&de*)$0: 0he very act of modeling can and should provide a way to better understand the problem 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 featuredriven ,evelopment, ,=,M, and =crum include significant modeling sessions, the purpose of modeling is primarily support understanding and communication, not documentation. ,efer simple or straightforward design problems until programming I 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 diagrams with a digital camera. Model in pairs )or traids* at the whiteboard I 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.

1D III CSE B Prepared by: VINOTHA S R All prior diagrams are incomplete hints I throw-away e"plorations1 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 #uality1 test early, often and realistically 2ractice 8hange 4e#uest and 8onfiguration Management

D)++ere$% UP P4a-e-: An U2 2ro+ect organi es work and iterations across four ma+or phases$ 1* I$(ep%)&$ I appro"imate Jision, 5usiness case, =cope, vague estimates .* E*ab&ra%)&$ I 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'(%)&$ I Iterative implementation of the remaining lower risk and easier elements, and preparation for deployment ;* Tra$-)%)&$ I 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 I 0he ,omain Model artifact, to visuali e noteworthy concepts in the application domain b* 4e#uirements I 0he Use 8ase Model and =upplementary specification artifacts to capture functional and non-functional re#uirements c* ,esign I 0he ,esign Model artifact, to design the software artifacts d* Implementation I 2rogramming and building the system, not deploying it Ca-e S%'dy: Ne;% POS -y-%e. 0he case study is the Le"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 to solve. In addition, it is a realistic problem1 organi ations really do write 2/= systems using ob+ect technologies. A 2/= system is a computeri ed application used )in part* to record sales and handle payments1 it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as

11 III CSE B Prepared by: VINOTHA S R a third-party ta" calculator and inventory control. 0hese systems must be relatively fault-tolerant1 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 business is 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$ M U-er I$%er+a(eNgraphical interface1 windows. M 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. M Te(4$)(a* Ser/)(e-Ngeneral purpose ob+ects and subsystems that provide supporting technical services, 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 Le"tKen case study primarily emphasi es 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 responsibility1 it is said to be thin. 'indows do 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 //=

1. III CSE B 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 the waterfall 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 the pro+ect, determine if it is feasible, and decide if it is worth some serious investigation in elaboration. It can be brief. Prepared by: VINOTHA S R

Re2')re.e$%-: 4e#uirements are capabilities and conditions to which the system I 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 I Managing re#uirements means I a systematic approach to finding, documenting, organi ing, 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 categori ed according to the !U42=O model @KradyG.A, a useful mnemonic with the following meaning$

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, internationali ation, 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 categori ation 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 2'a*)%y a%%r)b'%e-= 2'a*)%y re2')re.e$%-, or the (- ilities( of a system. 0hese include usability, reliability, performance, and supportability. In common usage, re#uirements are categori ed as +'$(%)&$a* )behavioral* or $&$!+'$(%)&$a* )everything else*1 some dislike this broad generali ation @58PGFA, 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 is primarily 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 cases1 for e"ample, a report generation. G*&--ary - In its simplest form, the Klossary defines noteworthy terms. It also encompasses the concept 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)-)&$ - =ummari es high-level re#uirements that are elaborated in the Use-8ase Model and =upplementary =pecification, and summari es 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 or policies 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 may be 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.

1; III CSE B Prepared by: VINOTHA S R U-e Ca-e-: Informally, '-e (a-e- are text stories of some a(%&r using 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 POS system 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. Lotice that use cases are not diagrams they are text3 !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* re2')re.e$%- by 1r)%)$0 -%&r)e- of using a system to fulfill user goals1 that is, ases o# use.

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(%&r is something with behavior, such as a person )identified by role*, computer system, or organi ation1 for e"ample, a cashier. A -(e$ar)& is a specific se#uence of actions and interactions between actors and the system1 it is also called a use case instance. It is one particular story of using a system, or one path through the use case1 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-e is a collection of related success and failure scenarios that describe an actor using a system to support a goal

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 @4U2A. U-e!(a-e M&de*)$0: U-e!Ca-e M&de* is the set of all written use cases1 it is a model of the system7s functionality and environment. U-e (a-e- are %e;% d&('.e$%-= $&% d)a0ra.-, and usecase 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-3 0his gives a nice (&$%e;% d)a0ra. of a system and its environment. It also provides a #uick way to list the use cases by name. 0here is nothing ob+ect-oriented about use cases1 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 organi ations, 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,. !or e"ample, the cashier. 'hy identify& 0o find user goals, which drive the use cases3 28 S'pp&r%)$0 a(%&r provides a service )for e"ample, information* to the =u,. 0he automated payment authori ation service is an e"ample. /ften a computer system, but could be an organi ation 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 supporting1 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 various scenarios. 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(

1E III CSE B Prepared by: VINOTHA S R Pre(&$d)%)&$- state what must always be true before a scenario is begun in the use case. 2reconditions are not tested within the use case1 rather, they are conditions that are assumed to be true. 0ypically, a precondition implies a scenario of another use case, such as logging in, that has successfully completed. S'((e-- 0'ara$%ee- :&r p&-%(&$d)%)&$-8 state what must be true on successful completion of the use case either the main success scenario or some alternate path. 0he guarantee should meet the needs of all stakeholders. 9<AM2L9$ 2reconditions$ 8ashier is identified and authenticated. =uccess Kuarantee )2ostconditions*$ =ale is saved. 0a" is correctly calculated. Accounting and Inventory are updated. 8ommissions recorded. 4eceipt is generated. G')de*)$e: H&1 %& F)$d U-e Ca-eU-e (a-e- are de+)$ed %& -a%)-+y %4e 0&a*- &+ %4e pr).ary a(%&r-3 He$(e= %4e ba-)( pr&(ed're )-: 1* 8hoose the system boundary. Is it +ust a software application, the hardware and application as a unit, that plus a person using it, or an entire organi ation& .* Identify the primary actors those that have goals fulfilled through using services of the system. 3* Identify the goals for each primary actor. ;* ,efine use cases that satisfy user goals1 name them according to their goal. Usually, user-goal level use cases will be one-to-one with user goals, but there is at least one e"ception, as will be e"amined. Use case !iagram representation )ith an example: Applying UML$ Use 8ase ,iagrams 0he UML provides use case diagram notation to illustrate the names of use cases and actors, and the relationships between them. G')de*)$e A simple use case diagram is drawn in con+unction with an actor-goal list. A use case diagram is an e"cellent picture of the system conte"t1 it makes a good conte"t diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summari es the behavior of a system and its actors. A sample !artial use case conte"t diagram for the Le"tKen system is shown below.

1F III CSE B Prepared by: VINOTHA S R

F)0're 73 3 Par%)a* '-e (a-e (&$%e;% d)a0ra.3 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. !or e"ample, the description of paying by credit occurs in several use cases, including Pro ess "ale, Pro ess $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 is simply refactoring and linking te"t to avoid duplication. 0he include relationship can be used for most use case relationship problems. 0o summari e$ !actor out sub function use cases and use the 'n lude relationship when$ M 0hey are duplicated in other use cases. M 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

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