The document discusses object-oriented system development and modeling. It covers topics like: 1. The main stages of traditional system development life cycles like requirements, analysis, design, implementation, and installation. As well as common life cycle models like waterfall, V-model, spiral, and prototyping. 2. Phases of object-oriented development focus on the state of the system rather than activities, including inception, elaboration, construction, and transition. 3. Modeling techniques for object-oriented systems including the Unified Modeling Language (UML), Rational Unified Process (RUP), abstraction, decomposition, and class-responsibility-collaboration (CRC) cards. 4

1. UNIT I
1. What is a system life cycle?
Ans: In software system development, a framework has traditionally
been known as a system life cycle model.
2. What are the main stages of a traditional system life cycle?
Ans:
 Requirements
 Analysis
 Design
 Implementation
 Installation
3. List four life cycle models that are based on the traditional approach to
developing software systems
Ans:
 Waterfall
 V-model
 Spiral
 Prototyping.
4. What are the main phases of object-oriented system development?
Ans: The phases in object-oriented development are known as inception,
elaboration, construction and transition, indicating the state of the
system, rather than what happens at that point in development.
5. In object-oriented development, what is the relationship between phases and
workflows?
Ans: The object-oriented approach to development views the relationships
between
workflows and phases of development rather like the spider’s web,
where any phase may involve all workflows, and a workflow may be
carried out during any phase.
6. What are (a)RUP and (b) UML?
a) RUP incorporates not only modelling techniques from the UML,but
also guidelines, templates and tools to ensure effective and successful
development of software systems. The tools offered by RUP allow a
large part of the development process to be automated, including
modelling, programming, testing, managing the project and managing
change.

2. b) The Unified Mode]ling Language, or UML, is a set of diagrammatic
techniques, which are specifically tailored for object-oriented
development, and which have become an industry standard for
modelling object-oriented systems.
7. What do we mean by (a) abstraction and (b) decomposition in the context of
modelling software systems?
a) The characteristic of a model to provide some but not all the
information about the person or thing being modelled is known as
abstraction. Abstraction provides a means of concentrating on only those
aspects of the system that are
currently of interest, and putting other details to the side for the time
being
b) equally important tool for modelling software systems is decomposition.
This is the breaking down of a large, complex problem or system into
successively smaller parts, until each part is a 'brain-size' chunk and can
be worked on as an independent unit.
8. What is a CASE tool?
One of the advantages of a standardized language for producing diagrams
during system development is that a number of CASE tools have been
developed to provide automated support for developers.
9. What are the main stages of requirements engineering?
Ans: Requirements engineering is traditionally divided into three
main stages:
 Elicitation, when information is gathered relating to the existing
system, current problems and requirements for the future
 Specification, when the information that has been collected is
ordered and documented
 Validation, when the recorded requirements are checked to
ensure that they are consistent with what the clients and users
actually want and need.
10. When are questionnaires useful?
Ans: In order to build up a comprehensive list of requirements for the
new system, it is important for the developer to find out as much as
possible about what the bike shop customers think about the current
bike hire procedures.
11. What is a scenario?
Ans: A scenario is a sequence of interactions between a user and the
system carried out in order to satisfy a specified goal

3. 12. What features of a requirement should be recorded in the problems and
requirements list?
One of these is the problems and requirements list, and the other is the problem
definition
13. What is the purpose of a Fagan inspection?
Ans: This is a systematic and structured method of checking the
documented output from any stage of the system development
process in order to identify omissions and errors
14. What aspect of a system does the use case model?
Each of the UML models concentrates on modelling its ownparticular aspects of
the system while ignoring others: theyprovide complementary views of the
system. The use case modelgives the user coherent and detailed documentation of
what thesystem does or will do.
 Checking the system using the use case model
 Estimating using use cases.
 Basis for interaction diagrams
 Starting point for the identification of classes
15. Suggest two ways of identifying use cases.
 Identifying use cases from the actors.
 Identifying use cases from scenarios.
16. What is the relationship between scenarios and use cases?
Each use case represents a group of scenarios. Scenarios belonging to the same
use case have a common goal - each scenario in the group describes a different
sequence of events involved in achieving (or failing to achieve) the use case goal.
17. Describe the typical contents of a high-level use case description
and an expanded use case description.
High-level description. It is useful to have two distinct types of use case
description. In the early stages of software development, when no detailed
decisions have been made about the design of the system and particularly the
design of the user interface, it is enough to have short unstructured descriptions,
known as highlevel descriptions.These descriptions need only document the
purpose of the use case, the actors involved and give
a general overview of what happens. Subsequently it is useful to have more
detailed structured descriptions known as expanded use case descriptions

4. Expanded use case description. This description is more detailed and structured
than the high-level use case description. It should document:
 What happens to initiate the use case
 Which actors are involved
 What data has to be input
 The u.se case output
 What stored data is needed by the use case
 What happens to signal the completion of the use case
 Minor variations in the sequences of events
18. What is the relationship between an actor and a use case?
Generalization. Both use cases and actors can be specialized, i.e. we can use an
inheritance relationship between actors and between use cases. In object-oriented
development inheritance is primarily associated with class diagrams If
aninheritance relationship exists between two entities it means thatone inherits the
characteristics of the other.
19. You can use four types of relationship on a use case diagram; list
them and give a brief description of each one.
Communication association. In a use case diagram the line linkingan actor to a
use case is called a communication association (see Communication associations
tell us which actors areassociated with which use cases. Each actor may be
associated withmany use cases and each use case may be associated with many
actors.
Include. Two other types of relationship may be used on a use
casediagram- <<include>> and <<extend>>. Both <dnclude>> and
<<extend>>are relationships between use cases. An <dnclude>>
relationship isuseful when you find you have a chunk of behaviour that
iscommon to several use cases. Rather than repeat a description ofthat
behaviour in several use case descriptions, the commonbehaviour can be
split off into a separate use case which is then
linked to all relevant use cases with an <dnclude>> relationship.
Extend. The <<extend>> relationship is used as a way of
specifyingsignificant alternative behaviour in a use case. It
usuallydocuments functionality that the user can opt to use over andabove
the norm. The practice of using an <<extend>> relationship inthis way is
only for documenting important variations from thenormal course of
events.
We would use an <<extend>>relationship if we want to describe:
• Extra functionality that is available if required, for example
printing a list rather than just viewing it on the screen.
• Behaviour done only under certain conditions, for example
printing an extra receipt if the whole deposit is not returned.

5. Documenting <<include>> and <<extend>> in the use case description. If
we have added <<include>> or <<extend>> relationships to a use case
diagram, we must document them in the use case description. This
is done using the keyword 'initiate'.
UNIT II
1. Developing systems using a structured approach can result in problematic
software. List three problems associated with the structured approach.
• Functional decomposition
• Maintenance
• Poor modularity
• Testing
• Software reuse
• Data versus function
2. List four qualities that are desirable in a software construct.
 Problem domain.
 Functionality.
 Cohesion.
 Substitutability
3. What is meant by the term seamless development?
The seamless development also provides traceability of user requirements from
initial identification through to the code. In the traditional structured approach to
development some of the models that were used to capture user requirements
(such as the data flow diagram) were abandoned at the design stage where a new
modelling technique was used to specify the structure of the code
4. What is meant by the term encapsulation?
Data can be hidden inside an object in such a way that it is protected and cannot
be directly accessed by other parts of the program. The big advantage of this is
that it cannot be accidentally corrupted.
5. What is instantiation?
Objects are sometimes called instances of classes; the process of creating a new
object belonging to a class is called instantiation.
6. What is dynamic binding?
The program works its way through the array, it only knows which methods will
be executed when it gets to the next object and works out which class it belongs
to. This is known as late or dynamic binding..

6. UNIT III
1. What aspect of a class is captured on a CRC card?
The CRC technique to allocate responsibilities to classes and work out the
interaction
between classes that is required to implement the use case scenarios.
2. How does a class deal with a responsibility that it cannot fulfil on its own?
3. What are the two types of interaction diagram?
sequence and collaboration.
4. What do interaction diagrams model?
Interaction diagrams model the messaging between a collaboration of objects that
will take place in the execution of a specific scenario
5. What does the thin rectangle on an object lifeline indicate?
Object activation is shown by a thin rectangle on the object lifeline. An object
becomes active as soon as it receives a message. This means that the object is
computing; processing is taking place in the object as the invoked operation
executes. The activation continues until the operation finishes processing when
control returns to the object that sent the message. If an active object, in turn,
sends a message, it remains active while it waits for a response. While it waits for
a response it cannot, itself, do any computing. Showing activation is an optional
feature of sequence diagrams
6. What features of an operation are defined in specification by contract?
• The signature of the operation (its name, any arguments, and the type of
values it returns)
• The purpose of the operation
• What the client object must provide in order to obtain the required service
• A description of the internal logic of the operation
• Any other operations that are called by this operation
• Any attributes of objects whose values are changed by the
• operation.
7. What is meant by 'state' in this context?
The model that illustrates all possible behaviours of a class of objects is called a
state diagram
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
8. What is meant by 'event' in this context?
the events that cause an object to move from one state to another.

7. An event is something that happens which has significance for the system and
affects an object of at least one of the System’s classes.
9. What is a self-transition on a state?
No change of state. E.g.: While in the 'In credit' state the 'deposit money' event
leaves a
Bank Account object in the same state.