Object Oriented Software Engineering

Part-A (2MARKS):

UNIT I INTRODUCTION

1. What is Software Engineering?

Software engineering is a modeling activity. Software engineers deal with complexity

through modeling.

Software engineering is a problem-solving activity. Models are used to search for an

acceptable solution.

Software engineering is a knowledge acquisition activity. It is a single piece of

additional data can invalidate complete models.

Software engineering is a rationale-driven activity. Rationale information represented as

a set of issue models enables us to understand the implication of proposed change whwn

revisiting a decision.

2. What is modeling?

Modeling is a means of dealing with complexity. Modeling means constructing an

abstraction of a system that focuses on interesting aspects and ignores irrelevant details.

3. List the steps of problem solving.

The five steps are formulating the problem, analyze the problem, search for

solutions, decide on the appropriate solution and specify the solution.

4. Why knowledge acquisition is a non linear process? Explain. Knowledge acquisition is a non linear process because of the addition of a new piece of

information may invalidate all the knowledge we have acquired for the understanding of

a system. Even if we had already documented this understanding in documents and code,

we must be mentally prepared to start from scratch.

5. Define Rationale.

A design rationale is the explicit listing of decisions made during a design process, and

the reasons why those decisions were made when designing a system or artifact. Its

primary goal is to support designers by providing a means to record and communicate the

argumentation and reasoning behind the design process.

6. Compare participant and role.

The client orders and pays for the system. The developers construct the system. The

project manager plans & budgets the project & co-ordinates the developers and client.

The end users are supported by the system. The persons involved in the project are

referred to as participants. The set of responsibilities in the project or a system as a role.

7. What is work product? List it types.

A work product is an artifact that is produced during the development, such as a

document or a piece of software for other developers or for the client.

The types of work product are Deliverable & Internal work product.

8. Define activity, task and resources.

An activity is a set of tasks that is performed towards a specific purpose.

A task represents an atomic unit of work that can be managed.

Resources are assets that are used to accomplish work.

9. Distinguish functional and non functional requirements

The functional requirements specify what the product must do.

They relate to the actions that the product must carry out in order to satisfy the

fundamental reasons for its existence.

Nonfunctional Requirement is a constraint on the operation of the system that is not

related directly to a function of the system.

The non-functional requirements add functionality to the product -- it takes some amount

of pressing to make a product easy to use, or secure, or interactive.

10. Distinguish method and methodologies.

A method is a repeatable technique that specifies the steps involved in solving a specific

problem. Example: A recipe is a method for cooking a specific dish.

A methodology is a collection of methods for solving a class of problems and specifies

how and when each method should be used.

11. Enlist the software engineering development activities.

The software engineering development activities are Requirements Elicitation, Analysis,

System design, Object design, Implementation & Testing.

12. What is the importance of testing?

Testing is the systematic attempt to find faults in a planned way in the implemented

software.

Testing is the process of demonstrating that faults are not present.

Testing try to detect faults in the system that is, differences between the reality of the

system and the requirements.

13. Why is analysis required for a difficult task?

Analysis is required for a difficult task to produce a model of the system that is correct,

consistent, and unambiguous. During this activity, developers discover ambiguities and

inconsistencies in the use case model that they resolve with the client. The result of

analysis is a system model annotated with attributes, operations and associations.

14. List two advantages & disadvantages of using a programming language as the whole

notation through development process.

15. What are the types of UML notations?

The types of UML notations are Use case diagrams, Class diagrams, Interaction

diagrams, State machine diagrams, Activity diagrams.

16. Can the system under consideration can be represented as an actor?

17. What is the difference between scenario & use case?

A scenario is an instance of a use case describing a concrete set of actions.

Scenarios are used as examples for illustrating common cases.

Their focus is on understandability.

A use case is an abstraction that describes all possible scenarios involving the described

functionality.

Use cases are used to describe all possible cases.

Their focus is on completeness.

18. What are different models focused on system developers?

The different models are use case models, class models and source code.

19. What is Notation? Explain with example.

A notation is a graphical or textual set of rules for representing a model. The Roman

alphabet is a notation for representing words. UML (Unified Modeling Language [OMG,

1998]), the notation we use throughout this book, is an object-oriented notation for

representing models.

20. Define data types and abstract data types.

A data type is an abstraction in the context of a programming language. Data types are

used in typed languages to ensure that only valid operations are applied to specific data

members.

An abstract data type is a special data type whose structure is hidden from the rest of

the system. This allows the developer to revise the internal structure and the

implementation of the abstract data type without impacting the rest of the system.

21. Define Inheritance

Inheritance is the relationship between a general class and one or more specialized

classes. Inheritance enables us to describe all the attributes and operations that are

common to a set of classes.

22. What is an abstract class? Give an example.

When a generalization serves only the purpose of modeling shared attributes and

operations, that is, if the generalization is never instantiated, it is called an abstract class.

Abstract classes often represent generalized concepts in the application domain.

For example, in chemistry, Benzene can be considered a class of molecules that belongs

to the abstract class Organic compound.

23. Compare operation & activities.

An operation defines something in terms of the specific process or set of validation tests

used to determine its presence and quantity.

An activity is a set of tasks that is performed toward a specific purpose. For example,

requirements elicitation is an activity whose purpose is to define with the client what the

system will do.

24. Distinguish application domain & selection domain.

The application domain model is a description of those aspects of the real-world system

that are relevant to the problem under consideration. This model is then used by the

system to represent the real-world concepts it manipulates.

The selection domain model is to choose one or more existing domain models or entities

from the knowledge base, which are expected to serve as the best raw material for further

elaboration.

25. Define the term Falsification and prototyping.

Falsification is the process of demonstrating that relevant details have been incorrectly

represented or not represented at all; that is, the model does not correspond to the reality

it is supposed to represent.

A technique for developing a system is prototyping. When designing the user interface,

developers construct a prototype that only simulates the user interface of a system. The

prototype is then presented to potential users for evaluation, that is, falsification, and

modified subsequently.

26. Enlist the relationship to the use case diagram.

Use case diagrams can include four types of relationships such as follows:

Communication, inclusion, extension, and generalization.

27. How is use case related to a system?

28. Compare classes and objects.

A class is an abstraction in object-oriented programming languages. Classes are

abstractions that specify the common structure and behavior of a set of objects.

Objects are instances of classes that are created, modified, and destroyed during the

execution of the system. An object has an identity and stores attribute values.

29. Define Association class with example.

30. What is Multiplicity? Give an example?

Each end of an association can be labeled by a set of integers indicating the number of

links that can legitimately originate from an instance of the class connected to the

association end is called as multiplicity. For example the association end author has a

multiplicity of l. This means each EmergencyReport object has exactly one link to an

object of class FieldOfficer.

31. What are the types of associations in multiplicity?

The types of associations in multiplicity are one-to-one association, one-to-many

association, and many-to-many association respectively.

32. Define complex transitions.

Complex transitions are transitions with multiple source states or multiple target states.

Complex transitions denote the synchronization of multiple activities or the splitting of

the flow of control into multiple threads.

33. Difference between work package and work product.

A work package describes the work products to be produced, the resources needed to

perform the work, the expected duration, dependencies on inputs, which are work

products produced by other tasks as well as dependencies on other tasks.

Work products represent the deliverables and intermediate products of the project.

Work products are the visible results of work.

34. What are the events included in planned & unplanned communication events?

The events in planned communication are problem presentation, client reviews, project

reviews, peer reviews, status reviews, brainstorming, releases and postmortem reviews.

The unplanned communication events are requests for clarification, requests for changes

and issue resolution.

35. Enlist the concepts used in project organization.

The concepts used in project organization are project organizations, roles, tasks & work

products and schedule.

36. What are the activities addressed for organizational and communication structure?

The activities addressed for communication structure are joining a team, joining the

communication infrastructure, attending team status meetings and organizing client &

project reviews.

37. Explain the major types of interaction in a project.

The major types of interaction in a project are reporting, decision and communication.

38. Define (I) Management Development (ii) Cross functional rule

Management Development is best described as the process from which managers learn

and improve their skills not only to benefit themselves but also their employing

organizations.

The cross-functional role is also called liaison. The liaison is responsible for

disseminating information along the communication structure from one team to another.

Cross-functional roles are concerned with co-ordination among teams.

39. What types of liaison used by subsystem team?

They are API engineer, document editor, configuration manager and tester.

40. Define tasks and work products.

Work products represent the deliverables and intermediate products of the project.

Work products are the visible results of work.

A task represents an atomic unit of work that can be managed. Tasks consume resources,

result in work products, and depend on work products produced by other tasks.

41. List the planned communication events.

The events in planned communication are problem presentation, client reviews, project

reviews, peer reviews, status reviews, brainstorming, releases and postmortem reviews.

42. What is PERT Chart? Where it is used?

A PERT chart represents a schedule as an acyclic graph of tasks. PERT charts are useful

tools for planning a project and tracking its execution.

Figure 11-10 is a PERT chart for the database subsystem. The planned start and duration

of the tasks are used to compute the critical path, which represents the shortest possible

path through the graph. The length of the critical path corresponds to the shortest possible

schedule, assuming sufficient resources to accomplish in parallel tasks that are

independent.

43. Define briefly the events of unplanned communication.

Requests for clarification: It represents the bulk of the communication among

developers, clients, and users.

Request for change: During a request for change, a participant reports a problem and,

in some cases, proposes solutions.

Issue resolution: A flat organization may select a solution through the brainstorming

process.

44. Explain why multiple choice questionnaires as a primary needs for extracting

information from user are not effective for eliciting requirements.

Multiple choice questionnaires is formalized as a primary needs for extracting

information from user which are not effective for eliciting requirements because of

45. What are the roles assigned for a meeting?

The roles assigned for meeting are group roles, ground roles, and meeting roles.

46. Enlist the organizational activities.

The activities addressed for communication structure are joining a team, joining the

communication infrastructure, attending team status meetings and organizing client &

project reviews.

47. Define Meeting minutes.

Meeting minutes represent a portion of the project history that can be analyzed after the

project is completed. Meeting minutes include a section describing the action items

resulting from the meeting (i.e.) the items describing actions to be taken by the meeting

participants as a consequence of the meeting.

48. What are the terms included in a project forum?

49. What is the difference between client & end user?

Client is a person or a co-operate group for whom product is developed and sold. They

are the ones who pay for that software. It can also mean someone who receives long term

benefits or services from another person whether or not they pay for them.

End user can be any person or a group that uses the software or product once it is sold to

client in their domain. A customer who uses online banking is called as an end user for

that online banking system.

50. What is the difference between cross functional team and subsystem team? A cross-functional team, the architecture team, made of representatives of each team, is

responsible for ensuring the integration of the requirements. Cross-functional team

made up of and selected developers (who will take part in the implementation of the

subsystem). Teams that do not work directly on a subsystem, but rather, accomplish a

project-wide function, are called cross-functional teams.

Each team which negotiates with other teams for the interfaces of the subsystems it needs

is said to be known as subsystem teams. Each subsystem team works with its system

engineering representative to define the metrology requirements for each of the critical

functional responses they have created.

51. Can a role be shared between one or more participants? Why or why not?

Roles can be played by two or more participants in front of the group. This is good for

exploring problem solving and provides a shared experience the entire group can discuss

and perhaps replay. It singles out people which may be inappropriate.

UNIT II ANALYSIS

52. List the activities of Requirement elicitation.

The activities of requirement elicitation are identifying actors, identifying scenarios,

identifying use cases, refining use cases, identifying relationship among actors and use

cases, identifying initial analysis objects, and identifying nonfunctional requirements.

53. Define Joint Application Design.

Joint Application Design (JAD) focuses on building consensus among developers,

users, and clients by jointly developing the system specification. Joint Application

Design (JAD) is a software design methodology developed by IBM to enhance

application design productivity and quality.

54. Compare functional & non-functional requirements.

The functional requirements specify what the product must do.

They relate to the actions that the product must carry out in order to satisfy the

fundamental reasons for its existence.

Nonfunctional Requirement is a constraint on the operation of the system that is not

related directly to a function of the system.

The non-functional requirements add functionality to the product -- it takes some amount

of pressing to make a product easy to use, or secure, or interactive.

55. What are categories of non-functional requirements used by Furts Model?

The categories of nonfunctional requirements are: usability, reliability, robustness, safety,

maintainability, performance, supportability, adaptability, and portability.

56. When the requirement specification is said to be realistic, traceable and verifiable?

The specification is said to be verifiable if, once the system is built, a repeatable test can

be designed to demonstrate that the system fulfills the requirement.

A system specification is traceable if each system function can be traced to its

corresponding set of requirements.

The requirement specification is realistic, if the system can be implemented within

constraints.

57. List the additional categories of requirement by Furts Model.

58. Define the terms Greenfield engineering, reengineering, and interface engineering.

In Greenfield engineering, the development starts from scratch, no prior system exists,

and the requirements are extracted from the users and the client. A Greenfield

engineering project is triggered by a user need or the creation of a new market.

A reengineering project is the redesign and reimplementation of an existing system

triggered by technology enablers or by new information flow.

An interface engineering project is the redesign of the user interface of an existing

system. The legacy system is left untouched except for its interface, which is redesigned

and reimplemented.

59. What are the types of scenario?

The four types of scenario are As-is scenarios, Visionary scenarios, Evaluation scenarios,

and Training Scenarios.

60. What are the scenarios which are expected to support the task in FRIEND example?

61. How is the use case identified?

A scenario is an instance of a use case, that is, a use case specifies all possible scenarios

for a given piece of functionality. A use case is initiated by an actor. After its initiation, a

use case may interact with other actors as well. A use case represents a complete flow of

events through the system in the sense that it describes a series of related interactions that

result from the initiation of the use case.

62. Compare Extend and Include relationship.

Include is a Directed Relationship between two use cases, implying that the behavior of

the included use case is inserted into the behavior of the including use case.

The first use case often depends on the outcome of the included use case.

The notation is a dashed arrow from the including to the included use case, with the label

"«include»".

Extend relationship indicates that the behavior of the extension use case may be inserted

in the extended use case under some conditions.

In another form of interaction, a given use case (the extension) may extend another.

The notation is a dashed arrow from the extension to the extended use case, with the label

"«extend»".

63. What are the requirements for managing requirement elicitation?

The requirements for managing requirement elicitation are, eliciting requirements from

users: Knowledge Analysis of Tasks (KAT), negotiating a specification with clients: Joint

Application Design (JAD), validating requirements: usability testing, and documenting

requirements elicitation.

64. How is Traceability maintained?

The traceability link is maintained through the development process, because we consider

the maintenance of traceability link as one of the documenting requirements elicitation.

65. What is RAD? Mention its use.

The documentation for the results of the requirements elicitation activity and the analysis

activity are called as Requirements Analysis Document (RAD). This document

completely describes the system in terms of functional and nonfunctional requirements

and serves as a contractual basis between the client and the developers.

66. Distinguish between Analysis object model & Dynamic model.

The intention with the analysis object model is that it is a means to describe the

architecture, i.e. the main objects that need to be implemented in the completed system.

The notations used are the same as for the requirements object model in the requirements

analysis. An overview of the notations is given in Object Model Notation and in State

Chart Notation. The analysis object models are represented by class and object

diagrams.

The dynamic model describes the behavior of a distributed parameter system in terms of

how one qualitative state can turn into another. The dynamic model, represented by state

chart and sequence diagrams.

67. Define Entity, Boundary, and Control Objects Entity objects represent the persistent information tracked by the system.

Boundary objects represent the interactions between the actors and the system.

Control objects represent the tasks that are performed by the user and supported by the

system.

68. Compare Specification and Generalization with an example. Requirement elicitation focuses on describing the purpose of the system. The client, the

developers, and the users identify a problem area and define a system that addresses the

problem. Such a definition is called a requirements specification and serves as a contract

between the client and the developers.

69. What are the activities that transform the use cases and scenarios into an analysis

model?

The activities that transform the use cases and scenarios produced during requirements

elicitation into an analysis model are,

70. What is CRC Card? Explain its importance.

called the CRC Card.

71. How is association identified? Give an example.

72. List the properties of associations.

73. State and explain the types of aggression.

74. What are the properties of attribute? Give an example.

The properties of attributes are,

75. What are the types of roles for assigning responsibility in documentation?

There are three types of roles for assigning responsibility in documentation such as

generation of information, integration, and review.

76. List the factors which enable communicating about analysis.

Communicating factors include different background of participants, different

expectations of stakeholders, new teams, and evolving system.

77. Briefly explain Brainstorming and Solidification

The goal of brainstorming is to generate and evaluate a large number of solutions for a

problem. Brainstorming is usually done in face-to-face meetings but can also be done via

E-mail or groupware. The fundamental idea behind brainstorming is that solutions

proposed by one participant, however invalid, can trigger additional ideas and proposals

from other participants.

Once the client and the developers converge on a common idea, define the boundaries of

the system, and agree on a set of standard terms, solidification starts. Functionality is

organized into groups of use cases with their corresponding interfaces. Groups of

functionality are allocated to different teams that are responsible for detailing their

corresponding use cases. During this stage, iterations are rapid but localized.

78. What is Client Sign-Off? List their properties.

UNIT III SYSTEM DESIGN

79. How are architectural concepts mapped with software engineering concepts?

80. What are products of analysis result in requirement model?

81. What are the products expected in system design?

System design results in the following products,

82. Differentiate coupling & cohesion.

Coupling measures the dependencies between two subsystems, whereas cohesion

measures the dependencies among classes within a subsystem.

In coupling the desirable property of a subsystem decomposition is that subsystems are

as loosely coupled as reasonable, whereas in cohesion the desirable property of a

subsystem decomposition is that it leads to subsystems with high cohesion.

83. Give UML diagram of Subsystem Decomposition.

84. Compare Layering and Partitioning.

A hierarchical decomposition of a system yields an order set of layers. Layering is a

grouping of subsystems providing related services, possibly realized using services from

another layer.

Partitioning can be done in two ways such as THE STATE, THE PROJECTION

85. List the design goals which are difficult to meet when using closed architecture with

many layers?

86. Distinguish open and closed architecture.

In an open architecture, a layer can also access layers at deeper levels, whereas in

closed architecture, each layer can access only the layer immediately below it.

An example of an open architecture is the Swing user interface toolkit for Java whereas

an example for closed architecture is the reference model of Open System Connection

(OSI) which consists of seven layers.

87. List the type of architectural styles.

The types are Repository, Model/View/Controller, Client/Server, Peer-to-peer, Three-tier,

Four Tier, and Pipe & filter.

88. What is Repository?

A repository is a storage location from which software packages may be retrieved and

installed on a computer. Repositories are typically used for database management

systems, such as a payroll system or bank system.

89. What are the system design activities from objects to subsystem?

The system design activities are: Starting point: Analysis model for a Route Planning

Subsystem, Identifying design goals, and identifying subsystems.

90. List the issues faced by system design activities.

The issues are, hardware/software mapping, data management, access control, boundary

conditions, and control flow.

91. What are the activities refining subsystem decomposition?

Activities refining subsystem decomposition are,

92. Define Proxy design pattern.

The proxy pattern is described as one which "decouples clients from their servers by

creating a local proxy, or stand-in, for the less accessible server. When the client needs to

request a service from the server, such as retrieving a value, it asks its local proxy. The

proxy can then marshal a request to the original server.”

93. Enlist the options available for storage management.

The options for storage management are: flat files, relational database, and object-

oriented database respectively.

94. Define boundary use cases.

To distribute use cases among subsystems, where to store data, & how to achieve access

control & ensure security, to decide how the system is started, initialized, and shutdown

and we need to define how we deal with major failures such as data corruption & network

outages. Use cases dealing with these conditions are called boundary use cases.

95. What is control flow? What are mechanisms available in it? Control flow is the sequencing of actions in a system. In object-oriented systems,

sequencing actions includes deciding which operations should be executed and in which

order. These decisions are based on external events generated by an actor or on the

passage of time. There are three possible control flow mechanisms such as Procedure-

driven control, Event-driven control and Threads.

96. What is the importance of access control? List the approaches available in it?

Access control is a system which enables an authority to control access to areas and

resources in a given physical facility or computer-based information system.

The approaches are global access table, access control list, and capabilities.

97. Define dynamic access control?

In the bank information system example, consider a broker actor who is assigned a set of

portfolios. By policy, a broker cannot access portfolios managed by another broker. In

this case, we need to model access right dynamically in the system, and hence this type of

access is called as dynamic access control.

98. How is boundary use case identified?

To have a better idea of how to decompose the system, how to distribute use cases

among, subsystems, where to store data, and how to achieve access control and ensure

security. We still need to examine the boundary conditions of the system, that is, to

decide how the system is started, initialized, and shut down, and we need to define how

we deal with major failures, such as data corruption, whether they are caused by a

software error or a power outage.

99. What design goals that lead to the decision that storage of consistent objects handled

by dedicated layer in 3 & 4 tier architecture?

100. Why u cannot display boundary use case during requirement elicitation or

analysis?

101. What is Exception? Enlist sources of it.

An exception is an unexpected event or error that occurs during the execution of the

system. Exceptions are caused by one of three different sources:

A user error, a hardware failure, and a software bug.

102. Define Exception handling with an example.

Exception handling is the mechanism by which a system treats an exception. In the case

of a user error, the system should display a meaningful error message to the user, such

that he/she can correct her input. In the case of a network link failure, the system needs to

save its temporary state in order to recover once the network comes back on line.

103. What is SDD? Explain its importance.

System design is documented in the System Design Document (SDD). The SDD is used

to define interfaces between teams of developers and as reference when architecture-level

decisions need to be revisited. It describes design goals set by the project, the subsystem

decomposition, the hardware/software mapping, the data management, the access control,

control flow mechanisms, and boundary conditions.

104. List the subsections available in proposed system architecture.

The subsections available are: overview, subsystem decomposition, persistent data

management, access control & security, global software control, and boundary

conditions.

105. What are the main roles for assigning responsibilities in system design?

The main roles for assigning responsibilities in system design are architect, architecture

liaisons, and the document editor/configuration manager/reviewer.

106. Why communication is difficult and what are the sources of complexity?

Communication during system design should be less challenging than during analysis:

The functionality of the system has been defined; project participants have similar

backgrounds and by now should know each other better. Communication is still difficult,

due to new sources of complexity such as size, change, level of abstraction, reluctance to

confront problems, and conflicting goals and criteria.

107. Define Façade design pattern.

The facade pattern is a software engineering design pattern commonly used with

Object-oriented programming. (The name is by analogy to an architectural facade.)

A facade is an object that provides a simplified interface to a larger body of code, such as

a class library. A facade can:

make a software library easier to use, understand and test, since the facade has convenient

methods for common tasks;

make code that uses the library more readable, for the same reason;

reduce dependencies of outside code on the inner workings of a library, since most code

uses the facade, thus allowing more flexibility in developing the system;

wrap a poorly-designed collection of APIs with a single well-designed API (as per task

needs).