Unit 3

Sri Manakula Vinayagar Engineering College, Puducherry
Object Oriented Analysis & Design 1

Department of Computer Science and Engineering

Subject Name: OBJECT ORIENTED ANALYSIS AND DESIGN
Subject Code: CS E61

Prepared By:
J. Madhusudanan, Associate Professor/CSE
M.Malar Vizhi, AP/CSE
R.Gayathri, AP/CSE

Verified by: Approved by:

UNIT III
Identifying functionality: Introduction CRC cards and interaction diagrams Identifying operations
using the CRC card technique Interaction diagrams Specifying operations Using the CRC cards and
interaction diagrams in system development State Diagrams States and events Constructing a state
diagram Using state diagrams in system development

2 Marks

1. What is the difference between sequence diagrams, state diagrams?
In sequence diagrams you are looking at all the classes affected by one use case .In state
diagrams you are looking at one class across all use cases and how it is affected by the events in the
system.
State diagram shows the object undergoing a process. It gives a clear picture of the changes in
the object's state in this process. e.g: ATM withdraw, Card object state: Checking, Approving,
ejecting. Sequence diagrams is that sequence diagrams are good at showing sequential logic but not
that good at giving you a "big picture view"

2. What is a state diagram? (Apr 2012)
A state chart diagram (also called a state diagram) shows the sequence of states that an object goes
through during its life in response to outside stimuli and messages. A state chart diagram is a view of
a state machine that models the changing behavior of a state. State chart diagrams show the various
states that an object goes through, as well as the events that cause a transition from one state to
another.

3. What are the elements used in State chart diagram model?
The common model elements that state chart diagrams contain are:
States
Start and end states
Transitions
Entry, do, and exit actions

4. Define the term state?
A state represents a condition during the life of an object during which it satisfies some condition or
waits for some event. Start and end states represent the beginning or ending of a process. A state
transition is a relationship between two states that indicates when an object can move the focus of
control on to another state once certain conditions are met.

5. What is the action can be used in state diagram?
Actions in a State chart diagram
Each state on a state chart diagram can contain multiple internal actions.
An action is best described as a task that takes place within a state.
There are four possible actions within a state:
On entry
On exit
Do
On event

6. Draw the sequence diagram for ATM bank system?

7. Draw a collaboration diagram for ATM BANK system?

8. Define CRC Cards (Apr 2012)
CRC Cards CRC cards are 10" x 15" index cards. All the information for an object is written on a
card.

CRC starts with only one or two obvious cards. If the situation calls for a responsibility not already
covered by one of the objects: Add, or create a new object to address that responsibility.
Finding classes is not easy.
The more practice you have, the better you get at identifying classes.
There is no such thing as the right set of classes.
Finding classes is an incremental and iterative process.

9. What is Sequence Diagram? (Nov 2012) (Apr 2013)
1) Shows interactions consisting of a set of objects and the messages sent and received by those
objects
2) Addresses the dynamic behavior of a system with special emphasis on the chronological ordering
of messages.

10. Draw an example for sequence diagram?

11. Draw an example for state chart diagram?

12. Define sequence diagram?
A sequence diagram shows interactions between objects.
Components of sequence diagrams:
1) Object lifelines
a) Object
b) Timeline
2) Messages
a) Message, stimulus
b) Signal, exception
c) Operations, returns
d) Identification
3) Message syntax

13. Define timeline?
The timeline is a line that runs:
1. from the beginning of a scenario at the top of the diagram
2. to the end of the scenario at the bottom of the diagram.

14. Define object lifeline?
An object lifeline consists of:
1) An object
2) A timeline
If an object is created and destroyed during the message sequence, the lifeline represents its whole
lifecycle.

15. Define the Message?
Message is a description of some type of communication between objects.
A unit of communication between objects and the sender object may:
1) Invoke an operation,
2) Raise a signal or
3) cause the creation or destruction of the target object.

16. How the State charts composed?
1) States a) initial state b) final state
2) Events a) guard conditions b) actions c) event syntax
3) Complex states a) activities b) entry actions c) exit actions

17. How to represent the state?
Notation:

18. Define the term Initial State?
The initial state identifies the state in which an object is created or constructed.
The initial state is called a pseudo-state because it does not really have the features of an actual state,
but it helps clarify the purpose of another state of the diagram. Notation:

19. Define final state?
The final state is the state in which once reached, an object
Can never do a transition to another state.
The final state may also mean that the object has actually
Been destroyed and can no longer be accessed.
Notation:

20. Definition Event?
Event is an occurrence of a stimulus that can trigger a state transition.
An event may be:
1) The receipt of a signal, e.g. the reception of an exception
2) The receipt of a call, that is the invocation of an operation,
E.g. for changing the expiration date of a license
An event on a statechart diagram corresponds to a message on a sequence diagram.
Notation:

21. Guard Condition?
Typically, an event is received and responded unconditionally. When the receipt of an event is
conditional, the test needed is called the guard condition.

22. Define Event Actions
The response to an event has to explain how to change the attribute values that define the objects
state.
The behavior associated with an event is called action expression:
1. Part of a transition event specifying the change from one state to another.
2. An atomic model of execution, referred to as run-to completion semantics.


23. Example of Event Actions

24. Event Syntax?
Event-name ( [comma-separated-parameters-list] )
[[Guard-condition]] / [action-expression]
Where:
1) event-name - identifies the event
2) parameters-list - data values passed with the event for use by the receiving object in its response to
the event
3) guard-condition - determines whether the receiving object should respond to the event
4) action-expression - defines how the receiving object must respond to the event

25. Example: Event?
Approve License (License.Id) [req=ok]
/setExistLicense(true)
Where:
1) Approve License is the event name
2) License.Id is the event parameter
3) The guard condition specifies that required attribute must be OK for the receiving object to
respond to the event.
4) The action executed in the receiving object is a call to the method setExistLicense which sends true
as its parameter

26. Define Complex States?
The state icon can be expanded to model what the object can
Do while it is in a given state.
The notation splits the state icon into two compartments:
1. Name compartment and
2. Internal transitions compartment.
State name compartment
Internal transitions compartment
Internal transitions compartments contain information about actions, activities and internal transitions
specific to that state.

27. Define Entry Actions?
More than one event can trigger a transition of an object into the same state. When the same action
takes place in all events that goes into a state, the action may be written once as entry action.
Notation:
1) Use the keyword entry followed by a slash and the actions to be performed every time the state is
entered
2) Entry actions are part of internal transitions compartment

28. Define Exit Actions?
The same simplification can be used for actions associated with events that trigger a transition out of
a state.
They are called exit actions.
Notation:
1) Use the keyword exit followed by a slash and the actions performed every time the state is exited
2) Exit actions are part of the internal transitions compartment Only when the action takes places
every time the state is exited.

28. Entry/Exit Actions Example?

29. Convert Sequence to State chart?
1) Identify the events directed at the lifeline of the desired object
2) Identify candidate states by isolating the portions of the lifeline between the incoming events
3) Name the candidate states using adjectives that describe the condition of the object during the
period of time represented by the gap
4) Add the new state and events to the state chart diagram

30. How to Design Sequence Diagrams?
1) Present the interactions between objects needed to provide a specific behavior
2) Capture the sequence of events between participating objects
3) Take into account temporal ordering
4) Optionally shows which objects active at any time
Design considerations:
a) Type of message
b) Timing of messages
c) Recursive messages
d) Object creation and destruction

31. Define Synchronous Messages?
1) Assumes that a return is needed
2) Sender waits for the return before proceeding with any other activity
3) Represented as a full arrow head
4) Return messages are dashed arrows

32. Define Asynchronous Messages?
1) Does not wait for a return message
2) Exemplified by signals
3) Sender only responsible for getting the message to the receiver
4) Usually modeled using a solid line and a half arrowhead to distinguish it from the full arrowhead
of the synchronous message.

33. Define Self-Reference Message?
A self-reference message is a message where the sender and receiver is one and the same object.
1) In a self-reference message the object refers to itself when it makes the call
2) Message 2 is only the invocation of some procedure that should be executed

34. Define Timed Messages?
1) Messages may have user-defined time attributes, such as sentTime or receivedTime
2) user-defined time attributes must be associated with message numbers
3) Instantaneous messages are modeled with horizontal arrows
4) Messages requiring a significant amount of time, it is possible to slant the arrow from the tail down
to the head

35. Define Activation and Deactivation?
Sequence diagrams can show object activation and deactivation.
Activation means that an object is occupied performing a task.
Deactivation means that the object is idle, waiting for a message.

36. Define Activation and Focus of Control?
Activation is shown by widening the vertical object lifeline to a narrow rectangle, called an activation
bar or focus of control.
An object becomes active at the top of the rectangle and is deactivated when control reaches the
bottom of the rectangle.
37. Define Recursion?
An object might also need to call a message recursively, this means to call the same message from
within the message.
1) Suppose that cityLocations is defined in the class diagram as a set of one or more apartments or
houses
2) A letter could be sent to all apartments in a location as shown

38. Define Creation and Destruction?
Object Creation:
If the object is created during the sequence execution it should appear somewhere below the
top of the diagram.
Object Destruction:
If the object is deleted during the sequence execution, place an X at the point in the object
lifeline when the termination occurs.

39. What is composition? (Nov 2012)
A composition relationship, which was named composition relationship in UML represents
whole-part relationships and is a form of aggregation. A composition relationship specifies that the
lifetime of the part classifier is dependent on the lifetime of the whole classifier. Data flows in only
one direction.

40. What is meant by responsibilities? (Apr 2013)
CRC (CLASS, RESPONSIBILITY, and COLLABORATOR) cards are not a formal part of
UML, but are commonly used as a vehicle for doing design that is then documented using UML
diagrams. Responsibilities here represent the responsibilities of the class. This list is out on the left
hand side.

11 Marks

1. Explain in detail about CRC cards? (Nov 2012)
Classes, Collaborators, Responsibilities Classification (CRC)
Classes represents group of similar objects.
Responsibilities represent the attributes and methods (responsibilities of the class)
Collaborators represent other objects whose interaction is needed to fulfill the responsibilities of the
class/object.
CRC Cards They are 4 X 6 cards where all the information about the objects is written.

The above diagram represents the format of a CRC card. It contains the class name and
responsibilities on the L.H.S compartment. Class name on the upper left most corner and
responsibilities in bulleted format. Class Name identifies the class and Responsibilities represent the
methods and attributes. Collaborators represent the other objects involved to fulfill the responsibility
of the object.
Responsibilities and Collaborations
Responsibilities of a class can be broken into two separate types: knowing and doing.
Knowing responsibilities are those things that an instance of a class must be capable of knowing. An
instance of a class typica11y knows the va1ues of its attributes and its relationships. Doing
responsibilities are those things that an instance of a class must be capable of doing. In this case, an
instance of a class can execute its operations or it can request a second instance, which it knows
about, to execute one of its operations on behalf of the first instance. The structural model describes
the objects necessary to support the business processes modelled by the use cases. Most use cases
invo1ve a set of severa1 classes, not just one class.
These classes form collaborations. Collaborations allow the analyst to think in terms of
clients, servers, and contracts. An analyst can use the idea of class responsibilities and client-server-
contract collaborations to help identify the classes, along with the attributes, operations, and
relationships, involved with a use case. One of the easiest ways to use CRC cards in developing a
structural model is through anthropomorphism-pretending that the classes have human characteristics.
Members of the development team can either ask questions of themselves or be asked questions by
other members of the team.
Elements of a CRC Card
The set of CRC cards contains all the information necessary to build a logical structural model
of the problem under investigation. Each CRC card captures and describes the essential elements of a
class.

Role-Playing CRC Cards with Use Cases
CRC cards can be used in a role-playing exercise that has been shown to be useful in
discovering additional objects, attributes, relationships, and operations. In general, members of the
team perform roles associated with the actors and objects previously identified with the different use
cases.

2. Discuss about identifying operation using the CRC card technique? (Apr 2013)

The CRC technique to allocate responsibilities to classes and work out the interaction between
classes that is required to implement the use case scenarios. We then discuss how to turn these high-
level responsibilities into operations on classes and how to describe the functionality of the operations
using process specifications. We introduce interaction diagrams and discuss how they are used to
document the details of the interactions we identified using the CRC technique. Interaction diagrams
also give us a much more precise idea of the associations between classes that are necessary to allow
the requisite message passing between objects.

Identifying operations using the CRC card technique
Objects can be identified from nouns in a description of the problem domain. In the same way
it is possible to identify operations on classes by picking out verbs and verb phrases from the problem
description. Phrases that occur in the requirements for the Wheels system such as 'keep a record of
all customers' or 'work out automatically how much it will cost to hire a given bike', tell us that
operations will be needed to fulfill these functions. However, analyzing verb phrases in this way turns
out to be an inefficient method of uncovering operations and allocating them to classes- a more
effective and popular approach is to use CRC cards. CRC (class-responsibility-collaboration) cards
are not officially part of the UML, but are regarded as a valuable technique that works extremely well
with it. CRC was popularized by a development method called Responsibility Driven Design. The
method and the book that describes it are both quite old now, but the idea of thinking about a class in
terms of the responsibilities it has to fulfill and the technique of CRC cards are both well regarded
and widely used in object-oriented development today. We will look first at the concept of a
responsibility and how this leads to identifying operations, and we will then describe how the CRC
card technique works in practice.

Class responsibilities and operations
At this stage of constructing a class diagram, our aim is to look at the overall functionality of
the system, as identified in the use cases, and divide it up between the classes that we have identified
in the class diagram. Each class is regarded as having certain responsibilities to provide services to
the user of the system (such as maintaining a customer record) or to another class (such as supplying
data for a calculation). Each responsibility identifies something that a class is expected to do; it is an
obligation on the class to provide some kind of service.

CRC cards
The aim of the CRC card technique is to divide the overall functionality of the system into
responsibilities which are then allocated to the most appropriate classes. Once we know the
responsibilities of a class, we can see whether it can fulfill them on its own, or whether it will need to
collaborate with other classes to do this.
The actual CRC cards are usually index cards about lo cm x 15cm in size, and each card
represents one class in the system. The size of the card is important because it restricts the amount
that can be written on it. On the front of the card is a high-level description of the class and the back
of the card records the class name, responsibilities and collaborations (if any). An example of a CRC
card for the Customer class in the Wheels system is shown in Figure 1. We can see from the figure
that the Customer class has two responsibilities; it is able to carry out the first of these (Provide
customer information) on its own, but in order to carry out the second responsibility (Keep track of
hire transactions) it will have to collaborate with the Hire class.

Figure: CRC cards for the customer class in the wheel system this size of card is used rather
than a sheet of A 4 paper to encourage system developers to restrict the size of each class in terms of
the number of its responsibilities. Good object-oriented design depends on having small cohesive
classes, each of which has limited, but well-defined functionality. The CRC card also encourages
developers to specify responsibilities at a high level rather than write lots of low-level operations. The
general rule is that no class should have more than three or four responsibilities. One of the most
effective ways of using CRC cards is in group role-play. Each member takes the role of an object of
one of the classes in the system, and the group then enacts the events that take place during a typical
scenario. As each responsibility arising from the scenario is identified, it is allocated to the most
suitable object. If a responsibility cannot be fulfilled by the existing objects, a new object (and
therefore class) will have to be identified.
The aim is to minimize the number and complexity of the messages that need to be passed
between the objects, and ultimately to produce classes that have a clear purpose and are internally
coherent. This method of using CRC cards is popular with both developers and clients as it tends to
promote ideas and facilitate discussions. CRC cards do not involve any special notation and so are
easily accessible to clients and users of the system. Figure shows a typical scenario from the 'Issue
bike' use case. In this figure, where we identify a responsibility of the system, we have added the
object (in bold, e.g.: Bike) that will carry it out. This illustrates how the overall functionality of the
'Issue bike' use case will be divided up between the classes in the system.
Although it does not feature in this scenario, which models only the user view of the system,
we also know that we need a: Hire object to record details about the hire transaction (see requirement
R4 in Figure: record the details of a hire transaction including the start date, estimated duration,
customer and bike). Collectively, the objects that interact to execute a use case are known as
collaboration; the collaboration for the 'Issue bike' use case is shown in Figure. Software developers
find that the simplicity of CRC cards, their lack of detail, make them an ideal tool for exploring
alternative ways of dividing responsibilities between classes. It easy to scrap one design and start
again without agonizing about the amount of work that is being discarded. Another way of exploring
alternatives is to use sequence diagrams, which are discussed later in this chapter. In practice,
however, sequence diagrams show too much detail and are too slow to draw to be useful for this
purpose. They are much more useful for documenting the detail of design decisions once these have
been reached using CRCs.

3. Explain about UML Interaction diagram (Apr 2012)

Interaction diagram
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data
among the things in the system being modeled. It consists of Sequence diagram and Collaboration
diagram

Sequence diagram
A sequence diagram is a kind of interaction diagram that shows how processes operate with
one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram
shows object interactions arranged in time sequence. It depicts the objects and classes involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the
functionality of the scenario. Sequence diagrams are typically associated with use case realizations in
the Logical View of the system under development. Sequence diagrams are sometimes called event
diagrams, event scenarios
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the
order in which they occur. This allows the specification of simple runtime scenarios in a graphical
manner.

Diagram building blocks
If the lifeline is that of an object, it demonstrates a role. Messages, written with horizontal
arrows with the message name written above them, display interaction. Solid arrow heads represent
synchronous calls, open arrow heads represent asynchronous messages, and dashed lines represent
reply messages. If a caller sends a synchronous message, it must wait until the message is done, such
as invoking a subroutine. If a caller sends an asynchronous message, it can continue processing and
doesnt have to wait for a response. Asynchronous calls are present in multithreaded applications and
in message-oriented middleware. Activation boxes, or method-call boxes, are opaque rectangles
drawn on top of lifelines to represent that processes are being performed in response to the message
(ExecutionSpecifications in UML).

Objects calling methods on themselves use messages and add new activation boxes on top of
any others to indicate a further level of processing. When an object is destroyed (removed from
memory), an X is drawn on top of the lifeline, and the dashed line ceases to be drawn below it (this is
not the case in the first example though). It should be the result of a message, either from the object
itself, or another. A message sent from outside the diagram can be represented by a message
originating from a filled-in circle (found message in UML) or from a border of the sequence diagram

Collaboration diagram
The UML Collaboration diagram is used to model how objects involved in a scenario interact,
with each object instantiating a particular class in the system. Objects are connected by links, each
link representing an instance of an association between the respective classes involved. The link
shows messages sent between the objects, and the type of message passed (synchronous,
asynchronous, simple, balking, and timeout). Collaboration diagrams offer a better view of a scenario
than a Sequence diagram when the modeler is trying to understand all of the effects on a given object
and are therefore good for procedural design.

Objects
Objects are depicted on a Collaboration diagram as rectangles. The object name is provided
first, with the class name to the right; the two names are separated by a colon. You may specify the
multiple occurrence of an object by opening its definition dialog, selecting its Symbol tab, and
toggling on the Multiple choice. You may also select the Multiple Object tool from the toolbar.

Links
Messages passed between objects are specified within the Link drawn between objects.

4. Discuss about the constructing state diagram? (Apr 2013)

Constructing a state diagram: The example concerns a Human Resources system, where one
class, Job Application, is complex enough to justify drawing a state diagram. The diagram will
illustrate all the different possible behaviors of objects of the Job Application class. A Job
Application object is created when an application form is received and the details recorded. The
application will then be read by the manager and may be shortlisted or rejected. If rejected, the
application is filed for six months. At the end of this time it is discarded. If it is shortlisted, interview
details are sent out and the interview is usually confirmed by the applicant.

Once the interview has taken place, the applicant may not be successful; in this case a
rejection letter is sent and the application is filed for six months and then discarded. If the applicant is
offered the job, an offer letter is sent. If the offer is rejected by the applicant the application is filed
for six months, and then discarded; if accepted, the application terminates and other procedures take
over.

The applicant may withdraw at any time during the application process. In order to draw a
state diagram, we need to sort out the events that can occur and the different states that a Job
Application object can be in see Table. An object always begins life in the start state, before anything
happens to it. We can see from the list that this diagram will be more complex than the previous
BankAccount example, as it not only has more states, but there are three different ways in which a
stop state may be reached.

Multiple stop states are common in state diagrams, as the way an object ends its life will
depend on the specific series of events that it undergoes. In contrast, there is only ever one start state
on a state diagram, as all objects of a class are created in the same way.

A number of the A number of the events that appear separately in the list are actually the same
event, but with different conditions, for example the 'read by manager' event has the conditions
'rejected' and 'shortlisted'. These conditions will be represented in the state diagram in square brackets
in the guard section of the relevant transition labels.

We should also check at this stage to see if there are any actions that the system has to
perform in response to an event. These will be included in the labels on the relevant transitions. In the
Job Application example there are two actions, 'send rejection letter' and 'send offer letter'. We start to
construct the state diagram by beginning with the start state, the event that creates a Job Application
object, and the state that the object moves into. Figure shows the first stage of the diagram. We can
build up the diagram by deciding what events can happen to a Job Application object while it is in the
Application logged' state and adding them. Figure shows the next stage in the process.

Table: Events and states for objects of the Job Application class

Figure: First stage of the state diagram for the Job Application class

Figure: State diagram for the Job Application class
We work through the events and states in the list and add them to the diagram, until every
item the list has been included, then we go back to make sure that we have not forgotten any of the
guards or actions that should be included in transitions. It is worth noting here that actions can also be
contained in states (indicated by the keyword 'do/...' in the state label). This type of action is usually
referred to as an activity; it is ongoing (not instantaneous) and can be interrupted by an event. For
example, there might be an activity 'send for references' associated with the 'Shortlisted' state. The
state diagram at this stage is shown in Figure. There is still one event that we have not included in the
diagram.
The description of the behavior of the Job Application class states that an applicant may
withdraw at any time. In order to include this in the diagram in Figure6, we would need to add a third
stop state and draw transitions to it with the event 'applicant withdraws' from each of the four states
on the diagram. This would make the existing diagram cluttered and very difficult to read. In order to
avoid clutter, we can draw a super state round the main body of the diagram, and show a single
'applicant withdraws' transition from it, indicating that an applicant can withdraw at any time during
the application process.
Finally, we need to check the completed diagram against the original description of the
behavior of the Job Application class, in order to confirm that it is an accurate representation. The
completed diagram with the superstate.

Completed state diagram with super state for the Job Application class

5. Explain about State Diagram. (Nov 2012)

A state diagram, also called a state machine diagram or state chart diagram, is an illustration
of the states an object can attain as well as the transitions between those states in the Unified
Modeling Language (UML). In this context, a state defines a stage in the evolution or behavior of an
object, which is a specific entity in a program or the unit of code representing that entity. State
diagrams are useful in all forms of object-oriented programming (OOP).A state diagram resembles a
flowchart in which the initial state is represented by a large black dot and subsequent states are
portrayed as boxes with rounded corners.
There may be one or two horizontal lines through a box, dividing it into stacked sections. In
that case, the upper section contains the name of the state, the middle section (if any) contains the
state variables and the lower section contains the actions performed in that state. If there are no
horizontal lines through a box, only the name of the state is written inside it. External straight lines,
each with an arrow at one end, connect various pairs of boxes. These lines define the transitions
between states. The final state is portrayed as a large black dot with a circle around it. Historical
states are denoted as circles with the letter H inside.
State diagrams require that the system described is composed of a finite number of states.
State diagrams are used to give an abstract description of the behavior of a system. This behavior is
analyzed and represented in series of events that could occur in one or more possible states. Hereby
"each diagram usually represents objects of a single class and tracks the different states of its objects
through the system.


6. How CRC cards and interaction diagrams are used in system development?

CRC cards are used to partition system behavior between the classes. CRC modeling, by
walking through the scenarios, has made us revisit all of our decisions so f a r - this is part of the
iterative nature of object-oriented design. During CRC modeling we may well discover classes and
attributes we didn't find doing a noun analysis because we are looking at the classes from a different
point of view. Each class of objects is responsible for some part of the system behavior. However, for
the system to produce a large chunk of required behavior, for example that specified in a use case,
objects must collaborate.
The CRC technique is used to discover how classes collaborate to achieve the behavior of the
use cases. Interaction diagrams are used to document in detail the decision arrived at in CRC analysis.
CRC cards talk about responsibilities and collaborations. Interaction diagrams talk about messaging
between objects. For a message from one object to another to work, the target object must understand
the message. It can only do this if we have already defined that operation on its class. Interaction
diagrams, therefore, act as a check that we have got the operations right. Interaction diagrams can be
shown at different levels of detail depending on when they are used during development. At their
most detailed they can serve as comprehensive specifications of the use cases.

7. Write notes on states and events of a state diagram.

A state diagram models the different states that objects of a class can be in, and the events that
cause an object to move from one state to another. In order to be able to draw these diagrams, we
therefore need to understand what is meant by state and event in this context. Each object of a class
such as BankAccount will have the same attributes (although with different values) and the same
operations.
This means that each object of the class is potentially capable of the same range of behaviors.
However, the actual behavior of an object during the life of the system depends not only on its
operations, but also on the events which determine the state that it is in.

Simple state diagram for BankAccount class

The state of the object here refers to the situation it is in while satisfying some condition (such
as a bank account having some money) or waiting for an event (such as someone trying to withdraw
or deposit money). An event is something that happens which has significance for the system and
affects an object of at least one of the system classes. We can tell if an object is in a particular state by
looking at the values of some of its attributes and its links to other objects. For example, if a
BankAccount object is in credit the value of the balance attribute will be a positive amount or zero,
but if it is overdrawn the value of balance will be negative.

State diagram symbols

8. How State diagram can be used in system development?

State diagrams model the system from the point of view of a single class and the events that
can affect the objects of the class. They show all possible behaviors of objects of a class, and record
the ordering of events, for example in the Wheels system a bike must be assigned a number before it
can be hired. This information about timing constraints is vital. Although state diagrams are a very
useful and important modeling technique, it is not necessary to draw one for every class.
In most systems, complexity arises from interaction between objects of different classes, as
modeled in sequence and Collaboration diagrams. For example, all Customer objects in the Wheels
case study system respond to events that happen to them in the same way, although with different
values: recording details, finding an associated Hire object, displaying customer details and amending
customer details. Their response to events does not depend on what state they are in. For this sort of
class which has relatively simple behavior there is not a lot to show on a state diagram. However,
other types of computer system for example process control or communication systems; frequently
have a number of classes whose dynamic behavior is extremely complex.
For this sort of class it is important to document all the possible behaviors of the objects of the
class by means of a state diagram. As with all models that are produced as part of the development
process, it is important to check that state diagrams are consistent with other diagrams. A state
diagram of a particular class should be checked against interaction diagrams which involve objects of
the class to ensure that all the events in the state diagram appear in the interaction diagram as an
incoming message to the object. It should also be checked against the class diagram to make certain
that every event and action corresponds to an operation on the relevant class.

9. Explain how the CRC cards are used for ATM. (Apr 2012)

A CRC card is an index card that is used to represent the responsibilities of classes and the
interaction between the classes.
CRC cards are an informal approach to object oriented modeling.
The cards are created from use-case scenarios, based on the system requirements

Use cases
1. User checks balance
2. User logs into the machine
3. User get "Fast Cash"
4. User makes a deposit
5. User withdraws from checking
6. User withdraws from savings


Pondicherry University Questions

2 Marks

1. What is a state diagram? (Apr 2012) (Ref.Pg.No.1 Qn.No.2)
2. Define CRC Cards (Apr 2012) (Ref.Pg.No.3 Qn.No.8)
3. What is Sequence Diagram? (Nov 2012) (Apr 2013) (Ref.Pg.No.3 Qn.No.9)
4. What is meant by responsibilities? (Apr 2013) (Ref.Pg.No.11 Qn.No.40)

11 Marks

1. Explain how the CRC cards are used for ATM. (Apr 2012) (Ref.Pg.No.21 Qn.No.9)
2. Explain in detail about Interaction diagrams (Apr 2012) (Ref.Pg.No.14 Qn.No.3)
3. Explain about CRC with an example in detail. (Nov 2012) (Ref.Pg.No.11 Qn.No.1)
4. Explain about state diagram with example. (Nov 2012) (Ref.Pg.No.18 Qn.No.5)
5. Discuss about identifying operations using the CRC card technique (Apr 2013) (Ref.Pg.No.12
Qn.No.2)
6. Discuss about the constructing state diagram. (Apr 2013) (Ref.Pg.No.15 Qn.No.4)

Unit 3

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Unit 3

Hochgeladen von

Copyright:

Verfügbare Formate

Sri Manakula Vinayagar Engineering College, Puducherry

Object Oriented Analysis & Design 1

Das könnte Ihnen auch gefallen