Explain Sequence Diagram using example .

Explain the notation to be used to represent iteration, conditional messaging, object creation and destruction and parallel processing ? The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Much like the class diagram, developers typically think sequence diagrams were meant exclusively for them. However, an organi ation!s business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. "esides documenting an organi ation!s current affairs, a business#level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation. $uring the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. %hen that occurs, use cases are often refined into one or more sequence diagrams. &xample ' (equence $iagram for Hotel Management (ystem

)igure *(equence $iagram for Hotel Management.

+n this above example of hotel management ,first we have to identify all use cases and object it shows the lifetime of the a particular object. Here customer ,wiater ,cook and cashier are the objects ,ustomer is come in to the hotel the look menu card and place the order of food item to waiter he submitted order to the cook ,then cook gives food item to wiater - he serves to customer food item.wiater gives the acknowledgement to the cashier,he gives a bill to wiater and wiater is given bill to customer after that customer pays bill to cashier and get exit from hotel .ll above activities are invoked and happens in sequence these activities are taken a spesific time to complete.

Notations used to represent

Iteration : +n sequence diagram to cancel any activities iterations are to be used,iteration are represent followed bu astrik/01.the analogous iteration are used in sequence diagram.

Conditional essaging*+n some cases ,we may want to specify that one object sends the maessage to another only if some particular condition holds in the sending object. The sender evaluates the condition and determines whether to send the message based on the result ,sequence diagram shows the conditional sending message.

!bject Creation "nd Destruction: +t is often to useful to indicates when an object may be created or deleted during a scenario can include new or destroyed property

#arallel #rocessing: Today!s modern computer systems are advancing in complexity and at times perform concurrent tasks. %hen the processing time required to complete portions of a complex task is longer than desired, some systems handle parts of the processing in parallel. The parallel combination fragment element needs to be used when creating a sequence diagram that shows parallel processing activities. The parallel combination fragment is drawn using a frame, and you place the text 2par2 in the frame!s namebox. 3ou then break up the frame!s content section into hori ontal operands separated by a dashed line. &ach operand in the frame represents a thread of execution done in parallel.

Explain $ogical architecture and hard%are architecture model ? $ogical architecture 4ogical architecture system can be organi ed logically such as into layer5s or sub system .This conceptis explored and the use of6M4 package to model such a group is discussed. . system or application ,whether object oriented or notcan be organi ed into logicall units such as layers or subsystem. These are logical because the grouping criterian is conceptual,. layer for e.g. define one tier or stratum of the system that is typically organi ed around functional cohesion.&ach layer carries out a different functional responsibility and therefore is defined by a conceptual boundary.

)ig 'Three Tier .rchitecture hard%are architecture model Many system are spread across multiple hardware boxes an important view of such a system is it5s hardware architecture,defined interm of hardware nodes and theire interconnections.This is a physical organi ation because the boundaries are defined by physical entities*computers. . 6M4 deployment diagram defines the hardware architecture of a system or application . the diagram includes a set of nodes depicted as three#dimensional cube.&ach node represent a class of hardware processor and is labeled with the type the node.The relationship between nodes represent physical connection between the corresponding processors. "oth the nodes and relationships can include cardinality constrints.The cardinality of s node appears in the upper right corner of the node and specifies how many instances of this type of processor can be includes in a deployment of the system

)ig* (uperimposing a hardware node onto a group of classes .n important view of a system is its hardware architecture, defined in terms of the hardware nodes and their interconnections +t is a physical organi ation because the boundaries are defined by physical entities . 6M4 deployment diagram defines the hardware architecture of a system or application in terms of hardware nodes and their connections The set of nodes are depicted as three#dimensional cubes &ach node represents a class of hardware processor and is labeled with the type of the node The relationships between nodes represent physical connections between the corresponding processors "oth the nodes and relationships can include cardinality constraints

De&eloping a Stoc'()rading S*stem: 3ou are to develop a small stock#trading system. ,ustomers place buy and sell orders and securities transfers with service representatives7 then, the service representatives enter those orders into the system. The system is closed, meaning that all buy orders are matched with sell orders within the system. . security transfer moves stock or cash into or out of the system. &ach transfer includes the customer5s account number and either the amount of cash, or stock name and number of shares that is being transferred. . service representative also creates accounts at customers5 requests.

 perimposing a +,% node onto the classes

Su The hardware nodes in a deployment can be superimposed onto the classes in a class diagram or the use cases in a use case diagram The classes or use cases within a node in the diagram reside on that type of hardware processor The instances of those classes, or the behaviors that implement those use cases, run on instances of that type of processor

 plo*ment Instance Diagram . deployment diagram is roughly equivalent to a class diagram because it describes all legal hardware configurations for the system .s an object diagram depicts a particular set of objects and links, a deployment instance diagram describes a particular configuration of node instances and their connections

De

 perimposing a deplo*ment instance diagram onto interaction diagram . deployment instance diagram can be superimposed onto an interaction diagram to show what instances are executing on what hardware nodes

Su

6M4 6niversity paper solution for may 899: -.. /a0 Dra% a use case diagram 1or the $ibrar* anagement S*stem described belo%. 2se all or maximum 2 $ notations, o1 2se Case Diagram. )he objecti&e o1 the s*stem is to automate all the acti&ities o1 the NCS) librar*. )he s*stem should 1acilitate monitoring o1 dela*ed boo's, reser&ations, 1ine collection, searching, help in planning budgets to purchase ne% boo's etc. )his s*stem should also 1acilitate capturing the data along the %hole 1lo% o1 processes &ia re&ie% and recommendation o1 boo's,CDs and then placing o1 purchase order, preparing in&oice, adding the ne% items to the stoc'. "part 1rom the abo&e( mentioned 1acilities the s*stem should capture data pertaining to the dail* transactions %ith members. "ctor: ;. Member 8. 4ibrarian <. "ook (upplier 2se case: ;. =alidate user 8. Manage member <. +ssue book >. ?eturn book @. ?eserve book A. (earch book :. Brder book C. Dlan budget E. 6pdate the stock ;9. Drepare invoice ;;. Maintain database

2se Case Diagram:

Syst em Manage User

I ssue Book < < include> > Ret urn Book < < include> > < < include> > Reserve Book

Validat e User Mem ber

< < include> >

Search Book

Book Supplier Order Book Librarian

Plan Budget

Prepare I nvoice

Maint ain Dat abase

2se Case: 3alidate 2ser .. 4. 5. 6. 7. 8. Description +nvoking .ctor .ssumption Dre#condition Dost#condition (cenario %henever librarian wants to use system, a login window will appear. . librarian will enter valid user name and password. )or members it will check whether user is valid or not. 3alidates the user 4ibrarian, Member 4ogin is always required

9. :.

"enefiting .ctor Darticipating .ctor

2se Case: .. 4. 5. 6. 7. 8.

anage 2ser anages details o1 the user 4ibrarian # # # . window will appear which will be having different options like add, modify, delete. 4ibrarian will select appropriate option and will add update or delete the record. Member Member

Description +nvoking .ctor .ssumption Dre#condition Dost#condition (cenario

9. :.

"enefiting .ctor Darticipating .ctor

2se Case: Issue ;oo' .. 4. 5. 6. 7. 8. Description +nvoking .ctor .ssumption Dre#condition Dost#condition (cenario Issues the boo' 4ibrarian # =alid user # ;. 4ibrarian will open issue book form 8. He will scan the +$ proof of member <. He will scan the bar code of book >. Then book is issued Member Member

9. :.

"enefiting .ctor Darticipating .ctor

2se Case: <eturn ;oo' .. 4. 5. 6. 7. 8. Description +nvoking .ctor .ssumption Dre#condition Dost#condition (cenario ;. 4ibrarian will open return book form 8. He will scan the bar code of book <. He will check for delay >. +f any delay, he will charge fine @. Bnce fine is paid, then book will be returned Member Member <eturns the boo' 4ibrarian # =alid user

9. :.

"enefiting .ctor Darticipating .ctor

2se Case: <eser&e ;oo' .. 4. 5. 6. 7. 8. Description +nvoking .ctor .ssumption Dre#condition Dost#condition (cenario <eser&es boo' 4ibrarian # =alid user # ;. 8. <. >. Member comes to the librarian to reserve a book He opens the book reservation form He first checks for availability of book +f book is not available he will enter that book name into reservation list @. Then book is reserved

9. :.

"enefiting .ctor Darticipating .ctor

2se Case: Search ;oo' .. 4. 5. 6. 7. 8. Description +nvoking .ctor .ssumption Dre#condition Dost#condition (cenario $oo's 1or a boo' 4ibrarian # =alid user # ;. 4ibrarian will open search book window 8. He will enter criteria for searching a book <. +f any book matches the criteria, message will be displayed as Fbook is foundF >. &lse GHo match foundF will be the message.

9. :.

"enefiting .ctor Darticipating .ctor

Di11erentiate bet%een: .. E&ent and State E&ent ;. .n event is something that happens at a point in time such as user depresses the left button of mouse. 8. .n event does not have any duration. State The attribute values and links held by an object are called its states. . state is a conditio n or situation during the life of an object during which it

satisfies some conditio n, performs some activity, or waits for some event. 4. Node and Component Node ;. . node corresponds to hardware. 8. The node can represent a piece of a larger hardware component, represented by encapsulating the node /having one node inside the other node1. <. . node represents a physical component of the system. Component ,omponent s represent software. &ach component is representati ve of one or more classes that implement one function within the system. ,omponent is used to represent any part of a system for which 6M4 diagrams are made.

5. "ggregation and Inheritance "ggregation ;. .ggregation is a special form of association, between a whole and its parts, in which the whole is composed of the part. 8. .n aggregation is relating an assembly class to one component. <. +t is also called Ihas a5 relationship. >. ,omponent objects do not have a separate existence, they depend on composite objects. Inheritan ce +nheritanc e is that property of object# oriented systems that allows objects to be built from other objects. +nheritanc e is a relationsh ip between classes where one class is the parent class of another class +t is called Iis a5 relationsh ip. The derived class has a separate existence, they only redefine its parent class and add a few properties of its own.

-4. /a0 Explain Sequence diagram %ith example.

=4>

;1 6M4 sequence diagrams are used to represent or model the flow of messages, events and actions between the objects or components of a system. Time is represented in the vertical direction showing the sequence of interactions of the header elements, which are displayed hori ontally at the top of the diagram. 81 (equence $iagrams are used primarily to design, document and validate the architecture, interfaces and logic of the system by describing the sequence of actions that need to be performed to complete a task or scenario. 6M4 sequence diagrams are useful design tools because they provide a dynamic view of the system behavior which can be difficult to extract from static diagrams or specifications. <1 .lthough 6M4 sequence diagrams are typically used to describe object#oriented software systems, they are also extremely useful as system engineering tools to design system architectures, in business process engineering as process flow diagrams, as message sequence charts and call flows for telecomJwireless system design, and for protocol stack design and analysis. >1 Sequence Diagram +eader Elements: The header portion of the sequence diagram represents the components or objects of the system being modeled and are laid out hori ontally at the top of the diagram. (ee an example sequence diagram here. "ctor !bject 2nit Separator @roup ?epresents an external person or entity that interacts with the system ?epresents an object in the system or one of its components ?epresents a subsystem, component, unit, or other logical entity in the system /may or may not be implemented by objects1 ?epresents an interface or boundary between subsystems, components or units /e.g., air interface, +nternet, network1 Kroups related header elements into subsystems or components

@1 Sequence Diagram ;od* Elements "ction ?epresents an action taken by an actor, object or unit "s*nchronous essage ;loc' .n asynchronous message between header elements . block representing a loop or conditional for a particular header element . call /procedure1 message between header elements

Call Create

essage essage

. 2create2 message that creates a header element /represented by lifeline going from dashed to solid pattern1 Destro* Element ?epresents the destruction of a header element Destro* essage ?epresents the destruction of a header element as a result of a call from another element

Diagram $in'

Else ;loc'

?epresents a portion of a diagram being treated as a functional block. (imilar to a procedure or function call that abstracts functionality or details not shown at this level. ,an optionally be linked to another diagram for elaboration. ?epresents an 2else2 block portion of a diagram block

Alo% Note Aree Note essage #age ;rea' <eturn

$ocumentation note that is automatically formatted to flow after previous elements $ocumentation note that is free#flowing and can be placed anywhere in the diagram /can also be anchored relative to a flow element1 . simple message between header elements . page break in the diagram

essage . return message between header elements (tart of a scenario /set of alternatives1 (tart of an alternative or case in a scenario &nd of a scenario . state change for a header element . steady state in the system (tart of a timer for a particular header element (top of a timer for a particular header element

Scenario Start Scenario Case Scenario End State Stead* State )imer Start )imer Stop

)imer Expiration &xpiration of a timer for a particular header element A1 Example : +t illustrates the basic course of action of the !edit item details! system use case. Hote how different stereotypes are used to indicate actor, boundary, controller, entity and database objects.

/b0 Explain State )ransition Diagram %ith example. ;1 6M4 state machine diagrams depict the various states that an object may be in and the transitions between those states. +n fact, in other modeling languages, it is common for this type of a diagram to be called a state#transition diagram or even simply a state diagram. . state represents a stage in the

behavior pattern of an object, and like 6M4 activity diagrams it is possible to have initial states and final states. .n initial state, also called a creation state, is the one that an object is in when it is first created, whereas a final state is one in which no transitions lead out of. . transition is a progression from one state to another and will be triggered by an event that is either internal or external to the object. 81 %hile coding, it is necessary to understand the details of the modes an Bbject of a ,lass can go through and its transitions at time intervals with the occurrence of any event or action. <1 (tate diagrams /also called (tate ,hart diagrams1 are used to help the developer better understand any complexJunusual functionalities or business flows of speciali ed areas of the system. +n short, (tate diagrams depict the dynamic behavior of the entire system, or a sub#system, or even a single object in a system. This is done with the help of Behavioral elements. >1 Elements o1 a State diagram: . (tate diagram consists of the following behavioral elements* Element and its Description Initial State: This shows the starting point or first activity of the flow. $enoted by a solid circle. This is also called as a 2pseudo state,2 where the state has no variables describing it further and no activities. State: ?epresents the state of object at an instant of time. +n a state diagram, there will be multiple of such symbols, one for each state of the Bbject we are discussing. $enoted by a rectangle with rounded corners and compartments /such as a class with rounded corners to denote an Bbject1. %e will describe this symbol in detail a little later. )ransition: .n arrow indicating the Bbject to transition from one state to the other. The actual trigger event and action causing the transition are written beside the arrow, separated by a slash. Transitions that occur because the state completed an activity are called 2triggerless2 transitions. +f an event has to occur after the completion of some event or action, the event or action is called the guard condition. The transition takes place after the guard condition occurs. This guard conditionJeventJaction is depicted by square brackets around the description of the eventJaction /in other words, in the form of a "oolean expression1. +istor* States: . flow may require that the object go into a trance, or wait state, and on the occurrence of a certain event, go back to the state it was in when it went into a wait stateLits last active state. This is shown in a (tate diagram with the help of a letter H enclosed within a circle. S*mbol

E&ent and "ction: . trigger that causes a transition to occur is called as an event or action. &very transition need not occur due to the occurrence of an event or action directly related to the state that transitioned from one state to another. .s described above, an eventJaction is written above a transition that it causes. Signal: %hen an event causes a messageJtrigger to be sent to a state, that causes the transition7 then, that message sent by the event is called a signal. ?epresented as a class with the MM(ignalNN icon above the actionJevent.

Ainal State: The end of the state diagram is shown by a bull!s eye symbol, also called a final state. . final state is another example of a pseudo state because it does not have any variable or action described. @1 Example : )igure below represents an example state machine diagram for the Seminar class during registration. The rounded rectangles represent states* you see that instances of Seminar can be in the Proposed, Scheduled, Open For Enrollment, Full, and Closed to Enrollment states. .n object starts in an initial state, represented by the closed circle, and can end up in a final state, represented by the bordered circle. This is the exact same notation used by 6M4 activity diagrams, a perfect example of the consistency of the 6M4. " seminar during registration.

-5. /a0 Di11erentiate bet%een ! ) )echnique B ;ooch ethodolog*

=4>?

! ) )echnique Dhases of BMT* ;. .nalysis 8. (ystem $esign <. Bbject $esign >. +mplementation BMT $iagrams * ;. Bbject Model 8. $ynamic Model <. )unctional Model

;ooch

ethodolog*

BMT Hotation for ,lass

Dhases Bf "ooch Methodology * ;. ,onceptuali ation 8. .nalysis <. $esign >. &volution @. Maintenance $iagrams of "ooch Methodology * ;. ,lass $iagram 8. Bbject $iagram <. (tate Transition $iagram >. Module Transition $iagram @. Drocess $iagram A. +nteraction $iagram "ooch Hotation for ,lass

Class Name

Attributes Class Name

Methods

BMT Hotation for class ?elationship .ssociation +nheritance .ggregation BMT notation for Multiplicity &xactly one 9 or more 9 or ;
Clas ssMyClass Clas object1=ne Clas MyClass w ssssMyCla object1= MyClass("H ss new ello",Clas Clas object1=ne 7, !7e1"#$ MyClass MyClass

"ooch Hotation for ,lass ?elationship .ssociation +nheritance .ggregation "ooch Hotation for Multiplicirty ; &xactly one 9 or more 9 or; 9..H 9..;

MyClass w ("Hello", object1=ne object1= MyClass(" w Clas new Hello",7, !7e1" MyClass(" MyClass 7, !7e1"#$ #$ Hello",object1= ("Hello", %ystem!out 7, new - !7e1"#$ !&rintln("ob MyClass 7, !7e1" ject1 ' " ("Hello", #$ ()object1#$

7, !&rintln("ob !7e1" out!&rintl %ystem!out #$ ject1 ' " n("object !&rintln("ob 1 ()object1#$ ' ject1 " '" %ystem! *ile+ut&ut ()object ()object1#$ out!&rintl %tream 1#$ n("object ,os=new %ystem! 1 '" *ile+ut&ut out!&rintl *ile+ut&ut ()object %tream("se n("object %tream 1#$ rial"#$ *ile+ut&ut 1 ,os=new '" *ile+ut& %tream ()object *ile+ut&ut ut%trea ,os=new 1#$ %tream("se m *ile+ut&ut rial"#$ ,os=new %tream("se *ile+ut& +bject+ut *ile+ut& rial"#$ ut%trea &ut%tream ut%trea m oos=new m("serial *ile+ut& ,os=new +bject+ut "#$ ut%trea +bject+ut *ile+ut& &ut%tream( m,os#$ss &ut%tream ut%trea +bject+ut ,os=new oos=new m("serial &ut%tream *ile+ut& +bject+ut "#$ oos=new ut%trea &ut%tream( +bject+ +bject+ut m("serial ,os#$ss ut&ut%tr &ut%tream( "#$ eam ,os#$ss oos=ne +bject+ w ut&ut%tr +bject+ eam ut&ut%tr +bject+ oos=ne eam(,os ut&ut%tr w #$ss eam +bject+ oos=ne ut&ut%tr w eam(,os +bject+ #$ss ut&ut%tr eam(,os #$ss

/b0 Explain reuse o1 Arame%or' %ith respect to blac' box and %hite box 1rame%or'

"bstract class and the %a* their instances interact: ;. . framework is a skeleton of an application that can be customi ed by an application developer. 8. .lthough it is hard to define frameworks formally and clearly, there are several common features of frameworks* ;1 . framework is for reuse purpose /in the development of applications in some specific problem domain1. 81 . framework is an skeleton program that can be extended to a complete application by being filled with necessary components at hot spots, the implementations of which vary from application to application of the framework /Dree ;EE>1 <1 . framework is customi able to fit the applications being developed. >1 . framework predefines some interfaces of the filling components as the framework contract so that the components fit each other and into the framework. @1 . set of abstract classes are usually used to describe the behaviors of frameworks. A1 ,orresponding concrete classes should be implemented as the filling components when extending the framework to applications. <. )ayad and (chmidt /;EE:1 categori ed the existing frameworks into three scopes* /;1 system infrastructure frameworks /81 middleware integration frameworks /<1 enterprise application framework >. )rameworks can also be classified into white#box frameworks and black#box frameworks by the technique used to extend them. @. %hite#box frameworks are extended to applications by inheriting from some base classes in the frameworks and overriding their interface methods, whilst black#box frameworks are extended by customi ing new components according to particular interfaces defined by the frameworks and plugging them into the frameworks )he Initial Chite(box Arame%or' ;. The inheritance feature among the classes of graphic objects listed is obvious and it is necessary to organi e them in a classes inheritance hierarchy, which is shown in )igure ;. 8. .t the root of the hierarchy is the class 2Drimitive2, which abstracts all features of all graphic objects. .t the second level of the hierarchy, there are several abstract classes. <. The class 24ine2 abstracts the most common features of all line classes. >. 4ines are classified into types by two attributes* geometry /shape1 and style /continuity1. @. The three line geometry classes are straight, circular, and polygonal. A. The four line style classes are solid, dashed, dash#dotted, and dash#dot#dotted. :. However, each concrete line class should be specified by the geometry and style simultaneously. C. Darallel inheritance can therefore be used to depict this feature. E. 2Textbox2 is inserted into the hierarchy to generali e the features of the classes 2,harbox2, 2(tringbox2, and 24ogicTextbox2. 2.rrowhead2 generali es the classes 2)illed.rrowhead2 and 2Hollow.rrowhead2. 24eader2 generali es the classes 2"ar4eader2 and 2.rc4eader2.

;9. "oth 2&ntity2 and 2Hatched.rea2 are concrete classes, but 2Hatched.rea2 can be considered as a subclasses of 2&ntity2. ;;. 2$imension(et2 can be used to generali e all kinds of dimension sets.
Primitive

Text ox

!rro"#ead

Leader

Dimension$set

&ntity

,harbox

(tringbox

Hollow .rrowHead

"ar 4eader .rc4eader Line and

4ongitudinal $imension#set

...... Hatched .rea

4ogicTextbox

)illed.rrowHead

.ngular $imension#set

GeometryLine

StyleLine

PolygonalLine

StraightLine

CircularLine

(olid4ine0

DiscontinuousLine

DashDotted Line Doly4ine "ar .rc Dashed Line DashDot Dotted Line

$ashed Doly4ine $ash$otted Doly4ine $ash$ot$otted Doly4ine $ashed (traight 4ine $ash$otted (traight4ine $ash$ot$otted (traight4ine $ashed.rc $ash$otted.rc $ash$ot$otted.rc

Aigure .. )he inheritance hierarch* o1 the graphic classes. ;8. "ased on the classes generali ation shown in )igure ;, the generic composition model of graphic objects shown in &rror* ?eference source not found and the graphic database model in &rror* ?eference source not found can be abstracted and combined to the one in )igure 8. ;<. The recognition process can be extracted and implemented inside 2Drimitive2 by the member function 2do?ecognition/gdb12, which can be considered as a white#box framework. ;>. +n the framework, the hot spots, which are also abstracted to the top abstract class 2Drimitive2 as abstract member functions, can be delegated to be implemented in some lower level abstract or concrete graphic classes. ;@. +n this case, a hot spot may be divided into several smaller hot spots that vary in different descendant classes. ;A. )or example, the 2extension.rea/12 function for all line classes can be implemented inside 24ine2 while the implementation of 2endDoint/12 and 2tanget.ngle/12 are delegated further to the descendant classes. ;:. The sub#framework of 2extension.rea/12 for all line classes is shown in )igure <.

Kraphics$atabase ; 9..0 Primitive OabstractP do?ecognition/1 %indFirstComponent&' %ill(ith&' numO%ExtensionDirections&' extension!rea&' testExtensi ility&' update(ith&' addTo&' ; ;..0

Aigure 4. )he abstract model o1 graphic objects and the graphic database.
Line OabstractP extension.rea/d*+nterger1*.rea endPoint&d*+nterger ')Point tangent!ngle&d*+nterger ')dou le &xtension.rea/d1 endDoint/d1

p * Doint tanget.ngle/d1 a * double create/p,a1 area* .rea

Aigure 5. )he sub(1rame%or' o1 Dextension"rea/0D 1or line classes. )he ;lac'(box Arame%or' "rchitecture ;. )ollowing the framework evolution guideline of ?oberts and Qohnson /;EE:1, we update the generic graphics recognition framework from a white#box one to a black#box one, so that it can be applied to any graphic class, no matter the graphic class inherits from 2Drimitive2 or not. 8. The black#box framework is depicted as a parameteri ed class in )igure >. <. +n the framework, the parameter class 2.Kraphic,lass2 is the overall 2hot spot2 and the contract object, which can be easily plugged into the framework. >. +t can be replaced with any class as long as the class meets the framework contract /the relationship among objects in the framework1 depicted in )igure >. @. However, the graphic class is preferred to inherits from the classes in )igure ; in order to fully reuse the framework. )igure @ shows three possible recognition applications of 2?ecogni erBfM$ashed.rcN2, 2?ecogni erBfM,har"oxN2, 2?ecogni erBfMHatched.reaN2 by instantiating the parameteri ed class 2?ecogni erBf M.Kraphic,lassN2 using arguments of 2$ashed.rc2, 2,har"ox2, 2Hatched.rea2, separately.

.Kraphic,lass ?ecogni erBf run%ith/gdb1 create/1 gobj * .Kraphic,lass gdb * Kraphics$atabase

find)irst,omponent)rom/gdb1

prm * .Drimitive,lass RprmSTnullU fill%ith/prm1

filled * boolean RfilledTTtrueUnumBf&xtension$irections/1 RfilledTTfalseUdestroy/1 n * +nteger Rfor dT;..nU extend/gobj, d, gdb1 extension.rea/d1 area * .rea

search/area1

candidsR9..0U * .Drimitive,lass test&xtensibility/candidsRiT9..0U1

extensible * boolean RextensibleTTtrueU update%ith/candidsRiU1

test,redibility/1

credible * boolean RcredibleTTtrueU addTo/gdb1 Rcredible TTfalseU destroy/1

Aigure 6. )he blac'(box 1rame%or' 1or recognition o1 an* class o1 graphic objects.
.Kraphic,lass ?ecogni erBf run%ith/gdb1 extend/gobj, d, gdb1

?ecogni erBf M$ashed.rcN

?ecogni erBf M,har"oxN

?ecogni erBf MHatched.reaN

Aigure 7. )he blac'(box graphics recognition 1rame%or' architecture and three possible applications

-6. /a0 Chat are the bene1its and dra%bac's o1 identi1*ing classes using "bstraction and Noun #hase approach? )he bene1its o1 "bstraction are as 1ollo%s: ;. +t is very efficient in terms of development time and effort because you do not underline nouns or describe use cases. 8. +t is therefore a good use of problem domain expertise. )he dra%bac's o1 "bstraction are as 1ollo%s: ;. +t requires extensive knowledge of the problem domain. Bnly a domain expert can use this approach effectively. )urthermore, the quality of the model is highly dependent on both the knowledge and skill of the domain expert. 8. +t can be difficult to trace design and implementation constructs back to requirements. +f use cases are employed, classes can be traced to use cases to written requirements. +f noun phrases are isolated from a problem statement, classes can be traced back to noun phrases. %ith abstraction, however, there is nothing available to which to trace classes. <. +t can result in analysis paralysis* agoni ing over details that aren5t in the model. >. The certainty that everything is being thought of is not there i.e. when to stop is not obvious. )he bene1its o1 Noun #hase are as 1ollo%s: ;. The process is almost mechanical and, hence, is appealing in situations where how to start is uncertain. 8. +t requires little, if any, problem domain knowledge, provided a written description of the system is available. <. There is a very clear stopping rule* when all the noun phrases have been looked upon, the identification of classes finishes. )he dra%bac's o1 Noun #hase are as 1ollo%s: ;. +t is a very tedious process, and the written description of a large system could be hundreds of pages long. 8. +t requires a written description of the problem to be solved. Many development organi ations are never provided such a description. <. The quality of the model highly depends upon the quality of the problem statement, and many problem descriptions are not very good.

/b0 Explain the ;ottom(up approach 1or so1t%are s*stem designing %ith a suitable example.

;. .n alternative approach to the Top#$own approach is responsibility#driven design, in which you begin by identifying the responsibilities/state and behavior1of each type of object and then work upward. 8. This process is opposite of the top#down approach because it starts with specific object methods and then uses scenarios primarily as a validation mechanism. <. The following are the steps in bottom#up approach* ;1 +dentify the classes in the system. 81 Make a list of the responsibilities of the objects of each class. .n object5s responsibilities are what it must know and do. <1 +dentify interesting scenarios that will be used to validate the enumeration of responsibilities. +n order to do this, the use cases have to be first identified and modeled. >1 $raw an interaction diagram for each scenario, validating that all necessary responsibilities are present. .dd /or rearrange1 responsibilities as necessary. >. ,onsider the example of 4ibrary (ystem ,lasses o "ook o =ideo o 4ibrary card o 4ibrary member o 4ibrary o ,lerk o %ork o 4oan transaction +dentifying classes and responsibilities o ?esponsibilities for each class o 4endable /book or video1 6nique item number, status*# checked o ut or available Must be able to check itself out Must be able to check itself in o 4ibrary card Membership number, expiry date Must be able to renew itself o 4ibrary member

 Hame, address and other personal information Must be able to update personal information o 4ibrary Droviding clerk access to the system o %ork Title and any other information about the book or video 4oan transaction due$ate

-7. Explain acti&it* diagram %ith an example. ;. .ctivity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity. 8. .n activity represents an operation on some class in the system that results in a change in the state of the system. <. Typically, activity diagrams are used to model workflow or business processes and internal operation. >. The easiest way to visuali e an activity diagram is to think of a flowchart of a code. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place. @. .ctivity diagrams represent the business and operational workflows of a system. .n activity diagram is a diagram that shows the activity and the event that causes the object to be in the particular state. +t expresses more about these transitions and activities Element and its description Initial "cti&it*: This shows the starting point or first activity of the flow. $enoted by a solid circle. This is similar to the notation used for +nitial (tate. "cti&it*: ?epresented by a rectangle with rounded /almost oval1 edges. Decisions: (imilar to flowcharts, a logic where a decision is to be made is depicted by a diamond, with the options written on either sides of the arrows emerging from the diamond, within box brackets. Signal: %hen an activity sends or receives a message, that activity is called a signal. (ignals are of two types* +nput signal /Message receiving activity1 shown by a concave polygon and Butput signal /Message sending activity1 shown by a convex polygon. S*mbol

Concurrent "cti&ities: (ome activities occur simultaneously or in parallel. (uch activities are called concurrent activities. )or example, listening to the lecturer and looking at the blackboard is a parallel activity. This is represented by a hori ontal split /thick dark line1 and the two concurrent activities next to each other, and the hori ontal line again to show the end of the parallel activity. Ainal "cti&it*: The end of the .ctivity diagram is shown by a bull!s eye symbol, also called as a final activity.

,onsider the example of attending a course lecture, at C am.

-8. /a0 Describe architectural pattern and design patterns. 1. Architectural Patterns:

=4>?

;1 .n architectural pattern is a problem#independent way of organi ing a system or subsystem. 81 +t describes a structure by which the different parts of a system are organi ed or interact. <1 %hen organi ed using the Dipes and )ilters pattern, an application consists of a set of filters that communicate with one another using data streams, or pipes. >1 &ach filter reads data from one or more input pipes, transforms that data, and then writes its results to one or more output pipes. +n most cases, an output pipe of one filter is an input pipe of another. 2. Design Patterns: ;1 . design pattern is a solution to a small problem that is independent of any problem domain. 81 +t represents an attractive solution to a design problem that could occur in any kind of application. <1 The same design pattern can be applied in areas as diverse as order processing, factory control, and meeting room scheduling. >1 $ifferent design patterns solve different kinds of problems. @1 Bbject#oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. A1 Many patterns imply object#orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. :1 $esign patterns reside in the domain of modules and interconnections. C1 .t a higher level there are architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system. E1 There are many types of design patterns, like 1. Algorithm strategy patterns: they address concerns related to high level strategies that describe how to exploit application characteristic on a computation platform.

2. Computational design patterns: they address concerns related to the identification of key computations. 3. Execution patterns: they address concerns related to the support of the execution of an application, including the strategies in executing streams of tasks and building blocks to support the synchroni ation between tasks. 4. Implementation strategy patterns: they address concerns related to the reali ation of the source code to support ;1 How the program itself is organi ed, and 81 The common data structures specific to parallel programming. . !tructural design patterns: they address concerns related to the high level structure of an application being developed.

/b0 Explain the 5(tier architecture. ;. . system or application, whether object#oriented or not, can be organised into logical units such as layers or subsystems. 8. These are logical because the grouping criterion is conceptual. <. . layer, for example, defines one tier or stratum of the system that is typically organi ed around functional cohesion. >. &ach layer carries out a different functional responsibility and, therefore, is defined by a conceptual boundary. @. $ue to the increasing performance needed in $istributed ,omputing, two#tier architectures become more and more outdated by the huge load that each client directly talking to the final server would cause. A. The three#tier architecture emerged to overcome. :. The user interacts with the top tier, the presentation layer, which contains the user interface. C. This interface might be a command line interface or a graphical user interface /K6+1. E. The presentation layer, in turn, makes requests of the application layer, which contains the business logic. ;9. That layer loads and stores items in persistent storage using a set of data services provided by the persistence layer.

;;. Ad"antages: ;1 . <#tier architecture helps in building not just an application, but a collection of client and server modules that communicate through standardi ed, abstract interfaces, and when combined they behave like an integrated application system. &ach module is a shareable, reusable object that can be included in other application systems. 81 (ince application functions are isolated within small granular application objects, application logic can be modified much more easily. <1 .pplication logic is no longer tied directly to the database structures or a particular $"M(. >1 Drogrammers can concentrate on developing powerful presentation components, and they do not need to know about the inner workings of the application business logic or how the data is accessed from the database. @1 $atabase analysts do not need to be concerned with how the data is presented to an end user, instead they can concentrate on developing business algorithms. ;8. Diagrammatic representation: Dresentation 4ayer K6+5s, command interfacesV "usiness logic .pplication 4ayer $ata repositories and services Dersistence 4ayer

-9. Short notes: .. Coupling:

=4>?

;1 ,oupling is the measure of interconnection among modules in a software structure like cohesion7 coupling may also be represented on a spectrum. 81 ,oupling depends on the interface complexity between modules, the point at which entry or reference is made and what data passes across the surface. <1 Then lowest possible coupling is optimum.

>1 (imple connectivity amongst modules results in software, that is easier to understand and less prone to a ripple effect caused when error occurs at one location and propagates through the system. @1 Types of coupling* 1. Data coupling: ;1 +f the modules communicate via an elementary data item, which is passed as parameter between the two then the modules are called as data coupled. 81 This data item should be problem related and not used for the control purpose. <1 &xample* passing an integer to a function which computes a square root. 2. !tamp coupling: +f modules communicate via a composite data item such as a structure in ,, then they are stamp coupled. 3. Control coupling: ;1 +f data from the module is used to direct the order of execution of instructions in another module, then the modules are control coupled. 81 &xample* a flag id set in one module and is tested in another module 4. Common coupling: +f two modules share some global data area then they are common coupled. . Content coupling: ;1 +f the modules share their code then they are content coupled. 81 &xample* a branch from one module into another module A1 The degree of coupling is in ascending from data coupling to content coupling.

4. "bstract class: ;1 .n abstract class, or a stract ase class /.",1, is a class that cannot be instantiated. 81 (uch a class is only meaningful if the language supports inheritance. <1 .n abstract class is designed only as a parent class from which child classes may be derived. >1 .bstract classes are often used to represent abstract concepts or entities. @1 The incomplete features of the abstract class are then shared by a group of subclasses which add different variations of the missing pieces. A1 .bstract classes are superclasses which contain abstract methods and are defined such that concrete subclasses are to extend them by implementing the methods.

:1 The behaviors defined by such a class are 2generic2 and much of the class will be undefined and unimplemented. C1 "efore a class derived from an abstract class can become concrete, i.e. a class that can be instantiated, it must implement particular methods for all the abstract methods of its parent classes. E1 %hen specifying an abstract class, the programmer is referring to a class which has elements that are meant to be implemented by inheritance. ;91 The abstraction of the class methods to be implemented by the subclasses is meant to simplify software development. ;;1 This also enables the programmer to focus on planning and design. ;81 Most object oriented programming languages allow the programmer to specify which classes are considered abstract and will not allow these to be instantiated.

5. #ol*morphism: ;1 Dolymorphism means the ability to take more than one form. 81 .n operation may exhibit different behaviour in different instances and this behaviour depends upon the types of data used in the operation. <1 +n object#oriented paradigm, it means different forms of data being handled by the same type of process. >1 )or example, consider the addition operation. )or two numbers, the addition operation will generate a sum. +f the operands were strings, then the addition operation would produce a third string by concatenation. @1 Dolymorphism plays an important role in allowing the objects having different internal structures to share the same external interface. A1 +n other words, this means that a general class of operation may be accessed in the same manner although specific action associated with each operation may differ. :1 Dolymorphism is extensively used in implementing inheritance. C1 +t is achieved by various forms of overloading ' allowing operators and the functions to behave differently in different context.

6. Stereot*pes in uml: ;1 . stereotype defines a constraint that i similar to some other construct, but has special semantics. 81 .ny notational construct can be stereotyped. <1 The name of the stereotype appears in guillemets /or double angle brackets if guillemets are unavailable1.

>1 .ctors are normally modelled in a class diagram as stereotyped classes, where the name of the stereotype is MMactorNN. @1 .ctor classes are like normal classes in that they have instances, can be associated with other classes, and can have a public interface. A1 They differ from regular classes, however, in that they are not implemented. :1 They are black boxes to one5s design. C1 .ny 6M4 construct can be stereotyped. E1 The speciali ation relationship for the uses and extends relationships between use cases is also stereotyped. ;91 $ependencies can be stereotyped for template instantiation.

7. @uidelines 1or 1lexible design: . flexible design is one that is extensible or reusable. Hew features can be added to an extensible design relatively painlessly. +deally, adding a new capability should affect as few classes as possible. . reusable design is one that can be used, either entirely or in part, in another system or application.

 To increase its flexibility, an object#oriented design should exhibit several properties* 1. #igh cohesion: ;1 ,ohesion is a measure of the degree to which an entity does just one kind of thing. 81 The more cohesive it is, the more it limits itself to one area of interest. <1 ,lasses should be cohesive in that they should represent a single abstraction. >1 . class that is not cohesive is more difficult to understand and, in some cases, to extend. @1 Bperations should also be cohesive in that each should handle a single responsibility. 2. $o% coupling: ;1 ,oupling measures what an entity needs to know about the world around it. 81 ,oupling involves what a class or object knows about other classes or objects. <1 4ow coupling means that the classes and objects know as little as possible about other classes and objects. >1 +f one class is coupled to another and the public interface of that second class changes, the implementation of the first class may be affected. @1 ?educing coupling can limit the scope of a change to the design. 3. An e"en distri&ution o' &eha"iour: ;1 Bne must strive to keep state and behaviour together in an object and to have that object Gdo things for itselfF. 81 +n doing so, one can avoid objects that control other objects. 4. !trong modularity: ;1 This is the degree to which Glike thingsF are grouped together. 81 Bne strives to group objects into meaningful packages, subsystems, processes, and so forth.

-4 b0. $ist and explain &arious 1lexible guidelines 1or ma'ing class diagrams. "NS: )ollowing are the flexible guidelines for making class diagram ,ohesion and ,oupling ,lass generali ation and speciali ation (peciali ation versus aggregation .ggregation

Cohesion and Coupling: . diverse entity lacks cohesion. &ntities should be as cohesive as possible. The cohesion must be increase. . design5s coupling, on the hand, is measure of the number and form of connection among its elements. The lower the coupling, is the more likely a change to the design will be more local to one small area.

Class generaliEation and specialiEation: . super class is a generali ation of its subclasses. . superclass defines a generali ation of two or more classes. 3ou generally introduce a superclass for either of two reasons* Two or more classes have common implementation. Two or more classes share a common interface. The common implementation or interface is placed in a superclass and is shared by the classes through inheritance.

The speciali ation of the subclasses is do for following reasons +t adds state information in the form of an attribute.

+t adds state information in the form of association. +t adds behavior in the form of method /or by implementing an abstract superclass method1 +t replaces behavior by overriding a superclass method.

.void the subclasses that do not speciali e anything. +n the typical case, a subclass should add a property or speciali e a method. .void creating subclasses that differ only in the value of a type attribute. Make the properties of superclasses meaningful in all subclasses. 3ou generally do not want subclass to inherit things they don5t need. .void the speciali ation a class along multiple dimension. ,omposing The subclasses require a diamond shaped inheritance graph. 6se speciali ation only when you have an is#a#kind#of relationship.

SpecialiEation &ersus aggregation: .void cases where an object must change its class dynamically that are where an object migrates from one class to another. This required replacing one instance with another. +n particular, avoid speciali ing a class based on the state of its instance or the roles those instance play.

,omposition through multiple inheritance when what you have is aggregation. 6sing multiple inheritance means that the composite inherits all interfaces of its places. 6se aggregation instead.

"ggregation: .ggregation is sometimes an alternative to inheritance when sharing implementation. 6se delegation through association where appropriate. %henever possible do not allow the outside world to see the part of an aggregate. This allows the parts to be change without affecting the outside world. %henever possible do not allow the parts of an aggregate to see one another. This allows one part to be replaced without affecting the others.

;0 De1ine the 1ollo%ing term? .0 2 $ The 6nified Modeling 4anguage /6M41 is a standard language for specifying, visuali ing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non#software systems. The 6M4 represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The 6M4 is a very important part of developing object oriented software and the software development process. The 6M4 uses mostly graphical notations to express the design of software projects. 6sing the 6M4 helps project teams communicate, explore potential designs, and validate the architectural design of the software. 6Ml is an extensive language that allow you to construct several views of a system through the use of its different diagram Aunctional 3ie% The )unctional =iew provides the functional specification of the methods that are to operate within designate containers in the +nterface =iew. The )unctional =iew describes the system using 6M4 notions and notations such as ,lass $iagrams and (tate Machine $iagrams. The )unctional =iew allows the designer to model the object#oriented structure of the system and its sequential behaviour only. Static structural &ie% This view define the static structure of the system. ,lass and object diagrams fulfill this view.. class diagram defines the legal configuration of the system. ;eha&ioural /d*namic structural0&ie% This view define the temporal behavior of the system.6M4 interaction diagram /in particular , collaboration and sequence diagram1 depict the specific sequence of interaction between object in different scenarios. "rchitectural &ie% This view outline the logical and physical structure of the system5s major building block. ,omponent diagram show the programming language source and binary unit architecture . @oal o1 2 $ The primary goals in the design of the 6M4 were* ;. Drovide users with a ready#to#use, expressive visual modeling language so they can develop and exchange meaningful models. 8. Drovide extensibility and speciali ation mechanisms to extend the core concepts. <. "e independent of particular programming languages and development processes. >. Drovide a formal basis for understanding the modeling language.

@. &ncourage the growth of the BB tools market. A. (upport higher#level development concepts such as collaborations, frameworks, patterns and components. :. +ntegrate best practices.

40 "ctors .n actor in the 2ni1ied odeling $anguage /6M41 2specifies a role played by a user or any other system that interacts with the subject.2 2.n .ctor models a type of role played by an entity that interacts with the subject /e.g., by exchanging signals and data1, but which is external to the subject.2 2.ctors may represent roles played by human users, external hardware, or other subjects. Hote that an actor does not necessarily represent a specific physical entity but merely a particular facet /i.e., GroleF1 of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances.2 6M4 8 does not permit associations between .ctors. 3et, this constraint is often violated in practice since the generali ationJspeciali ation relationship between actors is useful in modeling overlapping behaviors between actors.

50 2se case To model system function , 6M4 offers the use case.

Qacobson adopted this term because a use case describe how an actor uses the system . Therefore , a use case represent a function that would Gmake senseF on an actor.

6se cases can be identified in any of several ways. Qacobson recommends that you consider how each actor interacts with the system.

That is , ask yourself two questions*

i1 ii1

%hat interaction with the system does the actor initiateW %htat interaction with the actor does the system initiateW

&ach such interaction is a use case. +n the business functional model for $ryKood.com , a catlog customer particiRates in at least five functions and initiate all five* i1 ii1 iii1 iv1 v1 The placing of an order. The cancelling of an order. The cancelling of an order item. The returning of an order item. =arious queries about orders.

60S%imlanes . swimlane is a way to group activities performed by the same actor on an activity diagram or to group activities in a single thread. Aigure 4 includes three swimlanes, one for each actor. Aigure. . " 2 $ acti&it* diagram 1or the enterprise architectural modeling /simpli1ied0.

-.4: "0 Di11erentiate bet%een ;. specialiEation and aggregation /page .4:(2 $(charles <ichter0 SpecialiEation &ersus aggregation*

The use of class speciali ation can result in an inflexible design. +n some cases, employing aggregation instead produces a superior solution. Bne such example is the speciali ation of a class along different /unrelated1 dimensions* .nother example is a property shared by some, but not all, subclasses. +n some cases, multiple inheritance is used in situations that call for aggregation. These problems and their solutions are described. X "ggregation* The advantages of hiding an aggregate!s parts within the aggregate are outlined. $ifferent approaches that allow an aggregate!s parts to be reused in other applications are examined.

4. )ernar* and <e1lexi&e associations /page 8.(2 $(charles <ichter0 )ernar* and <e1lexi&e "ssociations * The degree of all of the associations described until now is two, meaning that each relates two classes. 6M4 permits the specification of associations of any degree, however. The notation for associations of degree three or greater is a diamond with 2legs2 to all classes that participate in the association, as depicted in

)igure 8.88.

Passenger name address Flight ,li-htNumber date

Seat rowNumber seatNumber

%hile ternary /and larger1 associations are permitted in 6M4, you should normally try to avoid them during design. Bne reason is based on human cognition* (uch associations are not intuitive and are somewhat difficult to describe. +n a ternary association, for instance, there are six cardinality constraints. %hat is the best means to specify those constraintsW .nother problem with ternary associations is that they have no standard implementation idioms. "inary associations have idioms, such as the containers /lists1 described above, but how would you implement the association in )igure 8.88W +f the association is implemented as a class /where each instance of the class is a link1, why not simply introduce that class in the designW +n )igure 8.8<, for example, the ternary association in )igure 8.88 has been transformed into the (eat .ssignment class. .n instance of this class represents a ternary link between a Dassenger, (eat, and )light instance.

6M4 also allows re1lexi&e/or recursive1 associations in which a class is linked to another..n &xample such association is shown below*

Employee name a-e

"!!1 mana-es *

5. method o&erriding and pol*morphism /page 9:(2 $(charles <ichter0 ethod !&erriding and #ol*morphism * ,onsider the example in )igure 8.><. . run method has been introduced in the .utomobile class. Hote also that a run method is defined in =ehicle, the super class of .utomobile. The .utomobile class is overriding the run implementation it inherits from =ehicle, which means that it is replacing the inherited run behav#ior with its own variant. The run implementation in .utomobile may either call the run implementation inherited from =ehicle /in which case it extends, rather than replaces, the behavior1, or it may ignore the inherited implementation altogether.

.ehicle /ehicle01 nun(#

Automobile race( # run(#

)+K6?& 8 .>< Bverriding a method.

,onsider the Qava code fragment for method x .#f /repeated from (ection 8.@.8, 2Type Dromotion21* class Y O

public static void f/=ehicle v1 O =. run/1 7 P P (uppose that you call x.f,passing a reference to an .utomobile. %hich run implementation will be invokedW The compile#time type of the reference in x.f is =ehicle, which means that if the decision is made at compilation /or link1 time, the run method in =ehicle will be called. Bn the other hand, the execution#time class of the object to which v refers in this example is .utomobile7 therefore, if the binding is deferred until execution time, .utomobile!s run method could be invoked. +n the typical case, the binding is delayed until execution time7 so, the run method for .utomobile will be called. /There are ways to force binding at com#pilation time, but that is beyond the scope of this book.1 This means that, even though an .utomobile object is being referenced as a vehicle, it still acts like what it really is an.utomobile. This is referred to as run#time /or execution#time1 binding, polymorphism, or single dispatching. /The 2dispatching2 part of the last term refers to the selection of a method implementation, whereas the 2sin#gle2 portion indicates that the selection is based on the type of a single object. +n the example, the correct implementation of run is selected based on the type of the object on which run is invoked.1 Note: Dolymorphism means many forms7 therefore, the mere overriding of a method technically would qualify as polymorphism, regardless of when the binding occurs. The customary use of the term, however, includes execution#time binding. %hat are the advantages of type promotion and polymorphismW ,onsider this scenario of a system that has text and binary files. 3ou occasionally must print files, but text and binary files employ different print implementations. +f you were to write ,#style code to print files, you would do something like the following* class ,lient O public void handle)ile /)ile f1 O switch /f.getType/11 O case T&YT* JJ print text file case "+H.?3* JJ Drint binary file P P P +n other words, each time you must print a file, you introduce conditional code that is based on the type of the file . 3ou originally intended to write this condi#tional code only once, but over time, the code is duplicated in several places. %hen confronted with your colleagues! comments about the proliferation of conditional code, you offer that there shouldn!t be any additional types of files. .fter all, other than text and binary files, what types of files could possibly existW Bver time, of course, you encounter several new file types, each printed in a different way. DostscriptTM files, for example, require the invocation of a Dostscript driver. +mage files require some rendering of the image. +n each case, 3ou must find every occurrence of the conditional printing code and add a new condition with the code to print the new type of file. The alternative to the preceding conditional code is to employ type promotion and polymorphism. . )ile superclass defines the print method. &ach different type of file is represented by a subclass of )ile that implements the print method appropriately for that type of file. .n initial hierarchy with Text )ile and "inary )ile is depicted in )igure 8.>>.

File name &rint(#

Text File &rint(#

Binary File &rint(#

)+K6?& 8.>> The initial )ile class hierarchy. . client that prints files is passed a reference to a specific type of file, but the client receives it as a reference to a generic )ile. The client code for printing files is as follows* class ,lient O public void dolt /)ile f1 O f.print/17 JJ polymorphic print call P P Hote that this client code is completely ignorant of the specific /sub1types of files. +n some part of your application, of course, you must create the specific types of files. 3ou should strive to restrict the code that is aware of the )ile subclasses to a small part of your application. .fter creating instances of specific type of )ile subclasses, promote those references to be of type )ile/and deal only with files in the rest of the application1. .dding a new type of file requires adding a new subclass. )igure 8.>@ illus#trates the addition of an +mage )ile. The preceding client code does not change, because it deals only with generic )ile references.

File name &rint(#

Text File &rint(#

Binary File &rint(#

Image File &rint(#

)+K6?& 8 . > @ +ntroducing an +mage )ile class.

Aollo%ing is a list o1 the bene1its o1 t*pe promotion and pol*morphism: X They allow clients to be unaware of specific subclasses. The client is given a reference to the more abstract superclass type /avoiding a form of cou#pling called subclass coupling or subtype coupling1. X They shield the client from changes in the subclasses. .dding or removing subclasses does not affect the client. ,hanging existing subclasses does not affect the client /as long as the interface of the superclass does not change1. X +n some languages, they can lessen the need for recompilation. .s long as the public interface of the superclass is unchanged, the client need not be recompiled. This is a major issue in large systems /4akos ;EEA, <8:#>:;1. . client should therefore refer to the most general type possible.

-.4.;0Explain the extension mechanism used in 2 $ notation./page:9(2 $(charles <ichter0 $ifferent programming languages offer different sets of features. )or example, Qava has the ,lass metaclass, and (malltalk implements the full metaclass pro#tocol, but many other languages have no explicit metaclasses. Qava also has interfaces, whereas (malltalk and ,ZZ have no analogous construct7 ,ZZ has an explicit friend relationship not present in other languages. How is it possible for a notational system to accommodate all of these variationsW )urthermore, you may want to model concepts that don!t lend themselves to graphical depiction. Bne example is a constraint, which is simply a rule that the implementation cannot violate. How could you hope to formulate a graphi#cal language that permits all the various forms of constraintsW

To address these needs, 6M4 includes a set of mechanisms that allow the addi#tion of new things to the 6M4 notation. The mechanisms come in two general forms* X "nnotation mechanisms* These are annotations of existing items in a 6M4 diagram. The two annotation mechanisms are specifications and adorn#ments. X Extension mechanisms* These allow the introduction of new properties, constraints, stereotypes, etc.

- 5 b.0 Crite a short notes on: i0 Class @eneraliEation .s you define classes, you may notice that some classes have the same attributes or the same operations. %hen this is the case, you place these common features /attributes, operations, and so on1 in a more generic class called the superclass*

The classes that share the common features are known as su classes of the superclass.
This process of finding similar attributes or operations across classes is known as generali+ation* The process for showing a generali ation in 6M4 is simple* .. Identi1* the subclasses. 4ocate classes that have the same attributes andJor operations. These classes are your subclasses. 4. Create a superclass. Drovide a superclass to hold the common attributes andJor operations of the subclasses. Kive the superclass a name that categori es all the subclasses. Dlacing the superclass above the subclasses in the diagram make it easier to read but is not required.1 5. "dd common 1eatures to the superclass. ?emove the common attributes and operations from the subclasses and place them /once1 in the superclass. 6. Dra% a generaliEation relationship.

3ou draw a generali ation line from each subclass to the superclass. +n 6M4 the generali ation line is represented as a solid line with a hollow arrowhead at the superclass end. +n 6M4, a line with the hollow arrowhead that connects a subclass to a superclass is known as a generali ation relationship.

)igure ; shows the beginnings of several generali ations, arranged in an inheritance hierarchy*

Aigure .: (imple inheritance hierarchy. ii1class specialiEation +n contrast to generali ation, speciali+ation means creating new subclasses from an existing class. +f it turns out that certain attributes, associations, or methods only apply to some of the objects of the class, a subclass can be created. The most inclusive class in a generali ationJspeciali ation is called the superclass and is generally located at the top of the diagram. The more specific classes are called subclasses and are generally placed below the superclass.

+n following)igure, the class Freight /;1 has the attribute Degree o% #a+ardousness /81, which is needed only for cargo, but not for passenger luggage. .dditionally /not visible in )igure >.8C1, only passenger luggage has a connection to a coupon. Bbviously, here two similar but different domain concepts are combined into one class. Through speciali ation the two special cases of freights are formed* Piece o% Cargo /<1 and Piece o% Luggage />1. The attribute Degree o% #a+ardousness /@1 is placed where it belongsL in Piece o% Cargo. The attributes of the class Freight /;1 also apply to the two subclasses Piece o% Cargo /<1 and Piece o% Luggage />1*

Figure ,*-. Example o% speciali+atio (o much for the mechanism. However, the domain meaning of the relationship between superclass and subclass is much more important. These rules apply to this relationship*

.ll statements that are made about a superclass also apply to all subclasses. %e say that subclasses GinheritF attributes, associations, and operations from the superclass. )or example* +f the superclass Freight has an attribute (eight, then the subclass piece of luggage also has an attribute %eight, even though this attribute is not listed in the subclass Piece o% Luggage.

.nything that can be done with an object of the superclass can also be done with an object of the subclass. )or example* +f freight can be loaded, pieces of luggage can also be loaded. +n the terminology of the system that is being modeled, a subclass has to be a special form of the superclass. )or example* . piece of luggage is a special case of freight. The counter#example to this is* . flight is not a special case of a flight number.

iii0Coupling

,ohesion is a measure of the diversity of an entity5s feature .the less diverse its feature are the more cohesive the entity is. +n other word,a highly cohesive entity represent a single concept . "ecause many simpler elements are generally preferable to cated ones, each entity in a design should be as cohesive as possible. ,oupling, on the other hand, occurs[when one element of design depends on another in some way. Therefore the#greater the interdependence among element the higher the leve,; of coupling. %hen possible, coupling should be avoided. a changr in one element may necessitate a corresponding change in other elements that depends on that element. .s its coupling is reduced, a design#generally becomes more maintainable and extensible. - 70 "0Dra% an acti&it* diagram to model 1lo% 1or goods returning s*stem.

Login

Select Order

Select Order Items

Choose Transport Mode

Enter Train Number !ate o" dispatch # challan No

Enter Transport Name !od # Challan No

$enerate %e"und &ill

%e"und Con"irmation

"0 Explain bottom(up approach o1 a s*stem in detail.

. bottom#up approach is the piecing together of systems to give rise to grander systems, thus making the original systems sub#systems of the emergent system. +n a bottom#up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top#level system is formed.

This strategy often resembles a 2seed2 model, whereby the beginnings are small but eventually grow in complexity and completeness. However, 2organic strategies2 may result in a tangle of elements and subsystems, developed in isolation and subject to local optimi ation as opposed to meeting a global purpose.

+n a bottom#up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top#level system is formed. This strategy often resembles a 2seed2 model, whereby the beginnings are small, but eventually grow in complexity and completeness. Bbject#oriented programming /BBD1 is a programming paradigm that uses 2objects2 to design applications and computer programs. +n Mechanical &ngineering with software programs such as DroJ&HK+H&&?, (olidworks, and .utodesk +nventor users can design products as pieces not part of the whole and later add those pieces together to form assemblies like building 4&KB. &ngineers call this piece part design. This bottom#up approach has one weakness. Kood intuition is necessary to decide the functionality that is to be provided by the module. +f a system is to be built from existing system, this approach is more suitable as it starts from some existing modules. DroJ&HK+H&&? /as well as other commercial ,omputer .ided $esign /,.$1 programs1 does however hold the possibility to do Top#$own design by the use of so#called skeletons. They are generic structures that hold information on the overall layout of the product. Darts can inherit interfaces and parameters from this generic structure. 4ike parts, skeletons can be put into a hierarchy. Thus, it is possible to build the overall layout of a product before the parts are designed.

\.: "0Explain !bject S*nchroniEation Bne, source of concurrency in the stock#trading system is the presence of multiple &ntry ,lients simultaneously accessing the same order (erver or .ccount (erver, This opens the possibility that two &ntry ,lients /that is, two (ervice ?epresentatives1 might attempt to simultaneously access .the same Brder or .ccount instance. ,(uppose, for example, that one (ervice ?epresentative is transferring money into an .ccount while another is removing money from that same account without any locking ,the two modification could conflict . +n general the level of locking can be any of the following

X . class or method is se uential. %hen invoked on an instance, a sequential me thod neither checks nor grabs the lock of that instance. This may mean that the method can execute concurrently with any other method called on the instance.. . sequential class is one in all methods are sequential. X class or method is concurrent /or synchronous in earlier versions of 6M4.1.. concurrent method grabs a lock on the instance on which it. was invoked. Then, it holds that lock throughout the duration of the execution of the method. Qust before control is returned to the caller, the lock is released. This blocks out requests. from all other clients, while the method is in progress. X !. class is guarded. The class provides methods that a client must invoke on an in instance of the class to Qock and subsequently unlock that instance. %hen a class is guarded the client must invoke lock /or sei e1 to obtain the lock on an inc,tance before calling any other methods on the instance. +f the instance already locked by another client when the client invokes lock the client # thread or process must wait until the lock becomes available. The synchroni ation semantics of a class or method is depicted as a ]property of #that entity. The (tock class in )igure C.88 includes a property indicating its instance are guarded. The class lists the lock and unlock methods used to lock and unlock a (tock instance.+n the account class in the figure., the fudbuy and fund(ell methods are concurrent, indicating that an .ccount instance locks itself when one of those methods is invoked. The balance method on the other hand, seqqcntial. +t does no locking, and so it can be invoked on] aninstaiace while that instance is simultaneously handling another request. /"ecause the! balance method simply returns the balance of the .ccount, the assumption is that no locking is required.1

(tock/guarded1

new"uyorder/1 newsellorder/1 lock/1 unlock/1 "ccount

)undbuy/1 )undsell/1 "alance/1

X The client code isn!t cluttered with calls to the locking and unlocking methods /for example,]lock and unlock1. ,lients simply invoke the application#specific methods provided by the service object.

X 3ou don!t have to depend on clients to behave correctly. %ith a guarded (tock dass,<.2..Jient must lock a (tock instance before using it. %hat if the client forgets to !unlock an instance the client has lockedW %hat if a client unlocks an instance that is. currently locked by another clientW X ,ircular waiting /that is, deadlock1 may be easier to prevent. This situa#tion can result when you have a cycle of locking dependencies. )or example,suppose ,lient ; has locked . and is trying to lock ", while, ,lint 8 has locked " and wants to lock .. ,lients ; and 8 will wait forever on e:Hothe:. %ith guarded ;<Ting, a client can hold a lock for a long # period of time. to prevent deadlock, therefore, you must predict clients! patterns of grabbing and holding locks. %ith concurrent locking, on the other hand, a lock is held only during the execution of a method. $eadlocks, therefore, are due to circular calling patterns, and these are typically easier to find than deadlocks in guarded schemes. X ,oncurrent ]policies can be ,changed without the client!s knowledge /and, therefore, without altering the client1. (uppose you discover that an .ccount can safely handle a fund"uy and a fund(ell request simultaneously. +n an .ccount class with concurrent locking, that modification is internal to the class. +n a guarded .ccount, however, the lock method must be extended to include an argument that indicates how the client intends to use the .ccount, and the client code must altered to supply the appropriate value.

b0Explain reuse o1 1rame%or' %ith respect to: i0%hite box 1rame%or' ii0blac' box 1rame%or' ans . component represent an attempt to achieve large scale . for the most part, however , a component is a monolithic entity. ,ustomi ation is typically achieved by adding external behavior and by composing component together.

. framework on the other hand is a set of classes that work together to achieve a purpose but that must be speciali e by the designer.

. frame work defines a family of related application in a general way. +t contains the element that are common to those application.

;lac' box 1rame%or': "lack#box frameworks consist of concrete and ready#to#use classes and services. .lthough developers can extend the existing framework components to achieve customi ation in a black#box framework, they more often adapt the framework by combining a number of components to create the desired result. . black#box framework may contain many common spots, and it employs the composition approach to enable its hot spots. )igure 8#C illustrates a black#box framework.

Aigure 4(:. ! lac/$ ox %rame"or/ "ecause of the composition approach in a black#box framework, it provides a greater range of flexibility than that of a white#box framework. $evelopers can pick and choose different components to achieve specific application requirements with infinite possibilities. 6nlike white#box frameworks, where a developer often needs to know the detailed implementation of the framework component for adaptation, black#box frameworks consist of components that hide their internal implementation. .daptation of such components is done through well#defined interfaces, such as certain public methods and properties.

$evelopers need to be familiar with only these public members in order to use the framework. ,ompared with white#box frameworks, black#box frameworks are harder to develop. &ncapsulating business#domain expertise into components that are generic enough to be used in many application scenarios is not an easy task. &ncapsulating too much will lead the domain expertise inside the component becoming less fit in many application scenarios. &ncapsulating too little will lead to developers having to work with a large number of components and more complex coordination logic in order to build the application. .lthough developers don5t have to deal with learning the internal implementation of the abstract class as they do with a white#box framework, they do have to be familiar with a greater number of components and their use when using a black#box framework, since the developer now has more GmovingF parts to deal with in order to combine them into something they need. %hen developing an application framework, there is no requirement that the framework contain either all abstract classes or all concrete classes. +n fact, neither pure white#box nor black#box frameworks are practical in the real world. Having a mix of both the inheritance approach and composition approach gives you the freedom to use whatever approach is best for the design of a particular component. "y mixing white#box frameworks and black#box frameworks, you effectively create a gray#box framework. Chite box 1rame%or' %hite box frameworks take both inheritance and composition approach, is usually made up with combination of abstract classes and concrete classes. The approach of enabling its common spots and hot spots is determined on a component#by#component basis. )igure 8#E shows a white#box framework.

Aigure 4(F. ! white $ ox %rame"or/

. "hite$ ox %rame"or/ requires the framework user to understand the internals of the framework to use it effectively. +n a white box framework, you usually extend behavior by creating subclasses, taking advantage of inheritance. . white box framework often comes with source code. The most common sign that a framework is white#box is heavy use of inheritance. %hen you use the framework by extending a number of abstract /or even concrete1 classes, you are dealing with a white#box framework. +nheritance is a closer coupling than composition7 an inherited class has more context it must be aware of and maintain. This is visible even in Qava5s protection scheme* a subclass has access to the public and protected parts of the class, while a separate object only sees the public parts. )urthermore, a subclass can potentially GbreakF a superclass even in methods it doesn5t override, for example by changing a protected field in an unexpected way.

;0 Di11erentiate bet%een I 0"rchitectural #attern and Design #attern "rchitectural #attern: .n .rchitectural pattern is a problem#independent way of oragani ing a system or subsyterm. +t sets which functionality the system should perform, split the functionality between components, set how components should behave and communicate in the system context, set the physical location of components and finally choose the tools in order to create components. .rchitecture patterns are more about behavior of the system +t describes a structure by which the different parts of a system are organi ed or interact. This organi es system using )ilters and Dipes. .pplication consist of a set of filters that communicate with one another using data streams, or pipes. &ach filter reads data from one or more pipes, transform that data, and then writes its result to one ot more output pipes.

Design pattern : $esign pattern is a solution to a small problem that is independent of any problem domain. +t represents an attractive solution to a design problem that could occur in any kind of application. while architecture deals more with the wide picture, design should drill down in to the details relating to implementing certain components. $esigning of components end up with classes, interfaces, abstract classes and other BB feature in order to fulfill the given component tasks. $esign pattern are more about classes and interfaces needed in order to create component

II 0Class Diagram and !bject Diagram Class Diagram : . class diagram is a static representation of your system. +t shows the types of classes, and how these classes are linked to each other . class diagram is a graph of ,lassifier elements connected by their various static relationships ,lass diagrams show the logical, static structure of a system and are central the 6nified Modeling 4anguage.

!bject Diagram : . pictorial representation of the relationships between these instantiated classes at any point of time /called objects1 is called an 2Bbject diagram.2 ,lass diagrams can contain objects, so a class diagram with objects and no classes is an Gobject diagram.F .n object diagram is a graph of instances, including objects and data values. . static object diagram is an instance of a class diagram7 it shows a snapshot of the detailed state of a system at a point in time. Bbject diagrams play a smaller role in 6M4. They are used primarily for documenting test cases and scenarios

III 0 "ggregation and SpecialiEation "ggregation : .ggregation is to create new functionality by taking other classes and combining them into a new class .n aggregation is the 2a part of2 relationship in which objects represents the components in same assembly. .ggregation may be the special form of .ssociation. %ith aggregation, you get to choose either implementation or interface, or both ## but you!re not forced into either. The functionality of an object is left up to the object itself &xample /aggregation1 * . Daragraph consists of many sentences. Here Daragraph contains sentences.

SpecialiEation : (peciali ation is relationship between the classes. (peciali ation is the is$a$/ind$o% relationship, in which the speciali ation is the subclass, or subtype. &xample* +f we have class =ehicle, .utomobile and Truck. Then .utomobile and Truck is$a$/ind$o% =ehicle. =ehicle is a superclass and .utomobile and Truck are subclasses.

I30 State and E&ent E&ents: (tate machines communicate by sending events to one another. &vents are typically treated as operations. +n some cases, an event may corrospond to a signal, such as a hardware interrupt. +n other situation, it may corrospond to a message, such as a method invocation or an inter#process message. The term event refers to the type of occurrence rather than to any concrete instance of that occurrence. )or example, ^eystroke is an event for the keyboard, but each press of a key is not an event but a concrete instance of the ^eystroke event. .n event can have associated parameters, allowing the event instance to convey not only the occurrence of some interesting incident but also quantitative information regarding that occurrence. )or example, the ^eystroke event generated by pressing a key on a computer keyboard has associated parameters that convey the character scan code as well as the status of the (hift, ,trl, and .lt keys.

State : . state is an abstraction of an object5s state. +t can represent particular values for a subset of the object5s attributes an links. . transition between states, therefore, represents some changes in those values. . state captures the relevant aspects of the system!s history very efficiently. )or example, when you strike a key on a keyboard, the character code generated will be either an uppercase or a lowercase character, depending on whether the ,aps 4ock is active. . state is depicted in 6M4 as a capsule with name andJor a set of actions.

-.40 "0 Dra% a class diagram to represent the 1ollo%ing in1ormation The .irlines operates various flights from airports in different cities across the world. The airline has a fleet of planes. %ith regards to every flight the airlines maintains information of crew, passengers, seat allocation.

-. 5 "0 Dra% a sequence diagram to model G")

Cithdra%H.

Customer

Screen!isplay

TransactionManager

'ccount!atabase

!ispenser

Transaction

( ) %e*uest 'mount+, - ) Sho. 'mount+,

/ ) Enter 'mount 0 ) $et 'mount 1 ) %e*uest 'ccount &alance+, I" amount > balance call use case O7erdra.n 'mount

2 ) %eturn 'ccount &alance+, 3 4i" amount < balance5 ) generateCash 6 ) Send Cash+,

8 ) CollectCash

(9 ) Compute&alance

(( ) :pdate 'ccount &alance (- ) Create Transaction+,

;0 Explain ;ooch !!" methodolog*. ;ooch ethodolog*:(

This method was published in ;EE; by Krady "ooch. This is widely used object oriented method that helps to design the systems using the object model. This method covers the analysis and design phases of an object oriented system. The method defines different models to describe the system - it supports iterative - incremental development of systems. +t includes six diagrams ' class diagram, object, state 'transition, module diagram, process and iteration diagram. "ooch methodology, prescribes a macro development process - micro development process. The development process* The primary concern of the macro process is technical management of the system. ,onceptuali ation* Here you establish core requirements of the system, you establish set of goals to develop a prototype to process the concept. .nalysis - development of the model* Here you use the class diagram to describe the roles and responsibilities objects are to carry out in performing the desired behavior of the system. Then use object diagram or alternatively use the interaction diagram. $esign or create system architecture* Here you use class diagram to decide what classes exist - how they relate to each other. Then use object diagram to decide what mechanisms are used to regulate how objects collaborate. Then use module diagram - finally use the process diagram to determine to which processor to allocate a process. &volution or implementation* ?efine the system through many iterations produce a stream of software implementation for executable each of which is a refinement. Maintenance* Make locali ed changes to add new requirements - eliminate bugs. Micro development process* The micro#process is a description of the day#to#day activities by a single or small group of software developers which could look blueey to outside viewer. The steps are* +dentify class and objects +dentify class and objects semantics +dentify class and objects relationships +dentify class and objects interfaces - implementation.

Explain logical architecture model and hard%are architecture model. .ns* . system or application, whether object#oriented or not, can be organi ed into logical units such as layers or subsystems. These are logical because the grouping criterion is conceptual. . layer defines one tier or stratum of the system that is typically organi ed around functional cohesion. &ach layer carries out a different functional responsibility and, therefore, is defined by a conceptual boundary. . common layered system organi ation is the three#tiered architecture. The user interacts with the top tire, the presentation layer, which contains the user interface. The presentation layer in turn, makes requests of the application layer, which contains the business logic. That layer loads and stores items in persistent storage using a set of data services provided by the persistent layer. The number of tires can be expanded further, resulting

in what is referred to as an H#tiered architecture in its general form. . layer can be modeled in 6M4 as a package, which is a logical grouping of classes or use cases. .s such, it can appear in a class diagram or a use case diagram. . package is depicted as a folder labeled with the name of the package. +n its closed form, a package includes its name on the folder, but the contents of the package are not visible. +n its open form, a package exposes the classes or use cases it contains. The folder5s tab is labeled with the name of the package.

- 6.". 2sing an example explain State )ransition Diagram. (tate Transition $iagram* . state transition diagram depicts the states through which an object passes, and so entering a state implies that a specific pre#condition on that object holds. The state transition diagram used in object#oriented design, for example, a transition from one state to another is enabled either by a specific condition arising, or by the receipt of a specific event. (tate transition diagram describes the state#based behavior of a class of instances across all scenarios. .lthough state transition diagram can be draw for any class, the diagrams for many classes be relatively uninteresting. .n object has meaningful state#based behavior if we can say one of the following * The object passes through a set of states. (ome of the object5s behaviors are meaningful in some states but meaningless in others The object5s methods must be executed in a particular order.

&xample for (tate Transition $iagram *#

#roblem Statement* . seminar is conducted during the C $ays workshop by an +nstitute. $raw a state diagram for seminar during the registration process.

Diagram:

= Student Enrolled)4Seat '7ailable5= addStudent

;roposed

Scheduled

Scheduled

open

Open <or Enrollment entry=entry = logSi>e+, closed

student Enrolled)4No seat '7ailable5= 'ddTo?aitingList+,

seat a7ailable

<ull entry=do = addTo ?aitingList+ ,@ considerSplit closed

Closed to Enrollment entry=entry= noti"yInstructor+,

Student !ropped ) 4 No seat '7ailable5

Student dropped) 4 seat a7ailable5 = enroll<rom?aitingList cancelled

cancelled

cancelled

cancelled

cancelled

Description o1 State )ransition Diagram:

)he diagram abo&e sho%s the State )ransition diagram 1or a registration process 1or the %or'shop.

State . : #roposed .0+t is the starting process. 40 +t shows the initial state of the seminar object.

State 4 : Scheduled This state of seminar object schedules various activities of seminar as a part of C days workshop.

State 5 : !pen Aor Enrollment .0 Bnce scheduling state of seminar object is completed , the object enters into Gopen for enrollment F state and those who wants to enroll for the seminar can register themselves through this process. 40 +f seat is available then interested person enrolled for the seminar through add student/1 method, otherwise enrollment gets canceled. 50 This state depends on other two states of seminar object which are )ull and ,losed to &nrollment.

State 6 : Aull .0 This state will check for the seat availability and if seat is not available then it puts those entries into waiting list. 40 +f any confirmed student cancels hisJher registration, then waiting list members get updated and enrolled for the seminar.

State 7 : Closed .0 This process closes the enrollment and notification is sent to the instructor about the same.

Chat are the ad&antages and disad&antages o1 !bject !riented #aradigm. .ns *#
-

The object#oriented paradigm views the world as a collection of unique objects, often referred to as a society of objects. &ach object has a lifecycle where it knows something, can do something, and can communicate with other objects. %hat an object knows and can do are known as features. )or example, a manager knows his or her name, can initiate or terminate a project, and can communicate with a team to lead the team to successfully execute the project. )eatures belong to two broad categories or types* attributes and operations. "ttributes class defines attributes and an object has values for those attributes. &ven if two objects have the same values for their attributes, the objects are unique and have their own identities.
+n a 6M4 diagram, a class may be shown with a second compartment that lists these

(omething that an object knows is called an attribute, which essentially represents data. .

attributes as text strings. Bperations represents processing. How an object does the processing for a given operation is known as the operation!s method or implementation. )or example, when using a programming language, we declare functions or procedures and define their bodies /lines of code1 that determine what the functions or procedures do when they are invoked and executed7 a function!s declaration is the operation, and the body definition is the method. "d&antages :(

(omething an object can do is called an operation or specification and essentially

BBD provides a clear modular structure for programs which makes it good for defining abstract datatypes where implementation details are hidden and the unit has a clearly defined interface. BBD makes it easy to maintain and modify existing code as new objects can be created with small differences to existing ones. BBD provides a good framework for code libraries where supplied software components can be easily adapted and modified by the programmer. This is particularly useful for developing graphical user interfaces.

Disad&antages:

BB is often provided through such imperfect vehicles as ,ZZ and Qava Rdiscuss their defects and BB is inapplicable

-.7 ;0 $ist and explain d*namic designing o1 the so1t%are s*stems. ^eep classes cohesive. . class should represent a single abstraction. .pplying data normali ation rules can result in more cohesive classes. ?educe identity coupling by reducing association in your class diagram and by implementing association in only one direction where possible. ?educe subclass coupling by pushing a client5s knowledge of types as high up in the class hierarchy as possible. %herever possible, a client should refer to a superclass rather than to specific subclasses. Move common interfaces and implementations to one place. 3ou can move them to a superclass, or you can share implementation through the aggregation of a helper class. .void subclasses that do not speciali e anything. +n the typical cases a subclass should add a property or speciali e a method. .void creating subclasses that differ only in the value of a type attribute. Make the properties of superclasses meaningful in all subclasses. 3ou generally do not want subclasses to inherit things that don5t need. .void speciali ing a class along multiple dimensions. ,omposing the subclasses requires a diamond#shaped inheritance graph /and is not possible in languages that ban multiple inheritance of implementation1. 6se speciali ation only when you an Gis#a#kind#ofF relationship. .void cases where an object must change its class dynamically. This requires replacement one instance /and its references1 with another. +n particular, avoid speciali ing a class based on the states of its instances or the roles those instances play /as when the state or role changes, the class of the instance must also change1. .void composition through multiple inheritance when what you have is aggregation. 6sing multiple inheritance means that the composite inherits all interface of its pieces. 6se aggregation instead. .void concrete superclasses, as they are somewhat Gbrittle.F .dding a property to the superclass introduces it in the subclasses, too. $on5t forget that association /or aggregation1 is sometimes an alternative to inheritance when sharing implementation. 6se delegation through association where appropriate. %herever possible, do not allow the outside world to see the parts of an aggregate. This allows the part to change without affecting the outside world. %herever possible, do not allow the parts of an aggregate to see one another. This allows one part to be replaced without affecting the others. +f the reuse of the parts is a goal, decouple the parts of an aggregate from their aggregate whole. +f a part must interact with its whole, use an interface class to generali e the interface.

-.8 "0Explain 5 approaches 1or identi1*ing classes. (everal class identification approaches have been proposed in the past. 6nfortunately, no single approach works best in all situations. The choice of an approach depends on several factors, including the type of system, the domain expertise of the staff, and the form of the requirements documentation. There are three different approaches* o $eveloping a class diagram from noun phrases o $eveloping a class diagram using abstraction o $eveloping a class diagram from use case

De&eloping a class diagram 1rom noun phrases: Bne approach for identifying classes is to use the syntactic elements of a problem statement or system specification. The reasoning behind this approach is that abstractions that represent classes are the kind of things that would appear as noun phrases in a written description or specification of the system. This approach is driven directly by a problem specification. The noun phrases are isolated /underlined, for example1 to provide an initial set of classes, after which any spurious classes are eliminated. The resulting list of noun phrases provides a first approximation of the classes in the application.

"d&antages: The process is almost mechanical and, hence, is appealing in situations where you are not certain how to start. /+t is often appealing to object#oriented design novices for the same reason1 +t requires little, if any, problem domain knowledge. Drovided you have a written description of the system, you can Gleap right inF. There is a very clear stopping rule* 3ou5re finished identifying classes when you5ve looked at all noun phrases.

Disad&antages: +t is very tedious process, and the written description of a large system could be hundreds of page long. +t requires a written description of the problem to be solved. Many development organi ations are never provided such a description. The quality of the model highly depends upon the quality of the problem statement, and many problem descriptions are not very good.

 De&eloping a class diagram using abstraction: . second approach for building a class diagram is to abstract from your problem domain expertise. The basic idea is that you employ your knowledge of the domain to drive the generation of a model. This is an especially efficient method if you are a domain expert, as you are hacking a model directly from what you know. Bn the other hand, you must understand the domain extremely well to apply this approach successfully because you are not using any crutches to aid the process. (everal methods adopt this technique, including methods described in object#oriented analysis, object# oriented systems analysis and object#oriented development. &ach method provides a set of identification keys to help you identify the major abstraction.

"d&antages: +t is very efficient in terms of development time and efforts because you do not underline nouns or describe use cases. +t is therefore a good use of problem domain expertise.

Disad&antages: +t requires extensive knowledge of the problem domain. Bnly a domain expert can use this approach effectively. )urthermore, the quality of the model is highly dependent on both knowledge and skill of the domain expert. +t can be difficult to trace design and implementation constructs back to requirements. +f you employ use cases, you can trace classes to use cases and use cases to written requirements. +f you isolate noun phrases from a problem statement, you can trace classes back to noun phrases. %ith abstraction, however, there is nothing available to which to trace classes. +t can result in analysis paralysis* agoni ing over details that aren5t required in the model. How can you be certain that you5ve thought of everythingW %hen to stop is not obvious.

De&eloping a class diagram 1rom 2se Cases: The previous two approaches, using noun phrases and applying abstraction, may seem very different in that one is a very tedious, almost mechanical approach, whereas the other is a somewhat unstructured, unfettered approach. The two approaches are similar, however, in that both are Ginformation#orientedF. +n both cases, an information model was built with little regard for the required behaviors of the system.

. third approach to building a class diagram employs use cases to guide the generation of the diagram. That is, you first identify the system5s use cases and then you Gstep throughF each use case, adding enough to the class diagram to support the use case.

"d&antages: The resulting model contains only features that are justified by behaviors. %hen developing a class diagram for the factory system, for instance, you didn5t spend any time agoni ing about factory orders or the estimated up time for down machines because no use cases required those features. +n other words, you produced a minimal model. 6se cases are good vehicles for eliciting, explaining and validating requirements. $evelopers often have difficulty getting customers to identify and flesh out requirements. +n addition, experts in object#oriented design, or even individuals with considerable domain expertise, sometimes struggle to write a requirements document. +n these situations, working through use cases can be effective first step. Bne way of identifying object interactions is to begin with use cases and Gdrill downward.F %ith such an approach, you can reuse the use cases during dynamic modeling and design.

Disad&antages: (ome systems may involve tens or even hundreds of use cases. Therefore the task of identifying and describing those use cases can be daunting. %riting use cases requires a good knowledge of the problem domain. .s a result, this approach may not be suitable to designers who are not domain experts. $eveloping classes from use cases isn5t always straightforward. Bverlooking a use case can result in an incomplete class diagram.

Crite short notes on: .. 4. 5. 6. Arame%or' Class normaliEation 1or cohesion Stereot*pes in 2 $ !bject s*nchroniEation

.. Arame%or': . framework is a set of classes that work together to achieve a purpose that is speciali ed internally by the designer.

. framework defines a family of related applications in a general way. +t contains the elements that are common to those applications. Handling sales orders and service orders, for example, are very similar activities that act on very similar entities. .n order processing framework casts those similarities in the form of a collection of interacting classes. Bne dichotomy among frameworks is the distinction between a white#box and a black#box framework. . white#box framework consists of a set of classes that define abstractions. &ach class defines both the interface and the implementation of its abstraction. %hen we speciali e a white#box framework, we define subclasses that inherit that abstraction. Therefore, a primary mechanism at play is inheritance of implementation. +n contrast, black#box framework consists of a set of classes that operate on specific interfaces. &ach interface defines a role. (peciali ing the framework entails introducing classes that play those roles by implementing the interfaces.

4. Stereot*pes in 2 $: . stereotype defines a construct that is similar to some other construct, but has special semantics. .ny notational construct can be stereotyped. The name of the stereotype appears in guillements /or double angle brackets if guillements are unavailable1. G.ctors as classesF, for example, actors are normally modeled in a class diagram as stereotyped classes, where the name of the stereotype is MMactorNN. .ctor classes are like normal classes in that they have instances, can be associated with other classes, and can have a public interface. They differ from regular classes, however, in that you don5t implement them. .ny 6M4 construct can be stereotyped.

)igure contains a model fragment with a stereotyped class and stereotyped dependencies. The Brder Hot Dending &xception class is special, because its instances are exceptions. )urthermore, order instances throw exceptions, which are caught by Telephone .gent instances.

Order "!!1

TelephoneAg 22e3ce&tion4 22catches4 4 ent Order Not Pending Exception

Cancel(# Commit(# add5ineitem(# total6rice(# 22throws4

orderNumber time6laced

!bject s*nchroniEation: The synchroni ation semantics of a class is depicted as a property of that entity. The stock class in the figure includes a property indicating its instances are guarded. The class lists the lock and unlocks methods used to lock and unlock a (tock instance. . concurrent locking scheme is normally preferable to a guarded one for the following several reasons* o The client code isn5t cluttered with calls to the locking and unlocking methods. ,lients invoke the application#specific methods provided by the service object o %e don5t have to depend on clients to behave correctly. %ith a guarded (tock class, a client must lock a (tock instance before using it. o ,ircular waiting may be easier to prevent. o ,oncurrent policies can be changed without the client5s knowledge.

Chat is the bene1it o1 reuse? Chat the &arious 1orms o1 reuse in object(oriented de&elopment? Explain. "ns:( ?euse of design and code is often cited as a principle benefit of object#oriented development. .lthough design and code is not a panacea, if it is properly executed, it can shorten the development time and increase product quality. ?eusing the exiting code can obviously reduce the development time of the project. +f that code has already been thoroughly tested, it reuse can also shorten the testing time and avoiding error that might have been introduce if the code had been written from scratch. ?euse is not single concept7 it comes in different si e and shape. The scale of reusable item can be anything from a single class to large component consisting internally of hundreds of classes. There are different forms of reuse in object#oriented development as follows* ?euse of classes ?euse of components ?euse of frameworks ?euse of patterns

<euse o1 classes: The simplest and probably most common form of reuse is reuse of individual classes. These classes are packaged in the form of class library. ,lasses are typically grouped in terms of functional cohesion7 in other words, all the classes in one functional area are placed in one library. (uppose you are building financial applications, and you have a class library of financial classes. Bne such classes is the .ccount class defines the interface and implementation of a basic cash#baring account. .n account instance maintain a cash balance and its method to deposit the cash in itself and withdraw cash from itself and return an indication of its current balance. +f you are developing a banking system you may be able to use the account class, as it stands, in your application. )or stock#trading application, the account class has subset of the required featured .%hen defining a stock# trading account class, therefore you can employ the exiting account class, but you must augment it with the feature unique to stock trading accounts.

<euse o1 Components: %hereas a class is a relatively small reusable part, a component is a large#scale building block that, like a class, is reused as a single unit. . component is a non#trivial, nearly independent, and replaceable part of system that fulfills a clear function in the context of a well#defined architecture. .n object#oriented application is a composite of classes whose execution# time instance work together. +n an analogous way , an application can include a set of components whose execution time instance collaborate by invoking operation in one another. However a components scale is much larger than that of the class. )or example, a component may be composed of many classes internally.

<euse o1 1rame%or's: . component represent an attempt to achieve large scale reuse. )or the most part, however, a component is monolithic entity. ,ustomi ation is typically achieve by adding external behavior and by composing component together. . framework, on the other hand, is a set of classes that works together to achieve a purpose but that must be speciali ed internally by the designer. . framework defines a family of related applications in a general way. +t consist the element that are common to those applications. Handling the sales order and service order are very similar activities that act on very similar entities.

<euse o1 patterns: The reuse of the classes, component, and frameworks differ in scale and mechanism of reuse, but the three share one important property* +n all three cases, we are reusing code. The codification and application of patterns, on the hand, is an attempt to reuse knowledge. . pattern is a way of solving a problem. Dattern form a part of the lore an experienced designer accumulates those interesting ways of solving problems that recur over time. . pattern typically promotes a design principle while solving a problem. (ome patterns strengthen encapsulation. Bthers reduce various type of coupling, whereas other increase cohesion. )rom that standpoint, employing a pattern not only provides a solution that you might not have formulate on your own, but it also makes your design more flexible. "ecause a pattern embodies the reuse of knowledge rather than code, developing catalogs of patterns has become an important point of emphasis in the object#oriented design community.

- 4a0 Explain in details concepts in d*namic modeling gi&ing suitable examples.

The dynamic model shows the time#dependent behavior of the system and the objects in it. "egin dynamic analysis by looking for event, externally visible stimuli and responses. The dynamic model is important for interactive systems, but insignificant for purely static data repository, such as database.

)op(Do%n "pproach( This is a 6se case driven approach. (teps include* +dentification of use cases. (pecification and refinement of use cases. $efinition of a scenario for each Ginteresting pathF. $rawing an interaction diagram for each scenario. +dentification of object methods in the interaction diagrams. .lteration of class diagrams to ensure consistency with interaction diagrams. $evelopment of state machines to understand the behavior of objects across scenarios, i.e., during its lifetime.

Identi1*ing 2se Cases Top down approach employs use cases as its starting point. +dentify actors )ind out what interactions the actor initiates with the system and what interactions the system initiates with the actor.

;ottom(2p Design

?esponsibility#driven design 3ou begin by identifying the responsibilities of each type of object and then work upward. +t starts with specific object methods and then uses scenarios primarily as a validation /rather than a discovery1 mechanism. +dentify classes /noun phraseJabstraction1. Make list of the responsibilities of the objects of each class /what an object must know and do1. +dentify scenarios $raw interaction diagram for each scenario to ensure that all responsibilities have been identified /validated1. .ddJmodify responsibilities as needed. .pply this approach repeatedly until complete set of responsibilities are identified.

- 5a0 Compare and Contrast micro de&elopment and macro de&elopment. X )he ;ooch methodolog* prescribes ' ! macro development process ' ! micro development process* (he )acro De"elopment Process +t servers as a controlling framework for the micro process. The primary concern is Technical Management of the (ystem. The macro development process consists of the following steps* 0* Conceptuali+ation -* !nalysis and development o% the model* 1* Design or create the system architecture* ,* Evolution or implementation* 2* 3aintenance* Conceptuali*ation: X &stablish the core requirements of the system X &stablish a set of goals and develop prototype to prove the concept Analysis and de"elopment o' the modal X 6sing the class diagram to describe the roles and responsibilities objects are to carry out in performing the desired behavior of the system X 6sing the object diagram to describe the desired behavior of the system in terms of scenarios or, alternatively X 6sing the interaction diagram to describe behavior of the system in terms of scenarios

Design or create the system architecture X 6sing the class diagram to decide what mechanisms are used to regulate how objects collaborate X 6sing the module diagram to map out were each class and object should be declared X 6sing the process diagram to determine to which processor to allocate a process. .lso, determine the schedules for multiple processes on each relevant processor E"olution or implementation X (uccessively refine the system through many iterations X Droduce a stream of software implementations, each of which is refinement of the prior one )aintenance X Make locali ed changes to the system to add new requirements and eliminate bugs (he )icro De"elopment Process X The micro development process consists of the following steps* X 4denti%y classes and o 5ects* X 4denti%y class and o 5ect semantics* X 4denti%y class and o 5ect relationships* X 4denti%y class and o 5ect inter%aces and implementation*

Micro Drocesses .. The micro#processes of object# oriented development is largely driven by the stream of scenarios and architectural products. ". +t represents the daily activities of the individual developer or a small team of developer. ,. +t applies equally to the software engineering and software architecture. $. The traditional phases of analysis and design are intentionally blurred, and the process is under opportunistic control.

Macro Drocesses .. The macro process serves as the controlling framework for the micro process. ". +t represents the activities of the entire development team on the scale of weeks to months at a time. ,. Many elements of the macro process are simply sound software management practice, and so apply equally to object#oriented as well as non#object#oriented systems. $. The traditional phases of analysis and design are to a large extent retained, and the process is reasonably well defined.

- 5 b0Describe <is's in&ol&ed in !bject(!riented De&elopment. There could be Derformance ?isks and (tart#up ,ost ?isks. #er1ormance <is's: There is a performance cost for sending a message from one object to another. . call to another function has an overhead on the run#time to handle stack management activities. +nheritance hierarchies can also add to the performance cost of an object#oriented system. &very time an object of a derived class is created, the constructor of that class and all its base classes are called. Thus, if the inheritance structure is very deep or very wide, there can be a significant drop in the performance. Dolymorphism adds further to the performance cost of a system. $ynamic lookup that is required to determine the method defined for the class of the receiving object can take significantly longer time than a simple, statically bound function call. Bften object#oriented system is defined in a manner whose components are built in layers of abstraction. Bn the positive side, such layering helps in the comprehending a complex system. +t may be impossible ever to get a complex system working without starting with a layered design. Bn the negative side, sometimes methods must be written to gain protected access to the otherwise encapsulated fields of an object. This plethora of methods means that we can end up with a glut of method invocations. +nvoking a method at a high level of abstraction usually results in a cascade of methods invocations involving lower levels.

.nother source of performance bottlenecks is due to the paging behaviour of running applications. Most compilers allocate object code in segments, with the code for each compilation unit /usually a single file1 placed in one or more segments. +f an operating system funds physical memory bottlenecks and uses the virtual memory concept, then it may result in a higher number of page swapping activities, as most of the function calls in object#oriented applications are across source file boundaries. $ynamic allocation and destruction of objects also contributes to performance costs. .llocating an object on a heap is a dynamic action as opposed to statically allocating an object either globally or on a stack frame. )or time#critical applications, the cycles needed for completing a heap allocation may be too costly. . commonly used solution to this problem is to pre#allocate such objects during elaboration of the program. Start(up Cost <is's: 6sing the object#oriented technology for the first time requires capitali ation of the software development tools.+f an organi ation is using a particular object#oriented language for the first time, they usually have no established base of domain#specific software to re#use.. first attempt to use the object technology is usually a failure without the appropriate knowledge and training. .n object#oriented language is not just another programming language that can be mastered in a short time period. The mindset shift for object#oriented design may take a long time in most cases.

-6 a0 Explain responsibilit* dri&en design in ")

context.

"utomated )eller achine Example %hen its idle, a greeting message is displayed. The keys and deposit slot will remain inactive. %hen a card is inserted, the card reader attempts to read it. +f the card cannot be read, the user is informed, and its ejected. +f the card is read, the user is asked to enter a D+H. +f its entered correctly, the user is shown the activity menu. Btherwise the user is given two additional chances to enter the D+H. )ailure to do so on the third try causes the machine to keep the card. The activity menu contains a list of transactions that can be performed. These include* deposit, withdrawal, query the balance, transfer funds, and terminate activity. Scenario %hen the user approaches the .TM there is a welcome message and something to receive the user5s card. %hile the card is in, the system must read the account information, ask for the D+H, and determine if its correct The D= uses the account info to determine the D+H and then ask the user to enter the number to be verified. +f the D+H is correct then the user is given a choice of selections.

The user selects one item and control passes to the managers of the appropriate selection . separate system controls the drawer to accept deposit or dispense cash. Data anagers The next step in the process of refining the specification emphasi es the management of data values. This step should be taken only after an acceptable set of responsibilities has been established. The task of the first part of the design process using ,?, cards is to define what responsibilities are assigned to each class. +t is only after these are established that we can talk about how those responsibilities are to be achieved. +t is important to distinguish between long#lived data # that is, those values which must be maintained for a significant period of time or used by a large number of individuals # and short lived data values. &xamples* account number, D+H number, account balance %ithdrawManager .ccountManager %hat is the balanceW The balance is _C@@ G+f + subs _899 it still is positive. B^.F ?eset balance to _A@@ %ithdrawManager .ccountManager ,an + withdraw _899 GThe balance is _C@@, if + subs _899 its still pos. 3es. B^. Dlease record the withdrawal The following principle can be described as basic to responsible data management* .ny value that will be accessed or modified widely, or that will exist for a significant period of time, should be managed. That is, one and only one class should have responsibility for the actions taken to view or alter the values. .ll other classes that need to obtain the values must pass requests to the manager for such actions, rather than accessing the data themselves. Disco&ering Inheritance Bnce the initial design is agreed on, the recognition of commonality can facilitate further development. /%e can state that this by saying that inheritance is a useful implementation technique, but not a design technique1. Two relationships are of fundamental importance. The is(a and the has#a relationship. X The is#a relationship holds between two concepts when the first is a speciali ed instance of the second /inheritance1. X The has#a relationship holds when the second concept is a component of the first, but when the two are not in any sense the same thing, no matter how abstract the generality /containment1. Common Design Ala%s X ,lasses that make direct modification to other classes X ,lasses with too much responsibility X ,lasses with no responsibility X ,lasses with unused responsibility X Misleading names X 6nconnected responsibilities X +nappropriate use of inheritance X ?epeated functionality

-7 a. Compare and contrast( i0 .ns. ! ) methodolog* %ith ISD/Iac'son structure de&elopment0

 BMT is an object#oriented design method. +n BMT, one constructs several kinds of diagrams. The focus is on the construction of class association diagrams /in short Class Diagrams1, that show the static structure of the object classes and their relations. )or each phase one constructs an appropriate class diagram. The dynamical behaviour of a system is first described by means of event trace diagrams /message sequence charts1. . data flow diagram shows the flow of values from external inputs, via operators and internal data structures to external outputs. "ecause the functional model is difficult to relate to the other models, it is not used very much in practice. Q($ does begin with consideration of real world and in this sense is object#oriented. However, Qackson identifies few entities /object1 and shows little of their structure. Q($ approach is complex and difficult to fully comprehend. Bne reasons for Q($5s complexity is its heavy reliance on pseudo code7 graphic models are easier to understand. Q($ is also complex because it was specifically designed to handle difficult real time problems. )or these problems, $ismay produce a superior design and be worth the effort. However, Q($5s complexity is unnecessary and a bit overwhelming for the more common, simple problem. Qackson places more emphasis on actions and less on attributes than we do. (ome Q($ actions look similar to BMT associations. )or example, a clerk allocates product to an order. %e call allocates an association, Qackson call it an action. Qackson finds attributes confusing and prefer to avoid them. .ctions have such a prominent role in Q($ modelling that they pre#empt attributes, in much The same way that attributes diminish the importance of operations in BMT object models.

ii0

! ) methodolog* %ith S"SD/Structured anal*sis,structured design0

.ns * (.J($ and BMT modelling have much in common. "oth methodologies use similar modelling constructs and supports the three orthogonal views of the system.

 The difference between (.J($ and BMT is primarily in style and emphasis. +n the (.J($ approach, the functional model dominates, the dynamic model is most important, and object modeling least important. +n contrast, BMT modeling regards the object modeling as most important, then dynamic model and finally the functional model. (.J($ organi es a system around procedures. +n contrast, BMT organi es a system around real world objects, or conceptual objects that exist in the user5s view of the world. Most changes in requirements are changes in function rather than objects, so change can be disastrous to procedure based design. "y contrast, design in function are readily accommodated in an object# oriented design by adding or changing operations, leaving basic object structure unchanged. (.J($ is useful for problems where functions are more important and complex than data. (.J($ assumes that this often occurs.

-7 b0 Details issues in&ol&ed in 1oundation class librar*

. library that provides abstraction for all foundation classes required by all possible applications would be huge. The requirements of the foundation class libraries are complete, adaptable, efficient, safe, simple, and extensible. A!2ND")I!N C$"SS $I;<"<J <E-I<E EN)S This library has* complete The library must provide a family of classes, united by a shared interface but each employing a different representation, so that developers can select the ones with the time and space semantics most appropriate to their given application

.daptable .ll platform#specific aspects must be clearly identified and isolated, so that local substitutions may be made. +n particular, developers must have control over storage management policies, as well as the semantics of process synchroni ation

&fficient components must be easily assembled must impose minimal run#time and memory overhead and must be more reliable than hand#built mechanisms

(afe &ach abstraction must be type#safe so that static assumptions about the behavior of a class may be enforced by the compilation system. &xceptions should be used to identify conditions under which a class5s dynamic semantics are violated7 raising an exception must not corrupt the state of the object that threw the exception (imple The library must use a clear and consistent organi ation that makes it easy to identify and select appropriate concrete classed

&xtensible $evelopers must be able to add new classes independently while at the same time preserving the architectural integrity of the framework.

- 8.

Cith suitable example explain the concepts in !bject

odelling.

.ns. Bbject model is the conceptual framework for bject oriented programming style. The concepts in Bbjects Modelling are#* ;.N ."(T?.,T+BH# +t denotes the essential characterstic of an object that distinguishes it from all other kinds of objects and provides crisply defined conceptual boundaries,relative to all the perspective of the viewer. +t focuses on the outside view of an object and so serves to seperate an object!s essential behavior from its implementat. . good abstraction emphasi es on the details that are significant to the user and hides the details that are immaterial. e.g. &mployee is a class that contains attributes employye+d,name,gender,age,salary,designation. The method of class employee is calculate(alary/1. (tudent is a class that contains attributes rollHo,name,gender,age,year,batch,grade. The common attributes for student class and employee class are name,age,gender. These attributes can be abstracted in a new class Derson. This is the concept of abstraction. 8.N &H,.D(64.T+BH# +t is about separation of the interface and the implementation. . good clock object would hide the internal implementation of time measurement and would supply us with only %hat we want. This serves a major purpose +f you don5t know what the inside looks like,it makes no difference if someone changes it# Bne of the major benefits of using an interface is that it hides the implementation. .n object oriented interface doesn5t need the user to tell it what data to work on,so if some internal data representation changes it has no impact on the code. %hile the internal source representation may change,the interface remains the same and no one using the object is affected by the change. &ncapsulation is the process of compartmentali ing the elements of an abstraction its structure and behaviour7 encapsulation serves to separate the contractual interface of an abstraction and its implementation. &g#* +n case of a car,the user can access the steering wheel,brakes and accelerator. +n case of all cars,the function is same but the fashion in which it is implemented is different internally. The implementation is not visible to the user and hence user cannot harm the engine. .lso the user fremains unaffected until the interface remains unchanged..

<.NMB$64.?+T3#* +t commnsists of dividing a program into modules which can be compiled separately bt still have connections with other modules. Moddules have interface and implementation. Modularity is a property of the system that has been decomposed into a set of cohesive and loosely coupled modules. +mplementation of a module can change independently without affecting other modules,if the interface remains unchanged. Bbject coupling describes the degree of interrelations among the objects that make up a system. Bbject cohesion is a measure how logically related the components of external view of an aobject are to each other.

>.N H+&?.?,H3#* a.N ,lass (tructure#

+t is the ranking or ordering of abstraction. +t is of two types#

+t refers to +HH&?+T.H,& +t is the most important Gis a F hierarchy. +t defines the relationship among classes wherein one class shares the structure or behaviour defined in ; or more classes. +t represents the hierarchy of abstraction in which a subclass inherits from one or more superclass. +t has the following iN iiN iiiN (ingle +nheritance Multilevel +nheritance Multiple +nheritance

b.N Bbject (tructure# +t refers to .ggregation. .ggregation refers to the Gpart#offF or Gpart#wholeF relationship in which objects representing the components of something are associated with objects representing an entire reassemibly.

@.N T3D+HK +t is the enforcement of the class of an object,such that objects of different types may not be interchanged,or at the most they may be interchanged only in very restricted ways. (trong Typing language means type conformance is strictly enforced,operation cannot be called upon an object unless the exact signature of the operation if defined in the object5s class or superclass. (tatic and $ynamic "inding# (tatic binding means that the the types of all variables and expressions are fixed at the time of compilation. $ynamic "inding refers to late binding where all type of variables and expressions are not known until runtime.

A.N D&?(+(T.H,& .n object in a software takes up some amount of space and exists for a particular amount of time. Bbjects usually get destroyedonce a program finishes execution. )or objects to be stored permanentaly they must be declared GpersistentF or GpermanentF. Dersistence can be defined as Gproperty of an object through which its existence transcends time /i.e. the object continues to exist even after its creator ceases to exist1andJor space /i.e. object location moves from the address space in which it was created1F

!&er&ie% o1 #rominent !bject !riented I. )he <ambaugh ! )

ethodologies

The Bbject Modeling Technique /BMT1 presented by Qames ?ambaugh and his co#workers describe the method for the analysis, design and implementation of a system using an object oriented technique. BMT consists of > phases which can be performed iteratively. ;."nal*sis* The results are objects, dynamic and functional models. 8.S*stem Design* The results are a structure of the basic architecture of the system along high level strategy decisions, <. !bject Design* This phase produces a design document, consisting of detailed objects, static dynamic and functional models. >. +mplementation* This activity produces reusable, extendable and robust code BMT separates modeling into three different parts#* ;. .n object model, presented by the object model and the data dictionary. 8 .. dynamic model presented by the state diagram and the event flow diagrams. <. . functional model presented by the data flow and constraints. !bject odel The Bbject Model describes the structure of objects in a system their identity, their relationships to other objects,their attributes and their operations. This model provides the essential framework in which the dynamic and functional models can be placed. D*namic odel The $ynamic Model describes those aspects of a system concerned with time and sequencing of operations. &vents that mark changes,sequences of events ,states that define the content for events,and the organisation of events and states. Aunctional odel The )unctional Model describes those aspects of the system concerned with transformations of values#functions, mappings, constraints and the functional dependencies . The functional model captures what a system does without regard for how or when it is done.

\ : &xplain the following as applied to Bbject oriented methodology* a1 $iscriminator in Bbject Modelling b1 ,onstraints in )unctional Modelling c1 .ctivity in $ynamic Modelling d1 Bverriding in Bbject Modelling e1 (ignature in )unctional Modelling f1 .ggregation in $ynamic Modelling "ns%er( "0 Discriminator in object modeling There is another variation of generali ation that might be used in a domain where the gender of a Derson makes a difference to what they do, and where the gender is a fixed property of the Derson*The word gender in the diagram is called a discriminant. The diagram, by the way, is only suitable for certain domains.+n a domain were an object can start out as a Derson and the become a (tudent, or where an object can start out as a (tudent and later cease to be a (tudent we would want some kind of dynamic connection between Derson and (tudent.

C0 "cti&it* in d*namic modeling .ctivity diagrams are used to show how different workflows in the system are constructed, how they start and the possibly many decision paths that can be taken from start to finish. They may also illustrate where the parallel processing may occur in the execution of some activities.

D0 !&erriding in object modeling )or overriding, there must be inheritance. Bnce you inherit, you can then override data member of methods of the parent class. +t is normal in object#oriented programming to find that same operation in many different classes each time with a different behavior. Thus objects know which version of the functions are to be invoked. This technique avoids much of the complex coding needed in structured programming. .ttributes can also appear in both Darent and ,hild. The child!s attribute effectively make the Darent!s version unavailable... but both are still stored in the object

A0"ggregation in D*namic modeling +n 6M4 models, an aggregation relationship shows a classifier as a part of or subordinate to another classifier. .n aggregation is a special type of association in which objects are assembled or configured together to create a more complex object. .n aggregation describes a group of objects and how you interact with them. .ggregation protects the integrity of an assembly of objects by defining a single point of control, called the aggregate, in the object that represents the assembly. .ggregation also uses the control object to decide how the assembled objects respond to changes or instructions that might affect the collection. $ata flows from the whole classifier, or aggregate, to the part. . part classifier can belong to more than one aggregate classifier and it can exist independently of the aggregate. )or example, a $epartment class can have an aggregation relationship with a ,ompany class, which indicates that the department is part of the company. .ggregations are closely related to compositions. 3ou can name an association to describe the nature of the relationship between two classifiers7 however, names are unnecessary if you use association end names. "s the 1ollo%ing 1igure illustrates, an aggregation association appears as a solid line %ith an un1illed diamond at the association end, %hich is connected to the classi1ier that represents the aggregate. "ggregation relationships do not ha&e to be unidirectional. KL(((((

-4 b0. $ist and explain &arious 1lexible guidelines 1or ma'ing class diagrams. "NS: )ollowing are the flexible guidelines for making class diagram ,ohesion and ,oupling ,lass generali ation and speciali ation (peciali ation versus aggregation .ggregation

Cohesion and Coupling: . diverse entity lacks cohesion. &ntities should be as cohesive as possible. The cohesion must be increase. . design5s coupling, on the hand, is measure of the number and form of connection among its elements. The lower the coupling, is the more likely a change to the design will be more local to one small area.

Class generaliEation and specialiEation: . super class is a generali ation of its subclasses. . superclass defines a generali ation of two or more classes. 3ou generally introduce a superclass for either of two reasons* Two or more classes have common implementation. Two or more classes share a common interface. The common implementation or interface is placed in a superclass and is shared by the classes through inheritance.

The speciali ation of the subclasses is do for following reasons +t adds state information in the form of an attribute. +t adds state information in the form of association.

+t adds behavior in the form of method /or by implementing an abstract superclass method1 +t replaces behavior by overriding a superclass method.

.void the subclasses that do not speciali e anything. +n the typical case, a subclass should add a property or speciali e a method. .void creating subclasses that differ only in the value of a type attribute. Make the properties of superclasses meaningful in all subclasses. 3ou generally do not want subclass to inherit things they don5t need. .void the speciali ation a class along multiple dimension. ,omposing The subclasses require a diamond shaped inheritance graph. 6se speciali ation only when you have an is#a#kind#of relationship.

SpecialiEation &ersus aggregation: .void cases where an object must change its class dynamically that are where an object migrates from one class to another. This required replacing one instance with another. +n particular, avoid speciali ing a class based on the state of its instance or the roles those instance play.

,omposition through multiple inheritance when what you have is aggregation. 6sing multiple inheritance means that the composite inherits all interfaces of its places. 6se aggregation instead.

"ggregation: .ggregation is sometimes an alternative to inheritance when sharing implementation. 6se delegation through association where appropriate. %henever possible do not allow the outside world to see the part of an aggregate. This allows the parts to be change without affecting the outside world. %henever possible do not allow the parts of an aggregate to see one another. This allows one part to be replaced without affecting the others.

Explain parallel iteration %ith interaction diagram. +nteraction $iagrams* .n interaction diagram is a graphical representation of how objects interacts with one another in a scenario. +t depicts only the communication between objects. These diagrams show objects in the system and the messages that are passed between them. 6M4 provides two forms of +nteraction $iagram # o ,ollaboration $iagram ' it is spatially oriented with an emphasis on the links between objects. o (equence $iagram.# is organi ed temporally with the focus on the order in which messages are sent between the objects. (ending messages can be done in several ways ' o +t corresponds to invoking a method, where a message name is the name of the method. o +t may indicate sending a message, event or signal such as an inter process message. . message can carry data with it. %hereas sending a message entails invoking a method, the data items are the parameters being passed. (ometimes message can be called repeatedly resulting into iteration.

+teration with +nteraction diagram The format for message labels is*

(equence +teration RKuardU * name /parameters1 (equence* represents the order in which the message is called. The sequence is redundant on sequence diagrams, but required on collaboration diagrams +teration* an asterix /01 is shown to represent iteration if the message is called repeatedly Kuard* an optional boolean expression /the result is either true or false1 that determines if the message is called Hame* represents the operation being called Darameters* represent the parameters on the operation being called

&xample

the+rder 7e-istery
9:;:

;* lookupBrder/@>A>@1

a8ele&hone A-ent

anBrder
an +rder '5ine 0tem

8*cancel
'catalo0tem

8.b0 model the beha&iour o1 the ele&ator object using state. Ele&ator starts at rest on one o1 the 1loors. "t that 1loor, a person ma* enter b* opening the door. )o tra&el up or do%n button based control is a&ailable inside the ele&ator and on the 1loors too. $i1t is not a&ailable during maintenance period. I1 li1t ele&ator is stuc' in bet%een suitable alarms %ill rung.

State transition diagram 1or Ele&ator:

,heck for pass

0dle

5oad &assen-ers
9 pass.

.fter loading Dass.

Mo/inu&

7in- the Alarm

.fter loading Dass

Mo/indown

<nload &assen-ers

(tuck in between

%to&
for loading Dass

-9.a0 Describe M"rchitectural #atternsN and MDesign #atternsN.

#atterns:

. pattern, is a type of theme of recurring events of or objects, sometimes referred to as elements of a set. These elements repeat in a predictable manner. +t can be a template or model which can be used to generate things or parts of a thing, especially if the things that are created have enough in common for the underlying pattern to be inferred, in which case the things are said to exhi it the unique pattern &xperienced designer while solving a problem promotes the design principles like, (trengthen encapsulation, ?educe coupling, +ncreases cohesion &mploying a pattern not only provides a solution that you might not have formulated on your own, but it also makes your design more flexible. There are different types of patterns* .rchitectural Datterns, $esign Datterns, .nalysis Dattern

"rchitectural #atterns:

.rchitectural patterns are software patterns that offer well#established solutions to architectural problems in software engineering. +t gives description of the elements and relation type together with a set of constraints on how they may be used. .n architectural pattern expresses a fundamental structural organi ation schema for a software system, which consists of subsystems, their responsibilities and interrelations. +n comparison to design patterns, architectural patterns are larger in scale. &ven though an architectural pattern conveys an image of a system, it is not architecture as such, but it is a concept that captures essential elements of software architecture. ,ountless different architectures may implement the same pattern and thereby share the same characteristics. Bne of the most important aspects of architectural patterns is that they embody different quality attributes. )or example, some patterns represent solutions to performance problems and others can be used successfully in high#availability systems. +n the early design phase, a software architect makes a choice of which architectural pattern/s1 best provide the system!s desired qualities.

Design #atterns: +t is a general reusable solution to a small problem that is independent of any problem domain. ?epresents an attractive solution to a design problem that could occur in any kind of application. (ame design pattern can be applied in diverse areas. . design pattern is not a finished design that can be transformed directly into code. +t is a description or template for how to solve a problem that can be used in many different situations. Bbject#oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Hot all software patterns are design patterns. $esign patterns deal specifically with problems at the level of software design. .lgorithms are not thought of as design patterns, since they solve computational problems rather than design problems. $esign patterns can speed up the development process by providing tested, proven development paradigms. &ffective software design requires considering issues that may not become visible until later in the implementation. ?eusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

-7 "0 Explain three tire logical architecture.

/80

. system or application , whether object oriented or not, can be organi ed into logical units such as layers or subsystems. . common layer subsystem organi ation is the tree tired architecture.

K6+s, command interfaces, V "usiness logic $ata repositories and services Dresentation layer .pplication 4ayer Dersistence 4ayer

. layer can be modeled in 6M4 as a package, which is logical grouping of classes or use cases. .( such, it can appear in a class diagram or a use case diagram. . package is depicted as a folder labeled with the name of the package. +n its closed form, a package includes its name or the folder, but the content of the package are not visible. ,onsider application layer of the stock#trading system7

=nter >uy +rder

Match orders

=3&ire +rders

=nter sell order

+&en Account

Close account

Add Customer

7emo/e Customer

?uery +rder

The package represents both the decomposition of the system into layers, as well as a composition of classes or use cases to form those layers. Hence you can decompose the system into layers, or you can compose the layers by superimposing packages over the top of an existing use case or class diagram.

+n layered architecture, each layer is dependent on the layer immediately below it. +n the stock#trading application, the presentation layer communicates with the trading (ystem instance in the application layers. )urthermore , that trading system instance must communicate with the persistence layer to obtain orders, .ccounts, and so forth from the application5s database.

Dackage* . layer is modeled in 6M4 is a Dackage. Dackage is a logical grouping of classes or use cases. +t is depicted as a folder labeled with the name of package. +n its closed form, a package contains the name on the folder, but contents are not visible. +n its open form, a package exposes the classes or use cases it contains. The folder tab is labelled with the name package. Having different packages as part of the overall system can help in assigning different aspects of software development to different teams. $ependency between layersJpackages can be shown using the MMimportsNN stereotype. +t is possible to nest packages to any depth.

These packages represents both composition and decomposition of the system into layers. Decomposition## is most appropriate in cases where an obvious system organi ation is apparent from the beginning. Composition ' deferring the identification of packages until the design of some of the classes has been completed. Bne functional area makes a layer. ,lasses in a layer might be partitioned into separate subsystem.

(pecifying the visibility of classes in a Dackage* +t is not necessary that every class is available to the external world. %e can indicate the visibility of a class by including the excessive directives before the class name. . plus /Z1 sign next to the class name implies that the class can be accessed by other packages. . minus /#1 sign next to the class name implies that the class is hidden from other packages.

Criteria 1or partitioning: +f a package is representing logical grouping, the criteria that we apply for partitioning the classes are ' Dartitioning based on )unctional ,ohesion # &ach package represents a distinct functional area, so the classes involved in that activity are placed in the same package.

 . package forms unit of reuse ' +t contains several classes that can be reused together. This reduces relational coupling. .ccess ,ontrol ' %e can hide classes within the package. $efine packages based on $elivery 6nits ' . package of classes defines a single salable unit. Dhysical configuration of components ' .ll the classes in one partition will be allocated to the same physical hardware box.

-7 ;0 Explain object migration across hard%are nodes through an example. /80 .n object migrates from one processor to another during the course of scenario. That is, the object that exists on one processor is shipped to another.

.bove figure contains collaboration diagram for a scenario in which a service representative queries the status of an order, providing an order number, 9<>>A:. The trading system instance asks the order store object on the order database server o load the order from the database, providing the order number. The order store loads the order, the returns it to trading system, %hich then reconstitutes the order on the order server. The migration of the order from order database server to the order server is depicted using a MMbecomesNN dependency, as shown in figure. The order on the order database server becomes the order on order server. 3ou can also stereotype nodes in a deployment diagram in situations where the nodes have special semantics. . common example is the node that acts as device, meaning that the node interacts with your system but not part of the system.

- 7 C0 Chat is object s*nchroniEation? Explain.

/:0

Bne source of concurrency in the stock trading system is the presence of multiple &ntry clients simultaneously accessing the same order server or account server. This opens the possibility that two entry clients might attempt to simultaneously access the same order or account instance. (uppose, for example, that one service representative is transferring money into an account while another is removing money from that same account. %ithout any locking the two modifications could conflict7 for example, they might both use the initial balance of the account as their starting point, meaning that one of the transactions will be overwritten by the other. The levels of locking as follows7 ! class method is se6uential) %hen invoked on an instance, a sequential method neither checks nor grabs the lock of that instance. This may mean that the method can execute concurrently with any other method called on the instance ! class or method is concurrent) a concurrent method grabs a lock of that instance on which it was invoked. Then, it holds that lock throughout the duration of the execution of the method. Qust before control is returned to the caller, the lock is released. ! class is guarded) The class provides methods that the client must invoke on an instance of the class to lock and subsequently unlock that instance. %hen the class is guarded, the client must invoke lock to obtain the lock on an instance before calling any other methods on the instance. +f the instance is already locked by another client when the client invokes lock, the client thread or process must wait until the lock becomes available. The synchroni ation semantics of a class or method is depicted as a property of that entity. The stock class in figure includes a property indicating its instance as guarded. The class lists lock and unlock method used to lock and unlock stock. +n account class in the figure, the fundbuy and fundsell methods are concurrent. The balance method is sequential. +t need not be locked when executed. . concurrent locking scheme is normally preferable to a guarded one for the following several reasons* The client code isn5t cluttered with calls to the locking and unlocking methods. ,lients simply invoke the application specific methods provided by the service object. 3ou don5t have to depend on clients to behave correctly. %ith guarded stock class, a client must lock a stock instance before using it. %hat if a client forgets to do thisW %hat if client forgot to unlock an instance the client has lockedW ,ircular waiting may be easier to prevent. The situation can result when you have a cycle of locking dependencies. %ith guarded locking, a client can hold a lock for long period of time. To prevent deadlock, therefore, you must predict clients patterns of grabbing and holding locks. ,oncurrent policies can be changed without the client5s knowledge. (uppose you discover that an .ccount can safely handle a fund"uy and fund(ell request simultaneously. +n account class with concurrent modification is internal to class.

- 9 ;0 Explain the di11erence bet%een %hite(box and blac'(box 1rame%or'. /.>0 . white#box framework allows for application#specific implementation through inheritance /by offering set of abstractions whose interfaces are defined and implemented1. . black#box framework allows for customi ation through additional classes that implement the interfaces defined in the framework, i.e., you just plug in classes that conform to the interface or role. %ith white#box frameworks you must understand the classes in them in order to tailor them for an application and in black#box frameworks you must understand what interfaces have to be implemented. (hite ox Frame"or/ consists of a set of classes that define abstractions. you define subclasses inherit that abstraction. inheritance of application. you must understand the implementation details of the classes in the framework. subclasses add state and behaviour specific to application. some framework classes are abstract, many are concrete and some can be used as it is. Blac/ ox %rame"or/ consists of a set of classes that operate on specific interfaces. each interface defines a role* you introduce classes that play those roles by implementing the interfaces. interface inheritance and polymorphism as principle speciali ation mechanism. you are Gplugging inF classes to a set of interfaces* "lack#box frameworks are easier to use than white#box. 3ou must understand only interfaces.

-6 c0 Dra% a collaboration diagram 1or a use case Gconduct inter&ie%sH in t*pical compan*. /:0
1!1' 0nter/iewee(:9 # 7e-estration 0nter/iewee 0n,ormation database

1' 7e-ester inter/iewee

1! ' %chedule %cheduler

1! !1 A/ailable8ime(# 0nter/iewer

7oom(N1"1 #

' ?uestion(# 1! ! ' 7oom(# ?uestion >an@

A' 7esult(:9 #

7oom A/ailability

7esult