Ooad Complete Material

VEL TECH HIGH TECH Dr.RANGARAJAN Dr.
SAKUNTHALA ENGINEERING COLLEGE
UNIT-1
UNIFIED PROCESS AND USE CASE DIAGRAMS
1.1 INTRODUCTION TO OOAD WIT OO BASICS
A software development methodology is a series of processes like
• System Analysis
• Modeling
• Design
• Implementation
• Testing and
• Maintenance
that leads to the development of an application.
There are two orthogonal views of software development.
1) Traditional Technique – focuses on data and functions.
2) Object Oriented methodologies – focuses on objects that combines data and
functionality.
Object oriented systems development develop software by building objects that can be
easily replaced, modified and reused. Objects has attribute (data) and methods (functions).
Object Oriented systems are
• Easier to adapt to changes
• Easier to maintain
• Promote greater design and code reuse
• Creates modules of functionality
WHAT IS OOAD?
1.1.1 Object Oriented Analysis
Analysis is the process of investigation of the problem and the requirements than finding
its solution.
Analysis is classified as
• Requirement Analysis
• Object Oriented Analysis
In object oriented analysis finding and describing the objects or concepts in the problem
domain is done.
Example:
In flight information system, during analysis the concepts identified are
• Plane
• Flight
• Pilot
1.1.2 Object Oriented Design
Design is the process of finding a conceptual solution that fulfills the requirements than
implementing it.
Design is classified into
• Database design
• Object oriented design
In object oriented design, software objects are defined and collaborated to fulfill the
requirements.
Example
In flight information system plane is a software object having
• Attribute – TailNumber
• Method – getFlightHistory
QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

VEL TECH HIGH TECH Dr.RANGARAJAN Dr.SAKUNTHALA ENGINEERING COLLEGE

To summarize
• Analysis means – DO THE RIGHT THING
• Design means – DO THE THING RIGHT
1.1.3 Example
The key steps in the analysis and design include.
1) Define use cases
2) Define domain model
3) Define interaction diagrams
4) Define design class diagrams
Figure 1.2 Key steps in OOAD
These key ideas are expressed with the “dice game”  A software simulates a player
rolling two dice.
If the total is „seven‟, they win; otherwise they lose.
Define use cases
Requirement analysis consists of use cases scenarios of how people use the application.
In the dice game, the use cases include
• Play a Dice game 
Player rolls dice
System gives results
Player wins if dice value totals seven
Otherwise loses
Define a Domain Model
Object oriented analysis describes the problem domain by identifying
• Concept
• Attributes
• Associations
All these are represented in domain model.
The concepts, attributes and association of the dice game are represented as

Figure 1.3 Partial Domain Model of dice game

Define Interaction Diagrams
• In Object Oriented Design, software objects are defined with their responsibilities and
collaborations.
• Sequence diagram is used to represent the collaborations.
• It is the flow of messages between software objects.
• Example: In dice game, the player rolls the dice in real world.
• But in software design it is illustrated as die object shown in the following sequence
diagram.
Figure 1.4 Sequence Diagram for dice Game

Define design class diagram
• In the interaction diagram (sequence diagram) the dynamic view of collaborating
objects is shown.
• The static view of the classes can be shown with class diagram.
• Example: The class diagram for the above sequence diagram of the dice game can be
shown, Here Dice game has play method. Dice has roll and getFaceValue methods.
Figure 1.5 Partial design class diagram

1.2 WHAT ARE UP (UNIFIED PROCESS) PHASES

Software development process is an approach to i) Build, ii) Deploy and iii) Maintain the
software
• The Unified Process (UP) is a software development process mainly for building
object oriented systems.
• The detailed refinement of the unified process is Rational Unified Process or RUP.
• The Unified Process
◦ is an iterative process
◦ provides an example structure for how to do Object Oriented Analysis and Design
◦ is flexible
◦ can be applied to lightweight and agile approach.
◦ combines iterative lifecycle and risk driven development into a cohesive and well
documented process description.
UP Phases
There are four major phases of UP
They are
1) Inception
2) Elaboration
3) Construction
4) Transition
1.2.1 Inception
Inception is a feasibility phase where enough investigation is done to support a decision to
continue or stop. Inception includes
• Approximate vision
• Business scope
• Vision
• Scope
• Vogue Estimates
1.2.2 Elaboration
Elaboration is the phase where the core architecture is iteratively implemented.
Here the high risk issues are mitigated.
Elaboration includes
• Refined vision
• Iterative implementation of the core architecture
• Resolution of high risks
• Identification of most requirements and scope
• More realistic estimates
1.2.3 Construction
Construction involves
• Iterative implementation of the remaining lower rise and easier elements
• Preparation for deployment
1.2.4 Transition
Transition involves
• Beta tests and
• Deployment.

Figure 1.6 Schedule oriented terms in UP

Milestone – An iteration endpoint where some significant
decision/evaluation occurs
Release – A stable executable subset of the final product
Increment – the difference between the release of two subsequent
iterations
Final production release – The system is released for production use
UP Disciplines
There are several disciplines in UP.
Some are
• Business Modeling
◦ The domain model artifact to visualize concepts in application domain.
• Requirements
◦ Usecase model
Supplementary specification to capture functional and non functional requirements
• Design
◦ Design Model artifact
◦ Design software objects
Programming and building the system
• Environment
◦ Establishing the tools and customizing the process for the project.
Figure 1.7 Disciplines and phases

1.3 UML DIAGRAMS
UML is expanded as „UNIFIED MODELING LANGUAGE‟
The UML is a visual language for
• Specifying
• Constructing and
• Documenting artifacts of the systems
The word visual indicates UML as the defacto standard diagramming notation for drawing
or presenting pictures related to software – i.e., Object Oriented Software.
1.3.1 Three ways to apply UML
(1) UML as sketch
Informal and incomplete diagrams are created to explore difficult parts of the problem or
solutions.
(2) UML as blue print
Detailed design diagrams are used for

• Reverse Engineering or

• Forward engineering
A UML tool reads the source and generates UML class, sequence and package diagrams
in reverse engineering.
Detailed diagrams can provide guidance for code generation.
UML as programming language
Complete executable specification of software system in UML.
Executable code is automatically generated.
It is still under development for usability.
1.3.2 Three perspectives to Apply UML
UML describes raw diagrams like
• Class diagrams
• Sequence diagrams
In three different perspectives
1) Conceptual
2) Specification
3) Implementation
(1) Conceptual Perspective
Diagrams interpret things in a situation of the real world or domain of interest.
(2) Specification (Software) perspective
The diagrams describe software abstracted or components with specification and
interfaces.
(3) Implementation (Software) perspective
The diagrams describes software implementations in a particular technology like Java.
“Class” Perspectives
Classes are represented by rectangular boxes.
Classes represent
• Physical things
• Abstract concepts
• Software things
• Events etc.
The class related terms used are
• Conceptual class or Domain concepts
 Realworld concept or thing
A conceptual or essential Perspective
• Software class
A class representing a specification or implementation perspective of a software component.

• Implementation class
A class implemented in a specific Object Oriented language such as Java.
1.4 USE CASE DIAGRAM
The use case concept was introduced by Ivar Jacobson in object oriented software
engineering (OOSE).
Usecases represent specific flow of events in the system.
Use cases define the outside (actors) and inside (use case) of the system‟s behavior.
A use case diagram is a graph of actors, a set of use cases enclosed by a system boundary,
communication (participation) association between the actors and the use cases and generalization
among the use cases.
Example: A USE CASE DIAGRAM FOR A HELP DESK
Figure 1.9
A use case is shown as an ellipse containing use case name.

Use case name can be placed below or inside the ellipse.
An actor is shown as class rectangle with the level <<actor>> or the label and a stick
figure or just the stick figure with the name of the actor below figure.
Three Representation of Actor Are Equivalent
Figure 1.10
The relationship shown in use case diagram are:
1) Communication
2) Uses
3) Extends
The communication relationship of an actor in a use case is shown by connecting the actor
symbol to the use case symbol with a solid path. The actor is said to communicate with “use
case”.
A uses relationship between the use cases is sown by a generalization arrow from the use cases.
The extends relationship is used when we have one use cases similar to another but does a bit
mode.
1.4.1 USE CASES
A use case is a set of scenarios tied together by a common use goal.
A scenario is a sequence of steps describing an interaction between a user and a system.

Example Use Case Text

A simple format of use case involves describing the primary scenario as a
• Sequence of numbered steps and
• Alternatives as variations on that sequence
But a product
1) Customer browser through catalog and selects items to buy.
2) Customer goes to check out.
3) Customer fills in shipping information (address; next-day or 3-day delivery)
4) System presents full pricing information including shipping.
5) Customer fills in credit card information
6) System authorizes purchase
7) System confirms sale immediately
8) System sends confirming email to customer
Alternative
Authorization failure
At step 6 system fails to authorize credit purchase
Allow customer to reenter credit card information and reentry
Alternative
Regular customer
3a. System displays current shipping information, pricing information and last four digit
of credit card information.
3b. Customer may accept or override these defaults
Return to primary
There is no specific standard for the use case in the UML.
1.4.2 Use Case Diagrams
The diagrams which visualizes the use cases are called use case diagrams. This was
introduced by Jacobson in 1994.
The use case diagram is a part of UML.
One of the projects in which use cases are involved are
• Keeping each one on an index card and
• Sorting the cards into piles to show what needed building in each iteration
Example
We can see the use cases for a financial trading system.

Actors
An actor is a role that a user plays with respect to the system.
There are four actors in the above diagram
• Trading manager
• Trader
• Salesperson and
• Accounting System
This can be also known as role but as far as system is concerned, all play the same role.
A user may play more than one role.
For example,
• A senior trader any play the trading manager role and also the role of a trader.
• A trader may also be a salesperson
Actors carry out use cases. A single actor may perform many use cases and a use case may
have several actors performing it Actors are most useful than the use cases. It is easier to arrive at
a list of actors first and then try to workout the use cases for each other. Actors need not be human
beings though they are represented as stick figures in the use case diagram.
An actor can also be a external system that needs some information from the current
system. Some people show every external system or human actor on the use case diagram. Others
prefer to show the initiator of the use case. In some situations, we can track the actors later like.
The system may need configuring for various kinds of users. Here each kind of user is an
actor and use cases show what each actor needs to do. Tracking who wants use cases can help us
to negotiate priorities among various actors. Some use cases don‟t have clear links to specific
actors.
Example:- In a utility company one of the use cases is to send out bill.
Here no ser requests a bill or no customer is objecting if the doesn‟t get the bill. The best
guess of the actor is given by the Billing Department. One way to identify use cases is external
events.
1.4.3 Use Case Relationship
Links exist between actors and use cases. In addition to that several kinds of relationship
exist between use cases like
1) Include
2) Use case Generalization
3) Extend
Include
When we have a chunk of behavior that is similar across more than one use case and we
don‟t want to copy the description of the behavior.
Example: Both Analyze Risk and Price Deal require to value the deal.
Instead of having a fair chunk of writing and copying it again, we can write a separate
value Deal use case and refer it from the original use cases.
Use Case Generalization
When we have one use case that is similar to another use cases but does a bit more then
we use, use case generalization.
Example: The basic use case is capture Deal.
One special case is when the limit is exceeded ie., the maximum amount the trading
organization has established for a particular customer.
Extend
The third relationship called as extend is similar to generalization but with more rules to it.
The extending use case may add behavior to the base use case, but it must declare certain
“extension points” and the extending use case may add additional behavior only at those extension
points.Extend Relationship

A use case may have many extension points and an extending use case may extend one or
more of these extension points.
Apply the following rules
Use include when you are repeating yourself in two or more separate use cases and you
want to avoid repetition.
Use generalization when you are describing a variation on normal behavior and you wish
to describe it casually.
Use extend when you are describing a variation on normal behavior and you wish to use
the more controlled form, declaring your extension points in your base use case.
Business and System Use Cases
Two different use cases are there. They are
• System Use Case
• Business Use Case
A system use case is dealing with the interaction with the software.
Business use case discusses how a business responds to a customer or an event.
Useage of Use Case
Most of the use cases will be generated during the phase of the project but they will be
unconverted as we proceed the project.
Every use case is a potential requirement and, we can plan it only after we capture a
requirement.
Use cases represent an external view of the system.
During a recent OOPSLA panel discussion, several use case experts said that for a 10
person year project, they would expect around a dozen use cases. These are base use cases, each
use case would have many scenario and many variant use cases.
1.5 CASE STUDY - THE NEXTGEN POS SYSTEM INCEPTION
Inception is the initial short step to establish a common vision and basic scope for the
project.
Inception deals with “Environment the product scope, vision and business case”.
The purpose of inception is
• To collect enough information to establish a common vision.
• To decide if moving forward is feasible.
1.5.1 Use cases
The use cases are text stories used to discover and record requirements.
Use cases influence many aspect of a project.
They are input to artifacts.
The use cases also influence.
 Analysis
 Design
 Implementation
 Project management
 Test artifacts
The influence of UP artifacts is shown in the following figure.

1.5.2 Definitions
(1) Actors
Something with behaviour, such as
A person (identified by role)
Computer system or organization is called an actor
Example:
Cashier
(2) Scenario
A scenario is a specific sequence of actions and interactions between actors and the
system. It is called use case instance.
Example:
Scenario of successfully purchasing items with cash.
Scenario of failing to purchase items because of credit payment denial.

Use Case
Use case is a collection of related success and failure scenarios that describes an actor
using a system to support a goal.
Example:
Main success scenario:
A customer arrives at a shop to return items.
The cashier uses POS system and records returned items.
Alternative scenarios
If customer paid credit and if return to the credit account is rejected, pay the customer with
cash. If the item is not found, notify the cashier to enter manually etc.
Thus RUP (Rational Unified Process) defines use case as
“A set of use case instances, where each instance is a sequence of actions a system
performs that yields an observable result of value to a particular actor”.
1.6 USE CASE MODELING
Use cases and Use case Model
 Use Cases are text documents and not diagrams.
 Use case modeling is primarily an act of writing text, not drawing diagrams.
 Use cases are requirements Functional or Behavior
 Use cases emphasize the user goals and perspectives.
The strength of use cases is the ability to scale both up and down in terms of
• Sophistications and
• Formality
1.6.1 Three kinds of Actors
An actor is anything with behavior including the System Under Discussion (SUD) when it
calls upon services of other systems.
Actors are roles played not only by people but by organization.
Example:
• Software
• Machines
In relation to SUD there are three types of actors
 Primary actor
 Supporting actor
 Offstage actor
(1) Primary actor
It has user goals fulfilled by using services of SUD.
Example: Cashier
Finds user goals that drive use cases
(2) Supporting actor
It provides services to SUD.
Example: Automated payment authorization
(3) Offstage actor
It has an interest in the behavior of use cases but not primary or supporting.
Example: A government tax agency.
Use case formats
There are different formats for use cases like
• Brief
• Casual
• Fully dressed

Brief
• One paragraph summary of main success scenario.
• It is written during early requirements analysis.
• It is written to get a quick sense of subject and scope
• It can be written in a few minutes.
Example:
Process sale (given previously)
Casual
 Informal paragraph format
 It involves multiple paragraphs that cover various scenarios.
Example:
Handle Returns
Fully dressed
• Detailed steps are written.
• Supporting sections like preconditions are present.
Example:
Next Gen case study
Processed sale, Fully Dressed style
More detailed and structured style is given in fully dressed format.
During the requirement analysis, 10% of the critical use cases are written in this format.
The design and programming then starts on the most significant use cases or scenarios.
Many templates are available for detailed use cases.
The popular format template is given by Alistair Cockburn.
The template is shown below
Use case section Comment
Use case Name Start with a verb
Scope System under design
Level “user-goal” or “subfunction”
Primary Actor Calls on the system to deliver its services
Stakeholders & interest Who cares about use case? What do they want?
Preconditions What must be true on start, and worth telling the reader?
What must be true on successful completion, and worth telling the
Success Guarantee reader.
Main Success scenario A typical, unconditional happy path scenario of success.
Extensions Alternate scenarios of success or failure
Special requirements Related non-functional requirements.
Technology and data
variations list Varying input methods and data formats
Frequency of occurrence Influences investigation, testing and timing of implementation
Miscellaneous Such as open issues
This template can be used to the NextGen casestudy and the detailed illustration is shown
below.
The detailed branching scenarios are illustrated.
Use Case UC1: Process Sale
Scope: NextGen POS application
Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:

• Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are
deducted from his/her salary.
• Salesperson: Wants sales commissions updated.
• Customer: Wants purchase and fast service with minimal effort. Wants easily visible display
of entered items and prices. Wants proof of purchase to support returns.
• Company: Wants to accurately record transactions and satisfy customer interests. Wants to
ensure that Payment Authorization Service payment receivables are recorded. Wants some
fault tolerance to allow sales capture even if server components (e.g., remote credit
validation) are unavailable. Wants automatic and fast update of accounting and inventory.
• Manager: Wants to be able to quickly perform override operations, and easily debug Cashier
problems.
• Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies,
such as national, state, and county.
• Payment Authorization Service: Wants to receive digital authorization requests in the correct
format and protocol. Wants to accurately account for their payables to the store.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated.
Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment
authorization approvals are recorded.
Main Success Scenario (or Basic Flow):

• Customer arrives at POS checkout with goods and/or services to purchase.
• Cashier starts a new sale.
• Cashier enters item identifier.
• System records sale line item and presents item description, price, and running total.
Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done.
• System presents total with taxes calculated.
• Cashier tells Customer the total, and asks for payment.
• Customer pays and System handles payment.
(5) System logs completed sale and sends sale and payment information to the external
Accounting system (for accounting and commissions) and Inventory system (to update
inventory).
(6) System presents receipt.
(7) Customer leaves with receipt and goods (if any).
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
1) System enters Manager-authorized mode.
2) Manager or Cashier performs one Manager-mode operation. e.g., cash balance
change, resume a suspended sale on another register, void a sale, etc.
3) System reverts to Cashier-authorized mode.
*b. At any time, System fails:
To support recovery and correct accounting, ensure all transaction sensitive state and
events can be recovered from any step of the scenario.
1) Cashier restarts System, logs in, and requests recovery of prior state.
2) System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1) System signals error to the Cashier, records the error, and enters a clean state.
2) Cashier starts a new sale.
1a. Customer or Manager indicates to resume a suspended sale.
1) Cashier performs resume operation, and enters the ID to retrieve the sale.

2) System displays the state of the resumed sale, with subtotal.

2a. Sale not found.
1) System signals error to the Cashier.
2) Cashier probably starts new sale and reenters all items.
3) Cashier continues with sale (probably entering more items or handling payment).
2-4a. Customer tells Cashier they have a tax-exempt status (e.g., seniors, native peoples)
1) Cashier verifies, and then enters tax-exempt status code.
2) System records status (which it will use during tax calculations)
3a. Invalid item ID (not found in system):
1) System signals error and rejects entry.
2) Cashier responds to the error:
2a. There is a human-readable item ID (e.g., a numeric UPC):
1) Cashier manually enters the item ID.
2) System displays description and price.
2a. Invalid item ID: System signals error. Cashier tries alternate method.
2b. There is no item ID, but there is a price on the tag:
1) Cashier asks Manager to perform an override operation.
2) Managers perform override.
3) Cashier indicates manual price entry, enters price, and requests standard
taxation for this amount (because there is no product information, the tax
engine can‟t otherwise deduce how to tax it)
2c. Cashier performs Find Product Help to obtain true item ID and price.
2d. Otherwise, Cashier asks an employee for the true item ID or price, and does either
manual ID or manual price entry (see above).
3b. There are multiple of same item category and tracking unique item identity not important
(e.g., 5 packages of veggie-burgers):
1) Cashier can enter item category identifier and the quantity.
3c. Item requires manual category and price entry (such as flowers or cards with a price on
them):
1) Cashier enters special manual category code, plus the price.
3-6a: Customer asks Cashier to remove (i.e., void) an item from the purchase:
This is only legal if the item value is less than the void limit for Cashiers, otherwise a
Manager override is needed.
1) Cashier enters item identifier for removal from sale.
2) System removes item and displays updated running total.
2a. Item price exceeds void limit for Cashiers:
1) System signals error, and suggests Manager Override.
2) Cashier requests Manager Override, gets it, and repeats operation.
3-6b. Customer tells Cashier to cancel sale:
1) Cashier cancels sale on System.
3-6c. Cashier suspends the sale:
1) System records sale so that it is available for retrieval on any POS register.
2) System presents a “suspend receipt” that includes the line items, and a sale ID
used to retrieve and resume the sale.
4a. The system supplied item price is not wanted (e.g., Customer complained about something
and is offered a lower price):
1) Cashier requests approval from Manager.
2) Manager performs override operation.
3) Cashier enters manual override price.
4) System presents new price.
5a. System detects failure to communicate with external tax calculation system service:
1) System restarts the service on the POS node, and continues.
1a. System detects that the service does not restart.

1) System signals error.

2) Cashier may manually calculate and enter the tax, or cancel the sale.
5b. Customer says they are eligible for a discount (e.g., employee, preferred customer):
1) Cashier signals discount request.
2) Cashier enters Customer identification.
3) System presents discount total, based on discount rules.
5c. Customer says they have credit in their account, to apply to the sale:
1) Cashier signals credit request.
2) Cashier enters Customer identification.
3) Systems applies credit up to price=0, and reduces remaining credit.
6a. Customer says they intended to pay by cash but don‟t have enough cash:
1) Cashier asks for alternate payment method.
1a. Customer tells Cashier to cancel sale. Cashier cancels sale on System.
7a. Paying by cash:
1) Cashier enters the cash amount tendered.
2) System presents the balance due, and releases the cash drawer.
3) Cashier deposits cash tendered and returns balance in cash to Customer.
4) System records the cash payment.
7b. Paying by credit:
1) Customer enters their credit account information.
2) System displays their payment for verification.
3) Cashier confirms.
3a. Cashier cancels payment step:
1) System reverts to “item entry” mode.
4) System sends payment authorization request to an external Payment Authorization
Service System, and requests payment approval.
4a. System detects failure to collaborate with external system:
1) System signals error to Cashier.
2) Cashier asks Customer for alternate payment.
5) System receives payment approval, signals approval to Cashier, and releases cash
drawer (to insert signed credit payment receipt).
5a. System receives payment denial:
1) System signals denial to Cashier.
2) Cashier asks Customer for alternate payment.
5b. Timeout waiting for response.
1) System signals timeout to Cashier.
2) Cashier may try again, or ask Customer for alternate payment.
6) System records the credit payment, which includes the payment approval.
7) System presents credit payment signature input mechanism.
8) Cashier asks Customer for a credit payment signature. Customer enters signature.
9) If signature on paper receipt, Cashier places receipt in cash drawer and closes
it. 7c) Paying by check…
7d) Paying by debit…
7e) Cashier cancels payment step:
1) System reverts to “item entry” mode.
7f) Customer presents coupons:
1) Before handling payment, Cashier records each coupon and System reduces price as
appropriate. System records the used coupons for accounting reasons.
1a) Coupon entered is not for any purchased item:
1) System signals error to Cashier.
9a) There are product rebates:
1) System presents the rebate forms and rebate receipts for each item with a rebate.
9b) Customer requests gift receipt (no prices visible):

1) Cashier requests gift receipt and System presents

it. 9c) Printer out of paper.
1) If System can detect the fault, will signal the problem.
2) Cashier replaces paper.
3) Cashier requests another receipt.
Special Requirements:
• Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
• Credit authorization response within 30 seconds 90% of the time.
• Somehow, we want robust recovery when access to remote services such the inventory
system is failing.
• Language internationalization on the text displayed.
• Pluggable business rules to be insertable at steps 3 and 7.
Technology and Data Variations List:
*a. Manager override entered by swiping an override card through a card reader, or
entering an authorization code via the keyboard.
3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. But within two years, we predict
many customers will want digital signature capture.
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
• What are the tax law variations?
• Explore the remote service recovery issue.
• What customization is needed for different businesses?
• Must a cashier take their cash drawer when they log out?
• Can the customer directly use the card reader, or does the cashier have to do it?
Meaning of the sections
Preface elements
(1) Scope
• It bounds the system under design
• Since usecase describes use of one software it is known as system use case
• Use cases describe how a business is used by its customers and partners.
• The enterprises level process description is called Business Use Case, which is an
example of wide applicability of use cases.
(2) Level
Use cases are classified as
• User goal level or
• Subfunction level in Cockburn‟s system
User goal level
The user goal level describes the scenarios to fulfill the goals of a primarily actor
It corresponds to elementary Business Process (EBP) in Business Process Engineering.
Subfunction level
A subfunction level use case describes substeps to support a user goal.
It is created to eliminate duplicate substeps shared by several regular use cases
Example:
Pay by credit is a subfunction use case which is shared by many regular use cases
Primary Actor
It calls upon system services to fulfill a goal
Stakeholders and InterestList

• This list is more important and practical

• It suggests and bounds what the system has to do.
“The system operates a contract between stake holders, with the use cases detailing the
behavioral parts of that contract”.
The use case, as the contract for behavior, captures all and only the behaviors related to
satisfying stakeholder‟s interest.
The stakeholder interest viewpoint provides a through and methodical procedure for
discovering and recording all required behaviors.
• Salesperson : wants sales commission updated

• …….
Preconditions and Success Guarantees (Post conditions)
• Before beginning a scenario, preconditions state what must always be true.
• Preconditions are assumed to be true and are not tested within use case
• Example: “The system has power”
Post conditions (Success Guarantees)
The post condition must be true on successful completion of use case (ie, Main success
scenario or some alternate path)
Main Success Scenario and Steps (or Basic Flow)

It is called “ happy path” scenario, Basic flow or typical flow.
Main Success Scenario describe a typical success path that satisfies the interests of
stakeholders.
It does not have any conditions or branching.
All conditions and branching statements can be present in Extension section.
The scenario has three kinds of steps
(i) An interaction between actors
(ii) A validation
(iii) A state change by the system (example: recording or modifying something)
The actor‟s names are always written in capital letters for ease of identification.
Main Success Scenario

1) Customer arrives at a POS checkout with items to purchase
2) Cashier starts a new sale
3) Cashier enters item identifier
4) ……Cashier repeats steps 3- 4 until indicates done
5) ……
Extensions ( or Alternate Flows)

• Extensions comprise the majority of text

• They are more complex than Main Success Scenario section because they indicates all
scenarios success and failure.
• They are notated with respect to its steps 1…..N
• An extensions has two parts
◦ the condition and
◦ the handling
Extension handling may be in one step or includes a sequence with a range of
steps 3-6a: Customer asks Cashier to remove an item from the purchase:
1) Cashier enters item identifier for removal from the sale.

2) System displays updated running total.
If the extension is not halting, the scenario merges back with the main success scenario at
the end of extension handling.
Some complex extension points can be had as a separate use case.
Failures within the extension can also be demonstrated.
7b. Paying by credit

1) Customer enters their credit account information
2) System sends payment authorization request to an external payment
Authorization Service system, and requests payment approval.
2a) System detects failure to collaborate with external system
1) System signals error to cashier
2) Cashier asks customer for alternate payment.
The labels *a, *b,… can be used to describe an extension condition.

Sometimes, a usecase branches to perform another use cases scenario.
Example: In the Process Sale use case, we use the Find Product help.
The second use case us shown with underlining.
3a. Invalid item ID (not found in system):

1) System signals error and rejects entry.
2) Cashier responds to the error:
2a. …..
1. 2c. Cashier performs Find Product Help to obtain true item ID and price.
Special Requirements
• The non functional requirements
• Quality attributes or
• Constraints
Relates specifically to use case are mentioned as special requirements The quality may be
of
• Performance
• Reliability
• Usability
• Design constraints etc.
• Touch screen on a large flat panel monitor
• Text must be visible from 1 meter
• Credit authorization response within 30 seconds 90% of the time.
• Language internationalization on the text displayed

• Pluggable business rules to be insertable at steps 2 and 6.

Technology and Data Variations List
There may be technology variations in how things are done.
Example: One stakeholders says
“The POS system must support credit account input using a card reader and the
keyboard”.
Another stakeholder may prefer some other input/output
This list is the place to record such variations.
Technology and Data Variations List
3a. Item identifier given by laser scanner or keyboard
3b. item identifier may be any UPC, EAN, JAN or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. After sometime it may be
digital signature capture.
Other format
A two column or conversational format where intersections are between actors and the
system.
It is given by Wirfs-Brock and promoted by Constantine and Lockword.
The same example is shown in two column format.
Use Case UC 1: Process Sale
Primary Actor:….
….. as before ……
Main Success Scenario:
Actor Action (or intention) System Responsibility
1. Customer arrives at a POS checkout
with goods and /or services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. records each sale line item and presents
item description and running total
Cashier repeats 3-4 until indicates done. 5. Presents total with taxes
6. Cashier tells customer the total and asks
for payment
7. Customer pays 8. Handles payment
9. Logs all completed sale & send
information to the external accounting
and inventory systems. System presents
receipt
Some prefer one column style and some prefer two column style.
Some guidelines are followed in the styles.
1) Guidelines – Write in an Essential is to „log in‟
a) New Improved
When the goal of cashier is to „log in‟.
Instead of thinking of GUI, dialog box, user ID and password, use keyboards and mice
with biometric readers for fingerprint.
b) Essential style writing
Here use cases are written in essential style

The guidelines is “Keep the user interface out focus on intent”

c) Contrasting Examples
…
1) Administrator identifies self
2) System authenticates identity
3) ……..
(i) Identification
(ii) Authentication
Concrete style
The concrete use cases are used as aid to concrete or detailed GUI design work. The text
may
• Show window screen shots
• Discuss window navigation
• GUI widget manipulation etc
Example
…….
1) Administrator enters ID and password in dialog box
2) System authenticates Administrator
3) System displays “edit users” window.
2) Guideline: Write Terse Use Cases.
Terse use cases are written by deleting noise words.
Example: small changes like “ System Authenticates” than “The system authenticates”.
3) Guideline: Write Black Box Use Cases
Black box use cases are recommended because they do not describe internal workings of
the system, its components or design.
Here, in black box uses “what the system must do” (function requirement) is specified
rather than “how it will do”.
Black Box style Not
The system records the sale The system writes the sale to a database
Or
The system generates a SQL INSERT statement for sale..
4) Guideline: Take an Actor and Actor – Goal perspective
1) Write requirements that focus on users or actors of a system with their goals.
2) Focus on understanding what the actor considers a valuable result.
5) Guideline: How to find Use
Cases The procedure is
1) Choose the system boundary (software or hardware application)
2) Identify primary actors
3) Identify goals for each primary actor
4) Define use cases that satisfy user goals
Step 1: Choose system boundary
The boundary of the system. The external primary actors and supporting actors.
Step 2 and 3: Find Primary Actors and Goals.
• The following are some questions to find the Actors and Goals.
1) Who starts and stops the system?
2) Who does system administration?
3) Who evaluates system activity or performance?
4) Who evaluates log? Etc
• Organise Actors and Goals
 There are two approaches

1) After getting results, draw them in use case diagram, naming the goals as use
cases.
2) Write actor goal list, review and refine it then draw use case diagram
Sales Activity System
Actor Goal Actor Goals
Cashier Process sales Manager startup
Process rentals handle returns cash in cash out shutdown
• Ask about Actor Goals rather than use cases.
Finding actors and their goals helps us to identify use cases. Its better to ask.
“What are your goals whose results have measurable value?” that to ask “What do
you do?”
• Event Analysis – Another way to find Actors and Goals Identifying external events
helps to find use cases.
Example
External Event From Actor Goal/ Use Case
Enter sale line item Cashier Process a sale
Enter payment Cashier or Customer Process a sale
Step 4: Define use cases

• Define one use case for each user goal
• Start the name of use cases with a verb.
Example:
Goal – Process a sale
Use case – Process a sale
Another way
CRUD – Create, Retrieve, Update delete separate goals into on CRUD use case
Manage Users – Edit user
Delete User etc.
(6) Guideline: Tests that help to find useful use cases:
1) BOSS test
2) EBP test
3) The size test
BOSS test
The use cases that fail in BOSS test are at some low goal level.
It is not the desirable level of focus for requirements analysis.
Example:
BOSS asks “ what have you been doing all day?” Reply “ Logging in!”
If the boss is not happy then the use case fails in BOSS test.
BOSS test failing usecases need not be ignored.
User authentication may fail boss test but it is important and difficult.
EBP Test
Elementary business process.
It is defined as
“A task performed by one person in one place at one time, in response to a business
event., which adds measurable business value and leaves the data in a consistence state”.
Example: Approve credit or price order.
The EBP takes five or ten steps i.e., a task done during a single session.
The size test
A use case is not always a single step.

For example:
„Enter an item ID‟
Use case seem to be single line but consists of a series of steps.
Example:
Applying tests
1) Negotiate a supplier contract
Broader and longer than EBP.
Can be modeled as business use case than system use case.
2) Handle returns
Ok with boss test
Seems like EBP
Size is good
◦ Log In
Boss not happy so fails boss teat.
◦ Move price on game board 
Single step. So fails size test.
Applying UML: Use case Diagrams
• The names of use cases and actors
• The relationship between them are shown by UML diagrams.  A
use case diagram shows an excellent picture of system context.
Figure 1.14 Partial Use case context diagram
The context diagram in UML shows the boundary of a system that lies outside it.
The use case diagram is a communication tool that summarizes the behavior of a system
and its actors.
Guidelines
(1) The notation for actors Human
actors – stick figures
Computer system actors – actor box with single character bracket.
Example:

Figure 1.15 a) Notation of

actor Some prefer external computer system actors like.
Figure 1.16 b) Actor Notation

(2) Guide line
Keep the diagram short and simple.
An organization cannot spend too much time on writing use case.
Applying UML: Activity Diagrams
The UML has an activity diagram.
It is used to visualize work flows and business processes.
It also describes complex work flows and concurrent actions.
Benefits of Use cases
• Use cases are simple and widely understood.
• Use cases focus on key actors, their goals and common tasks.
Example:
Another example is “Monopoly Game”.
The typical use case in monopoly game is “Play Monopoly Game”.
Figure 1.17 Monopoly Game

The Use case Text is given by
Use case UC1 : Play Monopoly Game

Scope : Monopoly application
Level : User goal
Primary actor : Observer
Stakeholders and interest :
Observer : Wants to easily observe the output of the game simulation.
1) Observer requests new game initialization, enters number of players.
2) Observer starts play
3) System displays game trace for next player move. Repeat step 3 until a
winner or observer cancels.
Extensions:
*a. At any time, system fails:
1) Observer restarts system
2) System detects prior failure, reconstruct state and prompts to continue
3) Observer chooses to continue
Special requirements
Provide both graphical and text trace modes.
Additional Examples for use cases:
Figure 1.18 Use Case Diagram of a HelpDesk

This use case diagram shows the relationship among actors and use cases within a
system. Process: How to work with use cases in Iterative methods?
The use cases driven development includes
• Functional Requirements
• Use cases are part of iterative planning
• Design is driven by use cases
• Organization manuals influence use cases
• Functional or system testing deals with scenarios of use cases
• UI or shortcuts are created for common tasks.
Use Cases in Inception
During inception all the use cases are not written in fully dressed format.
Some of the use cases are identified according to magnitude, complexities.
Use Cases in Elaboration
In elaboration user goals are refined and 80 - 90% of use cases are written details.
Use case relationship
Links exist between actors and use cases. Several relationships exists between use cases
like:

1) Include
2) Use case generalization
3) Extend
Include
When we have a chunk of behavior that is similar across more than one use case and we
don‟t want to copy the description of the behavior.
Example:
Both analyze Risk and Price require to value the deal.
Instead of having a fair chunk of writing and copying it again, we can write a separate
value deal use case and refer it from the original use cases.
Use case generalization
When we have one use case that is similar to another use cases but does a bit more then
we use, case generalization.
Example:
The basic use case is capture deal.
One special case is when the limit is exceeded i.e., the maximum amount the trading
organization has established for a particular customer.
Extend
The third relationship called as extend is similar to generalization but with more rules to it.
The extending use case may add behavior to the use case, but it must declare certain
“extension points” and the extending use case may add additional behavior only at those extension
points.
Extend relationship
A use case may have many extension points and an extending use case may extend one or
more of these extension points.
Apply the following rules

Use include when you are repeating yourself in two or more separate use cases and you
want to avoid repetition.
Use generalization when you are describing a variation on normal behavior and you wish
to describe it casually.
Use extend when you are describing a variation on normal behavior and you wish to use the more
controlled form, declaring your extension points in your base use case.
Business and system Use cases
Two different use cases are there. They are
• System Use Case
• Business Use Case
A system use case is dealing with the interaction with the software. Business use case
discusses how a business responds to a customer or event.
Useage of Use Case
Most of the use case will be generate during the phase of the project but they will be
uncovered as we proceed the project.
Every use case is a potential requirement and, we can plan it only after we capture a
requirement.
Use cases represent an external view of the system.

1.7 RELATING USE CASES

Use cases can be related to each other.
Example:
Regular use cases like Process Sale. Process Rental can have subfunctions use case like
HandleCredit Payment.
Relationship among use cases
• Improves communication and comprehension of use cases
• Reduces duplication of text
• Improves management of use case document
Writing the use case text is highly essential. This improves comprehension and reduces
duplication.
Relationships
The common relationships present are
(i) include relationship
(ii) extend relationship and
(iii) generalize relationship
1.7.1 Include Relationship
• It is the common and important relationship
• The partial behavior is used in common among several use cases
Example
Paying by credit occurs in several use cases like Process Sale, Process Rental, Contribute
to Lay-away Plan etc.
Instead of duplicating the text, separate it into its own subfunction use case and indicate its
inclusion.
Guideline to use include relationship – Fowler
“Use include when you are repeating yourself in two or more separate use cases and you
want to avoid repetition”
Longer use cases can be decomposed into subunits to improve comprehension.
They include relationship is used when
• They are duplicated in other use cases
• A use case is very complex and long, and separating it into subunits aid
comprehension.
Example:
UC1 : Process Sale
..
Customer arrives at a POS Checkout with goods and/or services to purchase
……
Customer pays and system handles payment
.…….
Extensions:
7b. Paying by credit : Include Handle Credit Payment
7c. Paying by check : Include Handle Check Payment
UC7: Process Rental
……
6b. Paying by Credit : Include handle Credit Payment …….
The underlined functions are the include functions for highlighting The
subfunction “Handle Credit Payment” can be expanded as follows.

UC12 : Handle Credit Payment
…….
Level : Subfunction
1) Customer enters their credit account information
2) System send payment authorization request to an external Payment
Authorization Service System and request payment approval.
3) System receives payment approval and signals approval to Cashier.
4) ……
2a. System detects failure to collaborate with external system.
1) System signals error to cashier
2) Cashier asks customer for alternate payment
Another use of the include relationship is to describe the handling of asynchronous event
like.
• When user is able to select/branch to a particular function, window or webpage within
a range of steps.
Notations of include
◦ Basic notations use a*, b*,… style labels in the Extensions section.
◦ A range label such as 3 – 9 can be used for asynchronous event within relatively
large range if use case steps.
UC1: Process FooBars
Main Success Scenarios:

1……
Extensions:
a* Customer can edit personal information, at any time Edit Personal Information.
b* Customer selects printing help, at any time, Present Printing Help.
2 – 11, Customer cancels : Cancel Transaction Confirmation ……..
Technologies
1) Concrete use case
◦ It is initiated by an actor
◦ It performs the entire behavior desired by actor
Example:
Process
sale
2) Abstract use case
It is never instantiated by itself
It is a subfunction use case that is part of another use case
Example:
Handle credit payment
It does not stand on its own. Part of process sale
3) Base use case
A use case that includes another use case.
It is extended or specialized by another use case. Base use case are usually concrete.
Example:
Process sale is a base use case with represent to handle credit payment subfunction.
4) Additional use case
The use case that is an Inclusion Extension Specialization
Is called additional use case
Example:

Handle credit payment is addition use case in include relationship to process

sale. Additional use cases are abstract.
1.7.2 The Extend Relationship
The extends relationship is used when an use case is similar to another use case but does a
bit more.
Here for an use case – create an extending or addition use case and within it, describe
where and where and under what condition it extends the behavior of some basic use case.
Example:
UC 1: Process sale (Base use case)
…
Extension points: VIP customer, step1.Payment, step 7
Main Success Scenario:
1. Customer arrives at POS checkout with goods and/or services to

purchase
….
7. Customer pays and system handles payment
The base use case can be extended as
UC 15: Handle Gift certificate payment (the extending use case)
Trigger : customer wants to pay with gift certificate
Extension points: Payment in Process Sale
Leve l : Subfunction Main Success Scenario:
2. customer gives gift certificate to cashier
3. cashier enters gift certificate ID.
1. Customer arrives at POS checkout with goods and/or services to purchase

….
7. Customer pays and system handles payment
The extension points are labels in base use case.
The extending use case references as point of extension.
Some extension point may be
“At any point in use case X”.
Example:
In asynchronous events like word processor.
◦ Do a spell check now.
◦ Do a the saurus now.
The „include‟ relationship can also have been used but since „The process sale‟ use
case should not be modified, it is better to go with „extends‟ relationship.
Instead of creating complex use case relationships, updating “extensions” can be
done.
1.7.3 The Generailze Relationship
Generalization is the relationship between a more general class and a more specific class.
Example:
The vehicle class behaves as a generalized class that has sub class like Bus, Truck can.
Figure 1.20 Generalize relationship


Additional example
Figure 1.23 Use case diagram for interlibrary loan

The use case diagram above depicts the
• Extends
• includes
Relationships
The interlibrary loan is a special case of checking out books.
Entering into the systems is common for
• getting into the system is common for So all are included So all are included
1.8 WHEN TO USE: USE CASES DIAGRAMS
• Use cases are used in almost every project.
• They are helpful in exposing requirements and planning the project.
• During the initial stage of a project most use cases should be defined.

UNIT-2
STATIC UML DIAGRAMS
2.1 CLASS DIAGRAMS
The Essentials
A class diagram describes the types of objects in the system and the various kinds of static
relationship that exist among them.
There are 2 kinds of static relationships.
• Associations
• Subtypes
The class diagrams show the attributes and operations of a class and the constraints that
apply to the way objects are connected.
Perspectives
There are three different perspectives; we use in drawing class diagrams. They are
• Conceptual
• Specification
We take the concepts in the domain under study and represent in diagrams, for the
conceptual perspective.
These concepts will relate to the classes that implement them by there us often no direct
aping.
A conceptual model should be drawn with little or no regard to the software that
implements it, so it is considered language independent.

(b) Specification
Here we look at the interface of the software but not its implementation.
The word type is used to talk about an interface of a class.
A type can have many classes that implement it and a classes that implement it an a class
implement many types.
(c) Implementation
Here we have classes and we lat the implementation base.
This is the most often used perspective but un many cases the specification perspective is
better than implementation.
Classes are marked with << implementation class >> to show the implementation
perspective and with <<type>> for the specification and conceptual perspective.
2.2 ELABORATION
Elaboration has the following series of iterations.
1) The core (risky) software architecture is programmed and tested.
2) Majority of the requirements are discovered and stabilized.
3) Major rises are mitigated or retired.
Elaboration normally consists of two or three iterations.
During these iterations the team
• Does serious investigations
• Implements programs and tests for core architecture
• Clarifies requirements tackles high risk issues.
Each iteration is time boxed. i.e. its end date is fixed. It lasts for two to six weeks.
• During elaboration the models are fully developed in preparation for implementation.
• During elaboration, the code and design are in production. It is called “Executable
architecture” or “Architectural baseline”.
Elaboration is
• Building the core architecture
• Resolving the high risk elements
• Define more requirements and
Estimate overall schedule and resources
Domain model
• Visualization of domain concepts.
• It is similar to static information model.
Design model
It is a set of diagrams that describe logical design.
It includes
• Class diagrams
• Object interaction diagrams
• Package diagrams etc.
Software architecture documents
A summary of outstanding design ideas.
Summarizes key architecture issues and their resolution in design.
Data model
Includes database schemas, mapping strategies between object and non-object
representations.
Use case storyboards, UI prototypes.
Description of user interface.
Paths of navigation
Usability models etc.
2.2.1 Key Ideas of Elaboration

• Elaboration is not more than few months

• Has short timeboxed iterations
• Has realistic tests early
• Adapt according to the feedback of users
• Most of the use cases and other requirements are written in detail, through a series of
workshops.
2.3 DOMAIN MODELS

A domain model is a visual representation of conceptual classes or real situation objects in
a domain.
In object oriented analysis, domain model is the most important.
It illustrates the concepts in a domain.
It acts as a source of inspiration for designing some software objects.
2.3.1 Example
A partial domain model for a visual dictionary is drawn with UML class diagram. The
conceptual classes of
• Payment and
• Sale
are shown
The payment is related to sale.
Sale has date and time information.
The conceptual perspective can be had by applying UML class diagram notation for
domain model.
Domain models are also called as conceptual models.

Domain models are illustrated with a set of class diagrams
• Domain objects or conceptual classes
• Association between conceptual classes

• Attributes of conceptual classes

In the above example if all the information were expressed in plain text it is not easy
to understand and hence we go for visual representations.
So the domain model is a visual dictionary of abstractions, domain vocabulary and
information content of the domain.
• A domain model shows real-situation conceptual classes and not software classes.
[such as Java or C++ classes]
• So a domain model should probably avoid
◦ Software artifacts like window or database
◦ Methods and responsibilities.
2.3.2 Conceptual classes

A conceptual class may not considered in terms of
1) Symbol – words or images
2) Intension – definition of conceptual class
3) Extension – set of examples to conceptual class
Example: Purchase transaction event
Symbol – sale (English)
Intension – Represents events of purchase transaction, having date and
time Extension – set of all sale instances in the universe.
A conceptual class
Figure 2.4 A domain model is not a data model

2.3.3 Creation of Domain Model

The steps for creating a domain model are
(i) Find the conceptual classes
(ii) Draw them as classes in UML class diagram
(iii) Add associations and attributes
2.4 FINDING CONCEPTUAL CLASSES AND DESCRIPTION CLASSES
2.4.1 Finding Conceptual Classes
The three strategies to find conceptual classes are
1) Reuse or modify existing models
2) Use a category list
3) Identity noun phrases
2.4.1.1 Reuse or Modify Existing Models
• It is the easiest approach
• There are published and well known domain models and data models like
◦ Inventory
◦ Finance
◦ Health
These can be modified into domain model
2.4.1.2 Use a Category List
Some of the common categories found in
1) POS
2) Monopoly and
3) Airline reservation are listed below
are listed below
Conceptual class category Examples
Business transactions
1. Guideline: They are critical Sale, payment reservation
Transaction line itemsGuideline:
Transaction come with related line
2. items SalesLineItem
Product or service relate to a
3. transaction or transaction line item Item flight, seat, meal
4. Where is transaction recorded? Register, ledger
5. Roles of people; actors in usecase Cashier, customer, passenger
6. Place of transaction Store, airport
7. Events with time or place to remember Sale, payment
8. Physical objects Item, Register, Airplane
9. Description of things ProductDescription, FlightDescription
10. Catalogs ProductCatalog, FlightCatalog
11. Containers of things Store, Bin, Board, Airplane
12. Things in container Item, Square
13. Collaborating systems Air Traffic Control
Records of finance, work, contracts,
14. legal matters Receipt, Ledger
Cash, Check, Line of credit,
15. Financial Instruments TicketCredit
Schedules, manuals, documents referred
16. regularly DailyPriceChangeList, RepairSchedule

2.4.1.3 Noun Phrase Identification

Linguistic analysis
Indentify the nouns and noun phrases in textual description of a domain.
Example:
Process Sale
Main success scenario (or Basic Flow)
1) Customer arrives at a POS checkout with goods
2) Cashier starts a new sale
3) Cashier enters item identifier
4) System records SaleLineItem
Presents item description, price and running total
Price calculated from a set price rules.
5) System presents total with taxes and asks for payment
6) Cashier tells customer the total and asks for payment
7) Customer pays and system handles payment
8) System logs completed sale and sends sale and payment to external accounting
9) System presents receipt
10) Customer leaves with receipt and goods
Extensions
7.a. Paying by cash
1) Cashier enters amount
2) System presents balance
3) Cashier deposits cash and returns balance
4) System, records cash payment
Some noun phrases are candidate conceptual classes. Some refer to simple
attributes of conceptual class.
The disadvantage of this approach is – Different noun phrases may represent same
conceptual class or attributes among ambiguities.
2.4.1.4 Examples
POS Domain
A list of candidate classes for the domain is generated.
The list consists of requirements and simplifications of process sale.
Sale Cashier
Cash payment Customer
SalesLineItem Store
Item ProductDescription
Register ProductCatalog
Ledger
Then, construct the UML class diagram for the above classes.
Figure 2.5 Initial POS Domian Model

Then we add attributes and associations.
Monopoly Domain

The list of candidate classes for Monopoly domain are

Player
Piece
Die
Board
Square
The representation of these classes are
Figure 2.6 Initial Monopoly Domain Model

2.4.2 Finding Description Classes
A description class is a class that contains information that describes something.
Example:
ProductDescription is a description class that records
◦ Picture
◦ Price and
◦ Text description
2.4.2.1 Need for description classes
Consider a store where
• An item is a physical item
• An item has serial no, cost, description, price, itemID etc.
• After selling the item, all these information are lost as the software instance of item is
deleted.
Example:
If a store has „Reynolds‟ pen and in a demand the pen is sold and its instance is
lost. If a customer asks
„What is the cost of Reynolds Pen‟
No one can answer because the price of the item is lost, once it is sold.
We also cannot have a duplicate instance of all objects because it causes inefficiency
and wastage of memory.
So the solution is to have a „description class‟. For example, here we have got
ProductDescription class.
Here ProductDescription would have the price, description of the item, but not the
serialNo which is irrelevant.
The ProductDescription class is represented by
Description classes are used when

• Need for description of item, or service required

• Deleting instance of item, leads to loss of information
• Reduces redundancy and duplication
Examples
1) Airline company
After a plane crash, all flights were cancelled for six months.
So flight instance software is deleted and all information about the flight services were
lost.
So here the description classes must have details on flight services.
So flight description has flight route even if flight is not scheduled.
2) Mobile phone company

It has packages like “gold”, “silver”, “bronze”. Here description classes contains
information about the package like
◦ Rates per minute
◦ Cost etc…
2.5 ASSOCIATION
An association is a relationship between classes that indicate meaningful and interesting
connection.
It is represented as a solid line connecting two class symbols.
Example
Figure 2.9 Association
Here the association “works for” connects two roles – employee and employer.
A person is an employee of a company and company is an employer of person.
2.5.1 Definition
An association is defined as “Semantic relationship between two or more classifiers that
involve connections among their instances”.

Avoid too many associations to a domain model.

Example:
A graph with „n‟ nodes can have (n(n-1))/2 associations to other nodes. i.e. 20 classes
will have 190 association lines.
So avoid the unnecessary associations.
An association is not statement about data flows during domain modeling.
2.5.2 Association Notation
Binary association is solid line connecting two class symbols with capitalized association
name. The ends of association contains multiplicity expression i.e., numerical instances of the classes.
Example:
Legal formats of compound association name.
• Work-for
• Work for
Each end of associations is called role.
Roles may optionally have
• Multiplicity expression
• Name
• Navigability
2.5.3 Multiplicity
Multiplicity defines how many instances of a class A can be associated with the instance
of class B
2.5.4 Multiplicity values
The multiplicity value depends on the modeler or software developer.

2.5.5 Navigation
UML uses association navigation or navigability to specify a role affiliated with each
other at the end of association line.
Figure 2.13 Navigation

An optional reading direction arrow indicates direction to read association name.

Here it means association from person to BankAccount (person has BankAccount) and not the
reverse. The convention is to read association from left to right and top to bottom.
2.5.6 Multiple associations between two classes

Two classes may have multiple (more than one) associations between them.
Example:
Airline system
Figure 2.14 Multiple Associations

2.5.7 Common associations list
1) POS 2) Monopoly 3) Airline reservation domains
Category Examples
A is a transaction related to another CashPayment – sale cancellation –
transaction B reservation
A is a line item of a transaction B SalesLineItem – Sale
A is a product or service for a transaction (or Item – SalesLineItem Flight –
line item) B reservation
A is a role related to a transaction B Customer- PaymentPassenger- Ticket
A is physical or logical part of B Drawer – RegisterSquare – BoardSeat–
Airplane
A is physically or logically contained in/on B Register – storeItem – shelfPassenger–
Airplane
A is a description of B ProductDescription- ItemFlightDescription –
Flight
A is Sale – RegisterPiece – Square
known/logged/recorded/reported/captured/in B
A is a member of B Cashier – storePlayer – monopoly
gamePilot – Airline
A is an organizational subunit of B Department- StoreMaintenance- Airline
A uses or manages or owns Cashier – RegisterPlayer – PiecePilot-
Airplane
A is next to B SalesLineItem – SalesLineItemSquare–
SquareCity – City
2.5.8 Examples – Associations in Domain Models:

CaseStudy:
(i) NextGenPOS:
In POS the association are given as
1) Transaction related to another
transaction: Sale paid – by CashPayment
2) Line items of transaction – Sale contains SalesLineItem
3) Product for transaction – SalesLineItem records – sale-of-item

(ii) Monopoly
The associations are
1) A is contained in or on B – Board contains square
2) A owns B – Players own piece
3) A is known in/on B – Piece Is-on square
4) A is member of B – Player member-of monopoly game
Figure 2.16 Monopoly partial Domain Model

2.5.9 Association
• Associations represents relationship between instances of classes. [A person works for
a company; a company has a number of offices]
• The associations represent conceptual relationship between classes.
• Each association has two association ends, each end is attached to one of the classes in
the association. An end can be explicitly named with a label. This label is called a role
name. Association ends are often called roles.

• An association end also has multiplicity which is an indication of how many elements
participate in the given relationship.
• Multiplicity indicates lower and upper bounds for the participating objects.
• The * represents the range 0…. Infinity.
• The 1 stands for 1…..1
• The most common multiplicaties are 1, * and 0…1.
• For general multiplicity we can have a single number (11 for players in crickets team)
a range (such as 2….4 for players of canasta game)
or discrete combinations of numbers and ranges (such as 2,4 for doors in a car before
the onset of minivans)
Within the specification perspective, associations represent responsibilities.
• In the specification perspective, associations represent responsibilities.
• Single valued relationship are implemented with a method that returns the related
objects.
• Multivalued relationship are implemented with an iterate into a collection of related
objects.
• An association implies some responsibility for updating the relationship.
• In implementation model there is pointer in both directions between related classes.
• Example: Association between order and customer. Arrows are indicated on the
association lines. They indicate navigability.
• Here order has a responsibility to tell which customer it is for, but a customer has no
corresponding ability to tell which orders it has. Here instead of symmetric
responsibilities, we now have responsibilities on only one end of the line.
• But in implementation diagram, order contains a pointer to the customer but customer
would not have a pointer to order.
• Navigability is an important part of implementation and specification diagrams.
• Navigability‟s are added as part of the shift to the specification and implementation
perspective.
• If navigability exists in only one direction, we call the associations as unidirectional
association.
• A bidirectional association contains navigability‟s in both direction.
• In UML, if the associations are without arrows it means the navigability is unknown
or the association is bidirectional.
• Bidirectional associations include an extra constraint, that the two navigations are
inverses of each other.
2.5.10 Naming Associations
There are many ways of naming associations. Traditional data modules like to name an
association using a verb phrase, so that the relationship can be used in a sentence. In object
modelers nouns are used to name the role of one or the other of the ends. An association
represents a permanent link between two objects. The link exists during the whole lives of the
objects, although the instances that are connected may change over time. So a parameters
reference creation of an object, doesn‟t imply an association. They are modeled with
dependencies.

2.6 ATTRIBUTES
• Attributes are very similar to associations.
• At conceptual level, an attribute customer‟s name indicates that customer have names.
• At specification level, the attributes name indicates the customer name and has a way
of selecting a name.
At the implementation level, a customer has a field ( an instance variable or a data
member) for its name.
The notation for an attribute shows the attributes name, type and default value.
The UML syntax is
Visibility name : type = defaultValue
where visibility is the same as for operations.
2.6.1 Difference between Attribute and Association:
• From conceptual perspective, there is no difference between attribute and association.
• An attribute carries another kind of notation.
• Attributes are usually single valued.
• From the diagram we cannot infer whether the attribute is optional or mandatory.
• Multiplicity is put after the attribute name in square
brackets Example: dateReceived [0….1]: Date
The difference occurs at the specification and implementation levels.
Attributes are small, simple classes such as strings, dates, money objects and non
object values such as int and real.

2.6.2 Operations
The processes carried out but a class are called operations.
At specification level, operation correspond to public methods on a type. We have to
indicate whether the object is read only or frozen.
At implementation model, we have to show private and protected operations.
2.6.3 UML syntax for operations
Visibility name (parameter_list) : return _type_ expression
{property_string} Where,
Visibility is + (public), # (protected) or – (private)
name is a string
Parameter list contains comma separated parameters.
Whose syntax is
Direction name: type = default value
Direction shows whether parameter used for input (in), output (out) or both (inout).
By default the direction value is in.
Return type expression is a comma- separated list of return types. Most people use single
return type but multiple return types are also allowed.
UML defines a query as an operation that gets a value from a class without changing the
system state. Such operations are marked with constraint {query}
Operations that do change state are called modifier.
Queries can be executed in any order but sequence of modifiers is more important Other
terms are
 getting method
 setting method
 A getting method returns a value from a field.
 A setting method puts a value into a field.
 A client from outside should not tell whether
A query is getting method or a modifier is a setting method knowledge of getting and
setting method is entirely internal to the class.
Other distribution is between operation and method.
An operation is something that is invoked on an object [procedure call] A method is the
body of the procedure.
In C++, operation are called „member function‟
Smalltalk calls operation as „methods‟
UML uses the term „feature‟ for an attribute or an operation.
2.6.4 Attributes
An attributes is a logical data value of an object. Attributes of conceptual classes are
identified to satisfy information requirements of current scenarios under development.
Example:
A receipt in processSale includes dateTime. So,
• Sale requires „dateTime‟ attribute
• Store requires „name‟ and „address‟
• Cashier requires an „ID‟
2.6.5 Notation
In the class representation, Attributes are shown in the second compartment.
Example:
Figure 2.18 Attributes

The types of attribute is optional.
Figure 2.19 Derived Attribute

2.6.6 Syntax
The syntax of attribute in UML is
visibility name : type multiplicity = default {property-string}
Examples
1)
2)
3)
Conventionally, all attributes have private visibility.

{read only} – Property of string for attributes
[0..1] - Optional multiplicity values 0 or 1
2.6.7 Derived Attributes
If an attribute is derived from some other information it is called derived attribute.
Example:
Total attribute in Sale is calculated or derived from „SalesLineItem‟.
Quantity calculated from actual multiplicity value of the association.
Figure 2.21 Derived attributes

2.6.8 Datatype Attribute in Domain Model

Most of the attributes types are primitive datatype like
• Numbers
• Booleans
• Characters
• Date(or DateTime)
• Time
• String(Text)
Other common types are
• Address
• Color
• Geometrics
• Phone number
• ZIP or postal code
• Enumerated datatypes and so on.
• In place of complex concepts, associations is used instead of attributes.
is replaced by
Figure 2.22 Relate with associations not attributes

2.6.9 Guidelines for Modeling Datatypes
In a domain model an attribute which may be initially considered as a number or string
may be assigned a new datatype in conditions like the following
1) Data is composed of separate sections
Phone no – Mobile, Landline, Office
Name of person – First Name, Middle Name, Last Name
2) There are operations associated with it like
validation SSN – Social Security Number
3) It has other attributes
Price of promotion can have start-date and end-date
4) It is a quantity with a unit
Payment amount has unit of currency
5) Abstraction of one or more types with some
quantities. ItemIdentifier is a generalization of
Universal Product Code (UPC)
European Article Number (EAN)
Applying the guidelines to POS domain attributes
1) „Item‟ is having common coding schemes
like UPC – A
UPC – E
EAN etc
These schemes have manufacturer, Product, Check-sum digit etc So datatype ItemID
class may be present.

2) „Price‟ and „amount‟ attributes will be of type „money‟ because they refer to currency.
3) The address attribute should be of type „Address‟ because it has got three separate sections.
Foreign keys (like relational databases) can be expressed with associations, instead of
attributes.
Example:
If the „cashier‟ class has a „current Register No‟ attribute it relates cashier to Register
object.
Here association can be used to relate cashier to Register object
There are quantities with associated units.

Example:
Money is a quantity with „currencies‟ as units.
Weight is a quantity with „kilograms‟ or „pounds‟ as units

2.6.10 Example: Attributes in Domain Model

Case Study 1:
1) NextGenPOS:
Class Attributes Description

CashPayment Amount Tendered Determines if sufficient payment is done
ProductDescription Description Shows description display or receipt looks up
itemID Looks up
ProductDescription
Calculates salestotal. Shows
price lineitemprice
Sale dateTime Shows date and time of sale
Useful for sales analysis
SalesLineItem Quantity Records quantity entered
Store Address, name Name and address of store

2) Case Study 2:
Monopoly game
Class Attributes Description
Die faceValue After rolling die, calculate distance of move
Square Name Print output desired
Player Name Name of player
Piece Name Name of piece
Figure 2.27 Monopoly Partial Domain Model

2.7 DOMAIN MODEL REFINEMENT
In the domain model refinement the fundamental concepts are
(i) Generalization
(ii) Specialization and
(iii) Conceptual class hierarchies
2.8 FINDING CONCEPTUAL CLASS HIERARCHIES
Generalization has to be understand to identify conceptual super and subclasses.
Generalization and conceptual class definition:
Definition:
A conceptual superclass is more general or encompassing than subclass
Example:
Superclass – Payment
Subclasses – CashPayment
Credit Payment
CheckPayment
Representation
Figure 2.28 Class Hierarchies

Here cash payment is transferring money from one party to another.
Credit payment is transfer of money via credit institution which to be authorized.
2.8.1 Generalization and class sets
All members of a conceptual subclass set are members of their superclass set.

Example:
In terms of set membership, all instances of set „CreditPayment‟ are also members of set
„Payment‟.
2.8.2 Conceptual subclass Definition conformance

During creation of class hierarchy, statements about superclass that apply to subclass are
made.
Example:
All „payments‟ have an attribute „amount‟ which are associated with „Sale‟.
2.9 AGGREGATION AND COMPOSITION
Aggregation is a form of association.
A hollow diamond is attached to the end of the path to indicate aggregation.
Figure 2.30 Aggregation

Composition (or a part of) is a form of aggregation.
It shows string ownership to represent the component of complex object.
Composition is also called as part whole relationship.
Composition is denoted as solid diamond at the end of the path.
A composition relationship implies that
1) An instance of the part (like square) belongs to only one composite instance (such
as board) at a time.
2) The part must always belongs to composite.
3) The composition is responsible for creation and deletion of its parts.

2.9.1 Guidelines for composition

• The life time of a part is bound within the lifetime of its composite.
• There is obvious whole-part physical or logical assembly.
• Composition sometimes refers to
• Operations like destruction, movement, recording parts such as location.
Benefits of composition
Composition is very useful in design than analysis.
1) Composition classifies domain constraint for the existence of the part independent of the
whole.
2) It assists in identification of creator using GRASP.
3) Operations like copy, delete apply to parts.
Composition in NextGen Domain Model
In POS domain
(i) SalesLineItem is a part of composite sale
(ii) ProductCatalog is a composite of ProductDescription
Figure 2.32
2.10 RELATIONSHIP BETWEEN SSD AND USE CASES
SSD shows systems events for one scenario of a use case.
The SSD is generated from inspection of a use case.
SSDs are derived from use cases.
Figure 2.33

While naming the system events, use the abstract level of representation rather than
physical input device.
Example:
“enterItem” is better than “Scan”.
Because the entry could be through scanner, keyboard, voice input or anything.
a verb like
• add…
• enter…
• end…
• make…
to improve clarity
SSDs are also used to collaborate between systems.
Example:
NextGenPOS and external credit payment authorizer.
The elements of SSD are
• operation name
• parameters
• return data
Glossary is used to maintain the information of what is coming in and what is going out
during design.
Example 1:
In the previous diagram, the return line has the description “change due, receipt”.
Here glossary has a receipt entry and shows receipt (digital picture) and layouts and
contents.
Example 2:
:Observer :System
initialize(num of players)
Play Game
Loop [no winner]
dicetotal, player, squrae
Figure 2.35 the SSD for Monopoly game

Here the events are

1) Observing person initializes number of players
2) He then request simulation of play
3) The output is watched until there is a winner.
SSDs are highly useful
• To understand the interface
• Collaborations of existing systems
• To document the architecture.
Normally it is not advisable to create SSDs for all scenarios.
SSDs can be drawn for scenarios of next iteration.
SSDs are part of the Use Case Model.
SSDs are used to represent analysis and design artifacts.
SSDs are not normally motivated during inception. They are created during
elaboration.
Their purpose is to
1) Identify details of system events
2) Clarify major operations the system is designed to handle
3) Write system operation contracts
4) Support estimation
(Example: Macro estimation with unadjusted function points and cocomo II)
2.11 WHEN TO USE CLASS DIAGRAMS
2.11.1 Class Diagrams
The Essentials
A class diagram describes the types of objects in the system and the various kinds of static
relationship that exist among them.
There are 2 kinds of static relationships.
• Associations
• Subtypes
The class diagrams show the attributes and operations of a class and the constraints that
apply to the way objects are connected.
Perspectives
There are three different perspectives; we use in drawing class diagrams. They are
• Conceptual
• Specification
We take the concepts in the domain under study and represent in diagrams, for the
conceptual perspective.
These concepts will relate to the classes that implement them by there us often no direct
aping.
A conceptual model should be drawn with little or no regard to the software that
implements it, so it is considered language independent.
Specification
Here we look at the interface of the software but not its implementation.
The word type is used to talk about an interface of a class.
A type can have many classes that implement it and a classes that implement it an a class
implement many types.


Implementation
Here we have classes and we lat the implementation base.
This is the most often used perspective but un many cases the specification perspective is
better than implementation.
Classes are marked with << implementation class >> to show the implementation
perspective and with <<type>> for the specification and conceptual perspective

UNIT-3
DYNAMIC AND IMPLEMENTATION UML DIAGRAMS
3.1 DYNAMIC DIAGRAMS
3.1.1 Interaction Diagrams
The main idea in developing interaction diagram is simplicity.
But interaction diagrams lose clarity with conditional behavior.
To capture complex behavior in a single diagram, we can go for activity diagrams.
Interaction diagrams are models that describe how groups of objects collaborate in some
behavior. There are two kinds of interaction diagrams
• Sequence diagrams
• Collaboration diagrams
3.1.2 Sequence Diagram
An object is shown as a box at the top of a dashed vertical line.
This vertical line is called objects life line. The life line represents objects life during
interaction.
This was given by Jacobson
Each message is represented by an arrow between the life lines of two objects.
The order of messages occur from top to bottom of the page.
Message contains message name, arguments and some control information.
Self call – is an message that an object sends to itself by sending message arrow back to
the same life line.
Two control information are valuable.

1) There is a condition which indicates when a message is sent only if condition is true.
QUEEN MARY VIDYA.M /ASST. PROF-CSE DEPT

2) Next is the iteration maker, which shows that a message is sent many times to
multiple receiver objects Basics of the iteration are shown within brackets *[for all
order lines]
◦ A return can be included to indicate the return from a message, not a new message.
◦ Return is indicated by dashed line.
Sequence diagrams are also valuable for concurrent processes.
At the creation of transaction, a Transaction coordinator is created. This coordinator

creates transaction checker objects which is responsible for a particular check.
Different checking processes are added. Each checker is called asynchronously and
proceeds in parallel.
When transaction checker completes, it informs transaction coordinator. After all checkers
are completed the coordinator notifies the transaction that all is well.
The half arrow heads indicate asynchronous message. It does not block the caller but
carries its own processing. It does one of the following things.
1) Create a new thread, in which case it links to the top of an activation.
2) Create a new objects
3) Communicate with a thread that is already running.
Object deletion is shown with a large X.
Objects can self destruct or they can be destroyed by another message.
A sequence diagram shown an interaction arranged in a time sequence.
It shows the objects participating in interaction by their life lines and the messages they
exchange, arranged in a time sequence.

Diagram A sequence diagram has 2 dimensions
1) Vertical dimension represents time [Lifetime]

2) Horizontal dimension represents different objects
We can look at the sequence diagram and understand the overall control flow of a
program.
3.1.3 Collaboration Diagram
A collaboration diagram represents a collaboration which is a set of objects related to
achieve a desired outcome.
In collaboration, the sequence is indicated by numbering the messages several numbering
schemes are available.
With Simple Numbering
COLLABORATION DIAGRAM
With Decimal Numbering

It is the second form of interaction diagrams.

Here in collaboration diagrams, we number the messages and indicates their sequences.
Several numbering schemes are used for collaboration diagrams.
1) Simple Numbering scheme [used in past]
2) Decimal Numbering scheme [used in UML]
The same kind of information are added regardless of what numbering systems used.
3.1.3.1 Comparing Sequence and Collaboration Diagrams
The principal feature of the interaction diagram is their simplicity.
Sequence diagram puts emphasis on sequence. It is easy to see the order in which the
things occur.
Collaboration diagram uses the layout to indicate how objects are statically connected.
3.1.4 When to use Communication Diagram
communication diagrams show the message flow between objects in an OO application
and also imply the basic associations (relationships) between classes. Figure 1 presents a

simplified collaboration diagram for displaying a seminar details screen or page. The rectangles
represent the various objects involved that make up the application. The lines between the classes
represent the relationships (associations, composition, dependencies, or inheritance) between
them. The same notation for classes and objects used on UML sequence diagrams are used on
UML communication diagrams, another example of the consistency of the UML. The details of
your associations, such as their multiplicities, are not modeled because this information is
contained on your UML class diagrams: remember, each UML diagram has its own specific
purpose and no single diagram is sufficient on its own. Messages are depicted as a labeled arrow
that indicates the direction of the message, using a notation similar to that used on sequence
diagrams
3.1.5 State Machine Diagrams and Modelling

A state machine diagram models the behaviour of a single object, specifying the sequence
of events that an object goes through during its lifetime in response to events. As an example, the
following state machine diagram shows the states that a door goes through during its lifetime.
Figure 3.7

The door can be in one of three states: "Opened", "Closed" or "Locked". It can respond to
the events Open, Close, Lock and Unlock. Notice that not all events are valid in all states; for
example, if a door is opened, you cannot lock it until you close it. Also notice that a state
transition can have a guard condition attached: if the door is Opened, it can only respond to the
Close event if the condition doorWay->isEmpty is fulfilled. The syntax and conventions used in
state machine diagrams will be discussed in full in the following sections.
States
A state is denoted by a round-cornered rectangle with the name of the state written inside
it.
Initial and Final States

The initial state is denoted by a filled black circle and may be labeled with a name. The
final state is denoted by a circle with a dot inside and may also be labeled with a name.
Figure 3.8
Transitions
Transitions from one state to the next are denoted by lines with arrowheads. A transition
may have a trigger, a guard and an effect, as below.
Figure 3.9
3.1.6 When to Use State Diagrams
3.1.6.1 Statechart Diagram
A statechart diagram (sate diagram) shows the sequence of states that an object goes
through during its life in response to outside stimuli and messages.
A state is represented as a rounded box which contains one or more compartments.
The name compartment holds the optional name of the state. States without names are
anonymous.
The internal transition compartment holds a list of internal actions or activities performed
in response while the object is in the state, without changing states.
Syntax: Event.name Argument List/Action. Expression
Example: help/display help

3.1.6.2 State Diagram
Figure 3.10
A complex transition
Figure 3.11
State diagrams describe all the possible states that a particular object can get into and how
the objects state changes as a result of events that reach the object. They describe the behavior of a
system.
We begin at start point.
An initial transition called as “/getfirstitem”. Leads to the checking state.
Syntax for transition label
Event[Guard]/Action
All are optional. In this case we have the action “get first item”
Checking state has an activity associated with it do/checkitem.
Syntax: do/activity
Action for transaction and Activity for the state.
UML state diagram for an order in the order processing system.
Actions
Actions are associated with transitions. They are the processes that occur quickly and are
not interruptible.
For a real time system “quickly” may be within s few machine instruction.
For regular information systems, “quickly” means less than few seconds.
Activity
Activities are associated with states and can take longer. An activity may be interrupted by
some event.
When no events are there in the transaction label, transition occurs as soon as any activity
associated with the given state is completed.
Here after completing checking state, there transitions come out. All the three have only
guards on their label.
Guard
A guard is a logical condition that will return only “true” or “false”. A guarded transition
only if the guard resolves to “true”.

One transition is taken out of given state, so the guards are mutually exclusive for any
event. We got 3 conditions.
1) If we have not checked all items. We get the next item and return to checking state.
2) If we have checked all items and were all in stock, we transition to dispatching state.
3) If we have checked all items but not all of them in the stock, we transition to the
waiting state.
Waiting State
Then we have waiting state. There are no activities for this state.
Two transactions are out of waiting state labeled ItemReceived event.
From the waiting state, guards on the transitions are evaluated and appropriate transitions
are made either to Dispatching or back to waiting.
Dispatching State
From dispatching state, an activity initiates delivery. There is alos a single unguarded
transition triggered by delivered event.
Once the “initiate delivery” activity is finished, given order remains in the Dispatching
state until delivered event occurs.
The final thing is the transition called “cancelled” we ant to cancel at any point. We cab
draw separate transition from checking, waiting and dispatching. Alternative is to create a
superstate of all 3 states and draw single transition from that.
Substates inherit any transition on super state.
State Diagram With Super states

There are a couple of other types of events in addition to named events from outside.
An event generated after a period of time. This is indicated with the keyword “after”.
Example: We say after (20 minutes)
An event can be generated when condition becomes true. Keyword is “when”
Example: when (temperature > 120 degrees)
Special Events
The special events are entry and exit
An entry event is executed whenever the given state is entered fro transaction.
An exit state is executed whenever the state is lift via a transition.
If the transition goes back to the same state with an action, exit is executed first, then
transition action and finally entry action. Such transition is called self transition.
Concurrent State Diagrams
Concurrent state diagrams are useful when an object has sets of independent behaviors.
If several complicated concurrent state diagrams are there for an objects, then split the
objects into separate objects.
Payment Authorization
Here we begin by doing authorization. Check payment “activity finishes and approves
payment.
If payment is “OK”, order waits in Authorized state until “deliver” event occurs.
Otherwise order enters Rejected state.
Concurrent State Diagram
Figure 3.15
The associated states and the cancelled states are combined on a concurrent state diagram.

In concurrent sections of state diagrams, the given order is in 2 different states.

If “check payment” activity of the Authorizing state completes successfully, the order will
be in checking and Authorized states.
If “cancel” event occurs, the order will be in cancelled state.
When to Use state diagrams
State diagrams are good at describing the behavior of an object across several use cases.
State diagrams can be used for classes that exhibit interesting behavior.
Building state diagrams helps to understand what is going on.
3.1.6.3 UML Activity Diagrams
An activity diagram is a variation or special case of a state machine, in which the states
are activities representing the performance of operations and the transitions are triggered by the
completion of operations.
Activity diagram is similar to state chart diagram where a token represented an operation.
An activity is shown as a round box, containing name of operation.
Concurrent control is indicated by multiple arrows leaving a synchronization bar,
represented by short thick bar with incoming and outcoming arrows.
Activity diagram shows internal state of object but external events ay also appear. The two
possible states in activity diagram are wait state and activity state.
3.1.7 Activity Diagrams

Activity diagram represents the performance of operations and transitions are triggered by
Activity diagram shows control flow and data flow.
The business processes are very complex and hence it is better to represent them in
pictures rather than text.

Activity diagrams are highly are highly useful for these purpose.
Data Flow Modeling

Data Flow Diagrams (DFD) are used to visualize the major steps and data involved in
software system processes. DFDS were used to document the data flows.
In Gane-Sarson notation of DFD the process steps are numbered to indicate order.
UML does not have DFD notations.

The DFD is replaced by activity diagrams in UML.
In addition to the object nodes the UML activity diagram includes „datastore‟ node for the
above example.

Action may be organized into swim lanes each separated from its neighboring swim lanes by
vertical solid lines on both sides.
3.1.7.1 Guidelines
1) Activity diagrams are used for complex processes.
2) In Business process modeling used „rake‟ notation and sub activity diagrams.
Level 0 – very high level of abstraction
Level 1 – expand the details
Level 2 – more expansion and so on
3) Levels of abstraction must roughly be equal within a diagram.
Example
The „Process Sale‟ usecase is shown as an Activity diagram

Activity diagrams are applicable within the business modeling discipline of UP.
3.1.7.2 Advanced Activity Diagrams
Activity diagrams are useful in connection with workflow and in describing behavior that
has a lot parallel processing.
The core symbol is “Activity state” or “Activity”.
Activity is a state of doing something
• Either real world process [Example: type a letter]
• Or execution of software runtime [Example: method on a class]
Activity diagram describes sequencing of activities, with support for conditional and
parallel behavior.
Activity diagram is a variant of state diagram in which states are activity states.
Much of the terminology follows state diagrams Conditional behavior is given
by
• Branch
• Merge
(a) Branch
• It has single incoming transition and several guarded outgoing transition.
• Only one of the outgoing transitions can be taken. So guards are mutually exclusive.
• [else] is a guard, „else‟ transition should be used if all other.
• In the example, after an order is filled, there is a branch.
◦ If the order is rush, do an overnight delivery.
◦ If the order is regular, do a regular delivery.

UNIT-4 - DESIGN PATTERNS

4.1 GRASP DESIGNING OBJECTS WITH RESPONSIBILITIES
4.1.1 Introduction
After the requirements identification, add the methods to the classes and define the
messages between the objects.
The designing of object starts with
• Inputs
• Activities and
• Outputs
(i) GRASP  General Responsibility Assignment Software Patterns
(ii) GOF  Gang of Four
(iii) RDD  Responsibility Driven Design
GRASP
The GRASP is a tool that helps to master the basics of OOD and understanding
responsibilities.
GRASP is a learning aid that helps to understand the essential object design and apply the
design in a methodical, rotational and explainable way.
RDD
RDD is a general metaphor for thinking about object oriented design.
The responsibilities include
• Doing responsibility  creating action, initializing, controlling and coordinating
activities
• Knowing responsibilities  includes knowing about private and related data.
4.1.2 Applying Grasp To Object Design

GRASP stands for ―General Responsibility Assignment Software Patterns‖.
It means low grasping of these principles to successfully design object oriented software.
While coding or drawing interaction and class diagrams, developers apply the ideas
behind GRASP to master the principles of object oriented design.
There are nine different GRASP patterns:
(i) Creator
(ii) Information expert
(iii) Low coupling
(iv) Controller
(v) High cohesion
(vi) Polymorphism
(vii) Pure fabrication
(viii) Indirection
(ix) Protected variations
Out of the nine the first five are dealt in detail.
4.2 CREATOR
Problem
One of the most common activities in object oriented system is creation of objects.
General principle is applied for the assignment of creation responsibilities.
Design supports
• Low coupling
• Increased clarity
QUEEN MARY VIDYA.M/ ASST.PROF-CSE DEPT

• Encapsulation
• Reusability
Solution
If B is a creator of A objects then atleast one of the following must be true.
• B contains A
• B compositely aggregates A
• B records A
• B closely uses A
• B is an expert while creating A (B passes the initializing data for A that is passed to A
when created).
If more than one option is true.
Class B aggregates or contains class A.
Example
NEXTGen POS Application
We have to find who is the creator of SalesLineItem instance.
Consider the partial domain model of SaleLineItem.
Here ‗Sale‘ takes the responsibility of creating ‗SalesLineItem‘ instance. Since sale
contains many ‗SalesLineItem‘ objects.
While assigning responsibilities ‗makeLineitem‘ must also be defined in ‗Sale‘.
The creator pattern finds a creator that needs to be connected to the created event.
The common task of creator is to assign responsibilities related to the creation of objects.

All common relationships between classes are

• Composite aggregates part
• Container contains content
• Recorder records
Enclosing container or recorder is good for creating the thing contained or recorded.
Composition is also considered for creator.
Initialization during creation is done by some method like Java
constructors. Example: ‗Payment‘ instance while creation initialized with
‗Sale‘ total. ‗Sale‘ is a candidate creator of ‗Payment‘.
Contradictions:
Based on some external value, creation requires complexity like
• Recycled instances for performances.
• Creating an instance from one of a family of similar classes based an external
property etc.
• Abstract factory or
• Concrete façade
Then use the class of creator.
Benefits
• Lower maintenance due to low coupling
• Higher opportunities for reuse
4.3 INFORMATION EXPERT (OR EXPERT)

Problem
When designing objects, interaction between objects are defined about assigning
responsibilities to software classes.
This makes the software easier to
• Maintain
• Understand and
• Extend
Solution
Assign the responsibilities to information expert.
Example:
NextGEN POS Application
Some classes need to know the grand total of ‗sale‘.
Here we start assigning responsibilities by clearly starting the responsibility.
Information expert looks for the class of objects that has information to determine total.
1) Look at relevant classes in design model

2) Otherwise look in domain model.
For example:
We look at design model. It is minimal and hence go for domain model for
information expert ‗sale‘.
Software class ‗sale‘ is added with the responsibility of getting total with the method
‗getTotal‘.

After adding the getTotal( ), the partial interaction and class diagrams given as
To determine lineitem sub total we need,
SalesLineitem.quantity’
ProductDescription.price
By information expert using the above the SalesLineItem should determine

subtotal. This is done by
• Sale sending getSubtotal messages to each SalesLineItem and sum the results.
After knowing and answering subtotal, a SalesLineItem has to know product price.
ProductDescription is an information expert for answering price.

Finally, three design classes, assigned with three responsibilities to find sales total.
Design class Responsibility

Sale Knows sale total
SalesLineItem Knows line item subtotal
Productdescription Knows product price
• Thus information expert is used in the assignment of responsibilities.

• Experts express the common ‗intuition‘ that objects do things related to information
they have.
• ‗Partial‘ information experts will collaborate in the task.
Example: Sales total problem – collaboration of three classes of objects.
Profit and loss statement – collaboration of chief financial officer, accountants to
generate reports on credits and debits.
• Information expert thus has real world analogy
• Information experts are basic guiding principle used continuously in object design.
Contradictions
Solution of expert is not desirable in some cases due to problems of coupling and
cohesion.
To overcome this
• Keep application logic in one place [like domain software objects]
• Keep database objects in another place [separate persistence services subsystem]
Separation of major concerns improves coupling and cohesion in a design.
Benefits
1) Information encapsulation use their information to fulfill tasks.
2) High cohesion is supported

4.4 LOW COUPLING

Coupling is the measure of low strongly one element is connected to the other elements.
Types of coupling
There are 2 types of coupling
1) Low coupling or weak coupling
2) High coupling or strong coupling
Low coupling
An element if does not depend on too many other elements like classes, subsystems
systems it is having low coupling.
High coupling
A class with high coupling relies on many other classes.
The problems of high coupling are
• Forced local changes
• Harder to understand
• Harder to reuse
Example
Figure 4.7 NextGen Case study

We have to create payment instance and associate it with sale.
Design 1:
Suggested by creator
1) Register instance send addpayment message to sale, passing newPayment as a
parameter.
2) Register class couples with payment class and creates payment.
Design 2:
Suggested by low coupling
1) Here sale does the creation of payment.
2) It does not increase coupling and hence preferred.
Figure 4.9 Sales creates Payment

Low coupling is an evaluation principle for evaluating all designs.
Common forms of coupling from objects A to B include

1) A has an attribute referring to B or instance of B

2) A calls B‘s services
3) A has a method referring to B or B‘s instance
4) A is direct/indirect subclass of B
5) B is an interface and A implements B.
Low coupling
1) Assigns responsibility that will not yield negative results that cause high coupling.
2) Support design of independent classes.
1) Generic in nature
2) Having high probability of reuse will have low coupling. Extreme case of low coupling
is no coupling between classes.
That is not desired because a moderate degree of coupling between the classes is
normal and is necessary for creating an object oriented system.
High coupling to stable elements is seldom a problem.
Benefits
• Not affected by changes in other components
• Simple to understand in isolation
• Convenient to reuse
4.5 HIGH COHESION

Cohesion is a measure of how strongly related and focused responsibilities of an element
are. An element has high cohesion if it,
• Does not do tremendous work
• Has high responsibilities 
Difficulties of low cohesion are
• Hard to comprehend
• Hard to reuse
• Hard to maintain
• Delicate
Example
Create a payment instance and associate it with sale
Design 1
• Register records a payment in real world
• Then it sends addpayment message to sale, passing newpayment as a parameter.

• In the second design, payment creation in the responsibility of sale.

• It is highly desirable because it supports
◦ High cohesion and
◦ Low coupling
Scenarios of varying degrees of functional cohesion
(1) Very low cohesion
A class is solely responsible for many things in different functional areas.
(2) Low cohesion
A class has sole responsibility for a complex task in one functional area.
(3) High cohesion
A class has moderate responsibilities in one functional area and collaborates with others.
(4) Moderate cohesion
A class has light weight. It is responsible for different areas logically related to the class
concept but not to each other.
Rule of thumb
A class with high cohesion has small number of methods (with highly related
functionality) and does not work too much.
High cohesion is
• Easy to maintain
• Understand and
• Reuse
Modular design
―Modularity is the property of system that has been decomposed into a set of cohesive
and loosely coupled modules‖.
Modular design creates methods and classes with single purpose, clarity and high
cohesion.
Lower cohesion is had in
• Grouping responsibilities or code into one class or component.
• Distributed server objects.
Benefits of high cohesion are
1) Clarity
2) Ease of comprehension
3) Reuse of fine-grained, highly related functionality.
4.6 CONTROLLER
A controller is defined as the first object beyond the user interface (UI) layer that is
responsible for the receiving or handling a system operation message.
Example:
1) A cashier is POS terminal pressing ―EndSale‖ button indicating ―sale has ended‖

2) Writer using word processor presses ―spell check‖ button to perform checking of
spelling
Solution
Assign responsibility to one of the following
• Represents overall ―system‖, ―a root object‖
◦ These are variations of façade controller.
• Represents a usecase scenario called
◦ <usecaseName> handler
◦ <usecaseName> coordinator or
◦ <usecaseName> session
Here we use some controller class for all system events in same usecase scenario.
A session is an instance of a conversation with an actor.
Example:
NextGen application contains several system operations.
Figure 4.12 Some system operations of NextGen POS Application

During the design the responsibility of system operations is done by the controller.
The controller are

1) Register POS system – Represents overall ‗system‘, ‗root object‘

2) Process Sale handler – Represents receiver/handler of system events.

The choice of which is the most appropriate controller is influenced by other factors.
Figure 4.14 controller choices

The system operations are assigned to the controller classes like,
A controller should assign other objects the work that needs to be done.
It coordinates or controls the activity. Same controller class can be used for all system
events to maintain information about the state of usecase.
A common defect in the design of controllers is it suffers from bad cohesion.
Controllers
The facade controller represents the overall system, device or a sub system.
Choose some class name that suggests a cover or faced over other layers of the application
that provides main service calls from UI layer down to the other layers.
Facade controllers are used
1) Where there are not ―too many‖ system events
2) When the UI (User Interface) cannot redirect system event messages.
In used case controller there is a different controller for each use case. Facade controllers
lead to low cohesion or high coupling design.

So usecase controllers are good when there are many system events across different
processes.
• Boundary objects
• Entity objects
• Control objects
Boundary objects : Abstractions of the interfaces
Entity objects : Application independent domain software objects
Control objects : Use case handless
An important corollary of the controller pattern is UI objects.
System operations should be handled in application logic or domain layer of objects rather
than UI layer of a system.
Web UIs and saver side application of controller
An approach used is
ASP.NET and webforms:
• Developers insert application logic handling in the ―code behind‖ file, mixing
application logic into the UI layer.
• Server side web UI frameworks embody the concept of web MVC (Model – view -
controller) pattern.
• Choosing server technical frameworks strongly influence handling of serverside
system operation.
• To lower the coupling of UI, the clientside UI forwards the request to the local client side
controller.
Benefits
1) Increased potential for reuse and pluggable interfaces.
2) Opportunity to reason about the state of the use case.
Implementation with Java Swing : Rich Client UI:
We deal with basic swing. The code has
1) ProcessJFrame window referring to domain controller object – Register
2) Define handler for button click.
3) Show key message – sending enterItem message to the controller.
Code
package.com.nextgen.ui.swing;
//import
public class ProcessSaleJFrame extends JFrame
{
//window refers to ‗controller‘ domain object
(1) private Register register
public ProcessSaleJFrame (Register-register)
{
register = -register;
}
private JButton BTN_ENTER_ITEM /* this button is clicked to perform sys operation
―enetrItem‖*/
———
———
——
(2) BTN_ENTER_ITEM.addActionListener (new ActionListener ( )
{
public void actionPerformed (ActionEvent e)
{
// utility class

———
———
(3) register.enterItem(id, qty);
}
}); // end of ActionListerner
return BTN_ENTER_ITEM;
}// end of method
———
}
Implementation with java statements: Client Browser and WebUI
1) Obtain a reference to the Register domain object.
2) Send ―enterItem‖ message to domain controller object.
Code:
package.com.nextgen.ui.web;
//import
public class EnterItemAction extends Action
{
public ActionForward execute (ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServlet Response
response) throws exception
———
———
(1) Register register = repository.getRegister ( );
———
———
(2) register.enterItem (id, qty);
}// end of method
} // end of class
A controller class has low cohesion i.e. unfocused and handling many responsibilities. It
is called bloated controller.
• When facade controller is chosen, a single controller class receives all system events.
• Violating information expert and high cohesion controller itself performs many of the tasks.
• Controller has many attributes.
These are signs of bloated controller.
Cures for bloated controllers
1) Add more controllers
Example: Airline Reservation may have
2) Controller must delegate the fulfillment of each system

operation. UI layer does not handle system events.
The responsibility of system operations in application can be assigned by controller
pattern rather than UI layer.
This is illustrated by diagrams.

Related patterns
• Command  Each message is a command object
• Facade Facade controller is kind of facade
• Layers  Domain logic in domain layer than presentation layer
• Pure fabrication  A use case controller

4.7 DESIGN PATTERNS

Designing for Visibility
The ability of one object to have reference of another is called visibility.
Example:
The getProductDescription message sent from a Register to a product catalog means that
ProductCatalog instance is visible to register.
Ways of visibility: from Object A to Object B

1) Attribute visibility – B is an attribute of A
2) Parameter visibility – B is a parameter of a method of A
3) Local visibility – B is a local object in a method of A
4) Global visibility – B is globally visible in some way
Motivation of visibility
For an object A to send a message to an object B, B must be visible to A.
Attribute visibility
• It is a permanent visibility.
• Attribute visibility from A to B exists if B is attribute of A.
• It persists as long as A and B exists
Example
Register has attribute visibility to ProductCatalog, because it is an attribute to Register.

Parameter visibility
Here B passes as parameter to A when parameter visibility exists.
It persists only within the scope of the method.
So it is relatively temporary visibility.
Example:
When makeLineItem is sent to a sale instance, a ProductDescription instance is passed as
a parameter.
Local visibility
It exists from A to B when B is declared as a local object within a method of A.
It persists only within the scope of the method. So it is relatively temporarily
visible. The local visibility is achieved by
• Creating a new local instance and assigning to a local variable
• Assign the returning object from a method invocation to a local variable.
Global visibility
Here global visibility is achieved from A to B if B is global to A. It persists as long as A and B
exist. So it is permanent visibility. To achieve global visibility,

(i) Assign instance to global variable in languages like C++.

(ii) To use ‗Singleton‘ pattern.
4.8 FACTORY METHOD

It is called as
• Simple factory or
• Concrete factory
It is the simplification of GOF abstract factory.
Next adapter raises the problem,
• Who create adapters?
• How to create adapters?
When domain objects create the adapter, their responsibilities are beyond pure application
logic and related to connectivity with other software components.
So, when a domain object creates adapters
(i) It does not support goal of separation of concerns.
(ii) It lowers cohesion.
So we go in for ‗factory‘ pattern, where pure fabrication ―factory‖ object is defined to
create objects.
Advantages of factory
(i) Separate the responsibility of complex creation into cohesive helper objects.
(ii) Potential complex creation is hidden.
(iii) Performance-enhancing memory management strategies such as object catching or
recycling are allowed.
Strategies such as object catching or recycling is allowed.
Name : Factory
Problem : For complex creation logic, for better cohesion who is responsible for creating
objects.
Solution : A pure fabrication object called ‗factory‘ is created that handles creation.
In ‗Service Factory‘, the logic to decide the class creation is resolved by reading
in the class name from external source.
This is called ―datadriven design‖

4.9 ADAPTER
Name : Adapter
Problem : If similar components have different interfaces then how to resolve
incompatible interfaces.
Solution : Using an intermediate adapter object, convert original interface of a
component to another interface.
The NextGen POS system supports many third party services like,
• Tax calculators
• Credit authorization services
• Inventory systems
• Accounting systems etc
Add a level of indirection with objects to adapt to the solution.

Here a particular adapter will

be instantiated such as
• SAP for accounting
• SOAP XML interface for intranet web services.
Type names are given by pattern name, ―Adapter‖, to communicate the user of the design
pattern being used.
A resource adapter that hides external system is considered as façade object.
The motivation to call resource adapter exist when wrapping objects provide adaptation.
Adapter and GRASP
Figure 4.24 Relating Adapter to GRASP principles
Adapters can be related to some core GRASP principles.

But here the underlying themes are highly important and details of adapter are secondary.
4.10 SINGLETON (GOF)

With the services factory, we have a problem who creates the factory.
One instance of factory is needed with the process.
Since at different places the adapter are called, the quick reflection suggest that the
methods of this factory may need to be called form various places in code.
This problem can be solved by passing ‗Service factory‘ as a parameter, initialize the
objects that need visibility.

But it is not convenient and hence go for ‗Singleton‘ pattern.
Name : Singleton
Problem : Exactly one instance of class allowed called ―Singleton‖. Objects are global and
have single point of access.
Solution : Static method of class is defined, that returns singleton.
Implementation of singleton applying UML

Singleton is implemented with a ‗1‘ in the top right corner of name compartment.
Class X defines a static method ‗getInstance‘ that provides single instance of X.
Here developer has global visibility to this instance by static ‗getInstance‘ method of the
class.
class.
public class Register
{
public void initialize ( )
{
… do some work…
//accessing singleton factory in a getInstance call accounting Adapter =
ServicesFactory.getInstance ( ).getAccountingAdapter( );
… do some work…
}
//other methods…
}//end of class
Figure 4.25 Singleton Pattern in the ServicesFactory class

At any point of code, in any method of class, one can write

Singletonclass.getInstance ( )
To obtain visibility to singleton instance. Send the message
‘Singletonclass.getInstance ( )’
Design Issues in implementation
In multithreaded applications, the creation step of ―lazy initialization‖ logic is a critical
section requiring thread concurrency control.
Example in java
public static synchronized ServiceFactory getInstance ( )
{
if (instance ==null)
{
//critical sec in Multithreaded application
instance = newServicesFactory ( );
}
return instance;
}
Lazy initializations is preferred for
1) Creation work is avoided.
2) getInstance lazy initialization sometimes have complex and conditional creation
logic.
Eager initialization
public class servicesFactory
{
//eager initialization
private static servicesFactory instance = new ServicesFactory ( ); public static
servicesFactory getInstance ( ) {
Return instance;
}
// other methods…
}
:Register
:ServiceFactory
aa=getAccounting Adapter
The ‗1‘ indicates that invisibility to this is achieved by singleton pattern
While implementation, we use instance object with instance side methods.

Example:
Static method getAccountingAdapter to serviceFactory.
These are preferred for reasons like:
1) static methods are not polymorphic No
overriding in subclasses
But instance side methods permit subclassing and refinement

2) singleton instance could be remote enabled.

3) In application X, class may be singleton. But in another application ‗y‘, it may be
multiton.
That is class is not always singleton.So here instance-side solution offers flexibility.
Singleton pattern is used for factory objects and façade objects.
4.11 OBSERVER PATTERNS

To extend the solution found for changing data, add the ability for a GUI window to
refresh its sale.
The model-view separation principle discourages such solutions. It states that ―Model‖
objects should not know about view or presentation objects such as window.
It promotes Low coupling.
Due to low coupling the replacement of the view or presentation layer by a new one or of
particular windows by new windows.
The variations are supported by model view separation.
To solve this problem observe patterns are used.

Name : Observer (Publish-subscribe)
Problem : Subscriber objects are interested in state changes or events of a publisher
object, want to react in their own unique way when the publisher generates an
event.
Solution : Subscriber-implementations this interface.Publisher dynamically registers
subscribers
interested in an event and notifies them when event occurs.
The above diagram shows sample solution.

The ideas in this example:

1) An interface is defined
Example: PropertyListener with operation OnPropertyEvent
2) Define window to implement interface.
Example: SaleFrame1 implements method OnPropertyEvent
3) Pass the sale instance from where it is displaying total to SaleFrame window.
4) SaleFrame1 window registers or subscribes to Saleinstance for notification of
―Property events‖ in a addPropertyListener message.
5) Sale does not know about SaleFrame1 objects. This lowers coupling.
Sale instance is a publisher of ―Property events‖.
Figure 4.29 The observer SaleFrame1 subscribes to publisher sale

Applying UML
The OnPropertyEvent message is polymorphic in the above interaction diagram.
In the diagram below, SaleFrame1 implements PropertyListener interface thus
implements onPropertyEvent.
SaleFrame1 on receiving the message sends to JTextFieldGUI widget object to refresh
with new Saletotal.
Figure 4.31 Subscriber receives notification of published event
Here there is loose coupling to the interface independent of presentation layer –

PropertyListener interface.
Coupling to generic interface need not be present, which can be dynamically added or
removed supports low coupling.
Thus protected variations is achieved through use of an interface and polymorphism.

Figure 4.32 Who is observer, listener, subscriber and publisher
The idiom was ―publish-subscribe‖ and hence called by that name.

It is observing the event and hence called ―observer‖.
It is also called as ―Delegation Event Model‖ in Java because publisher delegates
handling of events.
The observer is not only for connecting UIs and model objects.
This is used in GUI widget event handling in Java technologies-AWT and swing and in
Microsoft.NET.
Example: JButton in swing publishes ―action event‖ when it is pressed.
Another example ―ALARM CLOCK‖ - publishes Alarm events and various subscribers.
Here AlarmListener interface, many objects can be registered listeners and all can react to
―alarm event‖.
One publisher can have many subscriber for an event
One publisher instance can have zero to many registered subscribers.
Example: One instance of an Alarmclock could have 3 registered subscribers.
• Alarm windows
• Four beepers
• One reliability WatchDog
The OnAlarmEvent notifies eight of these AlarmListeners when event happens.
Implementation

Events:
In java and C#.NET implementation of observer, ‗event‘ is shown as regular message such as
onPropertyEvent.
In these cases, the event is defined as class and filled with event data.
Event is then passes as a parameter in event message.
Example:
class PropertyEvent extends Event
{
private object sourceOfEvent;
private string propertyName;
private object oldvalue;
private object newvalue;
//…
}
class sale
{
private void publishPropertyEvent (string name, object old, object new)
{
PropertyEvent evt = new PropertyEvent (this, ―sale-total‖, old, new); for each
AlarmListener al in alarm Listeners al.onPropertyEvent (evt);
}
//…
}

Java
In 1996, the observable-observer design was replaced by Java Delegation Event Model
(DEM) version of publish-subscribe.
Observer thus provides a way to couple objects for communication.
Publishers/subscribers are to register with publisher.
We conclude that, Observer is based on polymorphism that provides protected variations
for protecting publishers from knowing specific class of object and number of objects that
communicates with publisher to generate event.
4.12 APPLYING GOF DESIGN PATTERNS

GOF – Gang Of Four
Here we see use case realizations for NextGen case study.
Gang Of Four Design Patterns
There are 23 patterns useful during object diagram.
Out of the 23 patterns, 15 are common and most useful.
4.13 MAPPING DESIGN TO CODE
In the implementation Model, the UML artifacts created during the code generation is
used as input. The implementation artifacts consists of source code, database definitions,
JSP/XML/HTML pages and so forth.
 Java
 C#
 Visual Basic
 C++
 Small talk
 Python
and many more languages use the object oriented design principles and map to code.
4.13.1 Programming – Iterative and Evolutionary Development
• Modern development tools are used to design while programming.
• The artifacts in Design Model provides the information to code.
• The strength of OOA/D and OO programming is they provide end-to-end road map
from requirements to code.
• The point of having a roadmap provides starting point for experimentation.
Creativity and change during implementation
• Some decision making and creative work are done during design.
• Generation of code is a mechanical translation process.
• The results generated during design modeling are initially incomplete and later during
programming and testing changes will be made.
• To encounter the new problems during programming  ideas and understanding are
generated during OO design modeling.
• Always plan for lot of change and derivation from the design during programming.
This is a key for iterative and evolutionary methods.
Mapping Designs to Code
Implementation requires writing source code in object oriented language for
• Class and interface definitions.
• Method definitions
The code generation is more-or-less independent of using UML tool.
Creating Class Definition from DCDS
DCDs depict
• Class or interface name
• Super classes
• Operation signature
• Attributes of a class. This is enough to create a basic class definition in OO language.

Defining a class with method signatures and attributes

The mapping to attribute definitions for SalesLineItem is shown
The java constructor salesLineItem (…) is derived from create (desc, qty) message sent to
SalesLineItem in the enterItem interaction diagram.
Creating Methods from Interaction Diagrams
The sequence of messages in an interaction diagram translates to series of statements in
the method definitions.
Figure 4.35 enterItem Interatction diagram
Here, enterItem, message is sent to register instance.

public void enterItem (itemID, ietmID, int qty)
Message 1:
A getProductDescription is sent to the Product catalog to retrieve Product
Description. ProductDescription desc = catalog.getProduct Description
(itemID);

Message 2:
The makeLineItem message is sent to the sale.
CurrentSale.makeLineItem (desc, qty);
Each sequence message is mapped to the statement in the java method.
The complete enterItem method and its relationship to interaction diagram is given below
Figure 4.37 enterItem method

Collection Classes in Code
There are many one to many relationships. These are implemented with the collection
object such as List or Map or array.
Example:
Sale must contain many SalesLineItem instances.
In Java List and Map interfaces are represented by ArrayList and HashMap.
The requirements for collection class are
(i) Key based lookup of a map

(ii) Ordered list requires a List.

LinesItems is described in terms of
interface.
Private List LineItems = new ArrayList ( );
Exceptions and Error Handling
In applications development consider large – scale exception handling strategies during
design modeling.
Exceptions are indicated in the property strings of messages and operation declarations.
Figure 4.38 Adding a Collection
Definition Sale makeLineItem Method

The makeLineItem method of class sale can be written by inspecting enterItem
collaboration diagram.
Sale.makeLineItem method
Order of Implementation
Implementation of least-coupled classes is done followed by most coupled classes.
Example:
First classes payment/product Description is implemented.
Next Product catalog / SaleLineItem are implemented.
Possible order of class Implementation and testing

Test Driven of Test First Development

Test Driven Development (TDD) or Test First Development is promoted by Extreme
Programming (XP).
Here developer writes unit testing code before testing it.
The rhythm is to write a little test code, then write production code, make it pass the test
write some more test code and so forth.
Summary of Mapping Design to Code
There is a translation process from UML class diagrams to class definitions and from
interaction diagrams to method bodies.
Introduction to NextGen POS Program Solution
A simple domain layer of classes in Java are largely derived from the design class
diagrams and interaction diagrams.
There is a translation from design artifacts to a foundation code.
Class Payment
//all classes in package
package com too.nextgen.domain;
public class Payment
{
private money amount;
public Payment (Money cash tendered)
{
amount = cashTendered;
}
public Money getAmount ( )
{
return amount;
}

class Productcatalog:
{
private Map<ItemID, ProductDescription>
description = newHashMap ( )
<ItemID, ProductDescripion>;
public ProductCataglog( )
{
// Sample Data
ItemID id1 = new ItemID (10);
ItemID id2 = new ItemID (20);
money price = new Money (3);
product Description d;
d = new Product Description (id1, price, ‗Product
1‘); description put (id1, d);
d = new Product Description (id2, price, ‗Product
2‘); description put (id2, d);
}
public Product Description getProductDescription (ItemID id)
return description get (id);
}
class Register:
public class Register
{
private Product Catalog Catalog;
private Sale currentSale;
public Register (ProductCatalog Catalog)
{
this.catalog = catalog;
}
public void endSale ( )
{
currentSale.become Complete ( );
}
public void enterItem (ItemID id, int quantity)
{
productDescription desc = catalog.getProductDescription
(id); currentSale.makeLineItem (desc, quantity);
}
public void makeNewSale ( )
{
currentSale = newSale ( );
}
public void makePayment (Money cashTendered)
{
currentSale.makePayment( cashTendered);
}
}
class Productdescription
public class ProductDescription
{
private ItemID id;
private Money price;

private String descripiton;

public ProductDescription
(ItemID id, Money price, string descriptio )
{
this.id = id;
this.price = price;
this.description = description;
}
public ItemID getItemID ( ) {return id;}
public Money getPrice ( ) {return price;}
public string getDescription {return description;
}
class Sale:
public class Sale
{
private List <SalesLineItem> lineItems = new ArrayList ( ) <SalesLineItem>;
private Date date = new Date ( );
private Boolean is complete = false;
private Payment Payment;
public Money getbalance ( )
{
return Payment getAmount ( ).minus (getTotal( ));
}
public void become Complete ( ) {isComplete = true;}
public Boolean is complete ( ) {return is complete;}
public void makeLineItem (Product description desc, int quantity)
{
linesItems.add (new SalesLinesItem (desc, quantity));
}
public Money getTotal ( )
{
Money Total = new Money ( );
Money subtotal = null;
for (SalesLineItem lineItem : lineItem)
{
subtotal = lineItem.getsubtotal ( );
total.add (subtotal);
}
return total;
}
public void makePayment (Money cashTendered)
{
payment = new Payment (cash Tendered);
}
}
class SalesLineItem
public class SalesLineItem
{
private int quantity;
private ProductDescription description;
public SalesLineItem (Product Description desc, int quantity)
{

this.description = d; this.quantity = quantity;

}
public Money getsubtotal ( )
{
return description.getPrice ( ).times (quantity);
}
}
class store
public class store
{
private ProductCatalog catalog = new Product Catalog(
); private Register register = new Register(Catalog);
public Register getRegister ( ) {return register;}
}
Introduction to Monopoly Program Solution
Here is a sample domain layer of classes in Java.
Class Square
//all classes are in the package
package.com.too.monopoly.domain;
public class square
{
private string name;
private square nextsquare;
private int index;
public square (string name, int index)
{
this.name = name; this.index = index;
}
public void setNextSquare (square S)
{
nextSquare = S;
}
public Square getnextSquare ( )
{
return nextSquare;
}
public string getname ( )
{
return name;
}
public int getIndex ( )
{
return index;
}
}
Class Piece
public class Piece
{
private Square location; public Piece (Square location)
{
this.location = location;
}

public Square getLocation ( )

{
return location;
}
public void setLocation (Square location)
{
this.location = location;
}
}
Class Die
public class Die
{
public static final int MAX = 6; private int faceVlaue;
public Die ( )
{
roll ( );
}
public void roll ( )
{
faceValue = (int) ((Math.random ( ) * MAX) + 1);
}
public int getfaceValue ( )
{
return faceValue
}
}
Class Board
public class Board
{
private static final int SIZE = 40;
private List squares = new ArrayList (SIZE);
public Board ( )
{
build squares ( );
link Squares ( );
}
public Square getSquare (Square start, int distance)
{
int endIndex = (start.getIndex( ) + distance)
%size; return (Square) Square.get (endIndex);
}
public Square getstartSquare ( )
{
return (Square) Squares.get (0);
}
private void bulidSquare ( )
{
for (int i=1 i<=SIZE; i++)
{
build (i);
}

}
private void build (int i)
{
Square S = new Square (―Square‖ +I, i-1);
Square.add(S);
}
private void linkSquare ( )
{
for (int i=0;i<(SIZE-1); i++)
{
link (i);
}
Square first = (square) Square.get(0);
Square last = (square) Square.get(SIZE-);
last.setNextSquare (first);
}
private void link (int i)
{
Square current = (Square) Squares.get(i);
Square next = (Square) Squares.get(i+1);
current.setNextSquare (Next);
}
}
Class player
public class player
{
private string name;
private Piece piece;
private Board board;
private Die [ ] dice;
public player (string name, Die [ ] dice, Board board)
{
this.name = name;
this.dice = dice;
this.board = board;
piece = new Piece (board.getstartsquare ( ));
}
public void take turn ( )
{
int roll Total = 0;
for (int i =0; i<dice.length; i++)
{
dice [i].roll ( );
rollTotal += dice[i].getFaceVlaue ( );
}
Square newLoc = board.getSquare (Piece.getLoaction ( ), rollTotal);
piece.setLocation(newLoc);
}
public square getLocation ( )
{
return piece.getLocation ( );
}

public string getName ( )

{
return name;
}
}
Class Monopoly Game
public Class Monopoly Game
{
private static final int ROUNDS – TOTAL = 20;
private static final int PLAYERS – TOTAL = 2;
private List players = new ArrayList (PLAYERS –
TOTAL); private Board board = new Board ( );
private Die [ ] dice = {new Die, new Die ( )};
public Monopoly Game ( )
{
player p;
p = new player (―Horse‖, dice, board);
players.add (p);
}
public void palyGame ( )
{
for (int i=0; i<ROUNDS – TOTAL; i++)
{
play Round ( );
}
}
public List getPlayers ( )
{
return players;
}
private void playground ( )
{
for (iterator iter = Players.iterator ( ); iter.hasNext ( );)
{
player player = (Player)iter.Next ( );
player.takeTurn ( );
}
}
}

Unit 5- TESTING
5.1 OBJECT ORIENTED MEHODOLOGIES
The Essentials
Many methodologies are available to choose from for the system development. Each
methodology is based on modeling the business problem and implementation in an object
oriented fashion. The Rumbaugh et al method has a strong method for producing object
models. Jacobson et al have a strong method for producing user-driven requirement and
object oriented analysis model. Booch has a strong method for producing detailed object
oriented design models
Rumbaugh’s Object Modeling Technique:
• Describes the dynamic behavior of objects in a system using the OMT dynamic
model.
• Four phases.
◦ Analysis – results are objects, dynamic and functional models. System
◦ design – gives a structure of the basic architecture.
◦ Object design – produces a design document.
◦ Implementation – produces reusable code.
• OMT separates modeling in to three different parts
• Object Model – presented by object model and the data dictionary.
• Dynamic model - presented by the state diagrams and event
• Flow diagrams.
◦ Functional Model – presented by data flow and constraints.
Object Model:-
Object model describes the structure of objects in a system, their identity and
relationships to other objects, attributes, and operations.
The object model is represented graphically with an object diagram.
Figure 5.1 OMT object model of a bank

system Boxes represent classes
Filled represents specialization
The OMT Dynamic Model:

• OMT provides a detailed and comprehensive dynamic model

• The OMT state transition diagram is a network of states and events.

◦ Each state receives one or more events, at which it makes the transition to the
next state.
◦ The next state depends on the current state as well as the events.
State transition diagrams for the bank application user interface.

• Round boxes represents states
• Arrows represents transitions
The OMT Functional Model
• The OMT data flow diagram (DFD) shows the flow of data between different
processing in a business.
• Data Flow Diagrams use four primary symbols:
◦ The process is any function being performed
◦ The data flow shows the direction of data element movement
◦ The data store is a location where data are stored.
◦ An external entity is a source or destination of a data element.
The Booch Methodology :
• Booch methodology is a widely used object-oriented method that helps to design
your system using the object paradigm.
• Is criticized for his large set of symbols.
• It consists of the following diagrams:
◦ Class diagrams.
◦ Object diagrams.
◦ State transition diagrams.
◦ Module diagrams.
◦ Process diagrams.
◦ Interaction diagrams.
• Two processes:
◦ Macro development process
◦ Micro development process.
Macro development process.
Primary concern – technical management of the system. Steps involved:
• Conceptualization.

Establish the core requirements and develop a prototype.

• Analysis and development of the model
Use the class diagram to describe the roles and responsibilities of objects. Use the
object diagram to describe the desired behavior of the system.
• Design or create the system architecture.
Use the class diagram to decide what classes exist and how they relate to each
other, the object diagram to decide what mechanisms are used, the module diagram to
map out where each class and object should be declared, and the process diagram to
determine to which processor to allocate a process.
• Evolution or implementation.
Refine the system through much iteration.
• Maintenance.
Make localized changes to the system to add new requirements and eliminate
bugs.
Micro development process.
• The micro development process is a description of the day-to-day activities.
• Steps involved:
◦ Identify classes and objects.
◦ Identify classes and object semantics.
◦ Identify classes and object relationships.
◦ Identify classes and object interfaces and implementation.
◦ An alarm state transition diagram with Booch notation

Jacobson Methodology:
• Object-oriented business engineering (OOBE)
• Object-oriented software engineering (OOSE)
• It covers the entire life cycle
• Stress traceability(enables reuse of analysis and design work) both forward and
backward
• Use cases

• Scenarios for understanding system requirements.

• Non formal text with no clear flow of events.
• Text easy to read.
• Formal style using pseudo code.
• Can be viewed as concrete or abstract (not initiated by actors).
• Understanding system requirements
• Interaction between user and system
• It captures the goal of the user and responsibility of the system to its users
• Object oriented software Engineering: Objectory

• OOSE is also called Objectory
• Development process is also called as use case driven development
• The system development method based on OOSE is a process for the
industrialized development of the s/w

• Use case model:-

The use-case model defines the outside and inside of the system behaviour
• Domain Object Model:-
The objects of the real worls are mapped in to the domain object model
• Analysis Object Model:-
The analysis object model presents how the source code should be carried out
written
• Implementation model:
The implementation model represents the implementation of the system
• Test model:-
The test model constitutes the test plans, specification and reports.
• Object oriented business Engineering
• Analysis phase:-
◦ The analysis phase defines the system to be built in terms of the
problem-domain object model
the requirements model
analysis model
• Design and Implementation phase:-
◦ The implementation environment must be identified for the design model.
• Testing phase:-
◦ This level includes unit testing, integration testing and system testing.
Patterns and the Various Pattern Templates:
• Pattern –
◦ Identifies a common structure that makes it useful for design.
◦ provide common vocabulary
◦ provide “shorthand” for effectively communicating complex principles
◦ help document software architecture
◦ capture essential parts of a design in compact form
◦ show more than one solution
◦ describe software abstractions
• Patterns do not...
◦ provide an exact solution
◦ solve all design problems
◦ only apply for object-oriented design
• Involves a general description of a solution to a recurring problem.
• Properties of a good pattern:
◦ It solves a problem:-
Patterns capture solutions not just abstract principles or strategies
◦ It is a proven concept:-
Patterns capture solutions with a track record, not theory or speculation
◦ Solution is not obvious:-
The best patterns generate a solution to a problem indirectly
◦ Describes a relationship:-
Patterns do not just describes modules but describes deeper system
structures and mechanisms
◦ Has significant human component:-
All software serves human comfort or quality of life
• Generative patterns – Tells us how to generate something.
◦ observed in a system

◦ descriptive and passive

• Non generative patterns –
◦ ogenerate systems or pats of systems
◦ operspective and active
• Patterns templates.
◦ Name:-
A meaningful name allows us to use a single word or short phrase to refer
to the pattern and the knowledge and structure it describes.
Some pattern forms also provide a classification of the pattern in addition
to its name.
◦ Problem:-
A statement of the problem that describes its intent: the goals and
objectives it wants to reach within the given context and forces.
The forces oppose these objectives as well as each other.
◦ Context:-
The preconditions under which the problem and its solution seem to recur
and for which the solution is desirable.
It can be thought of as the initial configuration of the system before the
pattern is applied to it.
◦ Forces:-
A description of the relevant forces and constraints and how they interact
or with one another and with the goals that the user wish to achieve.
A concrete scenario that serves as the motivation for the pattern frequently
is employed.
◦ Solution:-
Static relationships and dynamic rules describing how to realize the desired
outcome.
It describes how to construct the necessary products.
It encompasses the pictures, diagrams and prose that identify the pattern
structure, and their participants and collaborations to show how the
problem is solved.
◦ Examples:-
One or more sample applications of the pattern that illustrate a specific
initial context; how the pattern is applied to and transforms that context.
◦ Resulting context:-
The state or configuration of the system after the pattern has been applied,
including the consequences of applying the pattern and other problems and
patterns that may arise from the new context.
◦ Rationale:-
Steps or rules in the pattern and also of the pattern as a whole in terms of
how and why it resolves it forces in a particular way to be in alignment
with desired goals.
• Related patterns:-
◦ The static and dynamic relationships between this pattern and others within the
same pattern language or system.
◦ Related pattern often share common forces.
◦ They also frequently have an initial or resulting context that is compatible with
the resulting or initial context of another pattern.
• Known uses:-

◦ The known occurrences of the pattern and its application within existing
systems.
This helps to validate a pattern by verifying that it indeed is a proven solution to the
recurring problem.
FRAMEWORKS:
Frameworks are a way of delivering application development patterns to support best
practice sharing during application development .
A frame work is a way of presenting a generic solution to a problem that can be
applied to all levels in a development. Several design patterns in fact a framework can be
viewed as the implementation of a system of design patterns.
The major differences between design patterns and frameworks as follows
• Design patterns are more abstract than frameworks.
• Design patterns are smaller architectural elements than frameworks.
• Design patterns are less specialized than frameworks.
The Unified Approach:
• Establishes a unifying and unitary framework by utilizing UML.
• The processes are:
◦ Use case driven development.
◦ Object oriented analysis.
◦ Object oriented design.
◦ Incremental development and prototyping
◦ Continuous testing.
• Methods and technologies employed include:
◦ UML:- Unified Modeling approach is used for modeling
◦ Layered approach:-
◦ Repository:- Repository for object-oriented system
development
patterns and frameworks
◦ CBD:- Component based development
The Unified Approach allows iterative development by allowing to go back
and forth between the design and the modeling or analysis phase.
It makes backtracking very easy and departs from the linear waterfall
process, which allows no form of backtracking.
• Object oriented Analysis.
◦ Identify actors.
◦ Develop a simple process model.
◦ Develop the use case.
◦ Develop interaction diagrams.
◦ Identify classes.
• Object oriented design
◦ Design classes, attributes, methods etc.
◦ Design the access layer.
◦ Design the prototype user interface.
◦ User satisfaction and usability tests.
◦ Iterate and refine the design.
• Continuous testing
• UML – modeling language
• Repository

◦ Allows maximum reuse of previous experience.

◦ Should be accessible by many people.
• Layered approach
◦ The business layer.
Displaying results.
Data access details
◦ The user interface or view layer.
◦ Responding to user interaction:-
It must be designed to translate actions by the user, such as clicking on a
button or selecting from a menu.
◦ Displaying business objects:-
This layer must paint a best possible picture of the business objects for the
user.
5.2 SOFTWARE QUALITY ASSURANCE : -
• Debugging is a process of finding out where something went wrong and correcting
the code to eliminate the errors or bugs that cause unexpected results. A software
debugging system can provide tools for finding errors in programs and correcting
them.
• Kinds of errors: In general, a software has three types of errors such as below
1) Language (syntax) errors are result of incorrectly constructed code, such as an
incorrectly typed keyword or punctuations. They are easiest error to be
detected on simple running system
2) Run–time errors are detected on running, when a statement attempts an
operation that is impossible to carry out. Eg.: if program tries to access a non-
exist file or object, it occurs
3) Logic errors occur when expected output is not formed. They can detected only
by testing the code and analyzing the results performed by intended codes
• The elimination of syntactical bug is the process of debugging, whereas detection
and elimination of logical bug is the process of testing. Quality assurance testing
can be divided into two major categories: error–based testing and scenario–based
testing
• Error–based testing techniques search a given class’s method for particular clues of
interests, then describe how these clues should be tested. E.g: Boundary condition
testing
• Scenario–based testing also called usage–based testing, concentrates on capturing
use–cases. Then it traces user’s task, performing them with their variants as tests.
It can identify interaction bugs. These are more complex tests tend to exercise
multiple subsystems in a single test covering higher visibility system interaction
bugs
• S/w testing is one element of a broader topic that is often referred to as verification
and validation (V&V). Verification refers to set of activities that ensure that
software correctly implements a specific function. Validation refers to different set
of activities that ensure that s/w that hs been built is traceable to customer
requirements
Testing Strategies: -
• The objective of s/w testing is to uncover errors. The various testing strategies
constitutes –

◦ Unit Testing – Black Box testing, White black testing

◦ Integration Testing – Top–down testing, Bottom–up testing, Regression testing
◦ Validation Testing – Alpha test, Beta test and
◦ System Testing – Recovery testing, Security testing, Stress testing,
Performance testing o Tom Gilb argues following issues for successful s/w
testing strategy is to be implemented:
1) Specify product requirements in a quantifiable manner long before testing
commences
2) State testing objectives explicitly
3) Understand the users of s/w and develop a profile for each user category
4) Develop a testing plan that emphasizes “rapid cycle testing”
5) Build “robust” s/w that is designed to test itself
6) Use effective formal technical reviews as a filter prior to testing
7) Conduct formal technical reviews to assess the test strategy and test cases
themselves
8) Develop a continuous improvement approach for testing process
• Unit incorporation and integration of tests concentrate on functional verification of
a module and modules into a program structure.
Validation testing demonstrates traceability to s/w requirements and system testing
validates s/w once it has been incorporated into a larger system
1) Unit test focuses verification effort on smallest unit of s/w design the module.
It constitutes two inner types of testing – White box testing and Black box
testing
Black box testing: The concept of black box is used to represent a system
that’s inside working are
not available for inspection. In black box testing, we try various inputs and
examine resulting output though which we learn what the box does nor
how conversion takes place
White box testing: White box testing assumes that specific logic important
and must be tested to guarantee system’s proper functioning. One form of
white box testing called path testing, makes certain that each path in a
object’s method is executed at least once during testing & is of types
1) Statement testing coverage: Its aim is to test every statement in object’s
method at least once
2) Branch testing coverage: Idea is to perform enough tests ensuring all
branches are perfect
• Integration Testing: It is a systematic technique for constructing the program
structure while conducting tests to uncover errors associated with interfacing. The
object is to take unit tested modules and build a program structure that has been
dictated by design. It has again 3 testing patterns: Top–down testing, Bottom – up
testing and regression testing
• Top–down testing: It assumes that main logic or object interactions and system
messages of application need more testing than an individual object’s method or
supporting logic. This strategy can detect serious flaws early in implementation
• Bottom–Up testing: It starts with details of system and proceeds to higher levels by
a progressive aggregation of details until they collectively fit requirements for
system i.e., start with methods and classes then to level up. It makes sense as it
checks behavior of piece of code before it is used

• Regression testing: It is activity that helps ensure that changes (due to testing or
other reasons) do not introduce unintended behavior or additional errors. The
regression test suite contain three different classes of test cases:
◦ A representative sample of tests that will exercise all s/w functions
◦ Additional tests that focus on s/w functions that are likely to be affected by
change
◦ Tests that focus on s/w components that have been changed
• Validation Testing: After integration testing, s/w is completely assembled as
a package: interfacing errors have been uncovered and corrected and final series of
s/w tests – validating testing – begins. It is nothing but continuous execution on
s/w by number of times & users. It is again implemented either by one of two
methods: Alpha testing or Beta testing
• Alpha test is conducted in controlled environment at developer’s site by a
customer. The s/w is used in setting with developer “looking over shoulder” of
user, recording errors & usage problems
• Beta test is conducted at one or more customer sites by end user(s) of the s/w. Its
live application of s/w where customer records all problems that are encountered
during beta testing and reports
• System Testing: It is a series of different tests whose primary purpose is to fully
exercise the computer – based system. Although each test has a different purpose,
all work to verify that all system elements have been properly integrated and
perform allocated functions. The different tests in series are Recovery, security,
stress and performance testing
• Recovery testing is a system test that forces s/w to fail in a variety of ways and
verifies that recovery is properly performed. If recovery is automatic, re –
initialization, checkpoint mechanisms, data recovery and restart are each evaluated
for correctness
• Security testing attempts to verify that protection mechanisms built into a system
will in fact protect it from improper penetration. During this test, tester plays the
role(s) of individual who desires to penetrate system. The role of system designer
is to make penetration cost greater than value of information that will be obtained
• Stress testing executes a system in a manner that demands resources in abnormal
quantity, frequency or volume. A variation of stress testing is a technique called
sensitivity testing. In some situations, a very small range of data contained within
the bunds of valid data for a programs may cause extreme and even erroneous
processing or profound performance degradation
• Performance testing is designed to test run –time performance of s/w within
context of an integrated system. It occurs throughout all steps in testing process.
Performance tests are often coupled with stress testing and often require both h/w
and s/w instrumentation
5.3 IMPACT OF OBJECT ORIENTATION ON TESTING

The impact of an object orientation on testing can be summarized as follows:
1) Some types of errors could become less plausible (not worth for testing)
2) Some types of errors could become more plausible (worth testing for now)
3) Some new types of errors might appear
Impact of Inheritance in Testing: If designers do not follow OOD guidelines
especially, if test is done incrementally, it will lead with objects that are extremely hard to
debug and maintain Reusability of Tests: Marick argues that simpler is a test, more likely it is

to be reusable in sub classes. The models developed for analysis & design should be used for
testing as well.
5.4 DEVELOP TEST CASES AND TEST PLANS

5.4.1 Develop Test
• Myers describes the object of testing as follows:
◦ Testing is process of executing a program with the intent of finding errors
◦ A good test case is one that has a high probability of detecting an as–yet
undiscovered error
◦ A successful test case is one that detects as as–yet undiscovered error
• Guidelines for developing Quality Assurance Test Cases: Freedman & Thomas
have developed guidelines that have been adapted for the Unified Approach
◦ Describe which feature or service (external of internal), test attempts to cover
◦ If test case is based on use case it must refer to use–case name and write test
plan for that piece
◦ Specify what to test on which method along with test feature and expected
action
◦ Test normal use of the object’s methods
◦ Test abnormal but reasonable use of the object’s methods
◦ Test abnormal and unreasonable use of object’s methods
◦ Test boundary conditions of number of parameters or input set of objects
◦ Test object’s interactions & message sent among them with assist of sequence
diagram
◦ On doing revision, document the cases so they become the starting basis for
follow–up test
◦ Attempt to reach agreement on answers of what–if questions and repeat
process until stabilized
◦ The internal quality of s/w such as its reusability and extendibility should be
assessed as well
Example: Testing a File Open feature, we specify the result as follows:
1) Drop down the File menu and select Open
Try opening following type of files

2) * A file that is there (should Work) * A file that
is not
there(should get an error message) * A file name with international characters

(should work)
* A file type that the program does not open (should get a message or conversion
dialog box)
5.4.2 Test Plan : -
• A test is developed to detect and identify potential problems before delivering the
s/w to its users. The test plan need not be very large; in fact, devoting too much
time to the plan can be counter productive. The following steps are needed to
create a plan
1) Objectives of test: Create objectives of test and describe how to achieve them
2) Development of test case: Develop test data, I/O based on domain of data &
expected behavior

3) Test analysis: It involves examination of test O/p and documentation of test

results
• All passed tests should be repeated with revised program called regression testing.
Most s/w companies use beta testing, a popular inexpensive, effective way to test
s/w and alpha testing
• Guidelines for developing Test Plans: Thomas stated following guidelines for
writing test plans
◦ Specific appearance or format of test plan must include more details about test
◦ It should contain a schedule and a list of required resources including number of
peoples &time
◦ Document every type of test planned with level of detail driven by several
factors
◦ A configuration control system provides a way of tracking changes to code
should exist
◦ Try to develop a habit of routinely bring test plan sync with product or product
specification
◦ At end of each moth or as reach each milestone, take time to complete routine
updates
1) The methods used to design test cases in OO testing are based on the
conventional methods. However, these test cases should encompass special
features so that they can be used in the object-oriented environment. The
points that should be noted while developing test cases in an object-
oriented environment are listed below.
2) It should be explicitly specified with each test case which class it should
test.
3) Purpose of each test case should be mentioned.
4) External conditions that should exist while conducting a test should be
clearly stated with each test case.
5) All the states of object that is to be tested should be specified.
6) Instructions to understand and conduct the test cases should be provided
with each test case.
Object-oriented Testing Methods
As many organizations are currently using or targeting to switch to the OO paradigm,
the importance of OO software testing is increasing. The methods used for performing object-
oriented testing are discussed in this section.

State-based testing is used to verify whether the methods (a procedure that is executed
by an object) of a class are interacting properly with each other. This testing seeks to exercise
the transitions among the states of objects based upon the identified inputs.
For this testing, finite-state machine (FSM) or state-transition diagram representing the
possible states of the object and how state transition occurs is built. In addition, state-based
testing generates test cases, which check whether the method is able to change the state of
object as expected. If any method of the class does not change the object state as expected, the
method is said to contain errors.
To perform state-based testing, a number of steps are followed, which are listed below.
1) Derive a new class from an existing class with some additional features, which are
used to examine and set the state of the object.
2) Next, the test driver is written. This test driver contains a main program to create
an object, send messages to set the state of the object, send messages to invoke
methods of the class that is being tested and send messages to check the final state
of the object.
3) Finally, stubs are written. These stubs call the untested methods.
Fault-based Testing
1) Fault-based testing is used to determine or uncover a set of plausible faults. In
other words, the focus of tester in this testing is to detect the presence of possible
faults. Fault-based testing starts by examining the analysis and design models of
OO software as these models may provide an idea of problems in the
implementation of software. With the knowledge of system under test and
experience in the application domain, tester designs test cases where each test case
targets to uncover some particular faults.
2) The effectiveness of this testing depends highly on tester experience in application
domain and the system under test. This is because if he fails to perceive real faults
in the system to be plausible, testing may leave many faults undetected. However,
examining analysis and design models may enable tester to detect large number of
errors with less effort. As testing only proves the existence and not the absence of
errors, this testing approach is considered to be an effective method and hence is
often used when security or safety of a system is to be tested.
Scenario-based Testing
Scenario-based testing is used to detect errors that are caused due to incorrect
specifications and improper interactions among various segments of the software. Incorrect
interactions often lead to incorrect outputs that can cause malfunctioning of some segments of
the software. The use of scenarios in testing is a common way of describing how a user might
accomplish a task or achieve a goal within a specific context or environment. Note that these
scenarios are more context- and user specific instead of being product-specific. Generally, the
structure of a scenario includes the following points.
 A condition under which the scenario runs.
 A goal to achieve, which can also be a name of the scenario.
 A set of steps of actions.
 An end condition at which the goal is achieved.
 A possible set of extensions written as scenario fragments.
Scenario- based testing combines all the classes that support a use-case (scenarios are
subset of use-cases) and executes a test case to test them. Execution of all the test cases
ensures that all methods in all the classes are executed at least once during testing. However,
testing all the

objects (present in the classes combined together) collectively is difficult. Thus, rather than
testing all objects collectively, they are tested using either top-down or bottom-up integration
approach.
This testing is considered to be the most effective method as scenarios can be
organized in such a manner that the most likely scenarios are tested first with unusual or
exceptional scenarios considered later in the testing process. This satisfies a fundamental
principle of testing that most testing effort should be devoted to those paths of the system that
are mostly used.
Challenges in Testing Object-oriented Programs

Traditional testing methods are not directly applicable to OO programs as they involve
OO concepts including encapsulation, inheritance, and polymorphism. These concepts lead to
issues, which are yet to be resolved. Some of these issues are listed below.
Encapsulation of attributes and methods in class may create obstacles while testing. As
methods are invoked through the object of corresponding class, testing cannot be
accomplished without object. In addition, the state of object at the time of invocation of
method affects its behavior. Hence, testing depends not only on the object but on the state of
object also, which is very difficult to acquire.
Inheritance and polymorphism also introduce problems that are not found in
traditional software. Test cases designed for base class are not applicable to derived class
always (especially, when derived class is used in different context). Thus, most testing
methods require some kind of adaptation in order to function properly in an OO environment.

UNIT-I
PART-A
1 What Is Object-Oriented Analysis and Design? [AU A/M 2011] [AU A/M 2014]
What is OOAD? [AU N/D 2014] [AU A/M 2015]
During object-oriented analysis, there is an emphasis on finding and describing the objects—or
concepts—in the problem domain. For example, in the case of the library information system, some of
the concepts include Book, Library, and Patron.
During object-oriented design, there is an emphasis on defining software objects and how they
collaborate to fulfill the requirements. For example, in the library system, a Book software object may
have a title attribute and a get Chap-ter method.
2 Define the inception step. [AU A/M 2011]
What is inception? [AU N/D 2017]
Inception is the initial short step to establish a common vision and basic scope for the project. It will
include analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirement,
creation of a business case, and preparation of the development environment.
3 What do you mean by use cases and actors? [AU N/D 2011]
A use case is a collection of related success and failure scenarios that describe an actor using a system to
support a goal. Use cases are text documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing diagrams.
An actor is something with behavior, such as a person (identified by role), computer system, or organization;
for example, a cashier.
4 What is UML? [AU A/M 2012] [AU N/D 2014]
What is Unified Modeling Language? [AU A/M 2019]
The Unified Modeling Language is a visual language for specifying, constructing and documenting the
artifacts of systems.
5 List the relationships used in use cases? [AU A/M 2012]
There can be 5 relationship types in a use case diagram.
 Association between actor and use case.
 Generalization of an actor.
 Extend between two use cases.
 Include between two use cases.
 Generalization of a use case.
6 What is the need for modeling? [AU A/M 2014]
Provide users a ready – to use expressive visual modeling language so they can develop and exchange
meaningful models.
• Provide extensibility and specialization mechanism to extend the core concepts.
• Be independent of particular programming language and development process.
• Provide a formal basis for understanding the modeling language.
• Encourage the growth of the OO tools market.
• Support higher – level development concepts.
7 Give the use of UML diagrams? [AU A/M 2014]
A UML diagrams are used to visually representing a system along with its main actors, roles, actions,
artifacts or classes, in order to better understand, alter, maintain, or document information about the system.
8 Define : Use case. [AU A/M 2015]
A use case is a collection of related success and failure scenarios that describe an actor using a system to
support a goal. Use cases are text documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing diagrams.
9 What is the purpose of the association relationship? [AU A/M 2015]
The purpose of an association relationship is to show the relation between classes (more precisely,
instances of those classes) that indicates some meaningful and interesting connection.
10 What are the three ways and perspectives to UML. [AU N/D 2015]
Three ways to apply UML
 UML as sketch
 UML as blue print
 UML as programming language
Three perspectives to Apply UML
1) Conceptual
2) Specification
3) Implementation
11 What tests can help find useful Use Cases? [AU M/J 2016]
The Boss Test
The EBP Test
The size test
12 Define conceptual classes. [AU M/J 2016]
The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class
is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol,
intension, and extension
 Symbol -words or images representing a conceptual class.
 Intension -the definition of a conceptual class.
 Extension -the set of examples to which the conceptual class applies
13 What are the three perspectives to apply UML? [AU N/D 2016]
What are the perspectives to apply UML? [AU A/M 2017]
Three perspectives to Apply UML
1) Conceptual
2) Specification
3) Implementation
14 What are the primary goals in the design of UML? [AU N/D 2016]
 Provide users a ready to use expressive visual modeling language so they can develop and
exchange meaningful models.
 Provide extensibility and specialization mechanism to extend the core concepts.
 Encourage the growth of oo tools market.
 Support higher level development concepts.
15 Why call a domain model a 'visual dictionary'? [AU N/D 2016]
The information it illustrates could alternatively have been expressed in plain text. But it's easy to
understand the terms and especially their relationships in a visual language, since our brains are good at
understanding visual elements and line connections. Therefore, the domain model is a visual dictionary of
the noteworthy abstractions, domain vocabulary, and information content of the domain.
16 Define OOAD. [AU A/M 2017]
Object-oriented analysis and design (OOAD) is a technical approach used in the analysis and design of an
application or system through the application of the object-oriented paradigm and concepts including visual
modeling.
17 What is the purpose of extends and include relationship in use case diagram? [AU A/M 2017]
"The include relationship is intended for reusing behaviour modeled by another use case, whereas
the extend relationship is intended for adding parts to existing use cases as well as for modeling optional
system services" .
18 Outline the purpose of using use cases, to describe requirements. [AU N/D 2017]
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements.
The use case is made up of a set of possible sequences of interactions between systems and users in a
particular environment and related to a particular goal. ... Models the goals of system/actor (user)
interactions.
19 When to create a subclass of a superclass? [AU N/D 2017]

Whenever you are writing a class whose members and functions are almost similar to the existing classes.
Then we can create a sub class for the super class. So that the code will get reduced. In inheritance concept
we create subclasses.
Definition: A subclass is a class that derives from another class. A subclass inherits state and behavior from
all of its ancestors. The term superclass refers to a class's direct ancestor as well as all of its ascendant
classes.
20 Define use case and actor. [AU A/M 2018]
A use case is a list of actions or event steps typically defining the interactions between a role (known in the
Unified Modeling Language (UML) as an actor) and a system to achieve a goal. The actor can be a human
or other external system.
List out the components of a POS system. [AU A/M 2018]
The components of a POS system are
 Back Office Server
 POS Monitor
 Customer Pole Display
 Bar-Code Scanner
 Cash Drawer
 Keyboards
 Printer
 MSRs & PIN Pads
 Magnetic stripe readers (MSR) are used to capture credit or debit card information to process
How to create an instance? [AU A/M 2018]
Creation of an object as a member of a class is called instantiation. Thus, object is an instance of a class.
A set of attributes for the objects that are to be instantiated from the class. Generally, different objects of a
class have some difference in the values of the attributes.
Define object. [AU N/D 2018]
An object is a combination of data and logic; the representation of some real-world entity.
What is a unified process? [AU N/D 2018]
A software development process describes an approach to building, deploying, and possibly maintaining
software. The Unified Process has emerged as a popular iterative software development process for
building object-oriented systems.
What is the difference between a class and an object? [AU N/D 2018]
The difference is simple and conceptual. A class is a template for objects. An object is a member or an
"instance" of a class. An object has a state in which all of its properties have values that you either
explicitly defines or that are defined by default settings.
What is an object modeling language. [AU N/D 2018]
An object-modeling language is a standardized set of symbols used to model a software system using
an object-oriented framework. . A modeling language is usually associated with a methodology for object-
oriented development. The modeling language defines the elements of the model.
List any two features of object based languages. [AU N/D 2018]
Here are three major features in object-oriented programming that makes them different than non-
OOP languages: Encapsulation, Inheritance And Polymorphism.
What is meant by generalization? [AU N/D 2018]
Generalization is the process of extracting shared characteristics from two or more classes, and
combining them into a generalized super class. Shared characteristics can be attributes, associations, or
methods. In contrast to generalization, specialization means creating new subclasses from an existing
class generalization is used when you have one or more use cases that are really specializations of a
more general case.
What is the significance of UML? [AU N/D 2018]

The significance of UML
 Permits you to specify the structure or behavior of a system.
 Helps you visualize a system.
 Provides template that guides you in constructing a system.
List the principles of modeling in UML. [AU A/M 2019]
Principles of UML Modeling
 The choice of model is important.
 Every model may be expressed at different levels of precision.
 The best models are connected to reality.
UNIT-II
PART-A
1 What is a domain model? [AU A/M 2011] [AU A/M 2015]
A domain model is a visual representation of conceptual classes or real-world objects in a domain of
interest. They have also been called conceptual models, domain object models, and analysis object models.
2 What is aggregation? [AU A/M 2019]
Define aggregation and composition. [AU A/M 2011] [AU A/M 2012] [AU A/M 2014] [AU N/D 2014]
Aggregation is a vague kind of association in the UML that loosely suggests whole-part relationships
(as do many ordinary associations). It has no meaningful distinct semantics in the UML versus a pl ain
association, but the term is defined in the UML.
Composition, also known as composite aggregation, is a strong kind of whole-part aggregation and is
useful to show in some models. A composition relationship implies that 1) an instance of the part
belongs to only one composite instance at a time, 2) the part must always belong to a composite and 3)
the composite is responsible for the creation and deletion of its parts either by itself creating/deleting
the parts, or by collaborating with other objects.
3 List the relationships used in class diagram. [AU A/M 2011] [AU A/M 2014] [AU N/D 2014] [AU N/D
2015]
The relationships in class diagrams include different types of logical connections. The following are such
types of logical connections that are possible in UML:
 Association
 Directed Association
 Reflexive Association
 Multiplicity
 Aggregation
 Composition
 Inheritance/Generalization
 Realization
4 Give the hint to identify the attributes of a class. [AU N/D 2011]
To identify attributes: choose a class from the evolving object model and look for the properties associated
with it, select a property candidate (e.g., from a problem statement or a requirements document) and look for
the class that it describes. Use the Parse Requirements technique to help identify attributes.
5 What is elaboration? [AU A/M 2012] [AU A/M 2014] [AU N/D 2014]
Elaboration is the initial series of iterations during which the team does serious investigation,
implements the core architecture, clarifies most requirements, and tackles the high-risk issues. In the
UP, "risk" includes business value. Therefore, early work may include implementing scenarios that are
deemed important, but are not especially technically risky. It Build the core architecture, resolve the
high-risk elements, define most requirements, and estimate the overall schedule and resources.
6 Distinguish between method and message in object. [AU N/D 2015]
Method Message
i) Methods are similar to functions, procedures or Message essentially are non-specific
subroutines in more traditional programming function calls.
languages.
ii) Method is the implementation. Message is the instruction.
iii) In an object oriented system, a method is An object understands a message when it
invoked by sending an object a message. can match the message to a method that
has the same name as the message.
7 What are the tasks performed in elaboration. [AU N/D 2015] [AU A/M 2018]
Elaboration has the following task.
The core (risky) software architecture is programmed and tested.
Majority of the requirements are discovered and stabilized.
Major rises are mitigated or retired.
8 How to create a domain model. [AU N/D 2015] [AU N/D 2016]
Domain models are also called as conceptual models. The steps for creating a domain model are
9 Define design class diagrams. [AU M/J 2016]
A static view of the class definitions is usefully shown with a design class diagram. This illustrates the
attributes and methods of the classes.
10 Define classifier. [AU M/J 2016]
A UML classifier is "a model element that describes behavioral and structure features”. Classifiers can also
be specialized. They are a generalization of many of the elements of the UML, including classes, interfaces,
use cases, and actors. In class diagrams, the two most common classifiers are regular classes and interfaces.
11 What is qualified association? [AU M/J 2016]
A qualified association has a qualifier that is used to select an object (or objects) from a larger set of related
objects, based upon the qualifier key.
12 Define modular design. [AU M/J 2016]
Modular design is a design approach that creates things out of independent parts with standard interfaces.
This allows designs to be customized, upgraded, repaired and for parts to be reused.
13 What is the relationship of a conceptual super class to a subclass? [AU A/M 2017]
Conceptual subclasses and super classes are related in terms of set membership. Definition: All members of
a conceptual subclass set are members of their superclass set. For example, in terms of set membership, all
instances of the set CreditPayment are also members of the set Payment.
It is valuable to identify conceptual super- and subclasses, it is useful to clearly and precisely understand
generalization, super classes, and subclasses in terms of class definition and class sets.
14 Define an object. Identify the probable attributes that will be modeled in a Library database for the
object BOOK. [AU N/D 2017]
Object: It is a real-world entity. There are multiple objects available within a single system. It is a
fundamental building block of UML.
Class: A class is nothing but a container where objects and their relationships are maintained
Objects name: Book
Attributes: book name, price, author name, edition, etc

15 What is meant by attributes? [AU N/D 2018]

An attribute is a specification that defines a property of an object, element, or file. It may also refer to or set
the specific value for a given instance of such. An attribute is frequently and generally a property of a
property.
16 Define responsibility with an example. [AU A/M 2019]
UML defines a responsibility as "a contract or obligation of a classifier". Doing something itself, such as
creating an object or doing a calculation. Initiating action in other objects.
17 Define refinement. [AU A/M 2019]
Refinement is the addition of detail to a design, or in other words, making a design more concrete.
Refinement is the counterpart of abstraction. Abstracting a design means leaving out irrelevant details of that
design. Refinement also interfaces with decomposition. Decomposition is used in the context of systems. A
system can be decomposed in subsystems, that together form the complete system. The main advantage of
the technique of refinement is the reduction of complexity in the analysis and design phase.
18 Write the common uses of class diagram. [AU A/M 2019]
The common uses the class diagram can be
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
UNIT-III
PART-A
1 What is the use of system sequence diagram? [AU A/M 2011] [AU A/M 2012] [AU A/M 2014] [AU N/D
2014]
A system sequence diagram (SSD) is a sequence diagram that are used to shows, for a particular scenario
of a use case, the events that external actors generate, their order, and possible inter-system events.
A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output
events related to the systems under discussion. They are input to operation contracts and most
importantly object design.
A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events
that external actors generate their order, and inter-system events. All systems are treated as a black box;
the emphasis of the diagram is events that cross the system boundary from actors to systems.
2 What is the use of operation contracts? [AU A/M 2011]
An operation Contracts are used to describes the change in the state of the system when a system
operation is invoked.
3 Give the meaning of event, state and transition. [AU A/M 2011] [AU A/M 2012]
An event is a significant or noteworthy occurrence. For example:
• A telephone receiver is taken off the hook.
A state is the condition of an object at a moment in time the time between events. For example:
• A telephone is in the state of being \"idle\" after the receiver is placed on the hook and until it is taken
off the hook.
A transition is a relationship between two states that indicates that when an event occurs, the object
moves from the prior state to the subsequent state. For example:
• When the event \"off hook\" occurs, transition the telephone from the \"idle\" to \"active\" state.
4 Define swim lane. [AU N/D 2011]
A swim lane (or swimlane) is a visual element used in process flow diagrams, or flowcharts or activity
diagrams, that visually distinguishes responsibilities for sub-processes of a business process. Swim lanes
may be arranged either horizontally or vertically. In the accompanying example, the swimlanes are named
Customer, Sales, Contracts, Legal, and Fulfillment, and are arranged vertically.
5 What do you mean by sequence diagrams? Mention its uses. [AU N/D 2011]
Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to
the right. Sequence diagrams describe interactions among classes in terms of an exchange of messages
over time. They're also called event diagrams. Uses:These can help to predict how a system will behave
and to discover responsibilities a class may need to have in the process of modeling a new system.
6 What do you mean by sequence number in UML ? Where and for what it is used? [AU N/D 2011]
A sequence diagram is a type of interaction diagram because it describes how—and in what order—a group
of objects works together. These diagrams are used by software developers and business professionals
to understand requirements for a new system or to document an existing process.
7 Define component with an example. [AU N/D 2011]
A component provides the set of required interfaces that a component realizes or implements. These are the
static diagrams of the unified modeling language. Component diagrams are used to represent the working
and behavior of various components of a system. UML Component diagrams are used in modeling the
physical aspects of object-oriented . Component Diagram Example - Using Interface (Order System).
8 How will you reflect the version control information in UML diagrams? [AU N/D 2011]
Benefits of using version control systems include: increasing the potential for parallel and distributed work,
improved ability to track and merge changes over time and automating management of revision history.
9 Define package and draw the UML notation for package? [AU A/M 2012]
Package − Package is the only one grouping thing available for gathering structural and behavioral things.
Notation:
10 What is the use of component diagram? [AU A/M 2012] [AU N/D 2014]
What is the purpose of using a component diagram? [AU A/M 2015]
Component diagrams are used to represent the working and behavior of various components of a system.
UML Component diagrams are used in modeling the physical aspects of object-oriented system.
11 When are contracts useful? [AU A/M 2014] [AU N/D 2014]
Operation Contracts describe how the internal state of the concepts in the Domain Model may change.
Operation Contracts are described in terms of preconditions and post-conditions.
Identify system operations from the SSDs.
Identify subtle or complex system operations.
12 What is a system sequence diagram? [AU A/M 2015]
A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events
that external actors generate their order, and inter-system events. All systems are treated as a black box;
the emphasis of the diagram is events that cross the system boundary from actors to systems.
13 Differentiate: sequence and communication diagrams. [AU A/M 2015]
Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to
the right.
Communication diagrams illustrate object interactions in a graph or network format, in which objects
can be placed anywhere on the diagram.
14 Draw the state machine diagram for telephone. [AU A/M 2015]

15 What is meant by system behavior? [AU N/D 2015]

System behavior is a description of what a system does, without explaining how it does it. One part of that
description is a system sequence diagram.
16 What are the steps for mapping designs to code? [AU N/D 2015] [AU M/J 2016]
The task of transforming an object design into code is a straightforward process. Implementation in an
object - oriented language requires writing source code for:
 class and interface definitions
 method definitions
The following figure shows the representation of the class Circle using C++.
17 How to naming system events and operation? [AU N/D 2016]

System events (and their associated system operations) should be expressed at the level of intent rather than
in terms of the physical input medium or interface widget level.
It also improves clarity to start the name of a system event with a verb Thus "enter item" is better than
"scan" (that is, laser scan) because it captures the intent of the operation while remaining abstract and
noncommittal with respect to design choices about what interface is used to capture the system event.
18 Define system events and the system boundary? [AU N/D 2016]
To identify system events, it is necessary to be clear on the choice of system boundary, as discussed in the
prior chapter on use cases. For the purposes of software development, the system boundary is usually
chosen to be the software system itself; in this context, a system event is an external event that directly
stimulates the software.
19 What are the strengths and weakness of sequence and collaboration diagram? [AU A/M 2017]
Sequence Diagram Collaboration Diagram
Strengths Strengths
 They clearly show sequence or time ordering of  Simplicity
messages. Weakness
 The notation is rather simple  They are good at describing behavior, they do not
Weakness define it.
 Forced to extend to right when adding new  Do not show all interaction and control that is
objects. needed to give a computationally complete
 Consumes a lot of horizontal space. description.
 More difficult to see sequence of messages.
 Fewer notation options
20 Differentiate between logical architecture and layers. [AU A/M 2017]
The logical architecture is the large-scale organization of the software classes into packages (or
namespaces), subsystems, and layers. It's called the logical architecture because there's no decision
about how these elements are deployed across different operating system processes or across physical
computers in a network.
A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive
responsibility for a major aspect of the system. Also, layers are organized such that "higher" layers
(such as the UI layer) call upon services of "lower" layers, but not normally vice versa.
21 Outline the key reason for modeling a package diagram. [AU N/D 2017]
The key reason for modeling a package diagram is to simplify complex class diagrams, it can group classes
into packages. Package diagrams are used to structure high level system elements. Packages are used for
organizing large system which contains diagrams, documents and other key deliverables.
22 Name the two types of UML interaction diagrams. [AU N/D 2017]
The two types of UML interaction diagrams are
 Sequence diagram
 Collaboration diagram.
23 What is activity diagram? Mention the elements of an activity diagram. [AU A/M 2018]
An activity diagram visually presents a series of actions and the flow of control in a system.
Fundamental elements of the activity are actions and control elements (decision, division, merge, initiation,
end, etc.): Elements are connected by so-called “activity edges” and form the “control flow”, which can
also be casually called 'flow'.
24 When to use package diagrams and collaboration diagram? [AU A/M 2018]
Packages are a vital tool for large projects. Use packages whenever a class diagram that encompasses the
whole system is no longer legible on a single letter-size (or A4) sheet of paper. Packages are particularly
useful for testing.
Collaboration diagrams useful whenever you want to refer to a particular interaction.
25 How to use the creating methods from interaction diagrams? [AU A/M 2018]
The sequence of the messages in an interaction diagram translates to a series of statements in the method
definitions.
26 List out the interaction diagrams. [AU A/M 2019]
There are two kinds of interaction diagrams
 Sequence diagrams
 Collaboration diagrams
UNIT-IV
PART-A
1 What is a design pattern? [AU A/M 2011] [AU A/M 2014] [AU N/D 2014]
A design pattern in architecture and computer science is a formal way of documenting a solution to a design
problem in a particular field of expertise. An organized collection of design patterns that relate to a
particular field is called a pattern language. The elements of this language are entities called patterns.
A pattern is a named problem/solution pair that can be applied in new context, with advice on how to
apply it in novel situations and discussion of its trade-offs.
2 Define coupling? [AU A/M 2011] [AU A/M 2012]
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other
elements. An element with low (or weak) coupling is not dependent on too many other elements; "too many"
is context-dependent, but will be examined. These elements include classes, subsystems, systems, and so on.
3 Distinguish between coupling and cohesion. [AU N/D 2011] [AU N/D 2015] [AU N/D 2016] [AU A/M
2017]
Cohesion Coupling
Cohesion is the indication of the Coupling is the indication of the
relationship within module. relationships between modules.
Cohesion is a degree (quality) to which a Coupling is a degree to which a
component / module focuses on the single component / module is connected to the
thing. other modules.
4 Write a note on Patterns. [AU N/D 2011]
apply it in novel situations and discussion of its trade-offs

Each pattern describes a problem that occurs over and over again in our environment, and then describes the
core of the solution to that problem, in such a way that you can use this solution a million times over,
without ever doing it the same way twice. The usefulness of speaking of patterns is to have a common
terminology for discussing the situations designers already see over and over.
5 How to use patterns? [AU A/M 2012]
A design pattern provides a general reusable solution for the common problems occurs in software design.
The patterns typically show relationships and interactions between classes or objects. The idea is to speed
up the development process by providing well tested, proven development/design paradigm.
6 What is meant by low coupling? [AU A/M 2014] [AU N/D 2014]
Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:
• low dependency between classes;
• low impact in a class of changes in other classes;
• high reuse potential;
7 Define pattern. [AU A/M 2015]
8 ‘A system must be loosely coupled and highly cohesive’ justify. [AU A/M 2015]
A system must be loosely coupled and highly cohesive
Low Coupling
In a system modules should be as independent as possible from other modules, so that changes to module
don’t heavily impact other modules. By aiming for low coupling, you can easily make changes to the
internals of modules without worrying about their impact on other modules in the system. Low coupling also
makes it easier to design, write, and test code since our modules are not interdependent on each other. We
also get the benefit of easy to reuse and compose-able modules. Problems are also isolated to small, self-
contained units of code.
High Cohesion
We want to design components that are self-contained: independent, and with a single, well-defined purpose
Cohesion often refers to how the elements of a module belong together. Related code should be close to each
other to make it highly cohesive.Easy to maintain code usually has high cohesion. The elements within the
module are directly related to the functionality that module is meant to provide. By keeping high cohesion
within our code, we end up trying DRY code and reduce duplication of knowledge in our modules. We can
easily design, write, and test our code since the code for a module is all located together and works together.
9 When to use patterns. [AU N/D 2015]
When we can use patterns? [AU A/M 2019]
We can use patterns To speed up the development process by providing well tested, proven
development/design paradigm. A design pattern provides a general reusable solution for the common
problems occurs in software design. The patterns typically show relationships and interactions between
classes or objects.
10 Mention the interface and domain layer responsibilities. [AU M/J 2016]
The UI layer should not have any domain logic responsibilities. It should only be responsible for user
interface tasks, such as updating widgets. The UI layer should forward requests for all domain-oriented tasks
on to the domain layer, which is responsible for handling them.
11 Define patterns and design patterns? [AU N/D 2016]
A design pattern in architecture and computer science is a formal way of documenting a solution to a design
problem in a particular field of expertise. An organized collection of design patterns that relate to a
particular field is called a pattern language. The elements of this language are entities called patterns.
12 What is refactoring? [AU N/D 2016]
Refactoring is "the process of changing a software system in such a way that it does not alter the external

behavior of the code yet improves its internal structure," according to Martin Fowler, the "father"
of refactoring.
13 Define modular design. [AU A/M 2017]
Modular design is a design approach that creates things out of independent parts with standard interfaces.
This allows designs to be customized, upgraded, repaired and for parts to be reused.
Coupling and cohesion are old principles in software design; designing with objects does not imply ignoring
well-established fundamentals. Another of these, which is strongly related to coupling and cohesion is to
promote modular design.
14 Define cohesion and coupling. [AU N/D 2017]
Cohesion is the indication of the relationship within module. Cohesion shows the module's relative
functional strength.
Coupling is the indication of the relationships between modules. Coupling shows the relative
independence among the modules.
15 What are design patterns? [AU N/D 2017]
Design patterns are devices that allow systems to share knowledge about their design, by describing
commonly recurring structures of communicating components that solve a general design problem within a
particular context. A design pattern provides a scheme for refining the subsystems or components of a
software system or the relationships among them. Design patterns are documented by writing essays in a
fairly well-defined form.
16 Mention the list of behavioral patterns used during design phase of software development. [AU A/M
2018]
Behavioral Patterns used during design phase of software development are
• Chain of Responsibility (requests through a chain of candidates)
 Command (encapsulates a request)
• Interpreter (grammar as a class hierarchy)
 Iterator (abstracts traversal and access)
• Mediator (indirection for loose coupling)
• Memento (externalize and re-instantiate object state)
• Observer (defines and maintains dependencies)
• State (change behaviour according to changed state)
 Strategy (encapsulates an algorithm in an object)
• Template Method (step-by-step algorithm w/ inheritance)
 Visitor (encapsulated distributed behaviour)
17 List out the types of coupling. [AU A/M 2018]
The types of coupling.
Low Coupling
High Coupling
18 What is refactoring and testing? [AU A/M 2018]
Refactoring is "the process of changing a software system in such a way that it does not alter the external
behavior of the code yet improves its internal structure," according to Martin Fowler, the "father"
of refactoring.
The process of Testing the individual classes are called testing. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free.
UNIT-V
PART-A
1 List out any four reasons for the complexity of software. [AU N/D 2011]
 Improve Code Quality.
 Reduce Maintenance Cost.
 Heighten Productivity.

 Increase Robustness.
 Meet Architecture Standards.
2 List out issues in OO testing. [AU N/D 2015]
 Unit of testing
 Implications of encapsulation and composition
 Implications of inheritance
 Implications of Polymorphism
3 Distinguish between OO integration testing and OO system testing. [AU M/J 2016]
Regression Testing is defined as a type of software testing to confirm that a recent program or code change
has not adversely affected existing features. Regression Testing is nothing but a full or partial selection of
already executed test cases which are re-executed to ensure existing functionalities work fine.
4 What is regression testing? [AU N/D 2016]
Regression Testing is defined as a type of software testing to confirm that a recent program or code change
has not adversely affected existing features. Regression Testing is nothing but a full or partial selection of
already executed test cases which are re-executed to ensure existing functionalities work fine.
5 Mention the steps involved in mapping design to code. [AU A/M 2017]
Implementation in an object-oriented programming language requires writing source code
for:
Class and interface definitions
Method definitions
6 Explain about OO Integration Testing. [AU A/M 2017]
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in software
testing in which individual software modules are combined and tested as a group. It occurs after unit testing
and before validation testing.
7 What is unit testing? [AU N/D 2017]
UNIT TESTING is a level of software testing where individual units/ components of a software are tested.
The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable
part of any software.
8 Define a test case. Give Example. [AU N/D 2017]
A TEST CASE is a set of conditions or variables under which a tester will determine whether a system
under test satisfies requirements or works correctly. The process of developing test cases can also help find
problems in the requirements or design of an application.
Example:
 Test Case 1: Check results on entering valid User Id & Password

 Test Case 2: Check results on entering Invalid User ID & Password
 Test Case 3: Check response when a User ID is Empty & Login Button is pressed, and many more.
9 What is meant by OO testing? [AU N/D 2018]
Object oriented testing is a requirements based Testing : Requirements-based testing is a testing approach
in which test cases, conditions and data are derived from requirements. It includes functional tests and also
non-functional attributes such as performance, reliability or usability.
10 Define class testing. [AU N/D 2018] [AU A/M 2019]
Class testing is whether the class attributes are implemented as per design and whether the methods and the
interfaces are error-free.
11 Write about GUI testing. [AU A/M 2019]
GUI testing is the process of ensuring proper functionality of the graphical user interface (GUI ) for a given
application and making sure it conforms to its written specifications.

UNIT-I
1 Briefly explain the different phases of unified process.[AU A/M 2011] [AU M/J 2012] [AU N/D
2014] [AU N/D 2015] [AU A/M 2019]
What do you mean by unified process in OOAD? Explain the phases with suitable
diagrams.[AU N/D 2011]
Explain in detail about/Unified Process in Object /Oriented /Analysis Design? Explain the
phases with neat diagrams. [AU M/J 2016] [AU N/D 2016] [AU A/M 2017]
UP (UNIFIED PROCESS) PHASES

Software development process is an approach to i) Build, ii) Deploy and iii) Maintain the
software.
• The Unified Process (UP) is a software development process mainly for building object
oriented systems.
• The detailed refinement of the unified process is Rational Unified Process or RUP.
• The Unified Process
◦ is an iterative process
◦ provides an example structure for how to do Object Oriented Analysis and Design
◦ is flexible
◦ can be applied to lightweight and agile approach.
◦ combines iterative lifecycle and risk driven development into a cohesive and well
documented process description.
UP Phases
There are four major phases of UP
They are
1) Inception
2) Elaboration
3) Construction
4) Transition
Inception
• Approximate vision
• Business scope
• Vision
• Scope
• Vogue Estimates
Elaboration
Elaboration is the phase where the core architecture is iteratively implemented.
Here the high risk issues are mitigated.
Elaboration includes
• Refined vision
• Iterative implementation of the core architecture
• Resolution of high risks
• Identification of most requirements and scope
• More realistic estimates
Construction
Construction involves
• Iterative implementation of the remaining lower rise and easier elements
• Preparation for deployment
Transition
Transition involves
• Beta tests and
• Deployment.
Figure Schedule oriented terms in UP

Milestone – An iteration endpoint where some significant
decision/evaluation occurs
Release – A stable executable subset of the final product
Increment – the difference between the release of two subsequent
iterations
Final production
release – The system is released for production use
UP Disciplines
There are several disciplines in UP.
Some are
• Business Modeling
◦ The domain model artifact to visualize concepts in application domain.
• Requirements
◦ Usecase model
Supplementary specification to capture functional and non functional requirements
• Design
◦ Design Model artifact
◦ Design software objects
• Implementation
Programming and building the system
• Environment
◦ Establishing the tools and customizing the process for the project.
Figure: Disciplines and phases

2 Explain with an example, how use case modeling is used to describe functional requirements.
Identify the actors, scenario and cases for the example.(16) .[AU A/M 2011] [AU M/J 2012] [AU
M/J 2014]
Explain about use case model for a case study of your choice. [AU N/D 2015]
(i)Write the use of case modeling and explain in detail. (7) [AU A/M 2019]
(ii)Write a short note on domain models. (6) [AU A/M 2019]
Draw and discuss and analysis model for banking system.(8) [AU A/M 2018]
Explain in detail about use case diagrams.(6) [AU A/M 2018]
Explain briefly the elements of use case diagrams. [AU N/D 2018]
USE CASE MODELING is used to describe functional requirements
Use cases and Use case Model
 Use Cases are text documents and not diagrams.
 Use case modeling is primarily an act of writing text, not drawing diagrams.
 Use cases are requirements Functional or Behavior
 Use cases emphasize the user goals and perspectives.
The strength of use cases is the ability to scale both up and down in terms of
• Sophistications and
• Formality
Three kinds of Actors
An actor is anything with behavior including the System Under Discussion (SUD) when it
calls upon services of other systems.
Actors are roles played not only by people but by organization.
Example:
• Software
• Machines
In relation to SUD there are three types of actors
 Primary actor
 Supporting actor
 Offstage actor
(1) Primary actor
It has user goals fulfilled by using services of SUD.
Example: Cashier
Finds user goals that drive use cases
(2) Supporting actor
It provides services to SUD.
Example: Automated payment authorization
(3) Offstage actor
It has an interest in the behavior of use cases but not primary or supporting.
Example: A government tax agency.
Use case formats
There are different formats for use cases like
• Brief
• Casual
• Fully dressed
Brief
• One paragraph summary of main success scenario.
• It is written during early requirements analysis.
• It is written to get a quick sense of subject and scope
• It can be written in a few minutes.

Example:
Process sale (given previously)
Casual
 Informal paragraph format
 It involves multiple paragraphs that cover various scenarios.
Example:
Handle Returns
Fully dressed
• Detailed steps are written.
• Supporting sections like preconditions are present.
Example:
Next Gen case study
Create a Use Case Diagram
 Identifying Actors
Actors are external entities that interact with your system. It can be a person, another system or an
organization. In a banking system, the most obvious actor is the customer. Other actors can be bank
employee or cashier depending on the role you’re trying to show in the use case.
An example of an external organization can be the tax authority or the central bank. The loan
processor is a good example of an external system associated as an actor.
 Identifying Use Cases
Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from
the system. In a banking system, a customer will need to open accounts, deposit and withdraw funds,
request check books and similar functions. So all of these can be considered as use cases.
 Look for Common Functionality to use Include
 Is it Possible to Generalize Actors and Use Cases
 Optional Functions or Additional Functions
EXAMPLE:

3 By consisdering the library management system, perform the object oriented system
development and give the usecase for the same(use include,extend and generalization) .[AU N/D
2011]

4 Explain about operation contracts. [AU M/J 2012] [AU N/D 2014]
· Contracts for operations define system behavior
· Describe the outcome of executing system operation in terms of state changes to domain objects.
Contracts
· Contracts describe detailed system behavior in terms of state changes to objects in the Domain
Model, after a system operation has executed.
· Contracts are defined for system operations
operations that the system offers in its public interface to handle incoming system events.
· System operations can be identified by discovering these system events
Example Contract: enteritem

Contract C02: enteritem
Operation: enterltem(itemlD: ItemID, quantity: integer)
Cross References: Use Cases: Process Sale
Preconditions: There is a sale underway.
Postconditions: — A SalesLineltem instance sli was created

(instance creation).
— sli was associated with the current Sale
(association formed).
— sli.quantity became quantity (attribute
modification).
— sli was associated with a ProductSpecification,
based on itemlD match (association formed).
When Are Contracts Useful ?
Use cases are main repository of project’s requirements.
Situations where details and complexity of required state changes are awkward to capture in use cases.
e.g. airline reservation system and the system operation addNewReservation.
Guidelines for creating Contracts

1. Identify system operations from the SSDs.
2. Construct a contract for system operations that are complex or subtle in their results, or which
are not clear in the use case
3. Describe postconditions, using the following categories:
o instance creation and deletion
o attribute modification
o associations formed and broken
5 List various UML diagrams and explain the purpose of each diagram.(16) [AU M/J 2014]
The types of UML Diagram?
 UML Use Case Diagram
 UML Sequence Diagram
 UML Component Diagram
 UML Class Diagram
 UML Activity Diagram
 UML Collaboration Diagram

 UML Deployment Diagram

 UML Statechart Diagram
 UML Package Diagram
The Purposes of UML diagrams
 To reason about system behavior.
 To detect errors and omissions early in the life cycle.
 To present proposed designs and communicate with stakeholders.
 To understand requirements.
 To drive implementation.
6 i)Describe the basic activities in object-oriented analysis and explain, How use case modeling is
useful in analysis. (10)
ii)Explain about the next gen POS system. (6) [AU N/D 2014]
Basic activities involved in OOA process:

1. Actor’s identification
2. Using UML activity diagram develop a simple business process
3. Develop the use case
4. Prepare interaction diagram
5. Classification-develop static UML class diagram
6. Iterate and refine
Use case modeling(Ref U-I ,Q-2)
The next gen POS system:
 Customer arrives at POS checkout with goods and/or services to purchase.
 Cashier starts a new sale.
 Cashier enters item identifier.
 System records sale line item and presents item description, price, and running total.
 Price calculated from a set of price rules.
7 What is the purpose of a use case model? Identify the actors, scenarios and use cases for a library
management system. [AU N/D 2016]

The purpose of a use case model:

Use case diagrams are typically developed in the early stage of development and people often apply
use case modeling for the following purposes:
 Specify the context of a system
 Capture the requirements of a system
 Validate a systems architecture
 Drive implementation and generate test cases
 Developed by analysts together with domain experts
8 Explain about UML diagrams in detail with neat example.[AU A/M 2017]
Types of UML Diagrams

The current UML standards call for 13 different types of diagrams: class, activity, object, use case,
sequence, package, state, component, communication, composite structure, interaction overview,
timing, and deployment.
These diagrams are organized into two distinct groups: structural diagrams and behavioral or
interaction diagrams.
Structural UML diagrams
 Class diagram
 Package diagram
 Object diagram
 Component diagram
 Deployment diagram
Behavioral UML diagrams
 Activity diagram
 Sequence diagram
 Use case diagram
 State diagram
 Communication diagram
UNIT-II
1 Describe the strategies used to identify conceptual classes. Describe the steps to create a
domain model used for representing conceptual classes (16).[AU A/M 2011] [AU M/J 2012]
[AU M/J 2014] [AU N/D 2014] [AU N/D 2016] .[AU A/M 2017] [AU A/M 2018] [AU N/D 2018]
(i) Explain the guidelines for finding Conceptual Classes with neat diagrams
(ii) Illustrate the concept of Domain model with examples. [AU M/J 2016]
Explain the conceptual model of the UML in detail? Explain various common mechanisms
used in UML. (13) [AU A/M 2019]
(i) Explain in detail about conceptual classes and description classes. (5) [AU A/M 2019]
Finding Conceptual Classes

The three strategies to find conceptual classes are
1) Reuse or modify existing models
2) Use a category list
3) Identity noun phrases
The steps for creating a domain model are


2 Explain the relationship that are possible among the classes in the UML representation with
your own example. .[AU N/D 2011]
Relationships
There are mainly three kinds of relationships in UML:
1. Dependencies
2. Generalizations
3. Associations
3 Explain the following with example: [AU N/D 2011]

I. Conceptual class diagram (REFER QUESTION-2)
II. Activity diagram( REFER UNIT-3 Q-1)
4 With a suitable example explain how to design a class. Give all possible representation in
class(name, attribute, visibility, methods, responsibilities) .[AU N/D 2011]
Class
A description of a group of objects all with similar roles in the system, which consists of:
 Structural features (attributes) define what objects of the class "know"
 Represent the state of an object of the class
 Are descriptions of the structural or static features of a class
 Behavioral features (operations) define what objects of the class "can do"

 Define the way in which objects may interact

 Operations are descriptions of behavioral or dynamic features of a class
1. Class Name
 The name of the class appears in the first partition.
2. Class Attributes
 Attributes are shown in the second partition.
 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
 Operations are shown in the third partition. They are services the class provides.
 The return type of a method is shown after the colon at the end of the method
signature.
 The return type of method parameters is shown after the colon following the
parameter name.
 Operations map onto class methods in code
4.Visibility of Class attributes and Operations
In object-oriented design, there is a notation of visibility for attributes and operations. UML
identifies four types of visibility: public, protected, private, and package.
The +, -, # and ~ symbols before an attribute and operation name in a class denote the visibility of
the attribute and operation.
 + denotes public attributes or operations
 - denotes private attributes or operations
 # denotes protected attributes or operations
 ~ denotes package attributes or operations
(EXAMPLE: REFER UNIT-2 ,Q-2)
5 i) Describe the UML notations for classes diagram with an example. [AU M/J 2012] [AU N/D
2014]
ii) Explain the concept of link, association and inheritance. [AU M/J 2012] [AU N/D 2014]
Describe UML notation for Class diagram with an example. Explain the concept of link,
association and inheritance. [AU M/J 2016]
Explain association, aggregation and composition relationships in detail. [AU N/D 2016] [AU A/M
2017] [AU A/M 2019]
(ii) Differentiate aggregation and composition. (8) [AU A/M 2019]
Discuss about aggregation and composition.(7) [AU A/M 2018]
UML notations for classes:

Example: Ref U-2, Q-3
Link, Association And Inheritance

Simple Association:
 A structural link between two peer classes.
 There is an association between Class1 and Class2
A solid line connecting two classes
Composition:
A special type of aggregation where parts are destroyed when the whole is destroyed.
 Objects of Class2 live and die with Class1.
 Class2 cannot stand by itself.
A solid line with a filled diamond at the association connected to the class of composite
Aggregation:
A special type of association. It represents a "part of" relationship.
 Class2 is part of Class1.
 Many instances (denoted by the *) of Class2 can be associated with Class1.
 Objects of Class1 and Class2 have separate lifetimes.
A solid line with an unfilled diamond at the association end connected to the class of composite
Dependency:
 Exists between two classes if the changes to the definition of one may cause changes to the
other (but not the other way around).
 Class1 depends on Class2
A dashed line with an open arrow
Inheritance (or Generalization):
 Represents an "is-a" relationship.
 An abstract class name is shown in italics.
 SubClass1 and SubClass2 are specializations of Super Class.
A solid line with a hollow arrowhead that point from the child to the parent class
6 Write briefly about elaboration and discuss the difference between elaboration and inception
with examples.(16) [AU M/J 2014] .[AU A/M 2017]
Elaboration has the following series of iterations.

1) The core (risky) software architecture is programmed and tested.
2) Majority of the requirements are discovered and stabilized.
3) Major rises are mitigated or retired.
Elaboration normally consists of two or three iterations.
During these iterations the team
• Does serious investigations
• Implements programs and tests for core architecture
• Clarifies requirements tackles high risk issues.
Each iteration is time boxed. i.e. its end date is fixed. It lasts for two to six weeks.
• During elaboration the models are fully developed in preparation for implementation.
• During elaboration, the code and design are in production. It is called “Executable
architecture” or “Architectural baseline”.
Elaboration is
• Building the core architecture
• Resolving the high risk elements
• Define more requirements and Estimate overall schedule and resources
• Approximate vision
• Business scope
• Vision
• Scope
• Vogue Estimates
7 Construct design for library information system which compresses and following notations.
(i)Aggregation
(ii)Compositions
(iii)Associations[AU N/D 2015]

UNIT-III
1 Explain about activity diagram with an example. .[AU A/M 2011] [AU N/D 2014]
What is UML Activity Diagram? Using an example explain the feature of basic UML activity
diagram notation. [AU M/J 2016] [AU N/D 2016]
With an example, explain the needs for activity diagram. [AU N/D 2018]
Activity diagram represents the performance of operations and transitions are triggered by
Activity diagram shows control flow and data flow.
Activity diagrams are mainly used as a flowchart that consists of activities performed by the system.
Activity diagrams are not exactly flowcharts as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane, etc.
Before drawing an activity diagram, we should identify the following elements −
 Activities
 Association
 Conditions
 Constraints
Where to Use Activity Diagrams?
Activity diagram is suitable for modeling the activity flow of the system. An application can have
multiple systems. Activity diagram also captures these systems and describes the flow from one
system to another.
NOTATIONS:
Initial State or Start Point

A small filled circle followed by an arrow represents the initial action state or the start point for any
activity diagram. For activity diagram using swimlanes, make sure the start point is placed in the top
left corner of the first column.
Activity or Action State

An action state represents the non-interruptible action of objects. You can draw an action state in
SmartDraw using a rectangle with rounded corners.
Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action state to another.
They are usually drawn with an arrowed line.
Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow
from an action to an object means that the action creates or influences the object. An object flow
arrow from an object to an action indicates that the action state uses the object.
Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a decision prior to
moving on to the next activity, add a diamond between the two activities. The outgoing alternates
should be labeled with a condition or guard expression. You can also label one of the paths "else."
Guards
In UML, guards are a statement written next to a decision diamond that must be true before moving
next to the next activity. These are not essential, but are useful when a specific answer, such as
"Yes, three labels are printed," is needed before moving forward.
Synchronization
A fork node is used to split a single incoming flow into multiple concurrent flows. It is represented
as a straight, slightly thicker line in an activity diagram.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.
Time Event

This refers to an event that stops the flow for a time; an hourglass depicts it.
Merge Event
A merge event brings together multiple flows that are not concurrent.
Sent and Received Signals

Signals represent how activities can be modified from outside the system. They usually appear in
pairs of sent and received signals, because the state can't change until a response is received, much
like synchronous messages in a sequence diagram. For example, an authorization of payment is
needed before an order can be completed.
Interrupting Edge
An event, such as a cancellation, that interrupts the flow denoted with a lightning bolt.
Swimlanes
Swimlanes group related activities into one column.

EXAMPLE:
Example: Library Management System

2 Illustrate with an example, the relationship between sequence diagram and use cases.(16) [AU
A/M 2011] [AU M/J 2014] [AU N/D 2014]
What are the system sequence diagrams? What is the relationship between SSDs and use
cases? Explain with an example. [AU N/D 2016]
Explain about relationship between sequence and use cases in detail. (13) [AU A/M 2019] [AU
A/M 2018]
We can elaborate use case scenarios with a sequence diagram: Sequence Diagram models the
collaboration of objects based on a time sequence. It shows how the objects interact with others, in
a particular, scenario of a use case.
Example:

3 Explain Or with an example Interaction diagram. .[AU A/M 2011] [AU A/M 2018]
What do you mean by interaction diagrams? Explain them with a suitable example. .[AU N/D
2011]
Interaction Diagrams
The main idea in developing interaction diagram is simplicity.
But interaction diagrams lose clarity with conditional behavior.
To capture complex behavior in a single diagram, we can go for activity diagrams.
Interaction diagrams are models that describe how groups of objects collaborate in some behavior.
Sequence Diagram
An object is shown as a box at the top of a dashed vertical line.
This vertical line is called objects life line. The life line represents objects life during
interaction.
This was given by Jacobson
Each message is represented by an arrow between the life lines of two objects.
The order of messages occur from top to bottom of the page.
Message contains message name, arguments and some control information.
Self call – is an message that an object sends to itself by sending message arrow back to the
same life line.

Two control information are valuable.

1) There is a condition which indicates when a message is sent only if condition is true.
2) Next is the iteration maker, which shows that a message is sent many times to multiple
receiver objects Basics of the iteration are shown within brackets *[for all order lines]
◦ A return can be included to indicate the return from a message, not a new
message.
◦ Return is indicated by dashed line.
Sequence diagrams are also valuable for concurrent processes.
At the creation of transaction, a Transaction coordinator is created. This coordinator creates

transaction checker objects which is responsible for a particular check.
Different checking processes are added. Each checker is called asynchronously and
proceeds in parallel.
When transaction checker completes, it informs transaction coordinator. After all checkers
are completed the coordinator notifies the transaction that all is well.
The half arrow heads indicate asynchronous message. It does not block the caller but carries
its own processing. It does one of the following things.
1) Create a new thread, in which case it links to the top of an activation.
2) Create a new objects
3) Communicate with a thread that is already running.
Object deletion is shown with a large X.
Objects can self destruct or they can be destroyed by another message.
A sequence diagram shown an interaction arranged in a time sequence.
It shows the objects participating in interaction by their life lines and the messages they
exchange, arranged in a time sequence.

Diagram A sequence diagram has 2 dimensions
1) Vertical dimension represents time [Lifetime]

2) Horizontal dimension represents different objects
We can look at the sequence diagram and understand the overall control flow of a program.
Collaboration Diagram
A collaboration diagram represents a collaboration which is a set of objects related to
achieve a desired outcome.
In collaboration, the sequence is indicated by numbering the messages several numbering
schemes are available.
With Simple Numbering
COLLABORATION DIAGRAM
4 Discuss about UML deployment and component diagrams. Draw the diagrams for banking
applications.(16) .[AU A/M 2011] [AU M/J 2014]
Discuss about UML deployment and component diagrams with suitable examples.
[AU M/J 2012]
Write short notes about deployment diagram (8) [AU N/D 2014]
Component Diagrams
Purpose of Component Diagrams
 Visualize the components of a system.
 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.
Component diagrams can be used to −
 Model the components of a system.
 Model the database schema.
 Model the executables of an application.
 Model the system's source code.

Before drawing a component diagram, the following artifacts are to be identified clearly −
 Files used in the system.
 Libraries and other artifacts relevant to the application.
 Relationships among the artifacts.
After identifying the artifacts, the following points need to be kept in mind.
 Use a meaningful name to identify the component for which the diagram is to be drawn.
 Prepare a mental layout before producing the using tools.
 Use notes for clarifying important points.
Deployment diagram
The purpose of deployment diagrams can be described as −
 Visualize the hardware topology of a system.
 Describe the hardware components used to deploy software components.
 Describe the runtime processing nodes.
Deployment diagram represents the deployment view of a system. It is related to the component
diagram because the components are deployed using the deployment diagrams. A deployment
diagram consists of nodes. Nodes are nothing but physical hardware used to deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is very
important as it controls the following parameters −
 Performance
 Scalability
 Maintainability
 Portability
Before drawing a deployment diagram, the following artifacts should be identified −
 Nodes
 Relationships among nodes
Example –Banking application

5 Explain the state chart diagram with a suitable example. Also define its components and use.
.[AU N/D 2011]
State chart diagram is used to describe the states of different objects in its life cycle. Emphasis is
placed on the state changes upon some internal or external events. These states of objects are
important to analyze and implement them accurately. State chart diagrams are very important for
describing the states.
Example

6 Consider the Hospital management system application with the following requirements. .[AU
N/D 2011]
I. System should handle the in-patient, out-patient information through receptionist.
II. Doctors are allowed to view the patient history and give their prescription.
III. There should be a information system to provide the required information.
Give the state chart, component and deployment diagrams.
The state chart diagrams:
The component diagram:
The deployment diagram:

7 When to use activity diagram. Describe the situations with an example. [AU M/J 2012]
 Analyzing a use case.
At this stage, I'm not interested in allocating actions to objects; I just need to understand
what actions need to take place and what the behavioral dependencies are. I allocate
methods to objects later and show those allocations with an interaction diagram.
 Understanding workflow.
Even before I get into use cases, I find activity diagrams very useful for understanding a
business process. I can easily draw these diagrams together with business experts to
understand how a business operates and how it may change.
 Describing a complicated sequential algorithm.
In this case, an activity diagram is really nothing more than a UML-compliant flowchart.
The usual pros and cons of flowcharts apply.
 Dealing with multithreaded applications.
I have not personally used activity diagrams for this purpose, but I have heard some good
reports.
Example: (Ref:U-3,Q-1)
8 Compare sequence vs collaboration diagram with suitable example. [AU M/J 2012]
SEQUENCE DIAGRAMS COLLABORATION DIAGRAMS
The sequence diagram represents the The collaboration diagram also comes under
UML, which is used to visualize the the UML representation which is used to
sequence of calls in a system that is used visualize the organization of the objects and
to perform a specific functionality. their interaction.
The collaboration diagram are used to

The sequence diagram are used to represent the structural organization of the
represent the sequence of messages that system and the messages that are sent and
are flowing from one object to another. received.

The sequence diagram is used when time The collaboration dagram is used when
sequence is main focus. object organization is main focus.
The collaboration diagrams are better suited

The sequence diagrams are better suited of for depicting simpler interactions of the
analysis activities. smaller number of objects.
Example: Ref U-3,Q-3
9 Explain the logical architecture and UML package diagram.(16) [AU M/J 2014]
The logical architecture is the large-scale organization of the software classes into packages,
subsystems, and layers.
It will not represents how the elements are deployed across different operating system processes or
across physical computers in a network.
A UML package diagram provides a way to group elements.
Package diagrams are used to structure high level system elements. Packages are used for
organizing large system which contains diagrams, documents and other key deliverables.
 Package Diagram can be used to simplify complex class diagrams, it can group classes
into packages.
 A package is a collection of logically related UML elements.
 Packages are depicted as file folders and can be used on any of the UML diagrams.
 Packages appear as rectangles with small tabs at the top.
 The package name is on the tab or inside the rectangle.
 The dotted arrows are dependencies.
 One package depends on another if changes in the other could possibly force changes in
the first.
 Package name should not be the same for a system, however classes inside different
packages could have the same name.
 Packages can include whole diagrams, name of components alone or no components at
all.
EXAMPLE:

10 Discuss about the UML State Machine diagrams and modeling.(16) [AU M/J 2014]
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions. State diagrams are also referred to as State machines and State-chart Diagrams. These
terms are often used interchangeably. So simply, a state diagram is used to model the dynamic
behavior of a class in response to time and changing external stimuli. We can say that each and
every class has a state but we don’t model every class using State diagrams. We prefer to model the
states with three or more states.
Uses of statechart diagram –
 We use it to state the events responsible for change in state (we do not show what processes
cause those events).
 We use it to model the dynamic behavior of the system .
 To understand the reaction of objects/classes to internal or external stimuli.
First let us understand what are Behavior diagrams? There are two types of diagrams in UML :
1. Structure Diagrams – Used to model the static structure of a system, for example- class
diagram, package diagram, object diagram, deployment diagram etc.
2. Behavior diagram – Used to model the dynamic change in the system over time. They are
used to model and construct the functionality of a system. So, a behavior diagram simply
guides us through the functionality of the system using Use case diagrams, Interaction
diagrams, Activity diagrams and State diagrams.
Difference between state diagram and flowchart –
The basic purpose of a state diagram is to portray various changes in state of the class and not the
processes or commands causing the changes. However, a flowchart on the other hand portrays the
processes or commands that on execution change the state of class or an object of the class.
Figure – a state diagram for user verification

The state diagram above shows the different states in which the verification sub-system or class
exist for a particular system.
Basic components of a statechart diagram –
1. Initial state – We use a black filled circle represent the initial state of a System or a class.
Figure – initial state notation

2. Transition – We use a solid arrow to represent the transition or change of control from one
state to another. The arrow is labelled with the event which causes the change in state.
Figure – transition

3. State – We use a rounded rectangle to represent a state. A state represents the conditions or
circumstances of an object of a class at an instant of time.
Figure – state notation

4. Fork – We use a rounded solid rectangular bar to represent a Fork notation with incomig
arrow from the parent state and outgoing arrows towards the newly created states. We use the
fork notation to represent a state splitting into two or more concurrent states.
Figure – a diagram using the fork notation

5. Join – We use a rounded solid rectangular bar to represent a Join notation with incoming
arrows from the joining states and outgoing arrow towards the common goal state. We use the
join notation when two or more states concurrently converge into one on the occurrence of an
event or events.
Figure – a diagram using join notation

6. Self transition – We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon the
occurrence of an event. We use self transitions to represent such cases.
Figure – self transition notation

7. Composite state – We use a rounded rectangle to represent a composite state also.We
represent a state with internal activities using a composite state.
Figure – a state with internal activities

8. Final state – We use a filled circle within a circle notation to represent the final state in a
state machine diagram.
Figure – final state notation

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.
2. Identify the possible states in which the object can exist (boundary values corresponding to
different attributes guide us in identifying different states).
3. Label the events which trigger these transitions.
Example – state diagram for an online order –
11 What is the purpose of state chart diagram? How to draw state chart diagram? Explain. [AU
N/D 2014]
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time.
Steps to draw a state diagram –
1. Identify the initial state and the final terminating states.
2. Identify the possible states in which the object can exist (boundary values corresponding to
different attributes guide us in identifying different states).
3. Label the events which trigger these transitions.
12 Explain about interaction diagram notation for inventory management system. [AU N/D 2015]
Collaboration Diagram For Inventory Management System:

Sequence Diagram For Inventory Management System:
13 Write a problem statement for Library management system. Draw the UML Case, Activity
diagram, class diagram, sequence diagram state chart diagram, package diagram, Component
and Employment diagrams. [AU M/J 2016] .[AU A/M 2017] .[AU A/M 2017]
Draw the activity and class diagrams for library management system. [AU A/M 2019]
Explain details about various Static and dynamic UML important diagrams with suitable
example.(13) [AU A/M 2018]

Use case diagram
Class diagram

Sequence diagram
Collaboration diagram
Statechart diagram

Activity diagram

Component diagram
Deployment diagram

14 Apply interactive modeling for a payroll system in UML. [AU N/D 2016]
15 consider an elevator that has the basic functions such as moving up and down open and close doors
and pick up passengers. the elevator is supposed to be used in a building having floors numbers
from 1 to n.There are call buttons in the elevator corresponding to each floor.For every floor
except floors 1 and n, there are two floor call buttons for the passengers to call elevator for going
up and down.There is only one down call button at floor and and one Call button in floor 1.Then
the car stops at a floor, the doors are opened on the elevator light indicating the current direction the
elevator is going is illuminated so that the passengers can get to know the current moving direction
of the elevator.When the elevator is moving a music audio is played inside the elevator.
Draw Class diagram, activity diagram and component diagram for designing this system.(13) [AU
A/M 2018]
Class Diagram
Class diagrams show the static structure of the object, their internal structure, and their
relationships.

Detailed Class Diagram
16 Draw and explain the Class diagram for a banking application. [AU N/D 2018]

UNIT-IV
1 Explain about GRASP Patterns.(16) .[AU A/M 2011] [AU M/J 2014] [AU N/D 2014] [AU A/M
2018]
What is GRASP?. Explain the design patterns and the principles used in it. .[AU N/D 2011]
What is GRASP? Explain the following GRASP patterns: Creator, Information Expert, Low
Coupling, High Cohesion and Controller. [AU M/J 2016]
Compare cohesion and coupling with suitable example. (8) [AU A/M 2019]
Explain the design principles in object modelling. Explain in details the grasp method for
designing objects with examples. [AU N/D 2016]
Explain in detail about controller. (5) [AU A/M 2019]
GRASP -General Responsibility Assignment Software Patterns.
GRASP
The GRASP is a tool that helps to master the basics of OOD and understanding
responsibilities.
GRASP is a learning aid that helps to understand the essential object design and apply the
design in a methodical, rotational and explainable way.
Applying Grasp To Object Design
GRASP stands for ―General Responsibility Assignment Software Patterns‖.
It means low grasping of these principles to successfully design object oriented software.
While coding or drawing interaction and class diagrams, developers apply the ideas behind
GRASP to master the principles of object oriented design.
There are nine different GRASP patterns:
(i) Creator
(ii) Information expert
(iii) Low coupling
(iv) Controller

(v) High cohesion

(vi) Polymorphism
(vii) Pure fabrication
(viii) Indirection
(ix) Protected variations
Out of the nine the first five are dealt in detail.
2 Write short notes on adapter, singleton, factory and observer patterns.(16) .[AU A/M 2011]
[AU M/J 2012] [AU M/J 2014] [AU N/D 2014] [AU A/M 2018]
Explain in detail about factory method. (6) [AU A/M 2019]

ADAPTER
Name : Adapter
Problem : If similar components have different interfaces then how to resolve
incompatible interfaces.
Solution : Using an intermediate adapter object, convert original interface of a
component to another interface.
The NextGen POS system supports many third party services like,
• Tax calculators
• Credit authorization services
• Inventory systems
• Accounting systems etc
Add a level of indirection with objects to adapt to the solution.
SINGLETON (GOF)
With the services factory, we have a problem who creates the factory.
One instance of factory is needed with the process.
Since at different places the adapter are called, the quick reflection suggest that the methods
of this factory may need to be called form various places in code.
This problem can be solved by passing ‗Service factory‘ as a parameter, initialize the
objects that need visibility.
But it is not convenient and hence go for ‗Singleton‘ pattern.
Name : Singleton
Problem : Exactly one instance of class allowed called ―Singleton‖. Objects are global and
have single point of access.
Solution : Static method of class is defined, that returns singleton.
FACTORY METHOD
It is called as
• Simple factory or
• Concrete factory
It is the simplification of GOF abstract factory.
Next adapter raises the problem,
• Who create adapters?
• How to create adapters?
When domain objects create the adapter, their responsibilities are beyond pure application
logic and related to connectivity with other software components.
So, when a domain object creates adapters
(i) It does not support goal of separation of concerns.
(ii) It lowers cohesion.
So we go in for ‗factory‘ pattern, where pure fabrication ―factory‖ object is defined to
create objects.
Advantages of factory
(i) Separate the responsibility of complex creation into cohesive helper objects.
(ii) Potential complex creation is hidden.
(iii) Performance-enhancing memory management strategies such as object catching or
recycling are allowed.
Name : Factory
Problem : For complex creation logic, for better cohesion who is responsible for creating
objects.
Solution : A pure fabrication object called ‗factory‘ is created that handles creation.
In ‗Service Factory‘, the logic to decide the class creation is resolved by reading
in the class name from external source.
This is called ―datadriven design‖
OBSERVER PATTERNS
To extend the solution found for changing data, add the ability for a GUI window to refresh
its sale.
The model-view separation principle discourages such solutions. It states that ―Model‖
objects should not know about view or presentation objects such as window.
It promotes Low coupling.
Due to low coupling the replacement of the view or presentation layer by a new one or of
particular windows by new windows.
The variations are supported by model view separation.
To solve this problem observe patterns are used.
Name : Observer (Publish-subscribe)
Problem : Subscriber objects are interested in state changes or events of a publisher
object, want to react in their own unique way when the publisher generates an
event.
Solution : Subscriber-implementations this interface.Publisher dynamically registers
subscribers
interested in an event and notifies them when event occurs.
The above diagram shows sample solution.
3 Explain about Implementation model(Mapping design to code) .[AU A/M 2011]
Elucidate the operation of mapping designs to code. [AU N/D 2015]
Explain in detail the design artifacts to implemental on code in an object oriented Language.
[AU M/J 2016] [AU N/D 2016]
How will you generate source code from design using UML? Illustrate. [AU N/D 2018]
In the implementation Model, the UML artifacts created during the code generation is used
as input. The implementation artifacts consists of source code, database definitions,
JSP/XML/HTML pages and so forth.
 Java
 C#
 Visual Basic
 C++
 Small talk
 Python
and many more languages use the object oriented design principles and map to code.
Programming – Iterative and Evolutionary Development
• Modern development tools are used to design while programming.
• The artifacts in Design Model provides the information to code.
• The strength of OOA/D and OO programming is they provide end-to-end road map
from requirements to code.

• The point of having a roadmap provides starting point for experimentation.
Creativity and change during implementation
• Some decision making and creative work are done during design.
• Generation of code is a mechanical translation process.
• The results generated during design modeling are initially incomplete and later during
programming and testing changes will be made.
• To encounter the new problems during programming ideas and understanding are
generated during OO design modeling.
• Always plan for lot of change and derivation from the design during programming. This
is a key for iterative and evolutionary methods.
Mapping Designs to Code
Implementation requires writing source code in object oriented language for
• Class and interface definitions.
• Method definitions
The code generation is more-or-less independent of using UML tool.
Creating Class Definition from DCDS
DCDs depict
• Class or interface name
• Super classes
• Operation signature
• Attributes of a class. This is enough to create a basic class definition in OO language.
Defining a class with method signatures and attributes
The mapping to attribute definitions for SalesLineItem is shown
The java constructor salesLineItem (…) is derived from create (desc, qty) message sent to
SalesLineItem in the enterItem interaction diagram.

4 What is design pattern? Explain the GoF design patterns. .[AU N/D 2011]
Designing the Use-Case Realizations with GoF Design Patterns. [AU M/J 2016]
A design pattern in architecture and computer science is a formal way of documenting a solution to a
design problem in a particular field of expertise. An organized collection of design patterns that
relate to a particular field is called a pattern language. The elements of this language are entities
called patterns.
A pattern is a named problem/solution pair that can be applied in new context, with advice on how
to apply it in novel situations and discussion of its trade-offs.
GoF design patterns:
• Adapter
• Factory
• Singleton
• Strategy
• Composite
• Façade
• Observer
5 i)Describe the concept of creators. [AU M/J 2012]
ii)Explain about low coupling, controller and high cohesion. [AU M/J 2012] [AU A/M 2017]
[AU N/D 2018]
CREATOR
Problem
One of the most common activities in object oriented system is creation of objects.
General principle is applied for the assignment of creation responsibilities.
Design supports
• Low coupling
• Increased clarity
• Encapsulation
• Reusability
Solution
If B is a creator of A objects then atleast one of the following must be true.
• B contains A
• B compositely aggregates A
• B records A
• B closely uses A
• B is an expert while creating A (B passes the initializing data for A that is passed to A
when created).
If more than one option is true.
Class B aggregates or contains class A.
LOW COUPLING
Coupling is the measure of low strongly one element is connected to the other elements.
Types of coupling
There are 2 types of coupling
1) Low coupling or weak coupling
2) High coupling or strong coupling
Low coupling
An element if does not depend on too many other elements like classes, subsystems systems
it is having low coupling.
HIGH COHESION
Cohesion is a measure of how strongly related and focused responsibilities of an element

are. An element has high cohesion if it,
• Does not do tremendous work
• Has high responsibilities
Difficulties of low cohesion are
• Hard to comprehend
• Hard to reuse
• Hard to maintain
• Delicate
CONTROLLER
A controller is defined as the first object beyond the user interface (UI) layer that is
responsible for the receiving or handling a system operation message.
6 i)Compare cohesion and coupling with suitable examples. [AU N/D 2015]
ii)State the role and patterns while developing system design. [AU N/D 2015]
Cohesion Coupling
Cohesion is the indication of the relationship Coupling is the indication of the
within module. relationships between modules.
Cohesion shows the module’s Coupling shows the
relative functional strength. relative independence among the
modules.
Cohesion is a degree (quality) to which a Coupling is a degree to which a
component / module focuses on component / module is connected to
the single thing. the other modules.
While designing you should strive for high While designing you should strive for low
cohesion i.e. a cohesive component/ module coupling i.e. dependency between
focus on a single task (i.e., single-mindedness) modules should be less.
with little interaction with other modules of the
system.
Cohesion is the kind of natural extension of Making private fields, private methods and
data hiding for example, class having all non public classes provides loose
members visible with a package having default
visibility.
EX

7 i)Differentiate bridge and adapter. [AU N/D 2015]

ii) How will you design the behavioral pattern? [AU N/D 2015]
Adapter:
 It is a structural pattern
 It is useful to work with two incompatible interfaces
Bridge:
 It is structural pattern
 It decouples an abstraction from its implementation and both can vary independently
 It is possible because composition has been used in place of inheritance
Behavioral patterns
are concerned with the assignment of responsibilities between objects, or, encapsulating behavior in
an object and delegating requests to it.
Chain of responsibility, Command, Mediator, and Observer, address how you can decouple senders
and receivers, but with different trade-offs.
 Chain of responsibility
A way of passing a request between a chain of objects
 Command
Encapsulate a command request as an object
 Interpreter
A way to include language elements in a program
 Iterator
Sequentially access the elements of a collection
 Mediator
Defines simplified communication between classes
 Memento
Capture and restore an object's internal state
 Null Object
Designed to act as a default value of an object
 Observer
A way of notifying change to a number of classes
 State
Alter an object's behavior when its state changes
 Strategy
Encapsulates an algorithm inside a class
 Template method
Defer the exact steps of an algorithm to a subclass
 Visitor
Defines a new operation to a class without change
8 Explain in detail about the Factory Pattern and mention the Limitations and applications of Factory
pattern. .[AU A/M 2017]Refu-4,Q-2
9 Differentiate bridge and adapter patterns.(7) [AU A/M 2019]
The main difference between an adaptor and a bridge pattern, is that a bridge pattern serves to
decouple an abstraction class from its implementation, and an adaptor pattern converts the
interface between classes with less inheritance.

UNIT-V
1 What is OO testing? Explain in detail about the concepts of OO testing in OOAD. [AU N/D
2015]
Explain in detail about the different types of testing in OOAD. [AU M/J 2016]
Discuss the various types of testing strategies in object oriented environment.(15) [AU A/M 2018]
Testing Object-Oriented Systems
Testing is a continuous activity during software development. In object-oriented systems, testing
encompasses three levels, namely, unit testing, subsystem testing, and system testing.
Unit Testing
In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free. Unit testing is
the responsibility of the application engineer who implements the structure.
Subsystem Testing
This involves testing a particular module or a subsystem and is the responsibility of the subsystem
lead. It involves testing the associations within the subsystem as well as the interaction of the
subsystem with the outside. Subsystem tests can be used as regression tests for each newly released
version of the subsystem.
System Testing
System testing involves testing the system as a whole and is the responsibility of the quality-
assurance team. The team often uses system tests as regression tests when assembling new releases.
Object-Oriented Testing Techniques
Grey Box Testing

The different types of test cases that can be designed for testing object-oriented programs are called
grey box test cases. Some of the important types of grey box testing are −
 State model based testing − This encompasses state coverage, state transition coverage,
and state transition path coverage.
 Use case based testing − Each scenario in each use case is tested.
 Class diagram based testing − Each class, derived class, associations, and aggregations
are tested.
 Sequence diagram based testing − The methods in the messages in the sequence diagrams
are tested.
Techniques for Subsystem Testing

The two main approaches of subsystem testing are −
 Thread based testing − All classes that are needed to realize a single use case in a
subsystem are integrated and tested.
 Use based testing − The interfaces and services of the modules at each level of hierarchy
are tested. Testing starts from the individual classes to the small modules comprising of
classes, gradually to larger modules, and finally all the major subsystems.
Categories of System Testing

 Alpha testing − This is carried out by the testing team within the organization that develops
software.
 Beta testing − This is carried out by select group of co-operating customers.
 Acceptance testing − This is carried out by the customer before accepting the deliverables.
2 Discuss in detail about OO integration testing and OO system testing. [AU N/D 2016]
Integration Testing
In integration testing, we check the interfacing between the inter-connected componenets.
It is performed after unit testing.
It is generally limited to functional aspects of the integrated components.
Since the interfacing logic is required to perform this testing, hence, it requires white/grey box
testing techniques along with black-box techniques.
The different approaches of performing integration testing namely - Top down, bottom up, big bang
and hybrid integration.
System Testing
In system testing, we check the system as a whole.
It is performed after integration testing.
It is carried out for performing both functional and non-functional testing(performance, usability
etc).
Since the testing is limited to evaluation of functional requirements, hence, it includes black-box
testing techniques only.
The different type of system testing are- Functional testing, Performance testing, Usability testing,
Reliability testing, Security testing, Scalability testing, Installation testing etc.
3 Explain the following.[AU A/M 2017]

(1) GUI Testing [AU A/M 2018]
GUI testing is defined as the process of testing the system's Graphical User Interface of the
Application Under Test. GUI testing involves checking the screens with the controls like menus,
buttons, icons, and all types of bars - toolbar, menu bar, dialog boxes, and windows, etc.
(2) OO System Testing[AU A/M 2019]REF U-5,Q2
4 Explain the issues involved in OO Testing. .[AU A/M 2017]

Discuss briefly about issues in OO testing.(13) [AU A/M 2018]
Give a brief note on issues in object oriented testing. [AU N/D 2018]
Traditional testing methods are not directly applicable to OO programs as they involve OO concepts
including encapsulation, inheritance, and polymorphism. These concepts lead to issues, which are
yet to be resolved. Some of these issues are listed below.
1.)Basic unit of unit testing.
 The class is natural unit for unit test case design.
 The methods are meaningless apart from their class.
 Testing a class instance (an object) can validate a class in isolation.
 When individually validated classes are used to create more complex classes in an
application system, the entire subsystem must be tested as whole before it can be considered
to be validated(integration testing).
2.)Implication of Encapsulation.
 Encapsulation of attributes and methods in class may create obstacles while testing. As
methods are invoked through the object of corresponding class, testing cannot be
accomplished without object.

 In addition, the state of object at the time of invocation of method affects its behavior.
Hence, testing depends not only on the object but on the state of object also, which is very
difficult to acquire.
3.) Implication of Inheritance.
 Inheritance introduce problems that are not found in traditional software.
 Test cases designed for base class are not applicable to derived class always (especially,
when derived class is used in different context). Thus, most testing methods require some
kind of adaptation in order to function properly in an OO environment.
4.)Implication of Genericity.
4.)Implications of Polymorphism
5.)Implications for testing processes
5 Discuss briefly about testing methods applicable at the class level. (13) [AU A/M 2019]
Random testing
•identify operations applicable to a class
•define constraints on their use
•identify a minimum test sequence
•an operation sequence that defines the minimum life history of the class (object)
•generate a variety of random (but valid) test sequences
•exercise other (more complex) class instance life histories
6 Give brief description about testing issues in OO testing and class testing in detail. (13) [AU A/M
2019]REF U-5 Q-1
CLASS TESTING
In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free. Unit testing is
the responsibility of the application engineer who implements the structure.
7 Explain the software development life cycle of object oriented approach.(7) [AU A/M 2018]
Object-oriented Life Cycle Model
The Object-Oriented approach of Building Systems takes the objects as the basis. For this, first the
system to be developed is observed and analyzed and the requirements are defined as in any other
method of system development. Once this is often done, the objects in the required system are
identified. For example, in the case of a Banking System, a customer is an object, a chequebook is
an object, and even an account is an object.
Object-oriented model employs an object-oriented strategy. The primary objectives are:
1. Object-oriented analysis,
2. Object-oriented design,
3. Object-oriented programming
Obiect-oriented analysis develops an object-oriented model of the application domain. Object-
oriented design develops an object-oriented model of the software system. Object oriented
programming realizes the software design with an object-oriented programming language that
supports direct implementation of objects, classes, and inheritance.
There are a variety of object-oriented methodologies such as:
 Object Identification:
System objects and their characteristics and events.

 Object Organization:
Shows how objects are related via “part-of” relationships.
 Object Interfaces:
Shows how objects interact with other objects.
These activities tend to be overlapping and in general and parallel.
8 Comparison between OO integration testing and OO system testing.(7) [AU A/M 2018]
System Testing Integration Testing
In integration testing, we check the

In system testing, we check the system as a whole. interfacing between the inter-connected
componenets.
It is performed after integration testing. It is performed after unit testing.
It is carried out for performing both functional and It is generally limited to functional
non-functional testing(performance, usability etc). aspects of the integrated components.
Since the testing is limited to evaluation of Since the interfacing logic is required
functional requirements, hence, it includes black- to perform this testing, hence, it

box testing techniques only. requires white/grey box testing

techniques along with black-box
techniques.
The different type of system testing are- Functional The different approaches of performing
testing, Performance testing, Usability testing, integration testing namely - Top down,
Reliability testing, Security testing, Scalability bottom up, big bang and hybrid
testing, Installation testing etc. integration.
9 What is GUI based Testing? How does it help improving software design? Explain. [AU N/D 2018]
GUI
There are two types of interfaces for a computer application. Command Line Interface is where you
type text and computer responds to that command. GUI stands for Graphical User Interface where
you interact with the computer using images rather than text.
GUI Testing Techniques / Methods
GUI testing can be done in three ways:
 Manual Based Testing

 Record and Replay
 Model Based Testing
GUI Testing basically involves
1. Testing the size, position, width, height of the elements.

2. Testing of the error messages that are getting displayed.
3. Testing the different sections of the screen.
4. Testing of the font whether it is readable or not.
5. Testing of the screen in different resolutions with the help of zooming in and zooming out
like 640 x 480, 600x800, etc.
6. Testing the alignment of the texts and other elements like icons, buttons, etc. are in proper
place or not.
7. Testing the colors of the fonts.
8. Testing the colors of the error messages, warning messages.
9. Testing whether the image has good clarity or not.
10. Testing the alignment of the images.
11. Testing of the spelling.
12. The user must not get frustrated while using the system interface.
13. Testing whether the interface is attractive or not.
14. Testing of the scrollbars according to the size of the page if any.
15. Testing of the disabled fields if any.
16. Testing of the size of the images.
17. Testing of the headings whether it is properly aligned or not.
18. Testing of the color of the hyperlink.

Ooad Complete Material

Uploaded by

Copyright:

Available Formats

Ooad Complete Material

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ooad Complete Material

Uploaded by

Copyright:

Available Formats

VEL TECH HIGH TECH Dr.RANGARAJAN Dr.

SAKUNTHALA ENGINEERING COLLEGE

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Figure 1.2 Key steps in OOAD

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Figure 1.3 Partial Domain Model of dice game

Figure 1.4 Sequence Diagram for dice Game

Figure 1.5 Partial design class diagram

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

1.2 WHAT ARE UP (UNIFIED PROCESS) PHASES

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Figure 1.6 Schedule oriented terms in UP

Figure 1.7 Disciplines and phases

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

• Reverse Engineering or

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Example: A USE CASE DIAGRAM FOR A HELP DESK

A use case is shown as an ellipse containing use case name.

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Example Use Case Text

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Main Success Scenario (or Basic Flow):

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

2) System displays the state of the resumed sale, with subtotal.

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

1) System signals error.

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

1) Cashier requests gift receipt and System presents

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

• This list is more important and practical

• Salesperson : wants sales commission updated

Main Success Scenario and Steps (or Basic Flow)

Main Success Scenario

4) ……Cashier repeats steps 3- 4 until indicates done

Extensions ( or Alternate Flows)

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

1) Cashier enters item identifier for removal from the sale.

7b. Paying by credit

1) System signals error to cashier

2) Cashier asks customer for alternate payment.

The labels *a, *b,… can be used to describe an extension condition.

3a. Invalid item ID (not found in system):

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

• Pluggable business rules to be insertable at steps 2 and 6.

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

The guidelines is “Keep the user interface out focus on intent”

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Step 4: Define use cases

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Figure 1.14 Partial Use case context diagram

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

Figure 1.15 a) Notation of

Figure 1.16 b) Actor Notation

Figure 1.17 Monopoly Game

QUEEN MARY VIDYA.M / ASST.PROF- CSE DEPT

The labels a, b,… can be used to describe an extension condition.