UNIT
1
|
Introduction: The system life cycle - Traditional life cycle models - The
object-oriented approach- the Rational Unified Process (RUP) - The Unified
Modeling Language (UML) - UML models -Introduction to the case study -
Requirements for the Wheels case study system – Requirements engineering -
Requirements elicitation - List of requirements for the Wheels system - Use
cases -Use case diagram - Use case descriptions- Actors and actor
descriptions - Use case relationships: communication association, include and
extend - Boundary - Using the use case model in system development.
|
11
MARKS
1.
Explain the system life cycle?
When
undertaking any large project, it is important to have some kind of framework
in order to help identify milestones, structure activities and monitor
deliverables. The development of a software system is no different from any
other kind of project in needing some kind of framework within which the
developers can work together.
An
agreed framework for development brings many advantages, and the larger and
more complex the project, the more evident these advantages become. First, a
framework provides an overall picture of the development process; this picture
is not cluttered by detail of what goes on at any stage in the process, but is
useful as a high-level view of the major areas of activity, milestones and
project deliverables. A framework provides a basis for development and ensures
a certain level of consistency in how the work is approached.
Consistency of approach is important
when a large number of developers are involved, and is helpful for new staff
joining the project after it has started. A framework plays a significant role
in ensuring quality, both of the development process and of the final system,
by providing a structure for project management- planning, monitoring and
controlling the development project.
In
software system development, a framework has traditionally been known as a
system life cycle model. Although life cycle models have been around for a long
time, there is still no general agreement about the precise stages in the
development process, the activities that take place at any particular stage, or
what isproduced at the end of it. This is hardly surprising, since factors such
as the type of system being built, the software being used; the time scales and
the development environment will all influence decisions about the detailed
stages of a project.
Historically
these stages have been referred to as requirements, analysis, design, implementation
and installation. Each stage is concerned with particular issues and produces a
set of outputs or deliverables.
2.
Explain the Traditional life cycle?
Over
the years there have been a number of life cycle models based on the
development stages outlined in Table 1.2.
Waterfall:
This
early life cycle model represents the stages of development as a
straightforward sequence, where one stage must be completed before the next
begins. It was the first model to identify the different stages that make up
the system development process, and its simplicity has made it a useful model
for many years. However, the waterfall model is not really a true reflection of
what actually happens in system development, since it does not emphasize the
need to iterate over the stages.
V-model:
This
is a variation of the waterfall, where the stages are visualized in the form of
the letter 'V'. It emphasizes how later stages of development are related to
earlier stages; for example, how testing should be derived from the activities
that are carried out during requirements and analysis.
Spiral:
This model is also derived from the waterfall. It incorporates iteration of
life cycle stages and focuses on identifying and addressing the risks involved
in development.
Prototyping:
In
the prototyping life cycle, implementation takes place early in the development
process. The working model produced is subsequently refined and enhanced during
a series of iterations until it is acceptable to the client.
Iterative development:
This approach is closely related to the spiral model and to prototyping. A
skeleton version covering the complete functionality of the system is produced
and then refined as development progresses.
Incremental
development: In this life cycle model the system is
partitioned according to areas of functionality. Each major functional area is
developed and delivered independently to the client. For example, in the bike
hire system, tasks relating to issuing a bike might be developed and delivered,
followed by returning a bike and then maintaining customer records.
3.
Explain the object-oriented approach?
One of the differences that is
immediately obvious between traditional life cycle models and the
object-oriented approach is the way that the various stages are named. In
traditional models the names, such as 'analysis' or 'implementation', reflect
the activities that are intended to be carried out in that stage. In object
orientation, however, a clear distinction is made between the activities and
the stages (generally referred to as phases) of development. 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 the
development.
Inception covers
the initial work required to set up and agree terms for the project. It
includes establishing the business case for the project, incorporating basic
risk assessment and the scope of the system that is to be developed.
Elaboration
deals with putting the basic architecture of the system in place and agreeing a
plan for construction. During this phase a design is produced that shows that
the system can be developed within the agreed constraints of time and cost.
Construction
involves
a series of iterations covering the bulk of the work on building the system; it
ends with the beta release of the system, which means that it still has to
undergo rigorous testing.
Transition
covers
the processes involved in transferring the system to the clients and users.
This includes sorting out errors and problems that have arisen during the
development process.
In object-orientation,
activities such as analysis or design are referred to as workflows.
.
Fig 1.1 Workflows that take place during development of a
system
It is
recognized that a workflow may be carried out at more than one development
phase and that developers may well engage in then whole range of workflows
during every phase of building a system. For example, in inception,
requirements engineering and analysis will obviously take place, but there may
well also be some design activity and even some implementation if all or part
of the system is to be prototyped. During the construction phase the main activities
will be implementation and testing, but if bugs are found there will have to be
some requirements and analysis as well.
.
Fig 1.2: An object-oriented view of
development phases and work flows.
The object-oriented approach also
recognizes fully the reality of iterative development. Activities at any phase
do not take place in a neatly ordered fashion. A developer may have to revisit
a range of workflows several times during one phase of development, before it
is possible to move on to the next phase.
Fig 1.3 Phases of object-oriented development
with iterations of workflows
The process is supported by the fact that
object-oriented development is driven by a single unifying idea- that of the
object. Because the object is the foundation of all development work,
object-orientation does not introduce new models to describe the system at
different phases, but develops and refines early models from the inception phase
right through the development process.
4.
Explain the Rational Unified Process (RUP)?
A life cycle does not
provide a high-level representation of the stages that a development project
must go through to produce a successful system, but it does not attempt to
dictate how this should be achieved, nor does it describe the activities that
should be carried out at each stage.
Object-oriented projects use the
Unified Modeling Language as the principal tool in their development process.
UML has been approved by the Object Management Group (OMG).
However, UML
is simply a notation or language for development; it is not in itself a development
method and does not include detailed instructions on how it should be used in a
project.
RUP is based on the following
Ø Develop
software iteratively
Ø Manage
requirements
Ø Use
component-based architectures
Ø Visually
model software
Ø Verify
software quality
Ø Control
changes to software.
Develop
software iteratively
Each iteration is
defined as a complete development loop resulting in the release of an
executable product that is a subset of the final system. In this way RUP
supports incremental development- the frequent release of small packages of
software that gradually build up to become the final system. Iteration and
incremental development encourage involvement and feedback from clients and
users; they make it easier to cope with changes, and reduce the risk factors
associated with any development project.
Manage
requirements
RUP offers sound
support for eliciting, organizing and recording requirements. Precise
documentation of requirements facilitates traceability through the development
process, which enhances the quality of the final system result of which we get
robust and reliable system.
Use
component-based architectures
RUP prescribes the
early identification and development of a system structure that is at the same
time robust enough to ensure system reliability, and flexible enough to
accommodate changes.
RUP describes how to
construct an architecture combining both new and previously existing
components, thus encouraging the reuse of software as part of the development process.
Visually
model software
RUP
is based around the Unified Modeling Language (UML) as a vehicle for
development.
UML diagrams facilitate
communication between developers and users and between members of the
development team, they offer
a number of different views of the system which combine to give a complete
picture, they help developers to decompose the problem into smaller, more manageable
chunks, and they provide a means of abstraction, concentrating on important
information while hiding details that are currently irrelevant.
Verify
software quality
RUP provides the
techniques to support quality assessment of functionality, reliability and
performance throughout the development process.
Control
changes to software
Changes are the norm in
a software development project, so an effective development process must be
able to monitor and control them.
RUP is an increasingly popular
approach to developing software systems, and is already laying claim to be the industry
standard.
5.
Explain the Unified Modeling Language (UML)?
The
Unified Modeling 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 modeling object-oriented systems.
Modeling:
Architects and engineers have
always used special types of drawing to help them to describe what they are
designing and building. Each model produced represents part of the system or
some aspect of it, such as the structure of the stored data, or the way that
operations are carried out. Each model provides a view of the system, but not
the whole picture.
Fig
1.4 Different models showing different information about one real-life person
The family tree is a graphical, diagrammatic model. Using these we can
see that she has four brothers and is the youngest child; we also discover the
first names of Jane's parents and siblings.
The Textual model tells us some
details about Jane, her birth date, address, school and which
class she is in. Each model
(the photograph, the family tree and the piece of text) tells us something
about Jane, but we can only get all the information by looking at all the models.
The characteristic of a model to
provide some but not all the information about the person or thing being modeled
is known as abstraction. Abstraction is a very important
tool in modeling any sort of software system Abstraction provides a
means of concentrating on only those aspects of the system those are currently
of interest so as to develop the model.
Another, equally important tool for modeling
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.
UML models
UML is not a development method since it
does not prescribe what developers should do, it is a diagrammatic language or
notation, providing a set of diagramming techniques that model the system from
different points of view.
The 4 + 1 view. The authors
of UML, Booch et al., (1999), suggest we look at the architecture of a system
from five different perspectives or views:
·
The use case view
·
The design view
·
The process view
·
The implementation view
·
The implementation view
Ø The use case view of the system is the users' view: it specifies
what the user wants the system to do; the other 4 views describe how to achieve
this. The use case view describes the external behavior of the system.
Ø The design view (sometimes called the logical
view) describes the logical structures required to provide the functionality
specified in the use case view. The design view describes the classes of the
system and their interactions. This view is captured in the class diagram and
the interaction diagrams.
Ø The process view is concerned with describing
concurrency in the system; sequence diagrams can be used to achieve it.
Ø The implementation view describes the physical
software components of the system, such as executable files, class
libraries and databases. This view of the system can be modeled using
component diagrams.
Ø The deployment view of the system describes the
hardware components of the system such as PCs, Mainframes, printers and the way
they are connected. This view can also be used to show where software
components are physically installed on the hardware elements. Deployment diagrams
describe this view of the system.
Not
all of these views will be required for every system. For instance, if your
system does not use concurrency, you will not need a process view. If your
system runs on a single machine, you will not need the deployment view or the component
view, as all of the software components will be installed on one machine.
The
4 + 1 view gives us five different ways of viewing a system and is supported in
UML by modeling techniques to capture each view. Each one offers a different perspective; no one
gives us the whole picture.
UML and CASE tools: 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.
CASE (Computer Aided Software Engineering)
refers to any piece of software that has been designed to help people develop systems.
CASE tool can be a simple drawing program or basic debugger, but today almost all
CASE tools cover the whole of the system life cycle, and provide automated
support for all development activities, both technical and managerial.
Introduction to the case study
The case study which is
used as the basis for examples and exercises in this book is a typical bicycle
hire shop. If you have ever hired a bicycle, you will already be familiar with
some of the details; in fact, if you have ever hired anything, such as a car or
even a video, you will see that the basic processes are very similar.
The bike hire shop is
called Wheels, and was started by Mike Watson, the current owner, about ten
years ago. Mike has always been a keen cyclist, and still competes regularly in
local races and rides for charity. He has an encyclopedic knowledge of all types
of bike, and is very proud of the range and quality of his stock.
The business has done
well, and now occupies large premises near the centre of town with a big
storage and workshop area in the basement. Wheels attracts a lot of passing
custom because of the position of the shop, and also gets many returning
customers who know that they will be given a good quality bike that will suit
their needs.
6.
Explain the Requirements for the Wheels case study system?
These requirements form
the starting point for the object-oriented development of the Wheels system
that is described in requirements.
Requirements
engineering
The activities that capture and
record client requirements are known collectively as requirements
engineering. Requirements engineering is a crucial and complex part of any
system
development, not just
object-oriented projects.
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.
7.
Explain the Requirements elicitation?
During requirements
elicitation, the focus is on collecting as much information as possible
about what the clients and users want and need from the new system. This
usually involves a large amount of work examining the way in which the system
operates at present, whether it is manual, automated, or a mixture of both.
Techniques for requirements elicitation include interviews, questionnaires, and
study of documents, observation of people carrying out day-to-day tasks, and
assessment of the current computer system if there is one.
Interviews:
Successful elicitation of requirements depends on good communication with
clients and users, and one of the most effective ways of achieving good
communication is through one-to one interviews. Ideally, a developer should
interview everyone in the client organization, from secretaries and office
juniors to bosses and managers. However, in a large business this is clearly
not practicable, so it is important that those members of staff who are
interviewed are a representative cross-section of the people who will be
involved in the new system.
Fig 1.5 Interview plan
for interview with Annie Price, shop manager at Wheels
The extract from the interview with
Annie is fairly typical in that relevant information does not emerge in a
structured, coherent order. From what Annie says, we can identify a number of
areas
that seems to be causing
problems.
·
It takes a long time to deal with queries such as 'Have you
got 5 women’s mountain bikes?' or 'How much would it cost to two adult racers
for three days?'
·
The only way Annie can tell if a bike is in the shop and
available for hire is by looking on the shop floor.
·
The bike cards are kept in number order, so Annie has to know
the bike number before she can find its card.
·
Wheels do not seem to keep any records of their customers' details
or the bikes that they hired on previous occasions.
·
When a customer hires more than one bike, Annie has to fill
out a separate card for each one.
·
Annie has to write out receipts for the customers by hand.
·
Bike return is slow because it takes Annie a while to
calculate whether the whole deposit can be returned.
·
Important information about
novelty bikes has to be written on the standard bike card
Questionnaires: 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’s customers think
about the current bike hire procedures. E.g.) Feedback form.
Scenarios:
Scenarios have been popular as a method of
requirements elicitation for many years and have now become closely associated with
object-oriented development of systems. A scenario is a sequence of
interactions between a user and the system carried out in order to satisfy a
specified goal. Scenario is a sequence of particular events, not a general
description. This example illustrates the straightforward return of a bike,
without any problems It is also important for the developer to find out about
what happens when a goal is not achieved, for example a customer may come into
Wheels to return a bike, but the bike card is missing.
Fig
1.6 Simple scenario for the return of a bike in the
current Wheels system
Requirements specification:
The main purpose of requirements
specification is to collate, order and record the mass of information gathered
during the elicitation
Requirements validation:
The purpose of the validation stage
of requirements engineering is to make sure that the developer has understood
and recorded correctly the wishes and needs of the clients and users of the new
system. Some validation can be carried out in parallel with elicitation, one of
the most effective methods of validation is to cross reference information
obtained from different elicitation approaches.
7. Mention the List of requirements for
the Wheels system?(6 marks)
The new Wheels system must:
R1 keep a complete list of all bikes and their
details including bike number, type, size, make, model, daily charge rate, deposit (this is
already on the Wheels system).
R2 keep a record of all customers and their past
hires transactions.
R3
work out automatically how much it will cost to hire a given bike
for a given number of days.
R4 record the details of a hire transaction
including the start date, estimated duration, customer and bike, in such a way that
it is easy to find the relevant transaction details when a bike is returned.
R5
keep track of how many bikes a customer is hiring so that the customer
gets one unified receipt not a separate one for each bike
R6 cope with a customer who hires more than one
bike, each for different amounts of time
R7 work out automatically, on the return
of a bike, how long it was hired for, how many days were originally paid for,
how much extra is due
R8
record the total amount due
and how much has been paid
R9
print a receipt for each customer
R10 keep track of the state of each bike, e.g. whether it
is in stock, hired out or being repaired
R11 provide the means to record extra details about specialist
bikes.
USE CASES
Introduction
Use cases model the user’s
view of the functionality of a system, i.e. what the system does as far as the
user is concerned; what it does that is of value to the user. The use case
model provides a means of organizing, structuring and documenting the mass of
information discovered during requirements elicitation; it therefore forms an
integral part of the requirements specification stage of the development
process.
Use cases are normally
presented in a graphical form, the use case diagram, supported by textual
descriptions, use case and actor descriptions, and scenarios.
8.
Explain the Use case diagram?
The use case model
consists of a use case diagram, a set of use case descriptions, a set of actor
descriptions and a set of scenarios. The use case diagram models the problem
domain graphically using four concepts: the use case, the actor, the
relationship link and the boundary.
Fig
1.7 The UML symbols for use case diagrams
UML symbols used to
model these concepts are shown in Fig. The use cases: 'Maintain bike list',
'Maintain customer list', 'Handle enquiries', 'Issue bike' and 'Handle bike
return'. Each use case is linked by a line to an actor. The actor, represented
by a stick figure, is the person (sometimes a computer system or an
organization) who uses the system in the way specified in the use case or who
benefits from the use case.
Fig 1.8 Use case
diagram for Wheels
The use case:
Identifying use cases from
the actors: There are several ways of approaching use case
identification. One is to identify the actors, the users of the system, and
for each one, to establish how they use the system, what they use it
to achieve. Issuing bikes therefore will be one of the use cases.
Issuing bikes involves finding
a suitable bike, calculating the hire charge, collecting the money,
issuing a receipt and recording details of the customer and the hire transaction.
Identifying use cases from scenarios: Another approach to
identifying use cases is to start with the scenarios. Scenario describes a series of interactions between
the user and the system in order to achieve a specified goal. 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. The scenarios
should document:
- A typical sequence of events leading to
the achievement of the use case goal - e.g. a customer hires one bike
- An obvious variation on the norm- e.g. a
customer hires several bikes for a fixed period; a customer hires several
bikes for different periods; a customer hires a specialist bike etc.
- Sequences of events where the use case
goal is not achieved - e.g. the customer cannot find a bike he likes; the
customer thinks the cost is too great, etc.
A use case is a complete end-to-end
use of the computer, a complete path through the system. A use case must
deliver some benefit to the actor associated with it - it must have a goal.
Each use case will have several scenarios associated with it. Some will be
successful, i.e. achieve the use case goal, some will not.
Use
case descriptions
The use case description is a narrative document that describes, in
general terms, the required functionality of the use case.
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 high level descriptions.
Fig 1.9 High-level
description of the "Issue bike" use case
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 use 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
Fig 1.10Expanded
description of the "Issue bike" use case
Preconditions:
Some practitioners include a section for preconditions in the expanded use case
descriptions. We might specify, for example, that the bike list needs to be up
to date before the use case 'Issue bike' is performed, i.e. the use case
'Maintain bike list' must have been executed.
Fig 1.11 Expanded description of the
"Issue bike" use case with preconditions
Actors
and actor descriptions
Actors are external to
the system- they represent people or things that interact with the system and
receive some benefit from it. Normally an actor is a user, but sometimes it is
another system such as banking or accounting system; an actor can also
represent a hardware device such as a printer. Typically an actor is someone
who inputs information to the system or receives information from it (or both).
Actors are identified during the
requirements elicitation stage by asking such questions as:
Who is involved in
major system processes such as issuing bikes?
Who will use the new
system?
Who supplies
information to the system?
Who will receive output
from the system?
Actor
descriptions: An actor description briefly describes
the actor in terms of role and job title.
Ø The Receptionist
uses the system to answer queries about bike availability and cost, to issue a
bike for hire and to register a bike return. The Receptionist can be the shop
manager (Annie), any of the mechanics or the owner (Mike).
Ø The Administrator
uses the system to maintain lists of customers and bikes. The Administrator can
be the head mechanic (Naresh), the shop manager (Annie) or the owner (Mike).
9. Explain the Use case relationships in
detail?
Use case relationships:
communication association, include and extend Communication association. In a use
case diagram the line linking an actor to a use case is called a communication
association. Communication associations tell us which actors are associated
with which use cases. Each actor may be associated with many use cases and each
use case may be associated with many actors.
Include:
Two other types of relationship may be used on a use case diagram- <<include>>
and <<extend>>. Both <include>> and <<extend>>
are relationships between use cases. An <include>> relationship is
useful when you find you have a chunk of behavior that is common to several use
cases. Rather than repeat a description of that behavior in several use case
descriptions, the common behavior can be split off into a separate use case
which is then linked to all relevant use cases with an <include>>
relationship.
Fig
1.12 Wheels system with includes and extends relationships
Figure:
Wheels system with includes and extends relationships
Extend.
The
<<extend>> relationship is used as a way of specifying significant
alternative behavior in a use case. It usually documents functionality that the
user can opt to use over and above the norm. The practice of using an
<<extend>> relationship in this way is only for documenting
important variations from the normal 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
·
Behavior done only under certain
conditions, for example printing an extra receipt if the whole deposit is not
returned.
Fig
1.13 Extract from the Wheels use case diagram showing the relationship between
"Issue bike" and "Maintain customer list".
Documenting
<<include>> and <<extend>> in the use case description.
If we
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'.
Boundary:
In
general the concept of the system boundary is important as it delineates the
domain of study. The system boundary may be included on a use case
diagram as a line round the use cases, separating them from the actors;
normally it is labeled with the name of the system or subsystem.
10.
Explain how use case models are useful in software development?
Each of the UML models
concentrates on modeling its own particular aspects of the system while ignoring
others: they provide complementary views of the system. The use case model
gives the user coherent and detailed documentation of what the system does or
will do.
Checking the system
using the use case model:
The use case model provides an excellent
basis for system testing. As each use case models a significant task, the use
cases provide ready made testing units. The scenarios provide instances of the
normal sequence of events in the use case and the main alternatives; exactly
what is required for testing purposes.
Estimating using use
cases:
Project managers find use cases useful for
planning and estimating the development process. Once the system has been
broken down into a set of use cases and the nature of each use case understood,
the project manager will have a good idea of how long each will take to
develop, how much risk is attached to each and how vital each is to the success
of the project.
Basis for interaction
diagrams:
Use cases are
closely related interaction diagrams, i.e. sequence diagrams and collaboration diagrams.
A use case provides a description of a particular task; the corresponding
interaction diagram shows how that use case will work in terms of messaging
between objects.
Starting point for the
identification of classes:
Use case descriptions and scenarios can
provide the starting point for the identification of
classes
for the class diagram.
Technical points:
Ø Documenting
extension points in a use case diagram:
Extension points can be
documented on the use case diagram as in fig. In the lower half of the use case
ellipse we specify the names of the extension points - in this case ‘Add customer' and 'Edit customer'.
We
can also specify the circumstances under which the extending use case is executed
by adding a comment on the relationship - in this case 'New customer or change
customer details’.
Fig
1.14 Documenting extension points in a use case diagram
Ø Generalization.
Both use cases and
actors can be specialized, i.e. we can use an inheritance (otherwise known as a
generalization/ specialization) relationship between actors and between use cases.
In object-oriented development inheritance is primarily associated with class
diagrams. If an inheritance relationship exists between two entities it means
that one inherits the characteristics of the other. Where use cases are
concerned, the use of generalization is another way of specifying alternative
courses of events.
Fig
1. 15 Generalization/specialization relationship
Initiating
actor and participating actor. It is worth understanding
Ø Initiating
actor and participating actor:
The initiating actor is the one
who starts off the sequence of events, i.e. initiates the use case. The rest of
the actors involved in the use case are the participating actors. The
most important actor is the one known as the beneficiary, i.e. the one
who gets benefit from the use case: the one using the computer, as specified in
the use case, to do something useful for him.
In the Wheels case study we have not modeled
Customer as an actor although it is
often the customer who initiates a use case.
Fig
1.16 Use case diagram with Customer actor
Ø Essential
and real use case: I
It is worth understanding the difference
between essential and real use .An essential use case is one that is
completely free of implementation or detailed design decisions. Real use
cases, by contrast, do show detail of design and implementation decisions
insofar as they affect the user.
Stereotype:
A stereotype is a specialized use of a modeling
element. The <<include>> and <<extend>> are stereotyped
association relationships
Fig 1.16 Receptionist as actor drawn as a
stereotyped class
Strictly speaking the actor icon
is a stereotyped class. Instead of using the stick figure to model an actor
such as the Receptionist, we could equally well use the UML class icon and
label it as an actor stereotype.
Ø Subsystems
and Packages:
UML has grouping notation known as
a package to cope with this. Packages are simply a convenient notation for
managing our models, they do not represent anything in the system, but are used
to group elements that do represent things in the system. We can use packages
to group any set of modeling elements: classes, use cases or an entire set of
models, e.g. the use case model, the object model, and the interaction diagrams
relating to a subsystem.
Fig
1.17 Packages of use cases
Ø Use
case realization: The development
of a use case from the initial identification during requirements elicitation to
its implementation is known as use case realization. During use case
realization, once all the use cases have been identified and documented, each
use case is analyzed separately to identify the classes required by it. The
group of classes involved in a particular use case is known as collaboration.
The classes in a particular are often grouped into a package.
Disadvantages
of use case model:
Ø Can more than one actor be associated with a use
case?
Ø What
dictates the granularity of use cases, i.e. how do we know how big or how small
to make them?
Ø How
do I know when it is appropriate to use an <<include>>relationship?
Fig
1.17 Unnecessary use of <<include>>
1 Can more than one
actor be associated with a use case?
2 MARKS
1.
Write about the traditional development
methodologies?
Most traditional development
methodologies are either algorithm centric ordata centric.
a) Algorithm-centric methodology:
You think of an algorithm that can
accomplish the task, and the build data structures for that algorithm to use.
b) Data- centric methodology:
You think how to structure the data, and
then build the algorithm around that structure.
2.
Define objects.
Ø Object
is a real-world entity, identifiably separate from its surroundings, has a well
defined set of attributes and a well-defined set of procedures or methods.
Ø Properties
(or attributes) describe the state (data) of an object.
Ø Methods
(procedures) define its behavior. Object means a combination of data and logic
that represents some real-world entity.
Ø (E.g.)
Car is an object. Color, manufacturer, cost, owner etc are attributes.
Drive it, lock it, tow it, carry
passengers in it are all methods.
3.
What do you mean by software development
process?
The
software development process consists of
Ø Analysis
Ø Design
Ø Implementation
Ø Testing
Ø Refinement
Ø The
essence of software development process is to transform users’ needs
into
a software solution that satisfies those needs. The main point is to build high
quality software.
Ø Print
Ø server
Ø Item
Ø Requesting
for printing
4. Explain briefly the waterfall
approach.
a.
It
starts with deciding what is to be done
b.
Once the requirements have been determined, we next must decide how
toaccomplish them.
c.
Followed by a step in which we do it.
d.
We then must test the result to see if we have satisfied the
users’requirements.
e.
Finally we use what we have done.
5.
Define collaboration.
The
object-oriented programming community has adopted use-cases to aremarkable
degree. Scenarios are a great way of examining who does what in theinteractions
among objects and what role they play; that is their interrelationships. This
intersection among objects’ roles to achieve a given goal is called
collaboration.
6.
Write the 80-20 rule.
a.
Documentation is another important activity, which does not end
withobject-oriented analysis but should be carried out throughout the
systemdevelopment.
b.
The 80-20 rule generally applies for documentation: 80 percent of the work can
be done with 20 percent of the documentation.
7. Define Prototype. Give the types
of prototype.
A
prototype is a version of a software product developed in the early stages
ofthe product’s life cycle for specific, experimental purposes. A prototype
enables you to fully understand how easy or difficult it will be to implement
some of the features of the system. It also gives users a chance to comment on
the usabilityand usefulness of the user interface design.
What
Use
Do
it
How
Test
Prototypes have been categorized in
various ways.
Ø Horizontal prototype
Ø Vertical prototype
Ø Analysis
prototype
Ø Domain
prototype
8. Write a brief note on RAD.
a.
Rapid application development (RAD) is a set of tools and techniques that can
be used to build an application faster than typically possible with traditional
methods.
b.
The developer sacrifices the quality of the product for the quickerdelivery.
c.
RAD does not replace the system development life cycle but complementsit, since
it focuses more on process description and can be combined perfectly with theobject-oriented
approach.
d.
The main objective of RAD is to build a version of an application rapidlyto see
whether the system does what it is supposed to do.
e.
RAD involves a number of iterations. RAD encourages the incrementaldevelopment
approach.
9. Write about CBD?
Component
based development is an industrialized approach to the softwaredevelopment
process. Application development moves from custom developmentto assembly of
rebuilt, pretested, reusable software components that operate witheach other.
10. Why do we go for object oriented
systems development?
The
motivation factor behind object-oriented system development is the desireto
make software development easier and more natural by raising the level
ofabstraction to the point where the level of abstraction to the point where
applications can be implemented in the same terms n which they are described by
users.
11. What is horizontal prototype?
It
is a simulation of the interface ie, it has the entire user interface thatwill
be in the full-featured system but contains no functionality.
12.
Explain the domain prototype?
It
is an aid for the incremental developmental of the ultimate softwaresolution.
It often is used as a tool for the staged delivery of subsystems to theusers or
other members of the developmental team.
13. Write about the Vertical
prototype?
It’s
a subset of the system features with complete functionality. Theprincipal
advantage of this method is that the few implemented functionality canbe tested
in great depth.
14. Explain Analysis prototype?
It
is an aid for exploring the problem domain. This class of prototype isused to
inform the user and demonstrate the proof of a concept. It is not used asthe
basis of development. The final product will use the concepts exposed by
theprototype, not its code.
15.
Define OOAD?
OOAD is the software engineering
application that models a system as a group of interacting objects. Each object
represents some entity in the s/w being modeled and characterized by its class,
its state and its behavior.
16.
Define OOA?
During Object oriented analysis
phase object modeling technique are used to analyze the functional requirements
of the system and create models which reflect the logical design of the system.
17.
Define OOD?
During Object oriented design phase
models are elaborated upon to include implementation specific details that show
how the physical design of the system will come together.
18.
Define UML?
The Unified Modeling Language, UML,
is a set of diagrammatic techniques, which are specifically used for
object-oriented development. However UML is simply a notation or language for
development; it is not in itself a development method and does not include
detailed instructions on how it should be used in a project.
19.
What do u meant by requirements engineering?
The activities that capture and
record client requirements are known collectively as requirements
engineering. Requirements engineering is traditionally divided
into three main stages:
·
Elicitation
·
Specification
·
Validation
20. Define OCL?
The rules and semantics of the UML are
expressed in English, in a form known as object constraint language. Object
constraint language (OCL) is a specification language that uses simple logic
for specifying the properties of a system.
BASICS
OF OBJECTS:
1. Give a brief note on object
behavior?
Object behavior is described in
methods or procedures. Behavior denotes the collection of methods that
abstractly describes what an object is capable of doing. Each procedure defines
and describes a particular behavior of an object. Methods encapsulate the
behavior of the object. Objects take responsibility for their own behavior.
2. What do you
mean by information hiding?
Information hiding is the principle
of concealing the internal data and procedures of an object and providing an
interface to each object and providing an interface to each object in such a
way as to reveal as little as possible
about its inner workings.
Ø An
object is often said to encapsulate the date and a program.
Ø Per-class protection.
·
Class methods can access any object of
that class and not just the
receiver
Ø Per-object protection.
·
Methods can access only the receiver.
3.
Define class hierarchy?
Object
oriented system organizes classes into a subclass-super class hierarchy. At the
top of the class hierarchy are the most general classes and at the bottom are
the more specific. A subclass inherits all of the properties and methods
defined in its super class. Subclasses may refine or constrain the state and
behavior inherited from its super class. A class may simultaneously be the
subclass to some class and a super class to another class. Formal or abstract
classes have no instances but define the common behaviors that con be inherited
by more specific classes.
4.
Write briefly about inheritance and
explain the types of inheritance.
Ø Inheritance
is the property of object-oriented systems that allows objects to be built from
other objects.
Ø Inheritance
is a relationship between classes where one class is the parent class of
another derived class called base class or super class.
Ø Inheritance
allows classes to share and reuse behaviors and attributes of all its super
classes.
Types
of inheritance
Ø Dynamic inheritance.
It allows objects to change and evolve over time. Since base classes provide
properties and attributes for objects, changing base classes changes the
properties and attributes of a class.
Ø Multiple inheritances.
Some object-oriented systems permit a class to inherit its state
(Attributes)
and behaviors form more than one super class.
5.
What do you mean by polymorphism?
Polymorphism means that the same
operation may behave differently on different classes. Polymorphism allows us
to write generic, reusable code more easily, because we can specify general
instructions and delegate the implementation details to the objects involved.
6. Explain object relationship and
associations?
a.
Association
represents the relationships between objects and classes.
b.
Associations are bidirectional.
c.
Cardinality
specifies how many instances of one class may relate to a single instance of an
associated class.
d.
Cardinality constraints the number of related objects and often is described as
being “one” or “many”
7.
What do you mean by consumer-producer
association?
It
is also known as client-server association. It uses relationship. It is a one
way interaction in which one object requests the service of another object. The
object that makes the request is the consumer or client and the object receives
the request and provides the service is the producer or server.
8. Write about static and dynamic
binding?
Ø Static binding
The process of determining which function to
invoke at compiles time is termed as static binding. Static binding optimizes
the calls.
Ø Dynamic
binding
The
process of determining which functions to invoke at run time are called as
dynamic binding. They occur when polymorphic calls are issued. Dynamic binding
allows some method invocation decisions to be deferred until the information is
known.
9.
Define object
persistence?
A
file or a database can provide support for objects having a longer lifeline,
longer than the duration of the process for which they were created. This is
called object persistence. An object can persist beyond application session
boundaries, during which the object is stored in a file or a database. The
object can be retrieved in another application session and will have same state
and relationship.
10.
Define meta-classes?
If
a class is an object, it must belong to a class which is called as meta-class
or a class of classes. All the objects are instances of a class and all classes
are instances of a meta-class. Meta-classes are used by the compiler.
