Unit 1: Introduction

1.1 Introduction to OOAD

- Object-oriented analysis and design (OOAD) is a technical approach for analyzing and
designing an application system, or business by applying object-oriented programming,
as well as visual modeling throughout the software development process to guide
stockholder communication and product quality.

- OOAD in modern software engineering in typically conducted in an iterative and

incremental way.
Iterative:
The iterative process is simply a series that you repeat, tweaking and improving your
product with each other.
In practical terms, think of it as practice to make your product perfect.
Incremental:
Incremental model is a process if software development where requirements are broken
down into multiple standalone module of software development cycle.
- The outputs of OOAD activities are analysis models for (OOA) and design model (OOD)
respectively.
- In dealing with OO technology, OOAD is the method of choice for software development
life cycle.
- It can be applied in the analysis and design phase and provide general instructions
as for what has to be accomplished.

- There are two phases has to clarified first:

i) In the phase of OOA, the typical question starts with What…? Like, “what will my
program need to do”? “what will the classes in my program be”? “what will each
class be responsible for”?
- Hence OOA cares about the real world and how to model this real world about getting
into much detail.
- According to Larman “it describes in the OOA phase as an investigation of the problem
and requirements rather than finding a solution to the problem.”

ii) In the phase of OOD, the questions typically start with How…? Like, “How will the
class handle its responsibilities?”, “How to ensure that this class knows all the
information it needs?”,” How will classes in the design communicate”?
- The OOD phase deals with finding a conceptual solution to the problem. It is about
fulfilling the requirements, but nit about implementation the solution.
1.1.1 OOA (Object oriented Analysis)
- It determined the system requirements, recognized the class and relationship between the
classes.
- During software requirement phase, requirement analysis and object analysis. it is the
method of analysis that examines requirements from the perspective of classes and
objects as related to the problem domain.
- OOA emphasis the building of real-world using the object oriented view of the world.
- The main purpose of OOA is to recognized application domain and specification
requirements of the system.
There are three different techniques of OOA:
1) Object Modeling
- It developed the static structure of the system regarding to object.
- It recognizes the objects, relationship between objects and classes in which objects
or groups.

The process of object modeling:

1) Recognized objects and group into classes.
2) Relationship between the classes.
3) user object model diagram is generated.
4) Define attributes of user object.
5) Define the operations need to perform on classes.

2) Dynamic Modeling
- Explain how single objects responds to event.
- The main aim is examining the behavior of the objects regarding time and external
changes.

The process of dynamic modeling

1. State of every object is recognized.
2. Recognize the event.
3. Generate dynamic model diagram and enclose with state transition diagram.
4. Communicate with every state regarding object attribute.
5. Verify state transition diagram.

3) Functional Modeling
- It shows the processes executed in an object how the data change while it moves
between methods.
The process of functional modeling:
1. All inputs and outputs are recognized.
2. Create a data flow diagram to show functional dependencies.
 3. Identify every function.
4. Identify the constraints.
5. Describe the optimization criteria.

1.1.2 OOD (Object oriented Design)

- While you are developing any software (if you want to develop the software by using
some object-oriented programming language than you need to design some concepts that
are related to this object oriented design.)
- The object oriented design involves designing the objects, classes and relationship
between the classes.
o Class: Blueprint or template identify something terms of data and operations.
o Object: Instance of Class. Object represent Noun.
- Example:
Data (state) operation:
On/off Turn on/off
Channel change channel
Volume set change volume set
Terms:
1) Instance Variable: A data, attribute, state that are specific to an instance of object.
2) Instance Method: Operations are specific to an instance object.
3) Class Variable: Data, attribute, state that are not specific to an instance.
4) Class Method: Operations that are not specific to an instance.
5) Constructors: It is special method that create an initialize object.

During OOD, there is an emphasis on define software objects and how they are collaborating to
fulfill the requirements.
- During user requirements phase: OOD involves understanding of the application domain
and build an object model.
- Identify Objects: It is a method of design showing process of object-oriented
decomposition.

OOD is a method of design encompassing the process of object oriented decomposition and a
notation for depicting logical and physical as well as static and dynamic model of the system
under design.
 For example: In the library system a book software object may hive title attribute and a
getChapter method.

1.1.3 OOP (object oriented programming)

- Object oriented programming (OOP) is a programming paradigm that relies on the
concept of classes and objects.
- It is used to structure a software program into simple, reusable pieces of code blueprints
(called classes), which are used to create individual instances of objects.
- There are many object oriented programming language i.e Java, JavaScript, C++, Python.

1.2 Basic Concepts of OOAD:

A. Objects
- An object is a real-world element in an object-oriented environment that may have a
physical or conceptual existence. Each object has:
o Identify that distinguishes it from other objects in the system.
o State the determines the characteristics properties of an object as well as the
values of the properties that the object holds.
- Object is an instance of a class.
- Objects can be modelled according to the needs of the application. An object may have a
physical existence, like a customer, a care, etc.; or an intangible conceptual existence,
like a project, a process etc.
- An object is an individual with a state and relationships to other objects. The state of an
object identifies the values for that object or properties of the classifier of the object.

B. Class
- The class represents a collection of objects having same characteristics properties that
exhibit common behavior.
- It gives the blueprint or description of the objects that can be created from it.
- Creation of an object as a member of a class is called instantiation.
The constituents of a class are:
- A set of attributes for the objects that are to be instantiated from the class. Generally,
different object of a class has some difference in the value of the attribute.
- A set of operation that portray the behavior of the objects of the class. Operations are also
referred as functions or method.

C. Encapsulation and data Hiding

Encapsulation:
- Encapsulation is one of the loosely defined OOAD concept. It is the process of binding
both attribute and methods together within a class.
- Through encapsulation, the internal details of a class can be hidden from outside.
- It permits the elements of the class to be accessed from outside only through the interface
provided by the class.

Data Hiding
- Typically, a class is designed such that its data or attribute can be accessed only by its
class methods and insulated from direct outside access.
- This process of insulating (creating a barrier) an object data is called data hiding or
information hiding.

D. Polymorphism
- Polymorphism allows objects with different internal structures to have a common
external interface.
- Polymorphism is particularly effective while implementing inheritance.
- I object-oriented paradigm, polymorphism implies using operations in different ways,
depending upon the instance they are operating.

E. Abstraction
Abstraction is a dependency relationship that relates two elements or set of elements
repressing the same concept but at different levels of abstraction or from different
viewpoints.

F. Inheritance
- Inheritance is the mechanism that permits new classes to be created out of existing
classed by extending and refining it capabilities.
- The existing classes are called the base classes/parent classes/super-classes, and the new
classes are called the derived classes/child class/subclasses.
- The subclass can inherit or derive the attributes and methods of the superclass provided
that the superclass allows so.
Types of Inheritance:
 1. Single inheritance: A subclass derives from the single super-class.
2. Multiple Inheritance: A subclass derives from more than one-super classes.
3. Multilevel Inheritance: A subclass derives from a super-class which is turn in
derived from another class and so on.
4. Hierarchical Inheritance: A class has a number of subclaess each of which may
have subsequent classes, continuing for a number if levels, so as to form a tree
structure.
5. Hybrid Inheritance: A combination of multipe classes.

Student

student
Student

Student

Fig: Hybrid Inheritance

G. Hierarchy:
Hierarchy is the ranking or ordering of abstraction. Through hierarchy, a system can be
made up of interrelated subsystem, which can have their own subsystem and so on until
the smallest level components are reached. It uses the principle of divide.

H. Modularity:

I. Object Interaction:

J. Interface Implementation:

Assignment: 6th June 2021

1. How object interaction and Interface implement are implemented in OOAD? Write the
example in programming language.
2. Difference between OOA, OOD and OOP.
OOA OOD OOP
3. Why encapsulation and polymorphism are used in OOAD? Explain with Your own view
with example.
4. What is the difference between object and class?
5. Explain OOD, OOA and OOP?
6. What is analysis and design?
7. Define class diagram and object diagram?
8. Describe hierarchical method and inheritance methods in detail.

Chapter TWO:
2.1 Unified Modeling Language (UML)
- The unified modeling language is a graphical language for OOAD that gives standard
way to write a software system’s blueprint.
- It helps to visualize, specify, construct, and document the artifact of an object-oriented
system.
- It used to depict the structure and the relationship in a complex system.
- The goal of UML is to provide a standard notation that can be used by all object-oriented
methods and to select and integrate the best elements of precursor notations.
History
- It was developed 1990s as an amalgamation of several techniques, prominently OOAD
technique by Grady Booch, OMT (object modeling technique) by James Rumbaugh and
OOSE (object oriented software engineering) by Ivar Jacobson.
- UML attempted to standardize semantic models, syntactic notations, and diagrams of
OOAD.
1. Object Modeling technique OMT [ James Rumbaugh 1991] was best for analysis and
data intensive information system.
2. Booch [Grady Booch 1994] – was excellent for design and implementation. Grady
Booch had worked extensively with the ADA language, and had been a major player in
the development of object oriented techniques for the language. Although, the Booch
method was strong, the notation was less well received.
3. OOSE [Object-oriented software Engineering Ivar Jacobson 1992]- featured a model
known as use cases. Use cases are a powerful technique for understanding the behavior
an entire system.

2.2 Notation and basic building blocks of UML

Graphical notations used in structural things are most widely used in UML.
Structural things
1. Class Notation
- The top section used to name the name.
- The second one is used to show the attributes of the class.
- The third section is used to describe the operations performed by the class.
- The fourth section is optional solution to show any additional components.
- Classes are used to represent Objects. Objects can be anything having properties and
responsibilities.

2. Object Notation
- The object is represented in the same way as the class.
- The only difference is the name which is underlined.

- As the object is an actual implementation of a class, which is known as the instance of a

class.

3. Interface Notation
- Interface is represented by a circle.
- Interface is used to describe the functionality without implementation. Interface is just
like a template, where you define functions.
- When a class implements the interface, it also implements the functionality as per
requirements.

4. Collaboration Notation
- Use case is represented by a dotted eclipse.
- Generally, responsibilities are in a group.

5. Use case notation

- Use case is represented as an eclipse with a name inside it.
- It may contain additional responsibilities.
- Use case is used to capture high level functionalities of a system.
6. Actor Notation
An actor can be defined as some internal or external entity that interacts with the system.
- An actor is used in a use case diagram, to describe the internal or external entities.

7. Initial state Notation

- Initial state is defined to show the start of a process.
- The usage of initial state notation is to show the starting point of a process.

8. Final notation
- Final state is used to show the end of the process. This notation is also used in almost all
diagrams to describe the end.
- The usage of Final notation is to show the termination point of a process.

9. Active Class notation

 - Active class looks similar to a class with a solid border. Active class is generally used to
describe the concurrent behavior of a system.
- Active class is used to represent the concurrency in a system.

10. Component notation

A component notation is used to represent any part of a system for which UML diagrams
are made.
Additional elements can have added wherever required.

11. Node notation

- Node notation is used to represent the physical part of a system such as the server,
network etc.
- A node represents the physical component of the system.

Behavioral Things
- Dynamic parts are one of the most important elements in
UML. UML has a set of powerful features to represent the dynamic part of software and

1. Interaction notation
- Interaction is basically a message exchange between two UML components.
- Interaction notation is used to represent the communication among the components of a
system.

2. State Machine notation

- State machine describes the different states of a component in its life cycle.
- It is used to describe different states of a system components.
- The state can be active, idle, or any other depend upon the situation.

2.3 UML diagrams

UML stands for Unified modeling language. It’s a rich language to model software
solutions, application structure, system behavior and business process.

There are 14 UML diagrams types to help you model the system behavior. There are two
main categories; Structure diagrams and behavioral diagrams.

Structure Diagram
1) Class diagram
2) Component Diagram
3) Deployment Diagram
4) Object Diagram
5) Package Diagram
6) Profile Diagram
7) Composite structure Diagram

Behavioral Diagram
1) Use case Diagram
2) Activity Diagram
3) State Machine Diagram
4) Sequence Diagram
5) Communication Diagram
6) Interaction Diagram
7) Timing Diagram
2.4 Extend, Generalization, Specification
2.4.1 Extend relationship
- In UML modeling, we can use an extend relationship to specify that one use case
(Extension) extends the behavior of another use case (Base). This type of relationship
reveals details about a system or application that are typically hidden in a use case.
- The extend relationship specifies that the incorporation of the extension use case is
dependent on what happens when the base use case executes.
- While the base use case is defined independently and is meaningful by itself, the
extension use case is not meaningful on its own.

We can add extend relationships to a model to show the following situations:

1) A part of a use case that is optional system behavior.
2) A sub flow is executed only under certain conditions.
3) A set of behavior segments that may be inserted in a base use case.

For example:
You are developing an e-commerce system in which you have a base use case called
PlaceOnlineOrder that has an extending use case called specify shipping instructions.
An extend relationship point from the specify shipping instructions use case to the
PlaceOnlineOrder use case to indicate that the behaviors in the specify shipping
instructions use care are optional and only occur in certain circumstances.

2.4.2 Generalization
- In UML modeling, a generalization relationship that implements the concept of object
oriented called inheritance.
- The generalization relationship occurs between two entities or objects, such that one
entity is the parent, and the other one is the child. The child inherits the functionality of
its parent and can access as well as updated it.
- Generalization relationships is utilized in class, component, deployment and use case
diagrams to specify that the child inherits actions, characteristics, and relationship from
its parent.
- The generalization relationship is incorporated to record attributes, operations, and
relationships in a parent model element so that it can be inherited in one or more child
model elements.
2.4.3 Instance of Specification in UML
- In UML models, instance specification are elements that represent an instance in the
modeled system.
- When you instantiate a classifier model, the instance specification that you create
represents an entity in the modeled system at a point in time, similar to a snapshot of the
entity.
- Instance specification can include the following information about the entity:
o The classification of the entity by one or more classifiers of which the entity is an
instance.
o The kind of instance, based on its classifier; for example, an instance specification
whose classifier is a class describes an object of that class, while an instance
specification whose classifier is an association describes a link of that association.
o Specific values of the structural features of the entity, which are represented by
slots.
2.5 Object-oriented Development Life cycle (Iterative and Incremental Life cycle)
(VVI)
2.5.1: Iterative Model:
- In the iterative model, iterative process starts with a simple implementation of small set
of the software requirements and iteratively enhances the evolving versions until the
complete system is implemented and ready to deploy.
- An iterative life cycle model does not attempt to start with a full specification
requirement. Instead, development beings by specifying and implementing just part of
the software, which is reviewed to identify further requirements.
- this process is then repeated, producing a new version of the software at the end of each
iteration of the model.

Applications:
- Requirements of the complete system are clearly defined and understood.
- Major requirements must be defined, however, some functionalities or requested
enhancements may evolve with time.
- There is a time to the market constraint.
- A new technology is being used and is being learnt by the development team while
working on the project.
- Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
- There are some high risk features and goals which may change in the future.
Advantage and Disadvantage:
 Advantage:
1) Some working functionality can be developed quickly and early in the life cycle.
2) Results are obtained early and periodically.
3) Parallel development can be planned.
4) Progress can be measured.
5) Less costly to change the scope/requirement.
6) Testing and debugging during smaller iteration is easy.
7) Manage Risk
8) Operational product delivered.
9) Risk analysis is better.
Disadvantage
1. More resources may be required.
2. Cost if change is lesser but it is not very suitable for changing requirement.
3. More management attention is required.
4. Not suitable for smaller projects.
5. Management complexity high.

2.5.2: Incremental Model

- Incremental model is a process of software development where requirements are broken
down into multiple standalone modules of software development cycle.
- Incremental development is done in steps from analysis, design, implementation,
testing/verification, maintenance.

- The system is put into production when the first increment is delivered. The fist
increment is often a core product where the basic requirements are addressed, and
supplementary features are added in the next increments.
- Once the core product is analyzed by the client, there is plan development for the next
increment.
Characteristics:
- System development is broken down into many mini development projects.
- High priority requirement is tackled first.
- Once the requirement is developed, requirements for that increment are frozen.
- Produce a final total system.
When to use Incremental models?
- Requirements of the system are clearly understood.
- When demand for an early release of a product arises.
- When software engineering team are not very well skilled or trained.
- High risk features and goals are involved.
- Such methodology is more in user for web application and product based companies.
Advantages and Disadvantages
Advantage:
1) The software will be generated quickly during the software life cycle.
2) Flexible and less expensive to change requirements and scope.
3) Development stages changes can be done.
4) Less costly compared to others.
5) A customer can respond to each building.
6) Errors are easy to identified.
Disadvantage:
- It requires a good planning designing.
- Problems might cause due to system architecture as such not all requirements collected
up front for the entire software cycle.
- Does not overlap each other while incremental phase is rigid.
- All the units consume a lot of time.
Assignment
 Chapter Three
Object Oriented Analysis

3.1. Introduction to model building

- Intention of object modeling and design is to learn how to apply object oriented concept
to all the stage of the software development life cycle.
- Object oriented modeling and design is a way of thinking about problems using models
organized around real world concepts.
- The fundamental construct is the object, which combines both data structure and
behavior.
3.1.1 Defining Model
- A model is a simplified representation of a system over some time period or spatial
extent intended to promote understanding of the real system.
3.1.2 Why Build a Model?
- Building models helps us understand the problem ( and its surrounding system) we are
investigating solutions. Computer system assists in organizing information about our
system, and more importantly, forces us to identify interrelationships between various
components of system.
- One goal for a collaborative model building process is to generate a model focused on
the interrelationships between geographic, economics, political and social components
of the local system.

3.1.3 How Do I make the right model?

 - Whether a model is right or wrong is a matter of judgement.
- While no model can be absolutely correct, all models can be helpful.
- The extent of which a model aids in the development of our understanding is the basis
for deciding how good the model is.
- In developing models there is always a tradeoff between over and under simplifying the
complexity of the problem.
- As a model is always a simplification of reality, certain details are excluded.
- If relevant components are excluded, we risk making the model too simplistic, which will
not develop the understanding desired.
- If we include too much detail the model becomes too complicated to develop a deeper
understanding of the problem or its solution.

Modeling achieves four aims:

- Helps us to visualize a system as we want it to be.
- Permits us to specify the structure of behavior of a system
- Gives us a template that guides us in constructing a system.
- Documents the decisions we have made.
Purpose of Models:
1. Testing a physical entity before building it.
2. Communication with customers
3. Visualization
4. Reduction of complexity
3.1.2 Types of Model
There are three types of models in the object oriented modeling and design are:
1) Class model
- The class models show all the classes present in the system.
- The class model shows the attributes and behavior associated with the objects.
- The class diagram is used to show the class model. It shows the class name followed by
the attributes, followed by the functions, or the methods that are associated with the
object of the class.
- Goal in constructing class model is to capture those concepts from the real world that
are important to an application.

2) State model
- State model describes those aspects of objects concerned with time and the sequencing
of operations, events that mark changes, states that define the context for events, and
the organization of events and states.
 - Actions and events in a state diagram becomes operations on objects in the class model.
- State diagram describes the state model.

3) Interaction model
Interaction model is used to show the various interactions between objects, how the
object collaborates to achieve the behavior of the system as a whole.
The following diagrams are used to show the interaction model:
- use case diagram
- sequence diagram
- Activity diagram

3.1.3 Benefits of Software model

- It facilities the system’s evolution and maintenance.
- It reduces the number of defects in the final code.
- Improves the productivity of the development team.
- Risk analysis and reduction can be done systematically.
- well planned and efficient project development.
3.1.4 Importance of Model building
- Modeling gives graphical representation of system to be built.
- Models helps us to visualize a system.
- specify the structure of behavior of the system.
- Supports the decision we have made.
- Give us templates that guides us in constructing a system.
- A model provides the blueprint of a system.

3.2 Domain Modeling:

- The discipline in the software development life cycle is also termed as “Domain Modeling”,
which is the main artifact of the elaboration phase of the Unified process.
- It represents the real world conceptual classes-not the software class. And, it is different from
object modeling hat is more design and implemented oriented.
- A part from the representation of conceptual classes, in the domain modeling, two major skills
are required
1) Adding associations
2) Adding attributes

- A domain modeling is a visual representation of conceptual classes or real-

situation objects in a domain.
- Domain models have also been called conceptual models, domain object
models, and analysis object model.

Conceptual Classes
- The domain model illustrates conceptual classes or vocabulary in the
domain. Informally, a conceptual class is an idea, things, or object. But
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.
For example, consider the conceptual class for the event of a purchase
transaction. I may choose to name it by the (English) symbol sale.
The intension of a sale may state that it “represent the event of a purchase
transaction, and has a date and time.”
The extension of Sale is all the examples of sales; in other words, the set of all
sale instances in the universe.

A conceptual class has a symbol, intension and extension

 For example, consider the conceptual class for the event of a purchase
transaction. I may choose to name it by the (English) symbol sale. The
intension of a sale may state that it “represent the event of a purchase
transaction, and has a date and time.” The extension of Sale is all the examples
of sales; in other words, the set of all sale instances in the universe.
Domains and data Models are the same thing? Explain. (VVI)
A domain model is not a data model (which by definition shows persistent data to
be stored somewhere), so do not exclude a class simply because the
requirements don’t indicate any obvious need to remember information about it
(a criterion common in data modeling for relational database design, but not
relevant to domain modeling). Or because the conceptual class has no attributes.
For example, it’s valid to have attributed less conceptual classes or conceptual
classes that have a purely behavioral role in the domain instead of an information
role.

How to find Conceptual classes?

1) Reuse or modify existing method
 - This is the first, best and usually easiest approach, and where I will start if I
can. There are published, well-crafted domain models and data models
(which can be modified into domain models) for many common domains,
such as inventory, finance, health and so forth.

2) Conceptual class category list (VVI)

Airline reservation domains:
Conceptual Class Category Examples
Business transactions Sale, payment, Reservation
Guidelines: These are critical (Involve money) so start with
transactions.
Transaction line items SalesLineItem
Guideline: Transactions often common related line item, so
consider these next.
Product or service related to a transaction or transaction Item
line item Flight, Seat, Meal
Guideline: Transactions are for something (a product or
service) consider these next.
Where is the transaction recorded? Register, ledger, store database
Guideline: Important
Roles of people or organizations related to the Cashier, customer, Airlines.
transaction;
Actor in the use case
Guidelines: we usually need to know about the parties
involved in a transaction.
Place of transaction; place of service Store, Airport.
Physical objects Item, Register Board, Airplan.
Guidelines: This is especially relevant when creating device-
control software or simulations.

3) Finding Conceptual Classes with Noun Phrase Identification

 - Another useful technique suggested in is linguistic analysis. Identify the
nouns and noun phrases in textual descriptions of a domain, and consider
them as candidate conceptual classes or attributes.
- Nevertheless, linguistic analysis is another source of inspiration.
- The fully dressed use cases are an excellent description to draw from for
this analysis.
- For example, the current scenario of the Process Sale use case can be used.
Main success scenario (Basic Flow)
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. System records sale line item and presents item description, price and
running total.
Price calculated from a set of price rules. Cashier repeats 2-3 until
indicates done.
5. System presents total with taxes calculated.
6. Cashier tells customer the total and ask for payment.
7. Customer pays and system handles payment.
8. System logs the completed sale and send sale and payment information
to the external Accounting (for accounting and commissions) and
Inventory system (to update inventory)
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).
Alternative Flows
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 record the cash payment.

Example: Find and draw conceptual classes.

Case study: POS Domain
From the category list and noun phrase analysis, a list is generated of candidate
conceptual classes for the domain. Since this is a business information system,
focus first on the category list guidelines that emphasize business transactions
and their relationship with other things. The list is constrained to the
requirements and simplification currently under consideration for iteration-1, the
basic cash-only scenario of Process Sale.
Iteration-1 requirements
Sale cashier cashpayment customer
SalesLineItem store Item ProductDescription
Register ProductCatolg Ledger

Register Item Store Sales

SalesLineItem Cashier Customer Manager

Payment Product Catalog Product

Specification

Fig: Initial POS Domain Model

3.3 Domain Model Refinement:

3.1 Define Association
- An association is a relationship between classes, that indicates some
meaningful information and interesting connection.

Fig: Example of Association

In the UML, associations are defining as “the semantic relationship
between two or more classifiers that involves connections among their
instances.”
The ends of an association may contain a multiplicity expression indicates
the numerical relationship between instances of the classes.
The association is inherently bidirectional, meaning that from instances of
either classes, logical traversal to the other possible. This traversal is purely
abstract it is not a statement about connection between software entities.
 Note: the reading direction arrow has no meaning in terms of the model;
it is only an aid to the reader of the diagram.
Q. How to Name an association in UML?
- Name and association based on a ClassName-VerbPhrase-ClassName
format where the verb phrase creates a sequence that is readable and
meaningful. Simple association names such as “Has” or “Uses” are usually
poor, as they seldom enhance our understanding of the domain.
For example:
- Sale Paid-by Cashpayment
o Bad example (doesn’t enhance meaning): Sales uses Cashpayment.
- Player Is-on Sequence:
o Bad example (doesn’t enhance meaning): player has square.
Roles:
Each end of an association is called a role. Roles may optimally have:
- Multiplicity expression name
- Navigability
- Multiplicity is examined.
 Fig: Multiplicity in Associations
Multiple association between two classes:

Case Study: NextGen POS

The domain model in figure shows a set of conceptual classes and
associations that are candidates for our POS domain model. The
associations are primarily derived from the “need-to-remember” criteria of
these iteration requirements, and the Common Attribute list. Reading the
list and mapping the examples of the diagram should explain the choices.
For example:
Transaction related to another transaction (sales paid – by cashpayment)
Line items of transaction Sale Contain SalesLineItem.
Product for a transaction (or line item) SalesLineItem Records-sale-of item.
2. Monopoly Game
Played-with Played-on
Monopoly
DIE Board
Game

2..8

plays Contain
owns Is-on
Player Piece Square
3.2 Define Attributes
It is useful to identify those attributes of conceptual classes that are needed
to satisfy the information requirements of the current scenarios under
development.
An attribute is a logical data value of an object.
When to show Attributes?
Include attributes that the requirements suggest or imply a need to
remember information.
For example, a receipt (which reports the information of a sale) in the
Process Sale use case normally includes a date and time, the store name
and address, cashier ID, among many other things.
Therefore,
Sale needs a dataTime attribute
Store needs a name and address
Cashier needs an ID.
Attribute Notation in UML
The full syntax for an attribute in the UML is:

Derived
attribute
 What are suitable attribute types?
Focus on Data Type attributes in the domain model

3.3 Association relationships in domain modeling class diagram

Java Source code

OwnedClass.Java:
Public class OwnedClass {
// <<class body>>
}
OwnerClass.java:
Public class OwnerClass
{
Private OwnedClass associatedClass;
Public OwnerClass otherClass;
// <<class body>>
}
3.4 UML activity diagrams and modeling (VVI)
Introduction
- Activity diagram is another important diagram in UML to describe the dynamic
aspect of the system.
- Activity diagram is basically a flowchart to represent the flow from one activity
to another activity. The activity can be described as an operation of the system.
- The control flow is drawn from one operation to another. This flow can be
sequential, branched or concurrent. Activity diagram deals with all type of flow
control by using different elements.
Purpose of Activity Diagram:
The basic purpose of activity diagram is similar to other four diagram. It captures
the dynamic behavior of the system.
Activity is a particular operation of the system. It is not only used for visualizing
the dynamic nature of a system, but they are also used to construct the
executable system by using forward and reverse engineering technique.
The purpose of an activity diagram can be described as:
- Draw the activity flow of a system
- Describe the sequence from one activity to another.
- Describe the sequential, branched and concurrent flow of the system.
How to Draw an Activity Diagram?
Activity diagram 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
Once the above-mentioned parameters are identified, we need to make a mental
layout of the entire flow. This mental layout is then transformed into an activity
diagram.
Example:
In the diagram, four activities are identified which are associated with conditions.
One important point should be clearly understood that an activity diagram cannot
be exactly matched with the code. The activity diagram is made to understand the
flow of activities and is mainly used by the business users.
Following diagram is drawn with the four main activities.
- Send order by the customer
- Receipt of the order
- Confirm the order
- Dispatch the order
After receiving the order request, condition checks are performed to check if it is
normal or special order. After the type of order is identified, dispatch activity is
performed and that is marked as the termination of the process.
Where to Use Activity Diagram?
- Activity diagram is suitable for modeling the activity flow of the system. An
application can have multiple system. It also captures these systems and
describes the flow form one system to another. This specific usage is not
available in other diagrams. The systems can be database, external queries,
or any other system.
o Modeling work flow by using activities.
o Modeling business requirements.
o High level understanding of the system’s functionalities.
o Investigating business requirements at a later stage.
3.5 System sequence diagrams and modeling (VVI)
What is a sequence diagram in UML?
It is also important to know the role of UML. UML is a modeling toolkit that guides
the creation and notation of many types of diagrams, including behavior diagram,
interaction diagrams and structure diagram.
A sequence diagram is a type of interaction diagram because it describes how-
and in what order -a group of objects work together. These diagram are used by
software developers and business professionals to understand requirements for a
new system or to document an existing process. Sequence diagrams are
sometimes known as event diagram or event scenarios.
Thera are also two types of sequence diagram: UML diagram and code based
diagrams.
Benefits of Sequence diagram
- Represent the details of a UML use case.
- Model the logic of sophisticated procedure, function or operation.
- How objects and components interact with each other to complete a
process.
- Plan and understand the detailed functionalities if an existing or future
scenario.
Example: sequence diagram of cardless money withdraw

Fig: sequence diagram of cardless money withdraw

- It explores the real-time application.
- Easy maintenance
- Easy to generate
- Implement both forward and reverse engineering.
- It can easily update as per the new change in the system.
Drawbacks of Sequence diagram
- In the case of too many lifelines, the sequence diagram can get more
complex.
- The incorrect result may be produced, if the order of the flow of message
change.
- The type of sequence is decided by the type of message.

3.5 Use Case Diagram

Introduction
- Use case diagram captures the system functionalities and requirements by
using actors and use cases. Use case model the services, tasks, function that
a system needs to perform.
- Use case represent high-level functionalities and how a user will handle the
system.
- Use cases are the core concepts of UML modeling.
Why Use-case diagram?
- A use case consists of use cases, persons, or various things that are invoking
the features called as actors and the elements that are responsible for
implementing the use cases.
- Use case diagram capture the dynamic behavior of a live system. It models
how an external entity interacts with the system to make it work.
- Use case diagrams are responsible for visualizing the external things that
interacts with the part of the system.
Tips for drawing a use case diagram
- A use case diagram should be as simple as possible.
- Should be complete.
- Represent all interactions with the user case.
- If there are too many use cases or actors, then only the essential use cases
should be represented.
- Describe at least a single module of a system
 - If the use case diagram is large, then it should be generalized.
Example: Use case diagram for a credit card processing system.

Assignment
1. Draw a use case diagram for a bank ATM.
2. Relationship between sequence diagrams and use cases
3. Relationship between class diagram and use cases
4. Benefits of software model
5. Importance of model building
 CHAPTER 4 OBJECT ORIENTED DESIGN
4.1 Introduction Object Oriented Design (OOD)
4.1.1 Introduction:

o OOD transforms the analysis model created using OOA into a design
model that serves as a blueprint for software construction.
o OOD results in a design that achieves a number of different levels of
modularity.
o Subsystem: major system components.
o Objects: Data and the operations.
o Four important software design concept:
 Abstraction
 Information Hiding
 Functional independence
 Modularity
o As stated earlier, analysis is the practice of studying a problem
domain, leading a specification of externally observable behavior.
o Building on this, design is the practice of taking a specification of
externally observable behavior and adding details needed for actual
computer system implementation.
o Analysis is what or the problem phase. Design is the how or the
solution phase.
o OOD consists mainly of expanding the requirements model to
account for the complexities introduced in selecting a particular
implementation.
 Human interaction.
 Data management
Other implementations area.
4.1.2 OOD Goals:
- To design classes identified during analysis phase and user interface.
- Identify additional objects and classes that support implementation of
requirements.
o E.g. add objects for user interface to system (data entry window,
browser windows)
- Can be intertwined with analysis phase
o Highly incremental, e.g. can start with OOA, model it, create OOD,
then do some more of each again and again, gradually refining and
completing models of system.
- Activities and focus of OO analysis and OO design are intertwined.
4.1.3 OOD steps:

o First, build object model based on objects and relationships.

o Then iterate and refine model
 Design and refine classes
 Design and refine attributes
 Design and refine methods
 Design and refine structure
 Design and refine associations

4.1.4 Guidelines in OOD

o Reuse rather than build new classes: knowing existing classes
o Design large number of simple classes rather than small number of
complex classes.
o Design methods
o What has been proposed: Go back and refine classes.
4.1.5 OOD design Strategy
- Problem domain component:
o The OOA results are placed here directly, certain modifications are
made base on implementation specific criteria.
- Human Interaction component:
o The actual displays and inputs needed for human interactions. The
classes will vary somewhat depending upon the type of user
 interface. Example, classes would include specializations of Menu,
Screen and display.
- Data management component:
Deals with the access and management of persistent data, using a flat file,
relational, or object-oriented database.

4.1.6 Generic Components of OOD

o Problem domain component: the subsystems that are responsible for
implementing customer requirements directly.
o Human interaction component: the subsystems that implement the
user interface. (this includes reusable GUI subsystems)
o Task management components: the subsystems that are responsible
for controlling and coordinating concurrent tasks that may be
packaged within a subsystem or among different subsystems.
o Data management component: the subsystems that is responsible
for the storage and retrieval of objects.
4.1.7 OOA to OOD (important)
 Analysis Model Design Model
Classes Objects
Attributes Data Structures
Methods algorithms
Relationships messaging
Behavior control

4.2 Designing Objects with Patterns (VVI)

4.2.1 GRASP (General responsibility assignment software patterns)
o GRASP help guide object-oriented design by clearly outlining who
does what: which object or class is responsible for what action or
role.
o It also helps us define how classes work with one other.
o The key point of GRASP is to have efficient, clean, understandable
code.
- Name chose to suggest the importance of grasping fundamental principles
to successfully design object-oriented software.
- Fundamental principles of object design and responsibilities.
- Patterns focus on one of the important aspects of object design.
- Assigning responsibilities to classes.
- GRASP patterns do not address architectural design.
Objectives
- You want to assign a responsibility to a class.
- You want to avoid or minimize additional dependencies.
- You want to maximize cohesion and minimize coupling.
- You want to increase reuse and decrease maintenance.
- You want to maximize understandability.
Principles of GRASP patterns
Creator, Information expert, low coupling, controller, high cohesion
a) Creator Pattern
Name: Creator
Problem: who creates an instance of any class say class A?
Solution: Assign class B the responsibility to create an instance of class A if
one of these is true.
- B contains or aggregates A.
- B records A
- B closely uses A
- B has the initializing data for A.
- If we have more than 1 class that satisfies the above condition for creating
B, give responsibility to the class that aggregates B or contains B.
Who creates the squares?

Board
How does create pattern lead to this partial sequence diagram?

- How does Create Patten develop this Design class diagram (DCD)?

Board has a composite aggregation relationship with square. I.e Board

contains a collection of square.
 Q. Creator:
who should responsible for the creation of a SalesLineItem.

b) Information Expert pattern or principle

Problem: A system will have hundreds of classes. How do I begin to assign
responsibilities to them?
Solution: Assign responsibility to the information expert, the class that has
the information necessary to fulfill the responsibility.
E.g, Board has the information needed to get a square.
 Mechanisms:
Step1: Clearly state the responsibility
Step 2: Look for classes that have the information we need to fulfill the
responsibility.
Step 3: Domain model or design model
Step 4: sketch out some interaction diagrams.
Step5: update the class diagram.
Introduction:
- Information expert is a basic guiding principle used continuously in object
design.
- The fulfillment of a responsibility often requires information that is spread
across different classes of object.
- This implies that there are many “partial” information experts who will
collaborate in the task.
- Different objects will need to interact via message to share the work.
- The information expert should be an early pattern considered in every
design unless the design implies a controller or creation problem, or is
contraindicated on a higher design level.
Advantage:
- Information expert has the effect of having a class with high cohesion.
o Cohesion: the degree to which the information and responsibilities of
a class are related to each other.
- Maintain encapsulation of information.
- Promotes low coupling.
- Promotes high cohesive classes.
Q. Example:
who is responsible for knowing the grand total of a sale in a typical Point of sale
application?
- To compute the grand total, we need the total of a SalesLineItem.
- We have to decide who calculates the total of a SalesLineItem.

Need all SalesLineItem instance and their subtotals. Only sakes know this so
Sale is the information expert.
Hence.
 Hence responsibilities assigned to the three classes are as follows:
Class Responsibility
Sale Knows sale total
SalesLineItem Knows line item subtotal
ProductSpecification Know product price

c)Low coupling
- How strongly the objects are connected to each other?
- Coupling: Object depending on the other object.
- When depended upon element change, it affects the dependent also.
- Low coupling: how can we reduce the impact of change in depended upon
elements on dependent elements.
- Assign responsibilities so that coupling remain low.
- Minimizes the dependency hence making system maintainable, efficient
and code reusable.
- Two elements are coupled, if
o One element has aggregation/composition association with another
element.
o One element implements/extends other element.
Example:
- VideoStore and Video class are coupled, and RentVideo is coupled with
VideoStore. Thus providing low coupling.
d)
Controller
- Deals
with how to
delegate
the
request
from the UI
layer
objects to domain layer objects.
- When a request comes from UI layer objects, Controller pattern helps us in
determining what is that first object that receive the message from the UI
layer Objects.
- This object is called controller object which receives request from UI layer
object and then controls/coordinates with other object of the domain layer
to fulfill the request.
- It delegates the work to other class and coordinates the overall activities.
We can make an object as controller, if
- Object represents the overall system.
- Object represent a use case, handling a sequence of operation (session
controller).
Benefits
- Can reuse this controller class.
- Can use to maintain the state of the use case.
- Can control the sequence of the activities.
Example:
 e) High Cohesion
- How are the operations of any element are functionally related?
o Related responsibilities in to one manageable unit.
o Prefer high cohesion
o Clearly defines the purpose of elements.
Benefits:
- Easily understandable and maintainable.
- Code reuse
- Low coupling
Low cohesion
High Cohesion

4.2.2 Applying GoF design Patterns: adapter, singleton, factory and observer
patterns
- The GoF design patterns are broken into three categories:

1) Creational patterns design

-Creational pattern design for the creation of objects:
a) Abstract Factory: Allow the creation of objects without specifying their
concrete type.
b) Builder: Uses to create complex objects.
c) Factory method: Creates objects without specifying the exact class to
create.
d) Prototype: Creates a new object form an existing object.
e) Singleton: Ensures only one instance of an object is created.
2) Structural Design Patterns
a) Adapter: Allows for two incompatible classes to work together by
wrapping an interface around one of the existing class.
b) Bridge: Decouples an abstraction so two classes can vary
independently.
c) Composite: Takes a group of objects into a single object.
d) Decorator: Allow for an object behavior to be extended dynamically
at run time.
e) Façade: Provides a simple interface to a more complex underlying
object.
f) Flyweight: Reduces the cost of complex object models.
g) Proxy: Provides a placeholder interface to an underlying object to
control access, reduce cost, or reduce complexity.

3) Behavior Design Patterns

a) Chain of Responsibility: Delegates commands to a chain of processing
objects.
b) Command: Creates object which encapsulate action and parameters.
c) Interpreter: Implements a specialized language.
d) Iterator: Access the elements of an object sequentially without
exposing its underlying representation.
e) Mediator: Allows loose coupling between classes by being the only
class that has detailed knowledge of their methods.
f) Observer: Is a publish/subscribe pattern which allows a number of
observer objects to see an event.
g) State: Allows an object to alter its behavior when its internal state
changes.
h) Strategy: Allows one of a family of algorithms to be selected in the fly
at run time.
i) Template method: Defines the skeleton of an algorithm as an
abstract class, allowing its sub-classes to provide concrete behavior.
 j) Visitors: Separates an algorithm form an object structure by moving
the hierarchy of methods into one object.

4.3 Designing for Visibility

- A visibility is the ability of one object to see or have reference to another
object.
- Whenever, there is a message a message passing between two objects, we
can determine the visibility between them.
- For a sender object to send a message to a receiver object, the sender must
be visible to the receiver i.e the sender must have some kind of reference
or pointer to the receiver object.

For example, in the interaction diagram, ProductCatalog is visible to

Register. The register has connection or reference to the ProductCatalog,
and hence can send message. When creating a design of interacting
objects, it is required to ensure that the necessary visibility is present to
support message interaction.

Types of Visibility
There are four common ways that visibility can be achieved 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 in some way globally visible.
1. Attribute Visibility:
Attribute visibility from A to B exists when B is an attribute of A. It is a
relatively permanent visibility because it persists as long as A and B
exists. This is a very common form of visibility in Object-oriented
system.
For example, a class definition statements and method creating
statement as below:

public class Register

{
…..
private ProductCatalog catalog:
….
}
{
public void enterItem (ItemID, quantity)
{
…
Spec = catalog. getSpecification(ItemID)
..
}
}
 Other Example:

class Profile:
def __init__(self,name,add):
self.name = name
self.add = add

class Info(Profile):
def __init__(self,name,add,sal):
Profile. __init__(self,name,add)
self.sal = sal

def info(self):
print (f"Hello my name is {self.name} and I am from {self.add} My
Salary is {self.sal}")

obj = Info('Ram',"Kathmandu",10000)
obj.info ()
Output: Hello my name is Ram and I am from Kathmandu My Salary is 10000

2. Parameter Visibility:
Parameter visibility from A to B exists when B is passed as a parameter
to a method of A. It is a relatively temporary visibility because it persists
only within the scope of the method.
 In this collaboration diagram, the makeLineItem message is sent to a
Sale Instance, passing a ProductSpecifiction instance as a parameter.
Within the scope of the makeLineItem method, the sale has parameter
visibility to a ProductSpecification.

{
makeLineItem (ProductSpecification spec, int, qty)
{
…
Sl = newSaleLineItem (Spec, qty)
….
}
}
It is common to transform parameter visibility into attribute visibility.
For example, when the sale creates a nesSaleLIneItem, it passes a
PrdouctSpecification into its initializing method. Within the initializing
method, the parameter is assigned to an attribute, thus establishing
attribute visibility.

2.3 Local Visibility

- Local Visibility from A to B exists when B is declared as a local object within
a method of A. It is a relatively temporary visibility because it persists only
within the scope of the method.
 Two common means by which local visibility is achieved are
- Create a new local instance and assign it to a local variable.
- Assign the returning object from a method invocation to a local variable. As
with parameter visibility it is common to transform locally declared visibility
into attribute visibility.
{
enterItem (itemID, qty)
{
…
ProductSpecification Spec = catalog.getspectification(ItemID)
…
}
}
2.4 Global Visibility
Global Visibility from A to B exists when B is global to A. It is a relatively
permanent visibility because it persists as long as A and B exist. It is the
least common form of visibility in object oriented system.
One way to achieve global visibility is to assign an instance to a global
variable, which is possible in some languages such C++, Jave.

4.4 Class responsibilities and collaborator (CRC) Design

- A CRC card is a collection of standard index card that has been divided into
three section, a class represents a collection of similar objects, a
responsibility is something that a class knows or does, and a collaboration is
another class that a class interacts with to fulfill its responsibilities.
CRC card layout

Class Name

Responsibilities Collaborations
 Example: Create a CRC model for a simple shipping/inventory control
system.

Order
Order Number Oder Item
Date Ordered Customer
Date Shipped
Order Items
Calculate order total
Print invoice
Cancel Order Item
Inventory
QuantityItem Inventory
Customer
Inventory
Item numberItem Item
Name Surface Calculate total
Name
Phone Number address Description
Customer Number Unit Price
Mark Order Give Price
Cancel Order
Make a payment

Surface address
Street
City
State
Zip
Print label
 Fig: A CRC model for a simple/inventory control system.

Assignment
4.5 UML state diagrams and modeling
ATM PIN verification

4.6 UML interaction diagrams and modeling

4.7 UML deployment and component diagrams
 CHAPTER 5: Object Oriented Implementations:
5.1 Introduction
5.1.1 Object oriented Implementation
- The Implementation model describes how design model’s element are
implemented in terms of components.
- It implies dependence.
- It also describes how components are organized according to structure and
modularization approaches available in the environment of the language.
- Implementation is the process of ensuring that the information system is
operational.
- It involves
o Constructing a new system from scratch
o Constructing a new system form the existing one.
- Implementation allows the users to take over its operation for use and
evaluation. It involves training the users to handle the system and plan for a
smooth conversion.

5.1.2 Structured vs object oriented based implementation

(Structured programming VS object oriented programming) (VVI)
Structured programming Object oriented programming
- A programming paradigm that divides -A programming paradigm bases on the
the code into module or functions. concept of objects, which contain
data in the form of fields known as
attributes, and code in the form of
procedures known as methods.
- Focuses on dividing the program into -Focuses on representing a program
a set of functions in which each using a set of objects which
function works as a subprogram. encapsulates data and object.
- Difficult to modify structured - Easier to modify object oriented
programs. programs.
- Main method communicates - Object communicate with each
with functions by calling those other by passing messages
functions in the main program.
 - These are no access specifiers. - There are access specifiers such
as private, public and protected.
- Data is not secured. - Data is secured.
- Difficult to reuse code. - Easy to reuse code.

Programming and development process.

- Coding is an end goal of software development.
- Iterative and incremental development process results in the feeding of
prior iteration into the beginning of next iteration, continuously refining the
implementation works.

5.2 Mapping design to code (Forward Engineering)

- It involves the implementation of object oriented design into the object
oriented programming code.
- It requires writing code for:
o Class and interface definitions.
o Method definitions
 Class definitions are created by mapping design class diagrams
to code.
 Method definition are created by mapping interaction diagram
to code.
5.2.1 Class definitions are created by mapping design class diagrams to code.
 public class SalesLineItem
{
Private int quantity:
Private ProductDescription description:
Public SalesLineItem (ProductDescription desc, int, qty)
{
……
}
Public Money get Subtotal ()
{
…
}
5.2.2 Method definition are created by mapping interaction diagram to
code.

Public void enterItem (ItemID id, int qty)

{
ProductDescription desc = catalog.getProductDescription (id);
currentSale.makeLineItem (desc, qty);
}
Assignment
 5.3 Exception and error handling in Object oriented software development
based.
- An exception is a condition that is caused by a runtime error in the
program.
o Invalid data entered by a user.
o File to be opened cannot be found.
o The network connection has lost in the middle of the
communication.
Sources for exception
- User errors
- Programmer errors
- Physical resource failure

Category of Exception
1. Checked exception
- It is the exception that cannot be foreseen by the programmer.
File Not Found Exception

2. Runtime exception
- It is the exception that could be avoided by the programmer.
- It is ignored at the time of compilation.
3. Error
- They are the problems beyond the control of user and programmer.
Exception Handling Process:
- In OOPL, there is a mechanism to handle exceptions in a proper manner.
- Try, throw and catch are the basic exception handling paradigms used.
- The general code is put in try block. It means try to execute the code.
- If the system succeeds to execute the code, execution flows in general or
normal order.
 - If something goes wrong while executing the try block, this code throws an
exception objects and stops executing code of try block.
- The error handler catches the exception object and make necessary actions
needed.
- Execution continues with the next instructions following the catch block.

Example of Error Handling in JAVA

Class WithExceptionHandling
{
Public static void main (string [] args)
{
Int a, b;
Float r;
a = 7; b = 0;
try
{
r = a/b;
system.out. println(“Result = “ + r);
}
Catch (ArthmeticExceptipon e)
{
System.out.println(“B is zero);
}
}
}

Exception Hierarchy
User Defined Exceptions
- All the exceptions must inherit Throwable class.
- For runtime exception, extend RuntimeException class.
- For checked exception, extend exception class.

5.4 Miscellaneous topics in OOAD

a) Forward engineering
- Forward engineering is the process of building from a high level model or
concept to build in complexities and lower level details.
- It moves from logical implementation to the physical implementations of a
system.
- It transforms a model into code through mapping to an implementation
language.
- It may cause loss in information as models are semantically richer than OOP
language.
- The structural and behavioral features are clearly visualized form the model
but not from a raw code.

b) Reverse engineering
- Reverse engineering is the process of extracting knowledge or design
information from the code.
- It includes disassembling of a computer program and analyze its
components and working in details.
- It transforms code into a model through mapping from a specific
implementation language.
- It is generally incomplete as the model cannot be completely recreated due
to information loss during forward engineering process.

c) Roundtrip engineering
- Roundtrip engineering is a functionality that synchronizes two or more
software artifacts like source code, models and so on.
- It is necessary when same information is present in multiple artifacts and
needed to be updated.
 - It has ability to synchronize existing artifacts that evolved concurrently by
incrementally updating each artificats to reflect changes made to other
artifacts.

d) Interface
- Interface is a concept of abstraction and encapsulation.
- It defines a set of methods, that an instance of a class that has that
interface.
- It declares the non-private method.
- It does not show the method implementation.
- It describes the actions that an object can do.
- No variables are allowed to be declared.
- All the functions listed must be public.
- The function description is not mentioned.

Example
public interface vehicle
{
function start_engine();
}
public class car implements vehicle
{
{
Function start_engine()
{
…….
}
}
5.5 Activity
diagram
and Swim
Lanes
- Draw activity diagram to withdraw money from ATM.
Course Complete
Questions
Submitted date: 8th August 2021

1. Draw the use case diagram for withdraw cash of Banking system.
2. Explain the types of OOAD models and describe the role of constraint
specification in a diagram.
3. Explain forward engineering and reverse engineering with its advantage.
4. What is CRC? Explain with the diagram.
5. Difference between OOD and OOA.
6. Construct a system sequence diagram for customer from a “Food ordering
system” of a very busy restaurant where seating and ordering is regulated
by seating manager.
7. Illustrate how can you create classes from design class diagram and
methods from interaction diagrams.
8. Explain development process with suitable example. How can you map
design into code?
9. What is framework? How design pattern is useful? Explain any one pattern
in details with suitable example.
10. Read the following case study carefully and answer the given questions:
Ministry of Health and population is willing to computerize the system. This
new system will be able to tell the population of the country, zone and
district and even of the word of specific place. The system will update its
data in monthly basis so that the birth rate and death rate can be easily
seen. The home page is displayed when a person enters to the system.
Administrators can enter to the admin panel by logging in with an ID and
Password. He/She has privileges to enter and modify the data into the
database. On the other hand, normal users can view the data but not
modify them. They can also visualize the data in graphical form with
animated charts, maps as well as in tabular form based on their selection of
data. Besides, they can also view the forecasted data. (Make your
assumptions if necessary)
Draw the collaboration diagram and use case diagram.

11. PU is willing to develop a system for the student result management of its
BCA program. Now, prepare the problem statement from the side of
examination control division. What are the building blocks of UML? Explain
with suitable examples and notations.
12. Explain object oriented system with reference to class, object,
encapsulation, abstraction message, inheritance, interface and
polymorphism with suitable examples.
13.Write short notes
 a. Sequence diagram
b. Swim lanes
c. Polymorphic signal
14. Draw a state diagram for the clock control unit.
15.Explain four different types of relationships that we model in object-
oriented analysis, which exists between two different classes.
a. Dependency
b. Association
c. Realization
d. Generalization