OOASE IMP QUES

2M
UNIT 3
1)LIST OUT THE STEPS IN OOA PROCESS
• Identify Objects and Classes: Recognize key entities and group them into classes based on
attributes and behaviours.
• Establish Relationships: Determine connections between classes, including associations,
generalizations, and compositions.
• Define Behaviour: Specify methods for classes to define their behaviour and fulfil
stakeholder requirements.

2) LIST OUT THE GUIDELINES FOR DEVELOPING USE CASE MODELS

• Identify Actors: Clearly define all actors (users, systems, or external entities) interacting with
the system.
• Define Use Cases: Describe each interaction between actors and the system as a distinct use
case, focusing on a specific goal or task.
• Keep it Simple: Ensure use cases are clear, concise, and focused on achieving specific
objectives without unnecessary complexity.

3) COMPARE ‘USES’ AND ‘EXTENDS’ ASSOCIATION

FEATURE USES
PURPOSE Indicates that one use case
relies on the behaviour
defined in another use case to
achieve its goals, representing
a mandatory dependency.
EXTENDS
Signifies that one use case can
optionally add or modify
behaviour defined in another
use case under specific
conditions

NATURE OF RELATIONSHIP Represents a mandatory Represents an optional

relationship where the relationship where the
included use case is essential extended use case may
for accomplishing the goals of enhance or modify the
the base use case. behaviour of the base use case

4) LIST THE APPROACHES FOR IDENTIFYING CLASSES

• Noun Phrase Analysis: Identify classes based on nouns or noun phrases.
• CRC Cards: Brainstorm classes, responsibilities, and collaborations.
• Use Case Analysis: Identify objects involved in system use cases.
• Attribute and Behaviour Analysis: Identify classes based on attributes and behaviours.
5) COMPARE AGGREGATION AND COMPOSITION
FEATURE AGGREGATION
NATURE Aggregation represents a
"has-a" relationship where
one class is associated
with another class, but the
part can exist
independently.
EXAMPLE A university has
departments.
Departments can exist
independently of the
university
COMPOSITION
Composition represents a
stronger form of the "whole-
part" relationship, where the
part cannot exist without the
whole.
A car has an engine. Without the
engine, the car cannot function.

6) EXPLAIN HOW WE CAN IDENTIFY ACTORS FOR A SYSTEM

• Stakeholder Analysis: Identify individuals, groups, that interact with the system.
• Role Identification: Determine the roles these stakeholders play in relation to the system.
• Use Case Analysis: Analyze the use cases of the system to identify external entities or
systems that initiate actions or respond to system behaviour.
• External Systems Integration: Consider any external systems that the system interacts with,
as they may also act as actors.

7)DRAW THE COMMOM TEMPLATE DESIGN

UNIT 4
1)DEFINE OCCUM RAZOR RULE
• Principle of Simplicity: Occam's Razor states that simpler explanations are generally
preferable to more complex ones.
• Minimal Assumptions: It suggests selecting hypotheses with the fewest assumptions needed
to explain a phenomenon.

2)COMPARE COUPLING AND COHESION

FEATURE COUPLING COHESION

Definition Coupling refers to the degree Cohesion refers to the degree
of interdependence between to which elements within a
modules or components in a module or component are
system related to each other

Nature It measures how closely two It measures the strength of the

modules are connected
Goal Low coupling is desirable as it
indicates that modules are
independent
Types data coupling, control coupling
relationship between elements
High cohesion is desirable as it
indicates that elements within
a module are closely related
functional cohesion, sequential
cohesion

3) DEFINE AXIOM AND COROLLARIES

An axiom is a self-evident or universally accepted principle, serving as a starting point for
reasoning.
Corollaries are logical consequences or conclusions derived from axioms or previously
established principles.
4) LIST OUT THE TYPES OF DATABASE MODELS
• Hierarchical Model: Data is organized in a tree-like structure with parent-child relationships.
• Network Model: Data is represented as interconnected records, allowing more complex
relationships than hierarchical models.
• Relational Model: Data is organized into tables with rows and columns, and relationships are
established using keys.
• Object-Oriented Model: Data is represented as objects, encapsulating both data and
behaviours.
• Document Model: Data is stored as documents, typically using formats like JSON or XML.
• Graph Model: Data is represented as nodes and edges, suitable for modelling highly
interconnected data.

5) ANALYZE THE PURPOSE OF DBMS

• Centralized data management and organization.
• Efficient data retrieval, querying, and manipulation.
• Ensuring data security and integrity.
• Managing concurrent access to the database.
• Providing backup and recovery mechanisms.
• Supporting data sharing and collaboration.
• Optimizing database performance through indexing and caching.

6) WHAT IS OCL
OCL stands for Object Constraint Language. It's a formal language used to express
constraints and conditions in the Unified Modeling Language (UML) and other object-
oriented modeling languages. OCL allows developers to define precise rules and conditions
that must be satisfied by objects within a system, aiding in specification and validation of
software designs.
7) CHARACTERISTICS OF OOD
• Objects are abstractions of real-world or system entities and manage themselves
• Objects are independent and encapsulate state and representation information.
• System functionality is expressed in terms of object services
• Shared data areas are eliminated. Objects communicate by message passing
• Objects may be distributed and may execute sequentially or in parallel
12M
UNIT 3
1) EXPLAIN THE GUIDELINES FOR DEVELOPING AN EFFECTIVE DOCUMENTATION
INTRODUCTION:

Good documentation is essential for managing projects effectively. It helps teams communicate
better, spot problems early, and make smart decisions about where to invest resources. Blum points
out that managers are responsible for things like software, hardware, and other costs, so they often
rely on documentation to decide where to allocate those resources.

Before we can document a project, it's crucial to understand the problem we're trying to solve. If we
don't know what problem we're addressing, it's hard to document a solution. Blum asks some
important questions about documentation, like how it will be used, what its goals are, and who will
read it. Answering these questions helps ensure that our documentation serves its purpose
effectively.

ORGANIZATION CONVENTIONS FOR DOCUMENTATION

Documenting a project relies heavily on the organization's guidelines and standards. While some
organizations have clear and helpful documentation rules, others may lack them altogether or have
overly complex standards.

Bell and Evans offer practical guidelines and a template for creating documentation, particularly for
systems development using the unified approach. It's important to remember that your modelling
efforts serve as documentation for analysis, design, and testing phases.

2. GUIDELINES FOR DEVELOPING EFFECTIVE DOCUMENTATION

Bell and Evans provide us the following guidelines for making documents fit the needs and
expectations of your audience:

1.Common cover. All documents should share a common cover sheet that identifies the document,
the current version, and the individual responsible for the content. As the document proceeds
through the life cycle phases, the responsible individual may change.

2.80-20 rule. As for many applications, the 80-20 rule generally applies for documentation: 80
percent of the work can be done with 20 percent of the documentation. The trick is to make sure
that the 20 percent is easily accessible and the rest is available to those who need to know.

3. Familiar vocabulary. The formality of a document will depend on how it is used and who will read
it. When developing a documentation use a vocabulary that your readers understand and are
comfortable with.

4. Make the document as short as possible. Assume that you are developing a manual. The key in
developing an effective manual is to eliminate all repetition; present summaries, reviews,
organization chapters in less than three pages

5. Organize the document. Use the rules of good organization such as the organization's standards,
college handbooks, etc within each section. Most CASE tools provide documentation capability by
providing customizable reports.
2) EXPLAIN THE OBJECT ANALYSIS CLASSIFICATION

1.CLASSIFICATION THEORY

Classification, the process of checking to see if an object belongs to a category or a class, is regarded
as a basic attribute of human nature.

Classification theory, in the context of Object-Oriented Analysis (OOA) and Object-Oriented Design
(OOD), involves organizing and categorizing objects or concepts into classes based on their shared
characteristics or attributes. This process helps in defining clear boundaries and relationships
between different classes, facilitating the development of robust object models. Essentially,
classification theory assists in structuring the system's components effectively, enabling better
understanding, organization, and management of the software's complexity.

Think of classes as categories or groups that help organize objects based on their similarities. Each
class defines the characteristics (like attributes or properties) and behaviours (like methods or
actions) that its objects share. For instance, if we have a class called "car," it might have an attribute
called "colour," and each actual car (or instance) would have a specific colour, like red, blue, or
white.

When we talk about classification, we're more interested in identifying the class an object belongs to
rather than focusing on individual objects. It's like sorting things into different boxes based on their
common traits rather than looking at each thing separately.

The classification process involves discriminating between classes by finding features or consistent
traits shared among their members. It's about categorizing input data into distinct groups by
focusing on important attributes and ignoring irrelevant details.

2.NOUN PHRASE APPROACH

The noun phrase approach is a strategy used in software development, particularly in object-oriented
analysis and design (OOAD), to identify potential classes based on the linguistic analysis of problem
statements or requirements documents.

In essence, this approach involves scanning the problem domain for nouns or noun phrases and
considering them as potential candidates for classes. Nouns typically represent objects or entities,
while noun phrases may describe more complex concepts or relationships.

Here's how the noun phrase approach works:

• Identify Nouns: Scan the problem statement or requirements document and highlight all the
nouns present. Nouns often represent tangible entities, such as "car," "customer," etc.
• Consider Noun Phrases: Look for noun phrases, which are combinations of words acting as a
single noun. These phrases may provide more context or specificity about the objects or
concepts in the problem domain. For example, "customer loyalty program," "payment”, etc.
• Evaluate Potential Classes: Each identified noun or noun phrase is a potential candidate for a
class. Evaluate these candidates based on their relevance, significance, and potential for
encapsulating attributes and behaviours within the system.
• Refinement and Iteration: Refine the list of candidate classes based on further analysis and
discussions with stakeholders. Iterate on the process to ensure that all important objects and
concepts within the problem domain are adequately represented.
3. COMMON CLASS PATTERN APPROACH
It is based on a knowledge base of the common classes that have been proposed by various
researchers. They have compiled and listed the following patterns for finding the candidate class and
object:

NAME: CONCEPT CLASS

A concept is an idea we use to understand the world. It's not something we can touch, but it helps us
organize thoughts and communicate effectively. Marin and Odell explain that when we share our
personal ideas with others, they become concepts. Without concepts, everything would seem
chaotic, as Martin and Odell point out.
EXAMPLE: Performance

NAME: EVENTS CLASS

Events classes are points in time that must be recorded. Things happen, usually to something else at
a given date and time or as a step in an ordered sequence. Associated with things remembered are
attributes such as who, what, when, where, how, or why.
EXAMPLE: Landing, interrupt, request, and order are possible events.

NAME: ORGANIZATION CLASS

An organization class is a collection of people, resources, facilities, or groups to which the users
belong whose existence is largely independent of individuals.
EXAMPLE: An accounting department might be considered a potential class.

NAME: PEOPLE CLASS

The people class represents the different roles users play in interacting with the application. People
carry out some function. What roles does a person play in the system? Coad and Yourdon [3] explain
that a class which is represented by a person can be divided into two types: those representing users
of the system, such as an operator or clerk who interacts with the system; and those representing
people who do not use the system but about whom information is kept by the system.
EXAMPLE: Employee, client, teacher, and manager

NAME: PLACES CLASS

Places are physical locations that the system must keep information about.
EXAMPLE: Buildings, stores, sites, and offices

NAME: TANGIBLE THINGS AND DEVICES CLASS

This class includes physical objects or groups of objects that are tangible and devices with which the
application interacts.
EXAMPLE: Cars are an example of tangible things, and pressure sensors are an example of devices.
4.USE CASE DRIVEN APPROACH

Use cases help model the system's scenarios and outline interactions with external actors. They can
be described in text or steps and are a problem-driven approach in object-oriented analysis, focusing
on the problem before the object relationships.

Modelling with use cases, like in the unified approach, aids in identifying system objects. While it
doesn't magically produce classes, creating sequence or collaboration diagrams helps visualize use
case execution and prompts consideration of involved objects.

During system development, designers depict scenarios to reflect how the system should operate.
When redesigning, some modelers start by capturing current system scenarios before transitioning
to desired scenarios.

IMPLEMENTATION OF SCENARIOS
To implement scenarios effectively, the UML recommends creating at least one scenario for each
distinct use-case instance. Each scenario illustrates a unique interaction sequence between actors
and the system, with clear decisions made along the way. This process helps us understand how the
system's objects behave.

Once you've reached the lowest level of a use case, you can create a child sequence diagram or
collaboration diagram to depict the scenario's implementation. Sequence diagrams, like use-case
diagrams, model system scenarios. However, they provide a more detailed view by illustrating
interactions between objects.

In a sequence diagram, objects involved are represented by vertical dashed lines, with their names
at the top. Events occurring between objects are depicted as horizontal lines connecting the vertical
object lines. These event lines are arranged in sequential order from top to bottom, illustrating the
flow of interactions. While sequence diagrams don't necessarily match the steps defined in a use-
case scenario, they offer valuable insights into system behavior and design.
5.CLASSES, RESPONSIBILITIES, AND COLLABORATORS APPROACH (CRC)

Classes, Responsibilities, and Collaborators (CRC) is a technique introduced by Cunningham,

Wilkerson, and Beck for teaching the fundamentals of object-oriented development.

This approach helps identify classes' responsibilities, which in turn determine their attributes and
methods. CRC aids in class identification by focusing on whether an object can fulfill a responsibility
independently or requires collaboration with other objects. If collaboration is needed, cooperative
objects are identified as collaborators, helping fulfill the responsibility. Through this process,
attributes and methods of classes are determined based on their responsibilities and collaborators.

Classes, Responsibilities, and Collaborators cards are 4" X 6" index cards. All the information for an
object is written on a card, which is cheap, portable, readily available, and familiar.

The class name should appear in the upper left-hand corner, a bulleted list of responsibilities should
appear under it in the left two thirds of the card, and the list of collaborators should appear in the
right third. CRC starts with only one or two obvious cards. If the situation calls for a responsibility not
already covered by one of the objects:
• Add, or create a new object to address that responsibility.
• Finding classes is not easy.
• The more practice you have, the better you get at identifying classes.
• There is no such thing as the ―right set of classes.
• Finding classes is an incremental and iterative process.

• Grouping: Classes are grouped based on shared attributes, suggesting superclass candidates.
• CRC Cards: Class names are written on CRC cards, noting superclass/subclass relationships.
• Requirement Analysis: Requirements are reviewed to assign responsibilities to classes.
• Responsibility Distribution: Responsibilities are allocated, aiming for generality and higher
placement in the inheritance hierarchy.
• Collaboration Identification: Collaboration between classes is identified, and closely
collaborating classes are physically grouped together.
UNIT 4
1)EXPLAIN ABOUT AXIOMS AND COROLLARIES IN DETAIL

An axiom is a fundamental truth that always is observed to be valid and for which there is no
counterexample or exception.

Axiom 1: The independence axiom. Maintain the independence of components

States that, during the design process, as we go from requirement and use-case to a system
component, each component must satisfy that requirement, without affecting other requirements
Axiom 2: The information axiom. Minimize the information content of the design.
Concerned with simplicity. Rely on a general rule known as Occam’s razor.
OCCUM RAZOR RULE:
The best designs usually involve the least complex code but not necessarily the fewest number of
classes or methods. Minimizing complexity should be the goal, because that produces the most
easily maintained and enhanced application.

A corollary is a proposition that follows from an axiom or another proposition that has been proven.

From the two design axioms, many corollaries may be derived as a direct consequence of the
axioms. These corollaries may be more useful in making specific design decisions, since they can be
applied to actual situations more easily than the original axioms. They even may be called design
rules, and all are derived from the two basic axioms

• Corollary 1. Uncoupled design with less information content. Highly cohesive objects can
improve coupling because only a minimal amount of essential information need be passed
between objects.
• Corollary 2. Single purpose. Each class must have a single, clearly defined purpose. When you
document, you should be able to easily describe the purpose of a class in a few sentences.
• Corollary 3. Large number of simple classes. Keeping the classes simple allows reusability.
• Corollary 4. Strong mapping. There must be a strong association between the physical
system (analysis's object) and logical design (design's object).
• Corollary 5. Standardization. Promote standardization by designing interchangeable
components and reusing existing classes or components.
• Corollary 6. Design with inheritance. Common behavior (methods) must be moved to super
classes. The super class-subclass structure must make logical sense.
2) DISCUSS IN DETAIL ABOUT

(I)CLIENT SERVER COMPUTING

Client-server computing is a model of distributed computing where tasks or processes are divided
between clients and servers, which communicate over a network. Here's a brief explanation:

• Client: A client is a device or software application that requests services or resources from a
server. Clients are typically user-facing and interact with users to collect input, process data,
and display results. Examples include web browsers, mobile apps, and desktop applications.
• Server: A server is a specialized computer or software application that provides services or
resources to clients over a network. Servers manage and store data, execute tasks or
processes, and respond to client requests. Examples include web servers, database servers,
and email servers.
• Communication: Clients and servers communicate with each other using standard protocols
and networking technologies. Clients send requests to servers, which process the requests
and return responses back to the clients. This communication can occur over various
network architectures, such as the Internet or a local area network (LAN).
• Roles: In client-server computing, clients and servers have distinct roles and responsibilities.
Clients initiate requests for services or resources, while servers fulfil these requests by
processing data, executing tasks, or providing access to shared resources.
• Benefits: Client-server computing offers several benefits, including scalability, where servers
can handle multiple client requests concurrently, and centralized management of data and
resources, which improves efficiency and security. It also enables the separation of concerns,
allowing clients and servers to focus on specific tasks without becoming overly complex.

2-TIER ARCHITECTURE

• Two layers: client and server.

• Client interacts directly with the server.
• Communication primarily between client and server.

3-TIER ARCHITECTURE

• Three layers: presentation, business logic, and data storage.

• Communication between presentation, business logic, and data storage layers.
• Offers additional separation of concerns and scalability compared to 2-tier architecture.
(II)DISTRIBUTED DATABASE

Distributed databases are databases in which data is stored across multiple physical locations or
nodes, connected by a computer network. Here's a brief explanation:

• Data Distribution: In a distributed database, data is distributed across multiple nodes or

servers rather than being stored in a centralized location. Each node contains a subset of the
overall database.
• Networking: The nodes in a distributed database are interconnected through a computer
network, such as the Internet or a local area network (LAN). This allows for communication
and coordination between the nodes.
• Data Replication: Some distributed databases replicate data across multiple nodes to
improve availability and fault tolerance. This means that the same data is stored on multiple
nodes, reducing the risk of data loss in case of node failure.
• Data Consistency: Maintaining data consistency across distributed nodes is a key challenge in
distributed databases. Techniques such as distributed transactions and consensus protocols
are used to ensure that updates to the database are propagated correctly and consistently
across all nodes.
• Scalability: Distributed databases offer scalability by allowing the addition of new nodes to
the network as the database grows. This horizontal scaling approach helps distribute the
workload and improve performance.
• Fault Tolerance: Distributed databases can be designed to be fault-tolerant, meaning that
they continue to operate correctly even in the presence of node failures or network
partitions. Data replication and redundancy help ensure that the database remains available
and operational.
3) EXPLAIN THE STEPS INVOLVED IN DESIGNING THE ACCESS LAYER AND VIEW LAYER CLASSES

Designing the access layer involves creating classes that facilitate communication between the
application and the data storage layer. The Steps are:

• Identify Needs: Determine what operations the application requires for data access.
• Define Responsibilities: Clarify what each access layer class will handle, like querying or
updating data.
• Design Interfaces: Create clear interfaces for the classes, specifying methods and parameters
needed for operations.
• Choose Patterns: Select appropriate access patterns, such as CRUD operations or transaction
management.
• Implement Classes: Write the classes according to the defined interfaces and patterns,
focusing on modularity and maintainability.
• Test Functionality: Develop tests to ensure the classes work correctly, handling various
scenarios and exceptions.
• Optimize Performance: Improve performance by minimizing database round-trips and
optimizing query execution.

The view layer in software architecture handles presenting information to users and capturing their
interactions. The Steps are:

• Understand Needs: Figure out what the user interface should do and look like.
• Assign Roles: Decide what each class in the view layer will handle, like displaying data or
responding to user input.
• Sketch Interface: Design the visual elements and layouts based on the requirements,
ensuring they're user-friendly.
• Choose Pattern: Select a presentation pattern like MVC or MVP to structure the view layer.
• Build Classes: Implement the classes to handle rendering, user interactions, and updating the
view.
• Test Interface: Check that the interface works as expected, including user interactions and
navigation.
• Speed Up: Optimize the performance of the view layer by reducing rendering times and
unnecessary updates.