SKR ENGINEERING COLLEGE DEPARTMENT OF COMPUTER SCIENCE CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN Unit-I Introd !

tion to OOAD
PART-A 1. What is Object-Oriented Analysis? During object-oriented analysis there is an emphasis on finding and describing the objects or concepts in the problem domain. For example, in the case of the flight information system, some of the concepts include Plane, Flight, and Pilot. 2. What is Object-Oriented Design? During object-oriented design (or simply, object design) there is an emphasis on defining software objects and how they collaborate to fulfill the re uirements. !he combination of these two concepts shortly "nown as object oriented analysis and design. 3. What is Object-Oriented Analysis and Design? APRIL !A"-2#11 During object-oriented analysis there is an emphasis on finding and describing the objects or concepts in the problem domain. For example, in the case of the flight information system, some of the concepts include Plane, Flight, and Pilot. During object-oriented design (or simply, object design) there is an emphasis on defining software objects and how they collaborate to fulfill the re uirements. !he combination of these two concepts shortly "nown as object oriented analysis and design. $. What is Analysis and Design? #nalysis emphasi$es an in%estigation of the problem and re uirements, rather than a solution. Design emphasi$es a conceptual solution (in software and hardware) that fulfills the re uirements, rather than its implementation. For example, a description of a database schema and software objects. &. De%ine Design &lass Diagra's # static %iew of the class definitions is usefully shown with a design class diagram. !his illustrates the attributes and methods of the classes. (. What is the )!L? !he 'nified (odeling )anguage is a %isual language for specifying, constructing and documenting the artifacts of systems.

*. What are the three +ays and ,ers,ecti-es t. A,,ly )!L? *ays-'() as s"etch, '() as blueprint, '() as programming language Perspecti%es-+onceptualperspecti%e, ,pecification (software) perspecti%e, -mplementation (,oftware) perspecti%e.

/. What is Ince,ti.n? APIRAL !A"-2#11 -nception is the initial short step to establish a common %ision and basic scope for the Project. -t will include analysis of perhaps ./0 of the use cases, analysis of the critical nonFunctional re uirement, creation of a business case, and preparation of the de%elopment 1n%ironment so that programming can start in the elaboration phase. -nception in one ,entence2 1n%ision the product scope, %ision, and business case. 0. What Arti%acts !ay 1tart in Ince,ti.n? ,ome sample artifacts are 3ision and 4usiness +ase, 'se-+ase (odel, ,upplementary ,pecification, 5lossary, 6is" )ist 7 6is" (anagement Plan, Prototypes and proof-of-concepts etc. 1#. De%ine Re23ire'ents and 'enti.n its ty,es. 6e uirements are capabilities and conditions to which the system and more broadly, the project must conform. .. Functional 8. 6eliability 9. Performance :. ,upportability 11. What are Act.rs?

#n actor is something with beha%ior, such as a person (identified by role), computer system, or organi$ation; for example, a cashier.

12. What is a scenari.?

# scenario is a specific se uence of actions and interactions between actors and the system; it is also called a use case instance. -t is one particular story of using a system, or one path through

the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial.

13. De%ine )se case.

# use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. 'se cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing diagrams.

1$. What are Three 4inds .% Act.rs?

Primary actor, ,upporting actor, offstage actor.

15. What Tests &an 6el, 7ind )se%3l )se &ases?

.. !he 4oss !est 8. !he 14P !est 9. !he ,i$e !est

1(. What are )se &ase Diagra's?

# use case diagram is an excellent picture of the system context; it ma"es a good context diagram that is, showing the boundary of a system, what lies outside of it, and how it gets used. -t ser%es as a communication tool that summari$es the beha%ior of a system and its actors.

1*. What are Acti-ity Diagra's?

# diagram which is useful to %isuali$e wor"flows and business processes. !hese can be a useful alternati%e or adjunct to writing the use case text, especially for business use cases that describe complex wor"flows in%ol%ing many parties and concurrent actions.

PART- 8 .. 1xplain about P<, generation systems.

-!he =ext 5en P<, ,ystem -#rchitectural )ayers and +ase ,tudy 1mphasis --terati%e De%elopment and -terati%e )earning

8. Define -nception. 1xplain about artifacts of -nception

--nception2 #n #nalogy 9> -*hat #rtifacts (ay ,tart in -nception -?ou @now ?ou DidnAt 'nderstand -nception *hen...

9. 1xplain about 'nified process phases. APRIL !A"-2#11

- -terati%e De%elopment -#dditional 'P 4est Practices and +oncepts -!he 'P Phases and ,chedule -!he 'P Disciplines (was *or"flows) -Process +ustomi$ation and the De%elopment Case -!he #gile 'P -!he ,e uential B*aterfall

:. 1xplain about 'se-+ase (odel and its *riting 6e uirements in +ontext. APRIL !A"-2#11

-4ac"ground -'se +ases and #dding 3alue

-'se +ases and Functional 6e uirements -'se +ase !ypes and Formats -Fully Dressed 1xample2 Process ,ale

&. )ist out the components of <bject-<riented #nalysis and Design. -#pplying '() and Patterns in <<#CD -#ssigning 6esponsibilities -*hat -s #nalysis and DesignD -*hat -s <bject-<riented #nalysis and DesignD -#n 1xample -!he '()

UNIT-II E"#$or#tion PART- A

1. What is 9lab.rati.n? 1laboration is the initial series of iterations during which the team does serious in%estigation, implements (programs and tests) the core architecture, clarifies most re uirements, and tac"les the high-ris" issues. -n the 'P, Bris"B includes business %alue. !herefore, early wor" may include implementing scenarios that are deemed important, but are not especially technically ris"y.

2. What are the tas:s ,er%.r'ed in elab.rati.n?

the core, ris"y software architecture is programmed and tested the majority of re uirements are disco%ered and stabili$ed the major ris"s are mitigated or retired

3. What are the :ey ideas and best ,ractices that +ill 'ani%est in elab.rati.n?

do short time boxed ris"-dri%en iterations start programming early adapti%ely design, implement, and test the core and ris"y parts of the architecture

test early, often, realistically adapt based on feedbac" from tests, users, de%elopers write most of the use cases and other re uirements in detail, through a series of wor"shops, once per elaboration iteration

$. What Arti%acts !ay 1tart in 9lab.rati.n? Domain (odel !his is a %isuali$ation of the domain concepts; it is similar to a static information model of the domain entities. !his is the set of diagrams that describes the logical design. !his includes software class diagrams, object interaction diagrams, pac"age diagrams, and so forth. # learning aid that summari$es the "ey architectural issues and their resolution in the design. -t is a summary of the outstanding design ideas and their moti%ation in the system. !his includes the database schemas, and the mapping strategies between object and non-object representations. Descriptions of the user interface, paths of na%igation, usability models, and so forth.

Design (odel

,oftware #rchitecture Document Data (odel

'se-+ase ,toryboards, 'Prototypes

5. What are the :ey ideas %.r Planning the ;e<t Iterati.n? <rgani$e re uirements and iterations by ris", co%erage, and criticality. (. What is a D.'ain !.del? APIRAL !A"-2#11 # domain model is a %isual representation of conceptual classes or real-situation objects in a domain. !he term BDomain (odelB means a representation of real-situation conceptual classes, not of software objects. !he term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities.

E. 6.+ the d.'ain '.del is ill3strated? #pplying '() notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. -t pro%ides a conceptual perspecti%e. -t may show2

domain objects or conceptual classes associations between conceptual classes attributes of conceptual classes

/. Why &all a D.'ain !.del a =>is3al Dicti.nary=? !he information it illustrates could alternati%ely ha%e been expressed in plain text. 4ut itAs easy to understand the terms and especially their relationships in a %isual language, since our brains are good at understanding %isual elements and line connections. !herefore, the domain model is a %isual dictionary of the noteworthy abstractions, domain %ocabulary, and information content of the domain. 0. What are the ele'ents n.t s3itable in a d.'ain '.del? !he following elements are not suitable in a domain model

,oftware artifacts, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of graphical user interfaces. 6esponsibilities or methods

1#. What are &.nce,t3al &lasses? !he domain model illustrates conceptual classes or %ocabulary in the domain. -nformally, a conceptual class is an idea, thing, or object. (ore formally, a conceptual class may be considered in terms of its symbol, intension, and extension

,ymbol words or images representing a conceptual class. -ntension the definition of a conceptual class. 1xtension the set of examples to which the conceptual class applies

11. 6.+ t. &reate a D.'ain !.del? !he current iteration re uirements under design2 .. Find the conceptual classes (see a following guideline). 8. Draw them as classes in a '() class diagram. 9. #dd associations and attributes. 12. 6.+ t. 7ind &.nce,t3al &lasses? .. 6euse or modify existing models. !his is the first, best, and usually easiest approach, and where - will start if - can. !here are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as in%entory, finance, health, and so forth. 1xample boo"s that -All turn to include #nalysis Patterns by (artin Fowler, Data (odel Patterns by Da%id Fay, and the Data (odel 6esource 4oo" (%olumes . and 8) by )en ,il%erton. 8. 'se a category list. 9. -dentify noun phrases.

13. !enti.n s.'e &.nce,t3al &lass &ateg.ry.

&.nce,t3al &lass &ateg.ry business transactions ,ale, Payment 6eser%ation transaction line items ,ales )ine -tem product or ser%ice related to a transaction or transaction line item -tem

9<a',les

Flight, ,eat, (eal where is the transaction recordedD 6egister, )edger Flight (anifest roles of people or organi$ations related to the transaction; actors in the use case +ashier, +ustomer, ,tore (onopoly Player Passenger, #irline ,tore place of transaction; place of ser%ice #irport, Plane, ,eat 1$. De%ine Ass.ciati.n. #n ass.ciati.n is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection. 15. Why 1h.3ld We A-.id Adding !any Ass.ciati.ns? *e need to a%oid adding too many associations to a domain model. Digging bac" into our discrete mathematics studies, you may recall that in a graph with n nodes, there can be associations to other nodes a potentially %ery large number. # domain model with 8/ classes could ha%e .G/ associationsH linesI (any lines on the diagram will obscure it with B%isual noise.B !herefore, be parsimonious about adding association lines. 'se the criterion guidelines suggested in this chapter, and focus on Bneed-to-rememberB associations. .>. 6.+ t. ;a'e an Ass.ciati.n in )!L? =ame an association based on a +lass =ame-3erb Phrase-+lass =ame format where the %erb phrase creates a se uence that is readable and meaningful. 1*. What is Aggregati.n? APRIL !A"-2#11

Aggregati.n is a %ague "ind of association in the '() that loosely suggests whole-part relationships (as do many ordinary associations). -t has no meaningful distinct semantics in the '() %ersus a plain association, but the term is defined in the '(). 1/. What is c.',.siti.n? APRIL !A"-2#11 &.',.siti.n, also "nown as composite aggregation, is a strong "ind of whole-part aggregation and is useful to show in some models. # composition relationship implies that .) an instance of the part (such as a , uare) belongs to only one composite instance (such as one 4oard) at a time, 8) the part must always belong to a composite (no free-floating Fingers), and 9) the composite is responsible for the creation and deletion of its parts either by itself creatingCdeleting the parts, or by collaborating with other objects. 10. !enti.n the g3idelines that s3ggest +hen t. sh.+ aggregati.n.

!he lifetime of the part is bound within the lifetime of the composite there is a createdelete dependency of the part on the whole. !here is an ob%ious whole-part physical or logical assembly. ,ome properties of the composite propagate to the parts, such as the location. <perations applied to the composite propagate to the parts, such as destruction, mo%ement, and recording.

2#. What is an acti-ity diagra'? # '() acti%ity diagram shows se uential and parallel acti%ities in a process. !hey are useful for modeling business processes, wor"flows, data flows, and complex algorithms. 4asic '() acti%ity diagram notation illustrates an action, partition, for", join, and object node. -n essence, this diagram shows a se uence of actions, some of which may be parallel. (ost of the notation is self-explanatory; two subtle points2

once an action is finished, there is an automatic outgoing transition the diagram can show both control flow and data flow PART ?8

.. *rite briefly about elaboration and discuss the differences between 1laboration and -nception with examples. --teration . 6e uirements and 1mphasis2 +ore <<#CD ,"ills --nception and 1laboration -Planning the =ext -teration 8. -llustrate the concept of Domain model with examples. APRIL !A"-2#11 -Definitions -5uidelines for creating domain model -1xamples 9. 1xplain the guidelines for finding +onceptual +lasses with neat diagrams

- !hree ,trategies -Find and Draw +onceptual +lasses

:. *hat is acti%ity diagramD 1xplain about its applications brieflyD APRIL !A"-2#11 -'() #cti%ity Diagram =otation -5uidelines for acti%ity modeling -1xample J=ext 5en #cti%ity Diagram &. 1xplain about #ggregations and compositions -Definitions --dentify +omposition 7#ggregations -1xample2 +omposition in the =ext 5en Domain (odel

Unit-III S%&t'( S') 'n!' Di#*r#(&

PART- A

1. What is 'eant by 1yste' 1e23ence Diagra's? APRIL !A"-2#11 # system se uence diagram (,,D) is a picture that shows, for a particular scenario of a use case, the e%ents that external actors generate their order, and inter-system e%ents. #ll systems are treated as a blac" box; the emphasis of the diagram is e%ents that cross the system boundary from actors to systems. 2. What is 'eant by 1yste' 8eha-i.r? 1yste' beha-i.r is a description of what a system does, without explaining how it does it. <ne Part of that description is a system se uence diagram. <ther parts include the 'se cases, and system contracts (to be discussed later). 3. What is 'eant by Inter-1yste' 11Ds? ,,Ds can also be used to illustrate collaborations between systems, such as between the =ext 5en P<, and the external credit payment authori$er. Fowe%er, this is deferred until a later iteration in the case study, since this iteration does not include remote systems collaboration. $. De%ine 1yste' 9-ents and the 1yste' 8.3ndary. !o identify system e%ents, it is necessary to be clear on the choice of system boundary, as discussed in the prior chapter on use cases. For the purposes of software de%elopment, the system boundary is usually chosen to be the software system itself; in this context, a system e%ent is an external e%ent that directly stimulates the software. 5. 6.+ t. ;a'ing 1yste' 9-ents and O,erati.ns? ,ystem e%ents (and their associated system operations) should be expressed at the le%el of intent rather than in terms of the physical input medium or interface widget le%el.

-t also impro%es clarity to start the name of a system e%ent with a %erb !hus Benter itemB is better than BscanB (that is, laser scan) because it captures the intent of the operation while remaining abstract and noncommittal with respect to design choices about what interface is used to capture the system e%ent. (. What is 'eant by interacti.n diagra'? !he term interaction diagram is a generali$ation of two more speciali$ed '() diagram types; both can be used to express similar message interactions2 . +ollaboration diagrams . ,e uence diagrams *. What is 'eant by lin:? A lin: is a connection path between two objects; it indicates some form of na%igation #nd %isibility between the objects is possible . (ore formally, a lin" is an instance of an association. For example, there is a lin" or path of na%igation from a Register to a Sale, along which messages may flow, such as the make 2 Payment message. /. What is 'eant by !essages? 1ach message between objects is represented with a message expression and small arrow indicating the direction of the message. (any messages may flow along this lin". # se uence number is added to show the se uential order of messages in the current thread of control. 0. 6.+ t. create an instance? #ny message can be used to create an instance, but there is a con%ention in the '() to use a message named create for this purpose. -f another (perhaps less ob%ious) message name is used, the message may be annotated with a special feature called a '() stereotype, li"e so2 create. !he create message may include parameters, indicating the passing of initial %alues. !his indicates, for example, a constructor call with parameters in Ka%a. 1#. What is 'eant by L.+ &.3,ling? &.3,ling is a measure of how strongly one element is connected to, has "nowledge of, or relies on other elements. #n element with low (or wea") coupling is not dependent on too many other elements; Btoo manyB is context-dependent, but will be examined. !hese elements include classes, subsystems, systems, and so on. 11. What is 'eant by 6igh c.hesi.n? &.hesi.n (or more specifically, functional cohesion) is a measure of how strongly related and focused the responsibilities of an element are. #n element with highly related responsibilities, and which does not do a tremendous amount of wor", has high cohesion. !hese elements include classes, subsystems, and so on. 12. De%ine &.ntr.ller. #ssign the responsibility for recei%ing or handling a system e%ent message to a class representing one of the following choices2 - 6epresents the o%erall system, de%ice, or subsystem (facade controller).

- 6epresents a use case scenario within which the system e%ent occurs, often named L'se+ase=ameMFandler, L'se+ase=ameM+oordinator, or L'se-+ase=ameM,ession (use case or session controller). - 'se the same controller class for all system e%ents in the same use case scenario. --nformally, a session is an instance of a con%ersation with an actor. -,essions can be of any length, but are often organi$ed in terms of use cases (use case sessions). 13. What is 'eant by &R& card? +6+ cards are index cards, one for each class, upon which the responsibilities of the class are briefly written, and a list of collaborator objects to fulfill those responsibilities. !hey are usually de%eloped in a small group session. !he 56#,P patterns may be applied when considering the design while using +6+ cards. 1$. What is 'eant by P3re 7abricati.n?
!his is another 56#,P pattern. # Pure Fabrication is an arbitrary creation of the designer, not a software class whose name is inspired by the Domain (odel. # use-case controller is a "ind of Pure Fabrication.

15. List the relati.nshi,s 3sed in class diagra'? APRIL !A"-2#11 o 5enerali$ation(class to class) o #ssociation (object to object) o #ggregation (object to object) o +omposition (object to object)

PART- 8

..

Fow to #dding =ew ,,Ds and +ontractsD

-=ew ,ystem ,e uence Diagrams -=ew ,ystem <perations -=ew ,ystem <peration +ontracts

8. 1xplain about -nteraction Diagram =otationD APRIL !A"-2#11 -,e uence and +ollaboration Diagrams -+ollaboration Diagram -,e uence Diagram -+ommon -nteraction Diagram =otation -4asic +ollaboration Diagram

-=otation -4asic ,e uence Diagram =otation

9. Design the (odel and +reating Design +lass Diagrams. -*hen to +reate D+Ds -1xample D+D -D+D and 'P -Domain (odel %s. Design (odel +lasses -D+Ds, Drawing, and +#,1 !ools -D+Ds within the 'P

:. *hat are concepts in%ol%ed in domain refinementD -5enerali$ation -Defining +onceptual ,uper classes and ,ubclasses -+lass Fierarchies and -nheritance -#ggregation and +omposition -1xamples &. -llustrate with an example, the relationship between se uence diagram and use cases. APIRAL !A"-2#11

Unit-I+ GRASP
PART- A

1. 6.+ t. &h..sing the Initial D.'ain Object? +hoose as an initial domain object a class at or near the root of the containment or aggregation hierarchy of domain objects. !his may be a facade controller, such as Register, or some other object considered to contain all or most other objects, such as a Store. 2. 6.+ t. &.nnecting the )I Layer t. the D.'ain Layer? N #n initiali$ing routine (for example, a Ka%a main method) creates both a '- and a domain object, and passes the domain object to the '-.

N # '- object retrie%es the domain object from a well-"nown source, such as a factory object that is responsible for creating domain objects. 3. !enti.n the Inter%ace and D.'ain Layer Res,.nsibilities. !he '- layer should not ha%e any domain logic responsibilities. -t should only be responsible for user interface tas"s, such as updating widgets. !he '- layer should forward re uests for all domain-oriented tas"s on to the domain layer, which is responsible for handling them. 5. De%ine ,atterns. # pattern is a named problemCsolution pair that can be applied in new context, with ad%ice on how to apply it in no%el situations and discussion of its trade-offs. (. 6.+ t. A,,ly the @RA1P Patterns? !he following sections present the first fi%e 56#,P patterns2 . -nformation 1xpert . +reator . Figh +ohesion . )ow +oupling . +ontroller *. De%ine Res,.nsibilities and !eth.ds. !he '() defines a responsibility as Ba contract or obligation of a classifierB O<(5/.P. 6esponsibilities are related to the obligations of an object in terms of its beha%ior. 4asically, these responsibilities are of the following two types2 - "nowing -doing Doing responsibilities of an object include2 - doing something itself, such as creating an object or doing a calculation - initiating action in other objects -controlling and coordinating acti%ities in other objects @nowing responsibilities of an object include2 - "nowing about pri%ate encapsulated data - "nowing about related objects - "nowing about things it can deri%e or calculate /. Wh. is creat.r? ,olution #ssign class 4 the responsibility to create an instance of class # if one or more of the following is true2 . 4 aggregates an object. . 4 contains an object. . 4 records instances of objects. . 4 closely uses objects. . 4 has the initiali!ing data that will be passed to # when it is created (thus 4 is an 1xpert with respect to creating #). 4 is a creator of an object. -f more than one option applies, prefer a class 4 which aggregates or contains class #. 0. List .3t s.'e scenari.s that ill3strate -arying degrees .% %3ncti.nal c.hesi.n. -3ery low cohesion

-low cohesion -Figh cohesion -(oderate cohesion 1#. De%ine !.d3lar Design. +oupling and cohesion are old principles in software design; designing with objects does not imply ignoring well-established fundamentals. #nother of these. *hich is strongly related to coupling and cohesionD is to promote modular design. 11. What are the ad-antages .% 7act.ry .bjects? N ,eparate the responsibility of complex creation into cohesi%e helper objects. N Fide potentially complex creation logic. N #llow introduction of performance-enhancing memory management strategies, such as object caching or recycling. 12. Designing %.r ;.n-73ncti.nal .r A3ality Re23ire'ents. -nterestinglyQand this a "ey point in software architectureQit is common that the large-scale themes, patterns, and structures of the software architecture are shaped by the designs to resol%e the non-functional or uality re uirements, rather than the basic business logic. 13. Abstract %.r 7act.ry B@.7C %.r 7a'ilies .% Related Objects. !he Ka%a P<, implementations will be purchased from manufacturers. For example&2 CC -4(As dri%ers com.ibm.pos.jpos.+ashDrawer (implements jpos.+ashDrawer) com.ibm.pos.jpos.+oinDispenser (implements jpos.+oinDispenser) CC =+6As dri%ers com.ncr.posdri%ers.+ashDrawer (implements jpos.+ashDrawer) com.ncr.posdri%ers.+oinDispenser (implements jpos.+oinDispenser) 1$. What is 'eant by Abstract &lass Abstract 7act.ry? # common %ariation on #bstract Factory is to create an abstract class factory that is accessed using the ,ingleton pattern, reads from a system property to decide which of its subclass factories to create, and then returns the appropriate subclass instance. !his is used, for example, in the Ka%a libraries with the "a#a.awt.$oolkit class, which is an abstract class abstract factory for creating families of 5'- widgets for different operating system and 5'- subsystems.

15. What is 'eant by 7ine-@rained &lasses? +onsider the creation of the Credit Card, %ri#ers &icense, and Check software objects. <ur first impulse might be to record the data they hold simply in their related payment classes, and eliminate such fine-grained classes. Fowe%er, it is usually a more profitable strategy to use them; they often end up pro%iding useful beha%ior and being reusable. For example, the Credit Card is a natural 1xpert on telling you its credit company type (3isa, (aster+ard, and so on). !his beha%ior will turn out to be necessary for our application. 1(. De%ine c.3,ling. APIRAL !A"-2#11

!he degree to which components depend on one another. !here are two types of coupling, BtightB and BlooseB. )oose coupling is desirable for good software engineering but tight coupling may be necessary for maximum performance. +oupling is increased when the data exchanged between components becomes larger or more complex. PART- 8

.. 1xplain 5rasp2 designing objects with responsibilities. -6esponsibilities and (ethods -6esponsibilities and -nteraction Diagrams -Patterns 8. 1xplain 56#,P2 Patterns of 5eneral Principles in #ssigning 6esponsibilities. APIRAL !A"-2#11 -!he '() +lass Diagram =otation --nformation 1xpert (or 1xpert) -+reator -low coupling -high cohesion -controller -object design and +6+ +#6D, 9. Fow to Determining the 3isibility of the Design (odelD -3isibility between <bjects -3isibility :. 1xplain about Patterns for #ssigning 6esponsibilities. -Polymorphism -Pure Fabrication --ndirection -Protected 3ariations &. Designing the 'se-+ase 6eali$ations with 5oF Design Patterns. APRIL !A"-2#11 -#nalysisB Disco%eries during Design2 Domain (odel -Factory -,ingleton -+onclusion of the 1xternal ,er%ices with 3arying -nterfaces Problem 9 -,trategy -+omposite -Facade

Unit-+ UML &t#t' di#*r#(& #nd (od'"in*

PART- A 1. De%ine ,.st c.nditi.n.

!he post conditions describe changes in the state of objects in the Domain (odel. Domain (odel state changes include instances created, associations formed or bro"en, and attributes changed. 2. De%ine Attrib3tes. #n attribute is a logical data %alue of an object. 3. When Are &.ntracts )se%3l? !he use cases are the main repository of re uirements for the project. !hey may pro%ide most or all of the detail necessary to "now what to do in the design, in which case, contracts are not helpful. Fowe%er, there are situations where the details and complexity of re uired state changes are aw"ward to capture in use cases. $. !enti.n the @3idelines %.r &.ntracts. !o ma"e contracts2 .. -dentify system operations from the ,,Ds. 8. For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract. 9. !o describe the post conditions, use the following categories2 - -nstance creation and deletion - attribute modification - #ssociations formed and bro"en 5. What are 1te,s %.r !a,,ing Designs t. &.de? -mplementation in an object-oriented programming language re uires writing source code for2 N +lass and interface definitions N (ethod definitions (. &reating &lass De%initi.ns %r.' D&Ds. #t the %ery least, D+Ds depict the class or interface name, super classes, method signatures, and simple attributes of a class. !his is sufficient to create a basic class definition in an objectoriented programming language. )ater discussion will explore the addition of interface and namespace (or pac"age) information, among other details. *. What are the 8ene%its .% Iterati-e De-el.,'ent? N 1arly rather than late mitigation of high ris"s (technical, re uirements, objecti%es, usability, and so forth) N 1arly %isible progress N 1arly feedbac", user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the sta"eholders N managed complexity; the team is not o%erwhelmed by Banalysis paralysisB or %ery long and complex steps N !he learning within iteration can be methodically used to impro%e the de%elopment process itself, iteration by iteration /. De%ine 9-entsD 1tatesD and Transiti.ns. APRIL !A"-2#11 #n e%ent is a significant or noteworthy occurrence. For example2

# telephone recei%er is ta"en off the hoo". # state is the condition of an object at a moment in timeQthe time between e%ents. For example2 N # telephone is in the state of being BidleB after the recei%er is placed on the hoo" and until it -s ta"en off the hoo". # transition is a relationship between two states that indicates that when an e%ent occurs, the <bject mo%es from the prior state to the subse uent state. For example2 N *hen the e%ent Boff hoo"B occurs, transition the telephone from the BidleB to Bacti%eB state. 0. What is 'eant by 1tate chart Diagra's? # '() state chart diagram, as shown in Figure 8G.., illustrates the interesting e%ents and states of an object, and the beha%ior of an object in reaction to an e%ent. !ransitions are shown as arrows, labeled with their e%ent. ,tates are shown in rounded rectangles. -t is common to include an initial pseudo-state, which automatically transitions to another state when the instance is created. 1#. 1tate chart Diagra's in the )P? !here is not one model in the 'P called the Bstate model.B 6ather, any element in any model (Design (odel, Domain (odel, and so forth) may ha%e a state chart to better understand or communicate its dynamic beha%ior in response to e%ents. For example, a state chart associated with the Sale design class of the Design (odel is itself part of the Design (odel. 11. )tility .% )se &ase 1tate chart Diagra's. - Fard-coded conditional tests for out-of-order e%ents - 'se of the State pattern (discussed in a subse uent chapter) - disabling widgets in acti%e windows to disallow illegal e%ents (a desirable approach) - # state machine interpreter that runs a state table representing a use case ,tate chart diagram. 12. List .3t the ty,es .% 9-ents. -1xternal e%ent --nternal e%ent -!emporal e%ent 13. De%ine 9<ternal e-ent. 1xternal e%entQalso "nown as a system e%ent, is caused by something (for example, an actor) outside our system boundary. ,,Ds illustrate external e%ents. =oteworthy external e%ents precipitate the in%ocation of system operations to respond to them. - *hen a cashier presses the Benter itemB button on a P<, terminal, an external e%ent has occurred. 1$. De%ine internal e-ent. -nternal e%entQcaused by something inside our system boundary. -n terms of software, an internal e%ent arises when a method is in%o"ed %ia a message or signal that was sent from another internal object. (essages in interaction diagrams suggest internal e%ents.

- *hen a Sale recei%es a make &ine item message, an internal e%ent has occurred. 15. De%ine te',.ral e-ent. !emporal e%entQcaused by the occurrence of a specific date and time or passage of time. -n terms of software, a temporal e%ent is dri%en by a real time or simulated-time cloc". -,uppose that after an end Sale operation occurs, a make Payment operation must occur within fi%e minutes, otherwise the current sale is automatically purged.

PART- 8 .. 1xplain '() ,tate (achine Diagrams and (odeling. -Definition -Fow to apply -1xample -Process 8. *hat is the operation of contracts wor"s. -+ontracts -+ontract ,ections -Post conditions -5uidelines2 +ontracts -=ext 5en P<, 1xample -+hanges to the Domain (odel -+ontracts, <perations, and the '() -<peration +ontracts *ith in the 'P 9. 1xplain the operation of (apping Designs to +ode. APRIL !A"-2#11 - Programming and the De%elopment Process -(apping Designs to +ode -+reating +lass Definitions from D+Ds -+reating (ethods from -nteraction Diagrams -+ontainerC+ollection +lasses in +ode -1xceptions and 1rror Fandling -Defining the ,ale--ma"e)ine-tem (ethod -<rder of -mplementation -!est-First Programming :. *hat is operation of '() Deployment and +omponent DiagramD Draw the diagram for a ban"ing application. APRIL !A"-2#11 -Deployment Diagram -+omponent Diagram