KSRCE/QM/7.5.

1/IT

K.S.R. COLLEGE OF ENGINEERING (Autonomous), TIRUCHENGODE – 637 215

Vision of the institution

 We envision to achieve status as an excellent educational institution in the global knowledge
hub, making self-learners, experts, ethical and responsible engineers, technologists, scientists,
managers, administrators and entrepreneurs who will significantly contribute to research and
environment friendly sustainable growth of the nation and the world.

Mission of the institution

 To inculcate in the students self-learning abilities that enable them to become competitive and
considerate engineers, technologists, scientists, managers, administrators and entrepreneurs
by diligently imparting the best of education, nurturing environmental an social needs.
 To foster and maintain a mutually beneficial partnership with global industries and institutions
through knowledge sharing, collaborative research and innovation.

DEPARTMENT OF INFORMATION AND TECHNOLOGY

Vision of the Department

 To produce excellent and competent software professional, researchers and responsible

engineers, who can significantly contribute to environment friendly societal industry through
quality education.

Mission of the Department

 To make the students competitive and efficient in technical field through technological
transformations’ in Information Technology, by providing them advanced curriculum,
infrastructure and nurturing human values.
 To provide an excellent forum for higher studies that leads to careers as Computer and IT
professionals in the widely diversified domains of industry, government and academia.
Program Educational Objectives(PEOs)
 Incorporate with necessary background in science and engineering fundamentals to analyze
and solve IT problems and to prepare them for skilled manpower in the field of IT for
subsequently generation.
 Enhance in various latest programming languages, technologies, software development
process and communication technology.
 Attain successful career in industry through effective communication skills, team spirit, learning
ethical responsibilities, attitude and adapt to emerging technologies.

Date Course Faculty HOD Principal

 K.S.R. COLLEGE OF ENGINEERING (Autonomous), TIRUCHENGODE – 637 215
DEPARTMENT OF INFORMATION TECHNOLOGY
Subject Name: Object Oriented Analysis and Design
Subject Code: 16IT662 Year/Semester: III / VI
Course Outcomes: On completion of this course, the student will be able to
CO1 Understand the object oriented life cycle
CO2 Know how to identify objects, relationship, services and attributes through UML
CO3 Understand the UML diagrams
CO4 Know the object oriented design process
CO5 Know about software quality and usability

Program Outcomes (POs) and Program Specific Outcomes (PSOs)

A. Program Outcomes (POs)
Engineering Graduates will be able to :
Engineering knowledge: Ability to exhibit the knowledge of mathematics, science, engineering
PO1
fundamentals and programming skills to solve problems in computer science.
Problem analysis: Talent to identify, formulate, analyze and solve complex engineering problems
PO2
with the knowledge of computer science. .
Design/development of solutions: Capability to design, implement, and evaluate a computer based
PO3
system, process, component or program to meet desired needs.
Conduct investigations of complex problems: Potential to conduct investigation of complex
PO4 problems by methods that include appropriate experiments, analysis and synthesis of information in
order to reach valid conclusions.
Modern tool Usage: Ability to create, select, and apply appropriate techniques, resources and
PO5
modern engineering tools to solve complex engineering problems.
The engineer and society: Skill to acquire the broad education necessary to understand the impact
PO6 of engineering solutions on a global economic, environmental, social, political, ethical, health and
safety.
Environmental and sustainability: Ability to understand the impact of the professional engineering
PO7 solutions in societal and Environmental contexts and demonstrate the knowledge of, and need for
sustainable development.
Ethics: Apply ethical principles and commit to professional ethics and responsibility and norms of the
PO8
engineering practices.
PO9 Individual and team work: Ability to function individually as well as on multi-disciplinary teams.
Communication: Ability to communicate effectively in both verbal and written mode to excel in the
PO10
career
Project management and finance: Ability to integrate the knowledge of engineering and
PO11
management principles to work as a member and leader in a team on diverse projects
Life-long learning: Ability to recognize the need of technological change by independent and life-
PO12 long learning.

Program Specific Outcomes (PSOs)

PSO1 Develop and Implement computer solutions that accomplish goals to the industry, government or
research by exploring new technologies.
PSO2 Grow intellectually and professionally in the chosen field.

Date Course Faculty H.O.D Principal

3|Page
 KSRCE/QM/7.5.1/33B/IT
K.S.R COLLEGE OF ENGINEERING (Autonomous), TIRUCHENGODE- 637 215
DEPARTMENT OF INFORMATION TECHNOLOGY
COURSE / LESSON PLAN SCHEDULE
Subject Code/Name : 16IT662 / Object Oriented Analysis and Design
Year/Sem : III / VI
Faculty Name : Dr. K. Balamurugan
A.) TEXT BOOKS :
i. Ali Bahrami, “ Object Oriented Systems Development”, Tata McGraw Hill, Ninth Reprint
2011
ii. Mahesh P Matha , “ Object Oriented Analysis and Design using UML”, PHI 2008
B.) REFERENCE BOOKS :
i.) Martin Fowler, UML Distitled”, PHIn/ Person Education, Third Edition, 2004
ii.) Stephen R, Schach “ Introduction to Object Oriented Analsis and design using UML”,
Tata Mc Hill, 2004
iii.) Hans – Enk Eriksson, Magnus Penker, “UML Toolkit”, OMG Press, Wilky publishing Inc,
2004
iv.) Timothy C, Lethbridge and Robert Lageniere, “ Object Oriented Software Engineering”,
tata McGraw Hill, Reprint 2011.
v.) C.) LEGEND:
L – Lecture BB - Black Board
T – Tutorial pp - Pages
OHP – Over Head Projector TX - Text book
RX – Reference book

Lecture Teaching Aids

Sl.No Topic to be Covered Reference
Hour Required
An Overview of Object Oriented
1 L1 BB TX1
System Development

2 L2 Object basics BB TX1

Object Oriented Systems Development

3 L3 BB TX1
Life Cycle

4 L4 The Software Development Process BB TX1

5 L5 Building High Quality Software BB TX1

6 L6 Rumbaugh Methodology BB TX1

 Lecture Teaching Aids
Sl.No Topic to be Covered Reference
Hour Required

7 L7 Booch Methodology BB TX1

8 L8 Jacobson Methodology BB TX1

9 L9 Patterns and Frameworks BB TX1

10 L10 Unified Approach BB TX1

11 L11 Unified Modelling language BB TX1

12 L12 Use case diagrams BB TX2

13 L13 Class diagram BB TX2

14 L14 Interactive diagram BB TX1

15 L15 Package diagram BB TX1

16 L16 Collaboration diagram BB TX1

17 L17 State diagram BB TX1

18 L18 Activity diagram BB TX1

19 L19 Identifying Use cases BB TX2

20 L20 Use case model BB TX1

21 L21 Classification BB TX1

22 L22 Approaches for identifying classes BB TX2

23 L23 Noun Phrase Approach BB TX1

5|Page
 Lecture Teaching Aids
Sl.No Topic to be Covered Reference
Hour Required

24 L24 Common class Pattern Approach BB TX1

25 L25 Use case Driven Approach BB TX1

26 L26 Classes BB TX1

27 L27 &28 Responsibilities and Collaborators BB TX1

28 L29 Verifying object responsibilities BB TX1

29 L30 & 31 Attributes and Methods BB TX2

30 L32 Object oriented design axioms BB TX1

31 L33 Designing Classes BB TX1

32 L34 Redefining attributes BB TX1

33 L35 &36 Designing methods and Protocols BB TX1

34 L37 Access Layers BB TX1

35 L38 Object storage BB TX1

36 L39 Object interoperability BB TX1

37 L40 &41 Designing interface objects BB TX1

38 L42 Software Quality Assurance BB TX1

39 L43 System Usability BB TX1

40 L44 & 45 Measuring User Satisfactions BB RX1

K.S.R. COLLEGE OF ENGINEERING (AUTONOMOUS), TIRUCHENGODE- 637 215

 DEPARTMENT OF INFORMATION TECHNOLOGY
Academic Year 2019 - 2020
Subject Name: Object Oriented Analysis and Design
Subject Code: 16IT662 Year/Semester: III / VI

UNIT - I
1. What is an object? CO1, U
An object is a combination of data and logic and it represent some real-world entity. High level
of abstraction
2. What are the main advantages of object oriented development? CO1, R
Seamless transition among different phases of software development
 Encouragement of good programming techniques
 Promotion of reusability
3. What is object oriented system development methodology? CO1, U
Object oriented system development methodology is a way to develop software by building
self contained modules or objects that can be easily replaced, modified and reused.
4. Distinguish between method and message in object. CO1, U

Method Message
Methods are similar to functions, procedures or Message essentially are non specific function
subroutines in more traditional programming calls
languages
Method is an implementation Message is an instruction
In an object oriented system, a method is An object understands a message when it can
invoked by sending an object a message. match the message to a method that has the
same name as the message.

5. What is analysis and design? CO1, U

Analysis emphasizes an investigation of the problem and requirements, rather than a
solution. For example, if a new computerized library information system is desired, how it will be
used. Where as design emphasizes a conceptual solution that fulfils the requirements, rather than
its implementation. For example, a description of a database schema and software objects.

6. What is object oriented analysis and design? CO1, U

During object oriented analysis, there is an emphasis on finding and describing the objects or
concepts in the problem domain. For example, in the case of the library information system, some of
7|Page
 the concepts include book, library and patron. During object oriented design, there is an emphasis
on defining software objects and how they collaborate to fulfil the requirements. For example, in the
library system, a book software object may have a title attribute and a get chapter method
7. What is UML? CO1, R
UML is a Unified modelling language is a set of notations and conventions and diagrams to
describe and model an application.
8. What are the primary goals in the design of UML? CO1, R
1. Exchange meaningful models.
2. Provide users a ready to use expressive visual modelling language so they can develop.
3. Provide extensibility and specialization mechanism to extend the core concepts.
4. Encourage the growth of OO tools market.
5. Support higher-level development concepts.
9. Define class diagram. CO1, U
The main static structure analysis diagram for the system, it represents the class structure of
a system including the relationships between class and inheritance structure.
10. Define activity diagram. CO1, U
A variation or special case of a state machine in which the states are activities representing
the performance of operations and the transitions are triggered by the completion of the operations.
11. What is interaction diagram? Mention its types. CO1, R
Interaction diagrams are diagrams that describe how groups of objects collaborate to get
the job done interaction diagrams capture the behaviour of the single use case, showing the
pattern of interaction among objects. Types: Sequence diagram & Collaboration diagram
12. What is sequence diagram? CO1, U
It is an easy and intuitive way of describing the behaviour of a system by viewing the
interaction between the system and its environment.
13. What is collaboration diagram? CO1, U
It represents a collaboration, which is a set of objects related in a particular context, and
interaction, which is a set of messages exchanged among the objects with in collaboration to
achieve a desired outcome.
14. Define start chart diagram? CO1, U
It shows a sequence of states that an object goes through during its life in response to
events. A state is represented as a round box, which may contain one or more compartments. the
compartments are all optional.

15. What is meant by implementation diagram? CO1, U

Implementation diagrams show the implementation phase of systems development such as
the source code structure and the run time implementation structure. There are two types of
implementation diagrams: Component diagram and Development diagram
16. Define component diagram. CO1, U
A component diagram shows the organization and dependencies among a set of
components. A component diagram is used to model the static implementation view of a system.
This involves modelling the physical thing that reside on a mode, such as executable, libraries, files
and documents.
17. Define deployment diagram CO1, U
1. Deployment diagram shows the configuration of run time processing elements and the software
components, processes and objects that live in them.
2. Deployment diagrams are used to model the static deployment view of a system. A deployment
diagram is a graph of nodes connected by communication association.
18. What is UP? CO1, U
A software development process describes an approach to building, deploying and possibly
maintaining software. The unified process has emerged as a popular iterative software
development process for building object oriented system.
19. What is iteration? CO1, U
A key practice in both the UP and most other modern methods is iterative development. In
this lifecycle approach, development is organized into a series of short, fixed length mini projects
called iterations.
20. What is iterative evolutionary development? CO1, R
The iterative lifecycle is based on the successive enlargement and refinement of a system
through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a
suitable system. The system grows incrementally over time, iteration by iteration and thus this
approach is also known as iterative and incremental development.
21. What are the phases of unified process? CO1, R
Inception, Elaboration, Construction, Transition
22. What is inception? CO1, U
Inception is the initial short step to establish a common vision and basic scope for the
project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-
functional requirement, creation of a business case and preparation of the development
environment.

23. Define use case modelling. CO1, U

Use case modelling is a form of requirement engineering. How to create an SRS in what we
might call the traditional way. Use case modelling is a different and complementary way of eliciting
and documenting requirements.
9|Page
24. Define use case generalization? CO1, U
Use case generalization is used when you have one or more use cases that are rally
specializations of more general case.
25. What is UML activity diagram? CO1, U
UML activity diagram shows sequential and parallel activities in a process, they are useful for
modelling business processes, workflows, data flows and complex algorithms.
16 Marks
1. Explain about Object Oriented Analysis and Design process.
2. Discuss about unified process.
3. Explain use case modelling with example.
4. Explain about interaction diagrams with example.
5. Explain UML activity diagram with example.
6. Discuss about package, component and deployment diagrams.

UNIT II – DESIGN PATTERNS

1. How to choose the initial domain object? CO2, R
Choose initial domain object as an initial domain object a class at or near the root of the
containment or aggregation hierarchy of domain objects. This may be a facade controller, such
as Register, or some other object considered to contain all or most other objects, such as a
Store.
2. Define patterns. CO2, U
Pattern is a named problem/solution pair that can be applied in new context, with advice
on how to apply it in novel situations and discussion of its trade-offs.
3. How to Connect UI Layer to the Domain Layer? CO2, Analyze
 An initializing routine (for example, a Java main method) creates both a UI and a domain
object, and passes the domain object to the UI.
 UI object retrieves the domain object from a well-known source, such as a factory object
that is responsible for creating domain objects.
4. Mention the Interface and Domain Layer Responsibilities. CO2, R
The UI layer should not have any domain logic responsibilities. It should only be
responsible for user interface tasks, such as updating widgets. The UI layer should forward
requests for all domain-oriented tasks on to the domain layer, which is responsible for handling
them.

5. How to Apply the GRASP Patterns? CO2, R

The following sections present the first five GRASP patterns: Information Expert ,
Creator, High Cohesion, Low Coupling, Controller
6. Define Responsibilities and Methods. CO2, U
The UML defines a responsibility as "a contract or obligation of a classifier".
Responsibilities are related to the obligations of an object in terms of its behaviour. These
responsibilities are of the following two types: Knowing, Doing
7. List out some scenarios that illustrate varying degrees of functional cohesion. CO2, R
Very low cohesion, Low cohesion, High cohesion, Moderate cohesion
8. Define Modular Design. CO2, U
Coupling and cohesion are old principles in software design; designing with objects does
not imply ignoring well-established fundamentals. Another of these, which is strongly related to
coupling and cohesion is to promote modular design.
9. What are the advantages of Factory objects? CO2, R
 Separate the responsibility of complex creation into cohesive helper objects.
 Hide potentially complex creation logic.
 Allow introduction of performance-enhancing memory management strategies, such as object
caching or recycling.
10. What is meant by Abstract Class and Abstract Factory? CO2, U
A common variation on Abstract Factory is to create an abstract class factory that is accessed
using the Singleton pattern, reads from a system property to decide which of its subclass factories
to create, and then returns the appropriate subclass instance. For example, this is used, in the
Java libraries with the java.awt.Toolkitclass, which is an abstract class abstract factory for creating
families of GUI widgets for different operating system and GUI subsystems.
11. Differentiate coupling and cohesion. CO2, U
Coupling deals with interactions between objects or software components while cohesion
deals with the interactions within a single object or software component. Highly cohesive
components can lower coupling because only a minimum of essential information need to b
passed between components.
12. What is meant by Fine-Grained Classes? CO2, R
Consider the creation of the Credit Card, Drivers License, and Check software objects. Our
first impulse might be to record the data they hold simply in their related payment classes, and
eliminate such fine grained classes. However, it is usually a more profitable strategy to use them;
they often end up providing useful behaviour and being reusable. For example, the Credit Card is a
natural Expert on telling you its credit company type (Visa, MasterCard, and so on). This
behaviour will turn out to be necessary for our application.

13. Define coupling. CO2, U

11 | P a g e
 The degree to which components depend on one another. There are two types of coupling,
"tight" and "loose". Loose coupling is desirable for good software engineering but tight coupling
may be necessary for maximum performance. Coupling is increased when the data exchanged
between components becomes larger or more complex.
14. What do you mean by degree of coupling? CO2, Analyze
` The degree of coupling is a function of
How complicated the connection is.
 Whether the connection refers to the object itself or something inside it.
 What is being sent or received.
 The degree or strength of coupling between two components is measured by the amount and
complexity of information transmitted between them.
 Coupling increases with increasing complexity and decreases when the connection is to the
component interface rather than to an internal component.
 Coupling is also lower for data connections than for control connections.
15. What do you mean by cohesion? Give the types of cohesion. CO2, R
Cohesion can be defined as the interactions within a single object or software component.
Cohesion reflects the single purposeless of an object. Cohesion helps in designing classes that
have very specific goals and clearly defined purposes.
 Method cohesion
 Class cohesion
 Inheritance cohesion
16. What do you mean by design patterns? CO2, U
Design patterns are devices that allow systems to share knowledge about their design, by
describing commonly recurring structures of communicating components that solve a general
design problem within a particular context. A design pattern provides a scheme for refining the
subsystems or components of a software system or the relationships among them. Design patterns
are documented by writing essays in a fairly well-defined form.
17. What are the three basic types of attributes? CO2, R
The three basic types of attributes are
1. Single-value attributes.
2. The single-valued attribute has only one value or state.
3. Multiplicity or multi value attributes.
 The multiplicity or multi valued attribute can have a collection of many values at any point in
time.
 Reference to another object, or instance connection.
 These attributes are required to provide the mapping needed by an object to fulfil its
responsibilities, in other words, instance connection model association.
18. What is a Metaphor? CO2, R
It is an analogy that relates two unrelated things by using one to denote the other.
19. Give the three UI design rules. CO2, R
UI design rule 1: Making the interface simple.
rule 2: Making the interface transparent and natural.
rule 3: Allowing users to be in control of the software.
20. Define Package. CO2, U
A package groups and manages the modelling elements, such as classes, their
associations, and their structures. Packages themselves may be nested within other packages. A
package may contain both other packages and ordinary model elements. The entire system
description can be thought of as a single high level sub-system package with everything else init.
All kinds of UML model elements and diagrams can
be organized into packages.
21. What is concurrency policy? CO2, R
A concurrency control policy dictates what happens when conflicts arise between
transactions that attempt access to the same object and how these conflicts are to be resolved
There are two policies:
1. Conservative or pessimistic policy It allows a user to lock all objects or records when they
are accessed and to release the locks only after a transaction commits.
2. Optimistic policy Two conflicting transactions are compared in their entirety and then their
serial ordering is determined.
16 Marks
1. Explain GRASP: designing objects with responsibilities.
2. Explain GoF design patterns.
3. Discuss about creator and information expert.
4. Explain about low coupling and high cohesion.
5. Explain about factory and observer patterns.
6. Explain adapter and singleton with an example.
UNIT - III
1. What is Inception? CO3, U
Inception is the initial short step to establish a common vision and basic scope for the
Project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-
Functional requirement, creation of a business case, and preparation of the development
environment so that programming can start in the elaboration phase. Inception in one Sentence:
Envision the product scope, vision, and business case.

13 | P a g e
2. What artifacts may start in Inception? CO3, R
Some sample artifacts are Vision and Business Case, Use-Case Model, Supplementary
Specification, Glossary, Risk List & Risk Management Plan, Prototypes and proof-of-concepts etc.
3. Define Requirements and mention its types. CO3, R
Requirements are capabilities and conditions to which the system and more broadly, the
project must conform.
1. Functional
2. Reliability
3. Performance
4. Supportability
4. What are Actors? CO3, R
An actor is something with behaviour, such as a person (identified by role), computer system,
or organization; for example, a cashier.
5. What is a scenario? CO3, R
A scenario is a specific sequence of actions and interactions between actors and the system; it is
also called a use case instance. It is one particular story of using a system, or one path through the
use case; for example, the scenario of successfully purchasing items with cash, or the scenario of
failing to purchase items because of a credit payment denial.
6. Define Use case. CO3, U
A use case is a collection of related success and failure scenarios that describe an actor using a
system to support a goal. Use cases are text documents, not diagrams, and use-case modelling is
primarily an act of writing text, not drawing diagrams.
7. What are three kinds of actors? CO3, R
Primary actor, Supporting actor, Offstage actor.
8. What are the tests can help find useful use cases? CO3, R
Boss Test, EBP Test, Size Test
9. What are Use Case Diagrams? CO3, U
A use case diagram is an excellent picture of the system context; it makes a good context
diagram that is, showing the boundary of a system, what lies outside of it, and how it gets used. It
serves as a communication tool that summarizes the behavior of a system and its actors.
10. What are Activity Diagrams? CO3, U
Activity diagram is useful to visualize workflows and business processes. These can be a
useful alternative or adjunct to writing the use case text, especially for business use cases that
describe complex workflows involving many parties and concurrent actions.
11. What is Elaboration? CO3, U
Elaboration is the initial series of iterations during which the team does serious investigation,
implements (programs and tests) the core architecture, clarifies most requirements, and tackles the
high-risk issues. In the UP, "risk" includes business value. Therefore, early work may include
implementing scenarios that are deemed important, but are not especially technically risky.
12. What are the tasks performed in elaboration? CO3, R
1. The core, risky software architecture is programmed and tested
2. The majority of requirements are discovered and stabilized The major risks are mitigated or
retired
13. What are the key ideas and best practices that will manifest in elaboration? CO3, R
1. Do short time boxed risk-driven iterations
2. Start programming early
3. Adaptively design, implement, and test the core and risky parts of the architecture
4. Test early, often, realistically
5. Adapt based on feedback from tests, users, developers
14. What artifacts may start in elaboration? CO3, U

This is a visualization of the domain concepts; it is similar

Domain Model
to a static information model of the domain entities.
This is the set of diagrams that describes the logical
Design Model design. This includes software class diagrams, object
interaction diagrams, package diagrams, and so forth.
A learning aid that summarizes the key architectural
Software Architecture issues and their resolution in the design. It is a summary
Document of the outstanding design ideas and their motivation in the
system.
This includes the database schemas, and the mapping
Data Model strategies between object and non-object
representations.
Use-Case Storyboards, UI
Descriptions of the user interface, paths of navigation,
Prototypes
usability models, and so forth.

15. What are the key ideas for Planning the Next Iteration? CO3, R
Organize requirements and iterations by risk, coverage, and criticality.

15 | P a g e
16. What is a Domain Model? CO3, U
A domain model is a visual representation of conceptual classes or real-situation objects in a
domain. The term "Domain Model" means a representation of real-situation conceptual classes,
not of software objects. The term does not mean a set of diagrams describing software classes,
the domain layer of a software architecture, or software objects with responsibilities.
17. How the domain model is illustrated? CO3, U
1. Applying UML notation, a domain model is illustrated with a set of class diagrams in which no
operations
2. domain objects or conceptual classes (method signatures) are defined. It provides a conceptual
perspective. It may show associations between conceptual classes and attributes of conceptual
classes
18. Why Call a Domain Model a "Visual Dictionary"? CO3, U
The information it illustrates could alternatively have been expressed in plain text. But it's
easy to understand the terms and especially their relationships in a visual language, since our
brains are good at understanding visual elements and line connections. Therefore, the domain
model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information
content of the domain.
19. What are the elements not suitable in a domain model? CO3, R
The following elements are not suitable in a domain model
1.Software artifacts, such as a window or a database, unless the domain being modelled is of
software concepts, such as a model of graphical user interfaces.
2. Responsibilities or methods
20. What are Conceptual Classes? CO3, U
The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a
conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered
in terms of its Symbol words or images representing a conceptual class. symbol, intension, and
extension Intension the definition of a conceptual class. Extension the set of examples to which
the conceptual class applies
21. How to Create a Domain Model? CO3, U
The current iteration requirements under design:
1. Find the conceptual classes (see a following guideline).
2. Draw them as classes in a UML class diagram and add associations and attributes.
22. How to Find Conceptual Classes? CO3, R
Reuse or modify existing models. This is the first, best, and usually easiest approach, and
where I will start if I can. There are published, well-crafted domain models and data models (which can
be modified into domain models) for many common domains, such as inventory, finance, health, and so
forth.
23. Define Association. CO3, U
An association is a relationship between classes (more precisely, instances of those classes)
that indicates some meaningful and interesting connection.
24. What is Aggregation? CO3, U
Aggregation is a vague kind of association in the UML that loosely suggests whole-part
relationships (as do many ordinary associations). It has no meaningful distinct semantics in the UML
versus a plain association, but the term is defined in the UML.
25. What is composition? CO3, U
Composition, also known as composite aggregation, is a strong kind of whole-part aggregation
and is useful to show in some models. A composition relationship implies that
1. An instance of the part (such as a Square) belongs to only one composite instance (such as one
Board) at a time,
2. The part must always belong to a composite (no free-floating Fingers), and
3. The composite is responsible for the creation and deletion of its parts either by itself
creating/deleting the parts, or by collaborating with other objects.
16 - Marks
1. Explain about Next Gen POS system.
2. Explain about inception. 4.Explain about association and attributes.
3. Discuss about conceptual classes description classes with examples.
4. Briefly discuss about elaboration use case modelling.
5. Explain about aggregation and composition.

UNIT - IV
1. What is meant by System Sequence Diagrams? CO4, R
A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a
use case, the events that external actors generate their order, and inter-system events. All systems
are treated as a black box; the emphasis of the diagram is events that cross the system boundary
from actors to systems.
2. Define System Events and the System Boundary. CO4, U
To identify system events, it is necessary to be clear on the choice of system boundary, as
discussed in the prior chapter on use cases. For the purposes of software development, the system
boundary is usually chosen to be the software system itself; in this context, a system event is an
external event that directly stimulates the software.
17 | P a g e
3. What is meant by System behaviour? CO4, R
System behaviour is a description of what a system does, without explaining how it does it.
One Part of that description is a system sequence diagram. Other parts include the Use cases, and
system contracts.
4. What is meant by Inter-System SSDs? CO4, R
SSDs can also be used to illustrate collaborations between systems, such as between the Next
Gen POS and the external credit payment authorizer. However, this is deferred until a later iteration in
the case study, since this iteration does not include remote systems collaboration.
5. How to Name System Events and Operations? CO4, R
 System events (and their associated system operations) should be expressed at the level of
intent rather than in terms of the physical input medium or interface widget level.
 It also improves clarity to start the name of a system event with a verb Thus "enter item" is
better than "scan" (that is, laser scan) because it captures the intent of the operation while
remaining abstract and noncommittal with respect to design choices about what interface is
used to capture the system event.
6. What is meant by interaction diagram? CO4, U
The term interaction diagram is a generalization of two more specialized UML diagram types;
both can be used to express similar message interactions: Collaboration diagrams, Sequence
diagrams
7. What is meant by link? CO4, R
A link is a connection path between two objects; it indicates some form of navigation and
visibility between the objects is possible . More formally, a link is an instance of an association. For
example, there is a link or path of navigation from a Register to a Sale, along which messages may
flow, such as the make 2 Payment message.
8. What is meant by Messages? CO4, R
Each message between objects is represented with a message expression and small arrow
indicating the direction of the message. Many messages may flow along this link. A sequence
number is added to show the sequential order of messages in the current thread of control.
9. How to create an instance? CO4, U
Any message can be used to create an instance, but there is a convention in the UML to use
a message named create for this purpose. If another (perhaps less obvious) message name is used,
the message may be annotated with a special feature called a UML stereotype, like so: «create».
The create message may include parameters, indicating the passing of initial values. This indicates,
for example, a constructor call with parameters in Java.
10. List the approaches for identifying classes. CO4, R
The four alternative approaches for identifying classes:
1. The noun phrase approach.
2. The common class patterns approach.
3. The use-case driven, sequence/collaboration modelling approach.
4. The classes, responsibilities and collaborators (CRC) approach.
11. What is the common class patterns strategy? Give the list of patterns used. CO4, R
The common class patterns approach is based on a knowledge base of the common classes
that have been proposed researchers. The patterns used for finding the candidate class and object
are: Concept class
 Events class
 Organization class People class
 Places class & Tangible things and devices class
12. Give the guidelines for naming a class. CO4, R
The guidelines for naming classes are
 The class name should be singular.
 One general rule for naming classes is that you should use names with which the users or
clients are comfortable.
 The name of a class should reflect its intrinsic nature Use readable name.
 Capitalize class names.
13. What is meant by CRC card? CO4, R
CRC cards are index cards, one for each class, upon which the responsibilities of the class
are briefly written, and a list of collaborator objects to fulfill those responsibilities. They are usually
developed in a small group session. The GRASP patterns may be applied when considering the
design while using CRC cards.
14. What is meant by Pure Fabrication? CO4, R
This is another GRASP pattern. A Pure Fabrication is an arbitrary creation of the designer,
not a software class whose name is inspired by the Domain Model. A use-case controller is a kind
of Pure Fabrication.
15. List the relationships used in class diagram? CO4, R
1. Generalization (class to class)
2. Association (object to object)
3. Aggregation (object to object)
4. Composition (object to object)

19 | P a g e
16. What is generalization hierarchy? Give the advantage. CO4, U
Super class–subclass relationship also known as generalization hierarchy; allow objects to
be built from other objects. Such relationships allow us to explicitly take advantage of the
commonality of objects when constructing new classes. The super-sub class hierarchy is a
relationship between classes, where one class is the parent (super or ancestor) class of another
(derived) class. The real advantage of using this technique is that we can build on what we already
have and more important, reuse what we already have.
17. What are some common associations? CO4, R
The common association patterns, which can be stored in the repository are based on some
common associations:
1. Location association:
2. Next to, part of, contained in.
3. Communication association: Talk to, order to.
18. Why do we need to identify the system’s responsibilities? CO4, U
We need to identify the system‘s responsibilities because responsibilities identify problems
that are to besolved. A responsibility serves as a handle for discussing potential solutions. Once
the system‘s responsibilities are understood we can start identifying the attributes of the system‘s
classes.
19. How would you identify attributes? CO4, R
i) Attributes usually correspond to nouns followed by preposition phrases. Attributes also may
correspond to adjectives or adverbs.
ii) Keep the class simple; state only enough attributes to define the object state.
iii) Attributes are less likely to be fully described in the problem statement.
iv) Omit derived attributes. They should be expressed as a method.
v) Do not carry excess identification.
20. How would you identify methods? CO4, R
The sequence diagrams assist us in defining services that the objects must provide. These
services are
 In a sequence diagram the events that occur between objects are drawn between the vertical
object lines. An event is considered to be an action that transmits information; therefore these
actions are the Methods also can be derived from the scenario testing, operations that the
objects must perform.
21. Why do we need methods and messages in object-oriented system? CO4, U
Objects not only describe abstract data but also must provide some services. Methods and
messages are the workhorses of object-oriented systems. In an object-oriented environment, every
piece of data or object is surrounded by a rich set of routines called methods. Methods are
responsible for managing the value of attributes such as query, updating, reading and writing.
16 Marks
1. Explain system sequence diagram with an example.
2. Explain logical architecture and UML package diagram.
3. Discuss about class diagram with example.
4. Explain about interaction diagram with example.
5. Discuss about GoF design patterns.

UNIT- V
1. What are the steps in mapping design to code? CO5, U
Implementation in an object-oriented programming language requires writing source code for
Class and interface definitions Method definitions
2. How will you create Class Definitions from DCDs? CO5, R
At the very least, DCDs depict the class or interface name, super classes, method signatures,
and simple attributes of a class. This is sufficient to create a basic class definition in an object-oriented
programming language. Later discussion will explore the addition of interface and namespace (or
package) information, among other details.
3. What are the Benefits of Iterative Development? CO5, R
1. Early rather than late mitigation of high risks (technical, requirements, objectives, usability, and
so forth)
2. Early visible progress, Early feedback, user engagement, and adaptation, leading to a refined
system that more closely meets the real needs of the stakeholders managed complexity; the
team is not overwhelmed by "analysis paralysis" or very long and complex steps iteration by
iteration.
3. The learning within iteration can be methodically used to improve the development process
itself,
4. Specify the issues in OO testing. CO5, R
1. Unit of testing
2. Implications of encapsulation and composition
3. Implications of inheritance
4. Implications of Polymorphism
5. List the levels of object oriented testing. CO5, R
1.Operation / Method
2. Class
3. Integration
4. System Testing a single, cohesive function

21 | P a g e
6. Define Unit. CO5, U
A function which, when coded, fits on one page the smallest separately compliable segment
of code the amount of code that can be written in 4 to 40 hours a task in a work breakdown structure
code that is assigned to one person
7. What is the purpose of unit testing? CO5, U
The goal of unit testing is to verify that, taken by itself, the unit functions correct.
8. Define integration testing. CO5, U
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in
software testing in which individual software modules are combined and tested as a group. It occurs
after unit testing and before validation testing.
9. What is meant by thread? CO5, U
A thread is a
sequence of machine instructions /
 sequence of source instructions /
 scenario of normal usage /
 system-level test case /
 stimulus/response pair /
 The behaviour that results from a sequence of system-level inputs /
 An interleaved sequence of system inputs (stimuli) and outputs (responses)
10. Define MM- path. CO5, R
A Method/Message Path (MM-Path) is a sequence of method executions linked by
messages. An MM-Path starts with a method and ends when it reaches a method which does not
issue any messages of its own.
11. Define ASF. CO5, U
An Atomic System Function (ASF) is an input port event, followed by a set of MM-Paths,
and terminated by an output port event. An atomic system function is an elemental function visible
at the system level.
12. Mention the five distinct levels of OO testing. CO5, R
Method
 Message Quiescence
 Event Quiescence
 Thread Testing
 Thread Interaction Testing
13. Define EMDPNs. CO5, R
 An Event and Message Driven Pertinent (EMDPN) is a quadripartite directed graph
(P,D,M,In,Out) composed of four set of nodes P,D,M and S and two mappings In and Out.
14. Define GUI testing. CO5, R
GUI testing is the process of ensuring proper functionality of the graphical user interface
(GUI ) for a given application and making sure it conforms to its written specifications.
15. List out the types of Events. CO5, R
External event, Internal event and Temporal event
16. Define External event.
External event—also known as a system event, is caused by something (for example, an
actor) outside our system boundary. SSDs illustrate external events. Noteworthy external events
precipitate the invocation of system operations to respond to them.
17. Define internal event.
Internal event—caused by something inside our system boundary. In terms of software, an
internal event arises when a method is invoked via a message or signal that was sent from another
internal object. Messages in interaction diagrams suggest internal events.
18. Define temporal event.
Temporal event is caused by the occurrence of a specific date and time or passage of time.
In terms of software, a temporal event is driven by a real time or simulated-time clock. GUI test
automation is difficult
20. What are the difficulties in GUI testing.
 Often GUI test automation is technology-dependent
 Observing and trace GUI states is difficult
 UI state explosion problem
 Controlling GUI events is difficult
 GUI test maintenance is hard and costly
16 Marks
1. Explain the process of mapping design to code.
2. Discuss about the various issues in OO testing.
3. Explain about class testing with example.
4. Explain the following:
I.) OO integration testing II.) OO system testing
5. Explain about GUI testing

****************

23 | P a g e