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 objectoriented 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 Proceduredriven 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 Faade 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).