1

Question) List and explain (Discuss) the stages in object oriented

methodology.
Object-oriented methodology (OOM) is a software development approach that uses real-world objects as the
foundation for modeling and designing software systems. The same object-oriented concepts and notation are used
throughout the entire software development process. The stages in OOM are:

1. System Conception: During this initial stage, the application is envisioned and the requirements are loosely
formulated. This stage involves identifying the need for the system, its potential users, and the problems it
aims to solve. It's a brainstorming phase where the feasibility and potential value of the system are assessed.

2. Analysis: The analysis stage involves a deep dive into the requirements. This is where developers create
models to gain a thorough understanding of what the system needs to do. This stage is divided into two
parts:

o Domain Analysis: This focuses on understanding the real-world context of the problem. It involves
identifying the key objects, their attributes (characteristics), and their relationships in the problem
domain. The goal is to create a model that accurately reflects the real-world system the software will
interact with.

o Application Analysis: This part focuses on the computer aspects of the application that are visible to
the users. It involves defining the user interface, identifying the commands and operations that
users will interact with, and specifying how the system will respond to user actions.

3. System Design: In this stage, developers devise a high-level strategy for solving the problem. This includes
making decisions about the system's architecture, the technologies to be used, and the overall structure of
the software. It's a crucial stage where the foundation for the system's implementation is laid.

4. Class Design: This stage involves refining the analysis models and adding more details to prepare for
implementation. It includes defining the classes (blueprints for objects), their attributes, and their operations
(actions they can perform). Algorithms for implementing the system's behavior are also designed in this
stage.

5. Implementation: This is where the actual coding takes place. The design is translated into a specific
programming language, and the database structures are created. The goal is to create a working system that
adheres to the design and fulfills the requirements.

6. Testing: Rigorous testing is conducted to ensure that the implemented system is free of errors and functions
as expected. This includes unit testing (testing individual components), integration testing (testing how
components work together), and system testing (testing the entire system).

7. Training: Users are trained on how to use the new system effectively. This involves creating user
documentation and providing instructions or workshops to help users understand the system's features and
functionalities.

8. Deployment: The system is deployed in the real-world environment where it will be used. This involves
installing the software, configuring it for the specific environment, and ensuring that it integrates smoothly
with existing systems.

9. Maintenance: After deployment, the system needs ongoing maintenance to fix bugs, address issues, and
adapt to changing requirements. This stage ensures the system's longevity and continued effectiveness.
2

Question) The domain “ATM System” keeps the day by day tally record as a
complete banking. Banking employees want to improve the way they
maintain information about their customers. In particular, they want to create
an information system that is able to perform the following functions- deposit,
withdrawal, and searching the transaction, transaction report, etc. The
exciting part of this project is; it displays transaction reports, statistical
summary of account type and interest information. Design and discuss a class
model for the given simple banking system with suitable UML notations.

Relationships (Associations)

 Customer - Account: A customer can have multiple accounts (one-to-many relationship).

 Account - Transaction: An account has a history of transactions (one-to-many relationship).

Question) Prepare a class diagram for the group of classes given below. Add relationships (association and
generalizations) to your diagram. Use association names and association end names where needed. Also use
qualified association, association class, enumeration and show multiplicity. Show minimum two attributes and
methods for each class. Explain your diagram.
3

school, playground, principal, school board, classroom, book, student, teacher, cafeteria, restroom, computer, desk,
chair, ruler, door, swing

Question) Analyze and identify the list of classes that you would expect each
of the following systems to handle.

1) A program to compute and store bowling scores.

2) A catalog store order entry system.
3) A telephone voice mail system with delivery options, message
forwarding, and group lists.

The classes that you would expect the following systems to handle are:

1. A program to compute and store bowling scores:

o Bowler
o Team
o Game
o Frame
o Roll
o Score
2. A catalog store order entry system:
o Customer
o Order
o Product
o OrderItem
o Inventory
o ShippingAddress
o BillingAddress
o Payment
3. A telephone voice mail system with delivery options, message forwarding, and group lists:
4

o User
o Mailbox
o Message
o Greeting
o DistributionList
o DeliveryOption

Question) Illustrate the restructuring technique used to deal the multiple

inheritance issue with relevant examples.
Multiple inheritance, while powerful, can introduce complexities in object-oriented design. To address this,
developers often use restructuring techniques. Here are the primary techniques, along with examples:

1. Delegation using Composition of Parts:

o Concept: Instead of a class inheriting directly from multiple superclasses, it's composed of
parts, each representing one of the original superclasses. The class then delegates operations
to the appropriate part.
o Example: An Employee class could be composed of EmployeeEmployment (handling full-
time/part-time status) and EmployeeManagement (handling manager/individual contributor
status). If a method like calculateBonus() is called on Employee, it would delegate the
calculation to either EmployeeEmployment or EmployeeManagement based on the
employee's role.
2. Inherit the Most Important Class and Delegate the Rest:
o Concept: The class inherits from the most crucial superclass and uses composition and
delegation for the less important ones.
o Example: In a vehicle hierarchy, a Car might inherit from LandVehicle (the dominant
superclass) and delegate to InsuredItem (a less important aspect) for insurance-related
operations.
3. Nested Generalization:
o Concept: Create multiple levels of inheritance, essentially multiplying out all possible
combinations of superclasses.
o Example: Instead of FullTimeEmployee inheriting from both Employee and FullTime, you'd
have FullTimeManager and FullTimeIndividualContributor as subclasses of
FullTimeEmployee. This can lead to a proliferation of classes if not used judiciously.

Choosing the Right Technique

The choice of technique depends on several factors:

 Importance of Superclasses: If all superclasses are equally important, delegation might be preferred
to maintain symmetry. If one superclass is dominant, inheriting from it and delegating the rest could
be a good option.
 Number of Subclasses: Nested generalization is manageable with few subclasses, but it can become
unwieldy with many.
 Code Duplication: Nested generalization can lead to code duplication, which should be avoided if
possible.
 Identity: If maintaining strict object identity is crucial, nested generalization might be the only
option.

Question) Illustrate with example the different types of events in state

modeling.
In state modeling, events are occurrences that trigger transitions between states. The different types of events are:
5

1. Signal Event:

o A signal event is the transmission of information from one object to another. It's a one-way
communication where an object sends a signal (a message) to another object, which may or may not
respond.

o Example: In a phone system, when a user presses a button to dial a number, a signal is sent to the
phone system to initiate the call. The signal contains the dialed number as information. Another
example is when the phone system sends a ring signal to the receiver's phone.

2. Change Event:

o A change event is triggered when a specific condition becomes true. The condition is continuously
monitored, and the event occurs at the moment the condition changes from false to true.

o Example: In a home security system, the event of a door opening while the alarm is armed is a
change event. The system constantly checks the state of the door sensor, and when it detects the
door opening, it triggers the alarm.

3. Time Event:

o A time event is an event that occurs at a specific time or after a certain time interval.

o Example: In a traffic light system, the event of the light changing from green to yellow after a fixed
duration is a time event. The system keeps track of time, and when the specified interval elapses, it
triggers the light change.

Question) Differentiate between

(a)Aggregation and Composition with relevant example

(b)Abstract class and Concrete class with example

(a) Aggregation vs. Composition

Both aggregation and composition are types of associations in UML class diagrams, representing part-whole
relationships between objects. However, they differ in the strength of the relationship and object lifecycle
dependencies.

Aggregation

 Definition: A "has-a" relationship where the whole (aggregate) is made up of parts (components), but the
parts can exist independently of the whole.

 Key Characteristics:

o Ownership: The aggregate may own the parts, but the parts can be shared with other aggregates.

o Lifetime: The parts can outlive the whole. If the whole is destroyed, the parts can still exist.

 UML Notation: A hollow diamond on the aggregate side of the association.

 Example: A Car has an Engine. The engine can be removed from the car and used in another car, or it can
exist on its own.

Composition
6

 Definition: A stronger "has-a" relationship where the whole is entirely responsible for the existence of its
parts.

 Key Characteristics:

o Exclusive Ownership: The parts belong exclusively to the whole and cannot be shared.

o Coincident Lifetime: The parts are created when the whole is created and destroyed when the
whole is destroyed.

 UML Notation: A filled diamond on the aggregate side of the association.

 Example: A Building is composed of Rooms. The rooms cannot exist without the building, and if the building
is demolished, the rooms are also destroyed.

(b) Abstract Class vs. Concrete Class

Abstract Class

 Definition: A class that cannot be instantiated (you cannot create objects directly from it). It serves as a
blueprint for its subclasses, defining common attributes and operations.

 Key Characteristics:

o May contain abstract methods (methods without implementation).

o Provides a common interface for its subclasses.

 UML Notation: The class name is written in italics, or the keyword {abstract} is added.

 Example: A Shape class could be abstract, defining methods like area() and perimeter(), but not providing
specific implementations for them.

Concrete Class

 Definition: A class that can be instantiated (you can create objects directly from it).

 Key Characteristics:

o Provides implementations for all its methods (including any inherited abstract methods).

 UML Notation: The class name is written in regular font.

 Example: Circle and Rectangle would be concrete subclasses of Shape, providing specific implementations
for the area() and perimeter() methods.

Question) Define Concurrency. Illustrate any two ways of handling

concurrency in state modeling with an example for each.
Concurrency in the context of state modeling refers to the ability of a system to have multiple active states
simultaneously. In other words, different parts of the system can be in different states and undergoing transitions
independently at the same time.

Here are two common ways to handle concurrency in state modeling, each with an illustrative example:

1. Orthogonal Regions (Concurrent Substates):

7

 Concept: An orthogonal region is a composite state divided into multiple compartments, each representing
an independent state machine. These regions operate concurrently, meaning they can be in different states
simultaneously.

 UML Notation: Orthogonal regions are depicted as compartments within a state, separated by dashed lines.

 Example: Consider a printer that can print documents while simultaneously receiving new print jobs and
managing its ink levels. (Draw the diagram)

o Printing Region: Handles the states involved in printing a document (e.g., "Idle," "Printing,"
"Paused").

o Job Queue Region: Manages the queue of pending print jobs (e.g., "Empty," "Waiting").

o Ink Level Region: Monitors and reports the ink levels (e.g., "Full," "Low," "Empty").

These regions operate independently. For instance, the printer can be in the "Printing" state while also having jobs
"Waiting" in the queue and a "Low" ink level.

2. Fork and Join Pseudostates:

 Concept: Fork and join pseudostates explicitly control the splitting and merging of concurrent threads of
execution within a state machine.

 UML Notation:

o Fork: A horizontal bar with multiple outgoing transitions.

o Join: A horizontal bar with multiple incoming transitions.

 Example: A vending machine that dispenses a product and gives change can have concurrent processes for
dispensing and change calculation.

UML state diagram for a vending machine with fork and join pseudostates

1. Fork: Upon receiving payment, the state machine forks into two concurrent regions.

2. Concurrent Regions: One region handles dispensing the product, and the other calculates the
change.
8

3. Join: Both regions must complete before the "Dispensing Complete" state is reached, indicating the
transaction is finished.

Key Points:

 Both orthogonal regions and fork/join pseudostates allow for modeling independent, concurrent activities
within a system.

 Orthogonal regions are often used when there's a clear separation of concerns, while fork/join is more
explicit about the points of concurrency and synchronization.

 Choosing the appropriate technique depends on the specific system being modeled and the level of control
and clarity desired in the state machine representation.

Question) Explain the Use Case Relationships with example for each.
Use case relationships are a way to structure and organize use cases in a system, especially in larger, more complex
systems. They help to avoid redundancy, promote reuse, and clarify the interactions between different use cases.
Here are the three main types of use case relationships, along with examples:

1. Include Relationship (<<include>>)

o Purpose: The include relationship allows one use case (the base use case) to incorporate the
behavior of another use case (the included use case). This is used when a piece of behavior is
common to multiple use cases, avoiding repetition.

o Example: In an online banking system, the use cases "Transfer Funds" and "Pay Bills" might both
include the use case "Authenticate User." This avoids having to describe the authentication process
separately for each use case.

2. Extend Relationship (<<extend>>)

o Purpose: The extend relationship allows one use case (the extension use case) to add additional
behavior to another use case (the base use case). This is used to model optional or conditional
behavior.

o Example: In an e-commerce system, the use case "Place Order" might be extended by the use case
"Apply Discount" if the customer has a valid discount code.

3. Generalization Relationship:

o Purpose: The generalization relationship is similar to inheritance in class diagrams. It allows one use
case (the child use case) to inherit and specialize the behavior of another use case (the parent use
case).

o Example: In a library system, the use case "Borrow Item" might be specialized into "Borrow Book,"
"Borrow DVD," and "Borrow Magazine." Each child use case inherits the basic borrowing process but
adds specific details for the type of item.

Question) Consider the following Problem statement (given below) for ATM System: “Design the
software to support a computerized banking network including both human cashiers and automatic
teller machines (ATMs) to be shared by a consortium of banks. Each bank provides its own computer to
maintain its own accounts and process transactions against them. Cashier stations are owned by
individual banks and communicate directly with their own bank’s computers. Human cashiers enter
9

account and transaction data. Automatic teller machines communicate with a central computer that
clears transactions with the appropriate banks. An automatic teller machine accepts a cash card,
interacts with the user, communicates with the central system to carry out the transaction, dispenses
cash, and prints receipts. The system requires appropriate recordkeeping and security provisions. The
system must handle concurrent accesses to the same account correctly. The banks will provide their own
software for their own computers; you are to design the software for the ATMs and the network. The
cost of the shared system will be apportioned to the banks according to the number of customers with
cash cards.”

What criteria would you take into consideration to find relevant classes?
Analyze with an example how to select the good classes from the set of ATM
classes that are identified from the knowledge of problem domain.
To find relevant classes for the ATM system, we should consider the following criteria:

 Relevance to the Problem Domain: Classes should represent the key entities and concepts within the ATM
system's problem domain. These are the real-world objects and ideas that the system needs to model and
interact with.

 Clear Boundaries and Definition: Each class should have a well-defined purpose and scope. Avoid vague or
overly broad classes that could lead to confusion or overlap in functionality.

 Importance to the Application: Classes should be chosen based on their significance to the ATM system's
functionality. Exclude classes that are not essential to the core operations of the system.

 Not Implementation Constructs: Avoid including classes that are purely technical implementation details
(e.g., data structures like arrays or linked lists). These are design and implementation concerns, not analysis
concerns.

Example Analysis of ATM Classes

Let's analyze some ATM classes identified from domain knowledge and determine their relevance:

Not an
Relevance to Clear Importance to Keep or
Class Implementation
Problem Domain Boundaries/Definition Application Discard
Construct

Customer High Yes High Yes Keep

Transaction High Yes High Yes Keep

CashCard High Yes High Yes Keep

Account High Yes High Yes Keep

No (Implementation
TransactionLog Low Low No Discard
Detail)

No (Implementation
CommunicationsLine Low Low No Discard
Detail)

drive_spreadsheetExport to Sheets
10

Explanation:

 Customer, Transaction, CashCard, Account: These classes are essential to the core functionality of an ATM
system. They represent real-world entities and concepts that the system needs to model and interact with.

 TransactionLog, CommunicationsLine: These classes are implementation details. While important for the
technical realization of the system, they are not fundamental to understanding the problem domain at the
analysis stage.

By applying these criteria, we can refine the initial list of classes and focus on those that are truly relevant to
modeling the ATM system's domain.

Question) Discuss the steps involved in constructing Application Interaction

Model for ATM System and illustrate with example for each.

The steps involved in constructing an Application Interaction Model for an ATM System are as follows:

1. Determine the System Boundary: Clearly define the scope of the ATM system. This involves
deciding what is included within the system (e.g., ATM machine, software components) and what is
external (e.g., the customer, the bank's central computer).
o Example: In the ATM system, the boundary could be defined as the ATM machine itself and
its software components. The customer interacting with the ATM and the bank's central
computer would be considered external to the system.
2. Find Actors: Identify the external entities that interact directly with the system. These are the actors.
o Example: In the ATM system, the primary actor is the Customer. Other potential actors
could include a Bank Technician (for maintenance) or a Bank System (for communication).
3. Find Use Cases: For each actor, determine the different ways they interact with the system. Each
unique interaction is a use case.
o Example: For the Customer actor, use cases could include:
 Withdraw Cash
 Deposit Cash
 Check Balance
 Transfer Funds
4. Find Initial and Final Events: For each use case, identify the event that starts the interaction and
the event(s) that mark its completion.
o Example: For the Withdraw Cash use case:
 Initial Event: Customer inserts card
 Final Events: Customer receives cash and receipt, Transaction canceled
5. Prepare Normal Scenarios: Create a detailed description of the typical sequence of actions and
interactions for each use case under normal conditions.
o Example (Withdraw Cash):
1. Customer inserts card.
2. ATM prompts for PIN.
3. Customer enters PIN.
4. ATM verifies PIN.
5. ATM displays account options.
6. Customer selects withdrawal.
7. ATM prompts for amount.
8. Customer enters amount.
9. ATM dispenses cash.
10. ATM prints receipt.
6. Add Variation and Exception Scenarios: Consider alternative paths and error conditions within
each use case.
o Example (Withdraw Cash):
 Invalid PIN entered.
11

 Insufficient funds.
 Machine out of cash.
7. Find External Events: Identify all events that originate from outside the system (e.g., user input,
signals from other systems).
o Example:
 Card inserted
 PIN entered
 Amount entered
 Button pressed
8. Prepare Activity Diagrams (Optional): For complex use cases, create activity diagrams to
visualize the flow of actions and decisions.
9. Organize Actors and Use Cases: Use relationships like <<include>>, <<extend>>, and
generalization to structure the use cases and actors if needed.
10. Check Against the Domain Class Model: Ensure that the interaction model aligns with the classes
and relationships defined in the domain model. Any inconsistencies should be resolved.

Question) Analyze and illustrate with an example the different sources used in
making a reuse plan.

Reuse is a software engineering principle that involves using existing assets to create new software. It can
save time, effort, and resources while improving the quality and reliability of the software. A reuse plan
identifies and evaluates potential reusable components and strategies for incorporating them into the new
system. Here are the different sources used in making a reuse plan:

1. Models:
o Models from previous projects can be reused if they capture similar concepts and
relationships.
o Example: A model of a banking system could be reused for a new financial application, as it
likely shares concepts like accounts, transactions, and customers.
2. Libraries:
o Libraries are collections of pre-written classes and functions that can be incorporated into
new projects.
o Example: A math library containing functions for trigonometric calculations, matrix
operations, or statistical analysis can be reused in various scientific or engineering
applications.
3. Frameworks:
o Frameworks provide a skeletal structure for an application, with placeholders for specific
functionality to be added.
o Example: A web application framework like Ruby on Rails or Django provides a structure
for handling requests, routing, and database interactions, allowing developers to focus on the
unique aspects of their application.
4. Patterns:
o Patterns are reusable solutions to common design problems. They describe a general
approach to solving a problem that can be adapted to different contexts.
o Example: The Model-View-Controller (MVC) pattern is a design pattern that separates an
application's data (model), presentation (view), and control logic (controller), making the
system more modular and easier to maintain.

Question) Analyze how Fine-tune classes and Fine-tune generalizations are

prepared from analysis and design during implementation modeling.

Implementation modeling is the stage in object-oriented software development where the design model,
created during the analysis and design phases, is refined and prepared for the actual coding process. During
12

this stage, developers make decisions about how to best represent the classes and generalizations in the
chosen programming language. Two key steps in this process are:

1. Fine-tuning Classes: This involves adjusting the structure of classes to make them easier to
implement or to improve the performance of the final code. This might include:
o Partitioning a Class: Splitting a class into multiple smaller classes if it has too many
responsibilities or unrelated attributes.
o Merging Classes: Combining classes that have very similar attributes and behaviors.
o Adjusting Attributes: Partitioning or merging attributes within a class to improve clarity or
organization.
o Promoting/Demoting Attributes: Deciding whether a concept should be represented as an
attribute of a class or as a separate class itself.

Example: In an e-commerce system, a Customer class might initially contain both billing and
shipping address information. During implementation modeling, you might decide to split this into
separate BillingAddress and ShippingAddress classes for better organization and potential reuse.

2. Fine-tuning Generalizations: This involves refining the inheritance hierarchy to ensure it

accurately reflects the relationships between classes and to optimize code reuse and maintainability.
This might include:
o Removing Generalizations: If a generalization doesn't provide significant benefits in terms
of code reuse or conceptual clarity, it might be removed.
o Adding Generalizations: New generalizations might be introduced to capture commonalities
between classes that were not initially apparent.

Example: In a vehicle management system, you might initially have separate classes for Car, Truck,
and Motorcycle. During implementation modeling, you might realize that they share common
attributes and behaviors (like make, model, year, startEngine(), stopEngine()), and create a
more general Vehicle class as their superclass.

These fine-tuning steps are crucial because they bridge the gap between the abstract design and the concrete
implementation. They ensure that the code is well-structured, efficient, and maintainable, ultimately leading
to a more robust and successful software system.

Question) Describe the role of link and association among objects and classes.
Links and associations are fundamental concepts in object-oriented modeling that describe the relationships
between objects and classes.

Links

A link is a connection between two or more objects. It represents a specific instance of a relationship between
objects. For example, if "John" is an object of the class "Person" and "Microsoft" is an object of the class "Company,"
then the statement "John works for Microsoft" represents a link between these two objects.

Associations

An association is a description of a group of links with a common structure and semantics. It defines the type of
relationship that can exist between objects of particular classes. In the example above, the association would be
"Person works for Company." This association describes the general relationship that can exist between any person
and any company.

Key Differences
13

 Instance vs. Type: A link is a specific instance of a relationship between objects, while an association is the
general type of relationship that can exist.

 Verbs vs. Nouns: Links are often represented as verbs (e.g., "works for"), while associations are often
represented as nouns (e.g., "employment").

 Object vs. Class Level: Links connect objects, while associations connect classes.

Role in Object-Oriented Modeling

Links and associations play a crucial role in object-oriented modeling by:

 Representing Relationships: They capture how objects interact and relate to each other in the real world or
within a software system.

 Providing Structure: They help to organize and structure the class model, making it easier to understand the
system's overall design.

 Enabling Navigation: They allow you to navigate between objects in the system, following the links to access
related objects.

 Enforcing Constraints: They can be used to specify constraints on the number of objects that can be linked
together (multiplicity).

In essence, links and associations are the "glue" that holds the object-oriented model together, providing a way to
represent and reason about the complex relationships between objects and classes.

Question) Explain Qualified Association with a suitable example.

A qualified association is a special type of association in UML class diagrams where an attribute, known as the
qualifier, is used to refine the relationship between classes. The qualifier acts as a key to select specific objects on
the "many" side of the association.

Key Points:

 Purpose: Qualified associations are used to add precision and reduce the effective multiplicity of an
association. They help in navigating and identifying specific objects within a relationship.

 Notation: A qualified association is represented by a small box attached to the association line near the
source class. The box contains the qualifier attribute.

 Multiplicity Reduction: The qualifier effectively reduces the multiplicity from "many" to "one" or "zero-to-
one," as it allows for the selection of a specific object based on the qualifier value.

Example:

Consider a Bank and Account relationship. A bank can have many accounts, but each account is uniquely identified
by an accountNumber within the context of that bank.

In this example:

 The association between Bank and Account is one-to-many (a bank can have many accounts).

 The accountNumber attribute is the qualifier.

14

 The qualified association indicates that for a given Bank and a specific accountNumber, there can be at most
one Account.

Benefits of Qualified Associations:

 Improved Navigation: They provide a clear path for navigating from the source class (Bank) to a specific
target object (Account) using the qualifier (accountNumber).

 Reduced Ambiguity: They clarify relationships where multiple objects of the same class can be associated
with a single object of another class.

 Enhanced Modeling Precision: They add a constraint to the model, specifying that the combination of the
source object and the qualifier value yields a unique target object.

Question) Discuss the significance of multiplicity in modeling and its UML

notation.
Multiplicity is a crucial concept in object-oriented modeling, specifically within class diagrams of the Unified
Modeling Language (UML). It defines the possible number of instances of one class that can be associated with a
single instance of another class. In essence, it quantifies the relationship between classes.

Significance of Multiplicity

 Defines Relationships: Multiplicity clarifies the nature of relationships between objects. It specifies whether
a relationship is one-to-one, one-to-many, many-to-many, or some other variation. This is essential for
understanding how objects interact and depend on each other within a system.

 Constrains the Model: Multiplicity acts as a constraint on the number of related objects. It helps to ensure
the logical consistency and integrity of the model by preventing invalid relationships. For example, if a model
specifies that a car can have only one engine, the multiplicity constraint would prevent a scenario where a
car is associated with multiple engines.

 Guides Implementation: Multiplicity provides valuable guidance during the implementation phase. It helps
developers choose appropriate data structures and algorithms to represent and manage relationships
between objects in the code.

UML Notation for Multiplicity

Multiplicity is represented in UML class diagrams using numeric intervals or special symbols at the ends of
association lines. Here's a breakdown of the notation:

Question) Explain <<include> and <<extend>> relationships in use case

diagram with an example.
Absolutely! Let's break down <<include>> and <<extend>> relationships in use case diagrams with clear examples:

1. Include Relationship (<<include>>)

 Purpose: The <<include>> relationship denotes that a base use case always incorporates the behavior of
another use case (the included use case). This is used to represent common functionality that's reused
across multiple use cases, preventing redundancy and promoting modularity.

 Notation: A dashed arrow points from the base use case to the included use case, with the keyword
<<include>> above the arrow.
15

 Example:

In an ATM system, the use cases "Withdraw Cash" and "Check Balance" both require the user to be authenticated
first. The "Authenticate User" use case represents this shared functionality.

 Explanation:

o Both "Withdraw Cash" and "Check Balance" include the "Authenticate User" use case, indicating that
authentication is a mandatory step in both scenarios.

o This avoids repeating the authentication steps in each use case's description.

2. Extend Relationship (<<extend>>)

 Purpose: The <<extend>> relationship indicates that an extending use case adds optional or conditional
behavior to a base use case. This is used to model variations or exceptions to the normal flow of a use case.

 Notation: A dashed arrow points from the extending use case to the base use case, with the keyword
<<extend>> above the arrow.

 Example:

In an online shopping system, the "Place Order" use case might be extended by the "Apply Discount" use case, which
is only triggered if the user has a valid discount code.

 Explanation:

o "Apply Discount" extends "Place Order," meaning it can optionally modify the base use case's flow.

o The "extension point" specifies when the "Apply Discount" use case can be triggered (e.g., after the
user enters a discount code).

Key Differences

Feature Include (<<include>>) Extend (<<extend>>)

16

Nature of Inclusion Mandatory Optional

Relationship Base is incomplete without included Base is complete on its own

Trigger Always at specific points Conditional (at extension points)

Purpose Reuse common behavior Model variations/exceptions

Additional Points

 Avoid Overuse: Using too many include or extend relationships can make the diagram overly complex. Use
them judiciously to enhance clarity and modularity.

 Focus on User Goals: Remember that use cases should focus on what the user wants to achieve, not on the
technical implementation details.

Question) Explain substate in state diagram and its importance with an

example.
In the context of state modeling, a substate is a state that exists within a higher-level state, known as a composite
state. Substates help to represent more complex behaviors and hierarchical relationships between states.

Importance of Substates

 Hierarchical Organization: Substates allow for a hierarchical organization of states, making the state diagram
more readable and easier to understand, especially for complex systems.

 Shared Behavior: Substates within a composite state can share common transitions and actions, reducing
redundancy in the diagram.

 Refinement of Behavior: Substates can refine the behavior of the composite state, providing more detailed
information about specific scenarios or conditions.

Example

Consider a vending machine. The overall state of the machine could be "Active," which is a composite state. Within
the "Active" state, there could be substates like "Waiting for Selection," "Dispensing Item," and "Returning Change."

In this example:

 The "Active" state is the composite state.

 "Waiting for Selection," "Dispensing Item," and "Returning Change" are substates within "Active."

 Each substate represents a specific stage in the vending machine's operation.

 The transitions between substates are triggered by events like "Item Selected," "Item Dispensed," and
"Change Returned."

By using substates, the state diagram becomes more organized and easier to understand. The "Active" state provides
a high-level view of the machine's operation, while the substates provide more detailed information about the
specific steps involved.
17

Question) Explain swimlanes in activity diagram with an example.

Swimlanes in an activity diagram are used to partition the diagram into vertical columns, each representing a
responsible party for the activities within that column. These responsible parties can be individuals, departments, or
even entire organizations. Swimlanes help to visualize which part of the system or process is responsible for each
activity, making the diagram easier to understand and analyze.

Example: Airline Flight Departure Process

In this example, the swimlanes represent different groups involved in the flight departure process:

 Passenger: Activities like check-in, security check, and boarding.

 Airline Staff: Activities like baggage handling, check-in processing, and boarding announcements.

 Ground Crew: Activities like fueling, maintenance checks, and pushback.

 Air Traffic Control: Activities like granting clearance for takeoff and managing airspace.

The diagram shows the flow of activities within each swimlane and the interactions between swimlanes through the
exchange of signals or data. For instance, the "Passenger" swimlane sends a "Boarding Pass" to the "Airline Staff"
swimlane, which then allows the passenger to proceed to the "Security Check."

Swimlanes are particularly useful in business process modeling, where it's important to understand the roles and
responsibilities of different departments or teams. They can also be used in software development to show which
components or modules are responsible for specific actions.

Question) Discuss the list of criteria to discard unnecessary and incorrect

classes while constructing domain class model with an example.
When constructing a domain class model, it's essential to refine the initial list of candidate classes to ensure
the model is accurate and focused. Here are the criteria to discard unnecessary or incorrect classes:

1. Redundant Classes: If two classes represent the same concept, keep the one with the most
descriptive and clear name.
2. Irrelevant Classes: Eliminate classes that have little or no relevance to the problem domain being
modeled.
3. Vague Classes: Discard classes with unclear boundaries or overly broad scopes. Ensure each class
has a specific and well-defined purpose.
4. Attributes: If a name primarily describes an individual object's characteristic, it should be modeled
as an attribute rather than a separate class.
5. Operations: If a name describes an action performed on an object rather than an object itself, it
should be modeled as an operation (method) of the relevant class.
6. Roles: Avoid naming classes based on the roles they play in associations. Instead, focus on their
intrinsic nature.
7. Implementation Constructs: Exclude classes that are purely technical implementation details (e.g.,
data structures, algorithms) from the analysis model.
8. Derived Classes: Omit classes that can be derived from other classes in the model. If a derived class
is essential, mark it with a slash (/) to indicate its derived status.

Example: Refining ATM Classes

Consider the following candidate classes for an ATM system:

18

 Customer
 User (redundant with Customer)
 Transaction
 Cash (better as an attribute of Transaction)
 Receipt (better as an attribute of Transaction)
 System (too vague)
 RecordKeepingProvision (vague, handled by Transaction)

Applying the criteria:

1. Redundant: User is redundant with Customer. We keep Customer.

2. Irrelevant: None in this list.
3. Vague: System and RecordKeepingProvision are too vague and should be discarded or refined.
4. Attributes: Cash and Receipt are better represented as attributes of Transaction.
5. Operations: None in this list.
6. Roles: None in this list.
7. Implementation Constructs: None in this list.
8. Derived Classes: None in this list.

Refined List:

 Customer
 Transaction
 Account (implied by the problem statement)
 ATM (implied by the problem statement)

By discarding or refining unnecessary classes, we create a more focused and accurate domain class model
for the ATM system.

Question) Explain the purpose of boundary classes in the application model.

Boundary classes are used in the application model to create a buffer between the internal workings of a
system and its external interfaces. They serve several important purposes:

1. Information Conversion: Boundary classes are responsible for converting information between the
format used by the system internally and the format expected by external actors or systems. This
ensures smooth communication and data exchange.
2. Encapsulation: They encapsulate the details of external interactions, hiding the internal complexity
of the system from the outside world. This promotes modularity and makes it easier to change the
internal implementation without affecting how external actors use the system.
3. Adaptability: Boundary classes make the system more adaptable to changes in external interfaces or
protocols. If the external environment changes, you only need to modify the boundary class, leaving
the core system logic untouched.
4. Simplified Testing: By isolating external interactions, boundary classes make it easier to test the
system's behavior in a controlled manner. You can simulate different external inputs and verify that
the boundary class correctly translates them for the internal system.

Example in the ATM System:

In an ATM system, a boundary class called CashCardBoundary could be responsible for:

 Reading data from the physical cash card.

 Validating the card's format and security features.
 Converting the card data into a format that the ATM's internal system can understand.
19

This boundary class shields the internal ATM system from the specifics of how cash card data is stored and
read, making the system more modular and adaptable to changes in card technology.

Question) Explain the different steps involved in design optimization.

Design optimization is the process of refining a software design to improve its efficiency, performance, and
resource utilization without altering its core functionality. It's typically done after the initial design is
complete and functional to avoid premature optimization, which can lead to overly complex and less
maintainable code. The main steps involved in design optimization are:

1. Provide Efficient Access Paths:

o Analyze how the system accesses data and identify any bottlenecks or areas where access is
slow.
o Add redundant associations or indexes to the class model to create shortcuts for frequently
accessed data.
o Consider using caching mechanisms to store frequently used data in memory for faster
retrieval.
2. Rearrange the Computation for Greater Efficiency:
o Examine the algorithms used in the system and identify any areas where the order of
operations can be changed to reduce computational complexity.
o Look for opportunities to eliminate redundant calculations or to reuse intermediate results.
o Consider using more efficient algorithms or data structures if they can significantly improve
performance.
3. Save Intermediate Results to Avoid Recomputation:
o Identify calculations that are performed repeatedly with the same inputs.
o Introduce new classes or variables to store the results of these calculations, so they can be
reused instead of being recalculated each time.
o Consider using memoization techniques, where the results of function calls are cached and
reused for the same inputs.

It's important to note that design optimization should be done judiciously. Over-optimization can lead to
code that is difficult to understand and maintain. The goal is to strike a balance between efficiency and
clarity, ensuring that the optimized system remains maintainable and extensible.

Question) Differentiate between

i) Aggregation and Association with relevant example

ii) Transition and Conditions with example

let's differentiate between the following object-oriented modeling concepts:

(i) Aggregation vs. Association

Both aggregation and association represent relationships between classes in a UML class diagram. However,
they differ in the nature and strength of the relationship.

 Association: A general relationship between two classes, indicating that they are connected or
interact in some way. It doesn't imply any specific dependency or lifecycle connection between the
objects.
o Example: A Person and a Company can be associated through a "works for" relationship.
The person and the company are independent entities, and the existence of one doesn't
depend on the other.
20

 Aggregation: A specialized form of association representing a "whole-part" or "has-a" relationship.

The aggregate (whole) is made up of components (parts), but the parts can exist independently of the
whole.
o Example: A Computer has a Monitor. While the monitor is part of the computer, it can be
detached and used with another computer, or exist on its own.

Key Difference: The main difference lies in the lifecycle dependency. In aggregation, the parts can outlive
the whole, while in composition (a stronger form of aggregation), the parts are destroyed when the whole is
destroyed.

(ii) Transition vs. Condition

In the context of state modeling using state diagrams:

 Transition: A transition represents the movement from one state to another. It's triggered by an
event and may have an associated guard condition and action.
o Example: In a traffic light system, the transition from the "Green" state to the "Yellow" state
is triggered by the event "Timer expires."
 Condition (Guard Condition): A guard condition is a Boolean expression that must be true for a
transition to occur. It acts as a filter, allowing the transition to fire only if the condition is met.
o Example: In the traffic light example, the transition from "Yellow" to "Red" might have a
guard condition like "[No cars in the intersection]." This means the light will only turn red if
there are no cars detected in the intersection.

Key Difference: A transition is the actual change of state, while a condition is a requirement that must be
met for the transition to happen.

Question) List and explain the guidelines for constructing Use case Model.

The guidelines for constructing a Use Case Model are:

1. First determine the system boundary: It's crucial to establish a clear system boundary before
identifying use cases or actors. This defines the scope of the system and what interactions will be
modeled.
2. Ensure that actors are focused: Each actor should have a single, well-defined purpose in
interacting with the system. If an entity has multiple roles, represent them as separate actors.
3. Each use case must provide value to users: A use case should represent a complete transaction that
delivers value to the actors involved. Avoid defining use cases too narrowly; they should represent
meaningful interactions from the user's perspective.
4. Relate use cases and actors: Every use case should have at least one actor associated with it, and
every actor should participate in at least one use case. This ensures that all interactions are accounted
for and that actors are relevant to the system's functionality.
5. Remember that use cases are informal: Use cases are not meant to be overly formal or rigid. They
are a tool for understanding and communicating system functionality from a user-centered
perspective. Details and precision can be added later during design and implementation.
6. Use cases can be structured: For larger systems, use cases can be broken down into smaller, more
manageable pieces using relationships like include, extend, and generalization. This helps to
organize and simplify complex interactions.

Question) Identify the steps involved in constructing an Application State

model.

The steps involved in constructing an application state model are as follows:

21

1. Determine application classes with states: Identify the classes in your application model that have
multiple states or exhibit dynamic behavior over time. These are the classes for which you'll create
state diagrams.
2. Find events: Analyze the use cases and scenarios from your interaction model to identify the events
that trigger state changes in the identified classes. These events can be user actions, system events, or
external stimuli.
3. Build state diagrams: For each class with multiple states, create a state diagram that represents its
possible states and the transitions between them. Each transition should be labeled with the
triggering event and any associated guard conditions or actions.
4. Check against other state diagrams: Ensure that the state diagrams for different classes are
consistent with each other, especially when they share common events. Verify that the events and
their effects are aligned across all relevant diagrams.
5. Check against the class model: Verify that the states and transitions in the state diagrams are
consistent with the attributes, operations, and relationships defined in the class model.
6. Check against the interaction model: Ensure that the state diagrams accurately reflect the behavior
described in the use cases and scenarios of the interaction model. Simulate the scenarios to confirm
that the state transitions and actions match the expected behavior.

Question) "A good way to implement a system is to focus on the system

design even if it sacrifices some of the requirements". Discuss your view on
the above statement with the tasks involved in the optimization of the design.

The statement "A good way to implement a system is to focus on the system design even if it sacrifices
some of the requirements" is generally not advisable in a well-structured software development process.
While system design is crucial, it should not come at the cost of sacrificing fundamental requirements.
Requirements are the foundation of any software project, and compromising them can lead to a system that
doesn't meet the needs of its users or stakeholders.

However, there are nuances to this statement. In some cases, during the design phase, it might become
evident that certain requirements are overly ambitious, impractical, or would lead to significant delays or
cost overruns. In such situations, it's important to have a discussion with stakeholders to re-evaluate and
possibly adjust the requirements. This is not about sacrificing requirements arbitrarily, but rather about
finding a balance between what's desired and what's feasible within the project's constraints.

Design Optimization and Requirements

Design optimization is the process of refining a design to improve its efficiency, performance, and resource
utilization. It should be done while keeping the core requirements in mind. Here's how design optimization
can be done without sacrificing requirements:

1. Prioritize Requirements: Clearly identify the most critical requirements that must be met. These are
non-negotiable and should not be compromised during optimization.
2. Identify Trade-offs: Analyze the design and identify areas where trade-offs can be made. For
example, you might be able to sacrifice some performance for a simpler implementation or reduce
memory usage by slightly modifying a feature.
3. Communicate with Stakeholders: Discuss potential trade-offs with stakeholders and get their input
and approval before making any changes to the requirements.
4. Focus on Non-Functional Requirements: Optimize aspects like performance, scalability, and
maintainability, which are often considered non-functional requirements. These can be adjusted
without directly impacting the core functionality of the system.
5. Iterative Refinement: Continuously evaluate the design and make incremental improvements. This
allows for flexibility and adaptation as the project progresses.
22

By following these steps, you can optimize the system design while ensuring that the essential requirements
are still met, resulting in a successful and efficient software solution.

Question) Justify that it is helpful to fine-tune classes before writing code in

order to improve performance.

Fine-tuning classes before writing code can significantly improve performance by addressing potential
bottlenecks and inefficiencies early in the development process. This proactive approach can lead to a more
streamlined and optimized implementation. For example, consider a class representing customer information
in a banking application. Initially, this class might contain all customer data, including personal details,
account information, and transaction history. However, during implementation modeling, you might realize
that storing the entire transaction history within the Customer class could lead to performance issues as the
number of transactions grows.

To address this, you could fine-tune the class by partitioning it into separate classes:

 Customer: Stores personal details and a list of accounts.

 Account: Stores account-specific information and a list of transactions.
 Transaction: Stores details of individual transactions.

This partitioning improves performance by distributing the data across multiple classes, reducing the size
and complexity of the Customer class, and allowing for more efficient retrieval and manipulation of
transaction data.

Question) Explain the ways of Downward Recursion in the design process.

Downward recursion in object-oriented design is the process of decomposing high-level operations into
lower-level operations. It involves refining the design by adding details and making decisions at
successively lower levels of abstraction. The two main ways of downward recursion in the design process
are:

1. Functionality Layers:
o This involves breaking down high-level functions into smaller, more manageable operations.
o Each operation is then further decomposed until it can be implemented using existing
operations or simple code.
o The focus is on the logical decomposition of functionality, ensuring that each operation is
coherent and serves a specific purpose.
o Example: In a banking system, the high-level operation "Process Transaction" could be
decomposed into "Verify Account," "Check Balance," "Debit Account," and "Update
Transaction History."
2. Mechanism Layers:
o This involves building the system using layers of support mechanisms that are not directly
visible in the high-level requirements but are necessary for the system to function.
o These mechanisms include data structures, algorithms, and control patterns that provide the
underlying infrastructure for the system.
o Example: In a graphics editor, the high-level operation "Draw Shape" might require
mechanisms like "Create Point," "Calculate Coordinates," and "Render Pixels." These
mechanisms are not explicitly mentioned in the requirements but are essential for
implementing the drawing functionality.

Both functionality and mechanism layers are often used in combination to create a well-designed system.
Functionality layers focus on the logical decomposition of the system's behavior, while mechanism layers
provide the underlying infrastructure and tools to support that behavior.
23

Question) Define System Conception. List and explain the questions that must
be answered by a good system concept.
System conception is the initial stage of software development where the application idea is formed and
preliminary requirements are established. It involves brainstorming and evaluating the feasibility and
potential value of the system.

A good system concept must answer the following questions:

 Who is the application for? Clearly identify the stakeholders, including the financial sponsors and
end-users. Understand their expectations and needs to ensure the system aligns with their interests.
 What problems will it solve? Define the scope of the project and determine the specific problems
the system aims to address. This helps in setting clear goals and boundaries for development.
 Where will it be used? Determine the context in which the system will operate. Will it be used
locally or distributed? Is it mission-critical or experimental? Understanding the environment helps in
making informed design decisions.
 When is it needed? Establish a timeline for development that aligns with both technical feasibility
and business goals. Consider the available resources and the urgency of the need for the system.
 Why is it needed? Prepare a business case outlining the financial justification for the system. This
includes costs, benefits (tangible and intangible), risks, and alternatives. Understanding the
motivation helps in prioritizing features and making informed decisions.
 How will it work? Brainstorm and explore the technical feasibility of the system. Consider different
architectures and technologies to gain confidence that the problem can be solved effectively. This
might involve prototyping or experimentation.

Answering these questions thoroughly during system conception sets a solid foundation for the subsequent
analysis and design phases, increasing the chances of developing a successful and valuable software system.

Question) Discuss two kinds of state diagrams with an example.

State diagrams are used to model the dynamic behavior of objects in a system, showing how they change
states in response to events. There are two main kinds of state diagrams:

1. Continuous Loop State Diagrams:

o These diagrams represent objects with ongoing behavior that repeats in a cycle.
o They have no specific start or end points, as the object continuously transitions between
states.
o Example: A traffic light system is a classic example. The traffic light cycles through the
states Green, Yellow, and Red, repeating the sequence indefinitely.
2. One-Shot State Diagrams:
o These diagrams represent objects with a finite lifespan or a specific sequence of states that
occur only once.
o They have a clear initial state (where the object starts) and a final state (where the object
ends).
o Example: The life cycle of a software order is a one-shot state diagram. It starts with the
"Order Placed" state, progresses through "Processing," "Shipped," and ends in the
"Delivered" state.

In summary, continuous loop state diagrams model ongoing, repetitive behavior, while one-shot state
diagrams model finite processes with a clear beginning and end.

Question) Discuss the different ways of concurrency handling in state

modelling with an example.
24

Concurrency in state modeling refers to the ability of a system to have multiple active states simultaneously.
This means that different parts or components of a system can be in different states and undergo transitions
independently at the same time.

There are two primary ways of handling concurrency in state modeling:

1. Aggregation Concurrency:
o This occurs when an object is composed of multiple parts, each with its own state diagram.
The overall state of the object is the combination of the states of its parts.
o Example: A car can be modeled as an aggregation of its components like the engine,
transmission, and brakes. Each component has its own state diagram (e.g., the engine can be
"on" or "off," the transmission can be in "drive," "park," or "reverse"). The car's overall state
is determined by the combined states of its components.
2. Concurrency within an Object:
o This occurs when an object has multiple independent aspects of its behavior, each represented
by a separate state diagram. These state diagrams operate concurrently within the object.
o Example: A printer can be modeled with concurrent state diagrams for printing, paper
handling, and ink levels. The printer can be in the "printing" state while simultaneously being
in the "low ink" state.

UML Notation for Concurrency

 Aggregation Concurrency: Represented by multiple state diagrams, one for each part of the
aggregate object.
 Concurrency within an Object: Represented by dividing a state diagram into regions using dashed
lines, with each region representing a concurrent substate.

By using these techniques, state modeling can effectively capture and represent the concurrent behavior of
complex systems, making it easier to understand and analyze their dynamic nature.

Question) Explain Procedural Sequence models with suitable examples.

Procedural sequence models, in the context of object-oriented design, are a way to represent the interactions
between objects in a system, particularly when the implementation is procedural (where only one object is
active at a time). They are an extension of sequence diagrams, providing more details about the
implementation of operations and the lifetime of objects.

Key Features of Procedural Sequence Models:

 Passive Objects: Most objects are passive, meaning they don't have their own thread of control and
are activated only when a method is called on them.
 Activations (Focus of Control): Represented by thin rectangles on the lifeline of an object,
activations show the time period during which an object is actively executing a method.
 Lifelines: Vertical lines representing the existence of an object over time.
 Messages (Calls and Returns): Solid arrows with filled arrowheads represent calls to methods,
while dashed arrows represent returns from methods.
 Object Creation and Destruction: Object creation is shown with an object symbol at the head of
the creation message arrow, and object destruction is marked with a large 'X' at the end of its lifeline.

Example:

Let's consider a simplified example of a procedural sequence model for calculating the total cost of items in
a shopping cart
25

1. The ShoppingCart object (active) initiates the calculateTotal() operation.

2. The calculateTotal() operation iterates through the items list.
3. For each Item in the list, it calls the getPrice() operation.
4. The Item object returns its price.
5. The calculateTotal() operation accumulates the prices.
6. Finally, the calculateTotal() operation returns the totalCost to the ShoppingCart.

Question) Explain the reusable components used in System Design.

System design is the high-level strategy for solving the application problem. It involves making decisions
about the system's overall structure, organization, and the technologies to be used. To streamline this process
and promote efficiency, reusability is a key principle in system design. It involves leveraging existing
components or solutions to avoid reinventing the wheel. Here are the reusable components used in system
design:

1. Models:
o Models from previous projects can be reused if they capture similar concepts and
relationships relevant to the current project. This saves time and effort in the analysis phase.
o For example, a model of a library system could be reused for a video rental system, as both
involve concepts like items, borrowers, and due dates.
2. Libraries:
o Libraries are collections of pre-written classes and functions that can be incorporated into
new projects. They provide ready-made solutions for common tasks, reducing the need to
write code from scratch.
o For instance, a graphics library can be reused in various applications that require drawing and
rendering capabilities.
3. Frameworks:
o Frameworks offer a skeletal structure for an application, with placeholders for specific
functionality. They provide a foundation for building applications of a particular type, saving
development time and effort.
o For example, a web application framework like Ruby on Rails provides a structure for
handling requests, routing, and database interactions, allowing developers to focus on the
unique aspects of their application.
4. Patterns:
o Patterns are reusable solutions to common design problems. They describe a general
approach to solving a problem that can be adapted to different contexts.
o For instance, the Model-View-Controller (MVC) pattern is a design pattern that separates an
application's data (model), presentation (view), and control logic (controller), making the
system more modular and easier to maintain.

Question) Explain the different possibilities of fine tuning classes to be

considered before implementation.

Fine-tuning classes before implementation is a crucial step in object-oriented software development. It

involves refining the classes identified during analysis and design to make them more suitable for the
specific programming language and environment. Here are the different possibilities to consider:

1. Partition a Class: This involves splitting a class into multiple smaller classes if it has too many
responsibilities or unrelated attributes. This improves modularity and maintainability.
o Example: A Customer class might be split into PersonalInfo, AccountInfo, and
TransactionHistory.
2. Merge Classes: If two or more classes have very similar attributes and behaviors, they can be
merged into a single class. This simplifies the model and reduces redundancy.
26

o Example: DomesticCustomer and InternationalCustomer might be merged into a single

Customer class if their differences are minor.
3. Partition/Merge Attributes: Attributes within a class can be split or combined based on their
relevance and relationships.
o Example: A PhoneNumber attribute might be split into CountryCode, AreaCode, and
LocalNumber.
4. Promote an Attribute/Demote a Class: This involves deciding whether a concept should be
represented as an attribute of a class or as a separate class.
o Example: An Address could be an attribute of Customer or a separate class with its own
attributes like street, city, and zipCode.

These fine-tuning steps are essential because they bridge the gap between the abstract design and the
concrete implementation. They ensure that the code is well-structured, efficient, and maintainable,
ultimately leading to a more robust and successful software system.

Question) Differentiate between Frameworks and Patterns.

Frameworks and patterns are both reusable components in object-oriented design, but they differ in their
scope and level of abstraction.

Frameworks

A framework is a skeletal structure of a program that must be elaborated to build a complete application. It
provides a foundation for building applications of a particular type, saving development time and effort.
Frameworks consist of more than just the classes involved and include a paradigm for flow of control and
shared invariants. Frameworks tend to be specific to a category of applications; framework class libraries are
typically application-specific and not suitable for general use.

Patterns

A pattern is a proven solution to a general problem. It is a recurring combination of classes and relationships
that can be applied to different contexts. Patterns are typically smaller in scope than frameworks and focus
on solving specific design problems. They come with guidelines on when to use them, as well as trade-offs
on their use.

Question) Illustrate the following UML constructs with examples.

i) Qualified Associations ii) Aggregation and composition iii) Bags and

Sequences

Let's illustrate these UML constructs with examples:

i) Qualified Associations

A qualified association is a special type of association in UML where an attribute, known as the qualifier, is
used to refine the relationship between classes. The qualifier acts as a key to select specific objects on the
"many" side of the association.

Example:
27

 The association between Library and Book is one-to-many (a library can have many books).
 The bookId attribute is the qualifier.
 The qualified association indicates that for a given Library and a specific bookId, there can be at
most one Book borrowed by a Member.

ii) Aggregation and Composition

Both aggregation and composition represent "whole-part" or "has-a" relationships in UML, but they differ in
the strength of the relationship and object lifecycle dependencies.

Aggregation:

 A "has-a" relationship where the whole (aggregate) is made up of parts, but the parts can exist
independently of the whole.
 Example: A Car has an Engine. The engine can be removed from the car and used in another car, or
it can exist on its own.

Composition:

 A stronger "has-a" relationship where the whole is entirely responsible for the existence of its parts.
The parts cannot exist without the whole.
 Example: A House is composed of Rooms. The rooms cannot exist without the house, and if the
house is demolished, the rooms are also destroyed.
28

iii) Bags and Sequences

Bags and sequences are both collections in UML, but they differ in how they handle duplicate elements and
ordering.

Bag:

 An unordered collection that can contain duplicate elements.

 Example: A ShoppingCart can be modeled as a bag of Product items, where the same product can
be added multiple times.

Sequence:

 An ordered collection where elements have a specific position, and duplicates are allowed.
 Example: A Playlist can be modeled as a sequence of Song objects, where the order of songs
matters.

Question) Describe propagation of operation with diagram and example.

Propagation (also called triggering) is the automatic application of an operation to a network of objects when
the operation is applied to some starting object. For example, moving an aggregate moves its parts; the move
operation propagates to the parts. Propagation of operations to parts is often a good indicator of aggregation.

The diagram below shows an example of propagation.

Person copy copy

Owns
1 * * 1 *
1
Document Paragraph Character
copy copy copy

A person owns multiple documents. Each document consists of paragraphs that, in turn, consist of
characters. The copy operation propagates from documents to paragraphs to characters. Copying a paragraph
copies all the characters in it. The operation does not propagate in the reverse direction; a paragraph can be
copied without copying the whole document. Similarly, copying a document copies the owner link but does
not spawn a copy of the person who is owner.

Question) Discuss various ways to realize association in implementation

modelling.

In implementation modeling, associations from the class model are translated into code. There are several
ways to realize associations, each with its own trade-offs:

1. One-Way Associations:
29

o Implemented using a pointer (or reference) in one class to point to an instance of the other
class.
o Suitable when the association is only traversed in one direction.
o Example: In a library system, a Book object might have a pointer to its Author object, but the
Author object doesn't need to know which books they've written.
2. Two-Way Associations:
o Implemented using pointers (or references) in both classes, allowing traversal in either
direction.
o Provides fast access but requires careful maintenance to keep the links consistent.
o Example: In a social network, a Person object might have a collection of Friend objects, and
each Friend object would also have a reference back to the Person.
3. Association Objects:
o Implemented as a separate class that represents the association itself, holding references to
both participating objects and any attributes of the association.
o Useful for many-to-many associations or when the association has its own attributes or
behavior.
o Example: In a course registration system, an Enrollment class could represent the
association between Student and Course, storing attributes like enrollment date and grade.

Advanced Associations:

 Association Classes: Typically promoted to a separate class, similar to an association object.

 Ordered Associations: Implemented using ordered collections (e.g., lists) or dictionaries with
ordered pairs.
 Bags and Sequences: Implemented using unordered collections (e.g., sets) or lists, respectively.
 Qualified Associations: Implemented using dictionary objects (maps) for efficient lookup based on
the qualifier.
 N-ary Associations: Usually promoted to a separate class to represent the complex relationship.

The choice of implementation depends on factors like:

 Navigation Direction: One-way or two-way traversal needs.

 Multiplicity: One-to-one, one-to-many, or many-to-many relationships.
 Association Attributes: Whether the association has its own attributes.
 Performance Requirements: The need for fast access or updates.
 Flexibility: The need to modify or extend the association in the future.

Question) Analyze the different ways of concurrency handling in state

modelling with 6 relevant examples.

Concurrency in state modeling refers to the ability of a system to have multiple active states simultaneously.
This means that different parts or components of a system can be in different states and undergo transitions
independently at the same time.

Here are six examples of concurrency handling in state modeling:

1. Orthogonal Regions: A printer can print a document while simultaneously warming up.
2. Fork and Join: A vending machine dispenses a product and calculates change concurrently.
3. Independent State Machines: A car's engine, transmission, and brakes operate concurrently, each
with its own state diagram.
4. Interleaved Signals: A phone system can handle multiple calls simultaneously, with each call
progressing through its own sequence of states.
5. Shared Events: Multiple objects in a system can react to the same event, leading to concurrent state
changes. For example, in a traffic simulation, multiple cars can react to a traffic light turning green.
30

6. Timers: A microwave oven can cook food while a timer runs independently, triggering an alarm
when the time is up.