END TERM EXAMINATION- Sample Paper (1)

FORTH SEMESTER [MCA]

Code: MCA208 Subject: Object-Oriented Analysis and DesignTime: 3 Hours Maximum Marks: 60

Note: Attempt five questions including Q.no. 1 which is compulsory. Select one question from each unit.

Q1 (a) Attempt any five of the following:- (2 x 5 = 10)

i. Define Negative Test with example.

When tester test the application from negative point of mind than it is known as negative testing. Testing the application always with invalid input and data is known as negative testing. Negative testing improves the testing coverage of your application. Using the negative testing approach allows you to test your applications with any possible input data (both valid and invalid) and can help you make your application more stable and reliable.

For Example, an application contains a textbox and as per the user's Requirements the textbox should accept only Strings. By providing input other than String as input data to the textbox & to check whether its working properly or not means it is Negative Testing.

ii. What is Association Class? Give example.

An association class is used to model an association as a class. Association classes often occur in many-to-one and many-to-many associations where the association itself has attributes. An association class is rendered by a dashed line from the association to the class rectangle. Each link in the association is an object of the association class. An association class is essentially a class attached to an association; the association itself is modeled as a class.

As an example, consider a many-to-many association between classes Person and Company. The association could have properties; e.g., salary, job Classification, start Date, etc. In this case, the association is more correctly modeled as an association class with attributes rather than trying to fold the attributes into one of the classes in the association.

iii. Differentiate Message and Signal with example.

An intraprocess stimulus (normal call inside one process) is called as a message. For example, a c++ message.

An interprocess stimulus is sent between two processes. Such a stimulus is called as signal. Signal may be synchronous and asynchronous.

A message and a signal are represented by a two separate symbols

A message

A signal

iv. Define Probe in Sequential Diagram with example.

The probe position indicates a position in the use case to be extended. The probe position indicates a position in the use case to be extended.

v. Define Homogenization with example. In parallel design process, several stimuli with the same purpose or meaning are defined by several designers. These stimuli should be consolidated to obtain as few stimuli as possible. It is called homogenization.

For Example:

What_is_your_phone_number? Where_do_you_live? Get_address Get_address_and_phone_number

Homogenized into:

Get_address Get_phone_number

VI. What is a CRC card? How it helps in the development of Object Oriented System?

A CRC cards is an index card that is use to represent the responsibilities of classes and the interaction between the classes. CRC cards are an informal approach to object oriented modeling. The cards are created through scenarios, based on the system requirements that model the behavior of the system. Not part of the UML design process but useful in detecting responsibilities of objects are CRC cards (developed by Kent Beck and Ward Cunningham). CRC stands for Class-Responsibility-Collaborator. They look like:

CRC helps in the development of Object Oriented System because:

They allow the (group) participants to experience firsthand how the system will work.

They are a useful tool for teaching the object-oriented paradigm. They can be used as a methodology themselves or as a front end to a more formal

methodology such as Booch, Wirfs-Brock, Jacobson, etc.

(vii). Discuss system development as a part of larger activity.

System development does not take place in isolation. It is part of a larger activity, often aimed at developing a product in which software is an integrated part. The main characteristics are:

Name ResponsibilitiesCollaborators

• Only person involved in production skilled in duplicating products, assembling and configuring system and testing.

• To minimize the development department with customer contacts.• Product is described as sets of packages of functionality services termed as service

packages.• Service Packages are translated into building blocks.

Q2. Differentiate the following with example: (2.5 x 4 = 10)

(i). Extend vs Include relationship in usecase diagram.

Extend is used when a use case conditionally adds steps to another first class use case. For example, imagine "Withdraw Cash" is a use case of an ATM machine. "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is instantiated when the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw Cash" use case stands on its own, without the extension.

Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. This should be used sparingly an only in cases where the duplication is significant and exists by design (rather than by coincidence).

For example, the flow of events that occurs at the beginning of every ATM use case (when the user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for aninclude.

(ii). Object Oriented Analysis (OOA) and Object Oriented Design (OOD).

Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design (OOD). Analysis is done before the Design. The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model.

Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take account of the constraints imposed by the chosen architecture and any non-functional - technological or environmental - constraints, such as transaction throughput, response time, run-time platform, development environment, or programming language.The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model of the solution domain, a detailed description of how the system is to be built.

(iii). Sequence Diagram vs. Collaboration Diagram.

Sequence Diagram:Sequence diagrams describe in detail how actors use use cases, they can also model external business processes the new system will support (e.g., processing a book order)

An interaction is a behavior that consists of a set of messages exchanged between external and system objects.

Interactions consist of one or more messages. Interactions may be synchronous (e.g., calling someone on the phone), or asynchronous (e.g., sending someone email).

Sequence diagrams defined during requirements analysis should not include design objects;

specify message signatures in any detail;

Collaboration diagram: Collaboration diagrams show interaction without the time dimension, but do include

object links. Like sequence diagrams, collaboration diagrams are intended to model scenario; each

scenario describes a possible sequence of events and actions. Sequence diagrams are helpful because they capture visually the sequence of events over

time. Collaboration diagrams capture more directly the interactions between actors and objects.

(iv). OOSA and OOSD.

Object-Oriented Systems Analysis (OOSA)• Many heuristics for object identification and analysis, which help with initial abstraction and object modeling.• Data modeling approach (ER modeling)• Models an object relationship network with subclasses. State transition specifications are constructed for each object and functions are

• State-modeled with data-flow diagrams.• Produces a composite activity-data model (synthesis not clearly specified)• Lack of support for inheritance.• Underspecified in the design phase.

Object-Oriented System Design:• Assumes analysis phase has been completed.• Provides detailed notation for object classes and management of inheritance.• Inter-object communications (event/message types).• Detailed notation for interface description and encapsulation.• No analysis advice is given.

UNIT – I

Q2(a). Discuss Software Development Process? Also elaborate the software process that is transforming needs to software product. (6)

Analysis, design, implementation, testing & refinement to transform users’ need into software solution that satisfies those needs Object-oriented approach:

• More rigorous process to do things right.

• More time spent on gathering requirements, developing requirements model & analysis model, then turn into Process to change, refine, transform & add to existing product transformation (analysis) - translates user’s need into system’s requirements & responsibilities.

• How they use system can give insight into requirements, eg: analyzing incentive payroll - capacity must be included in requirements transformation (design) - begins with problem statement, ends with detailed design that can be transformed into operational system.

‹#›• Bulk of development activity, include definition on how to build software, its

development, its testing, design description and testing material transformation 3 (implementation) - refines detailed design into system deployment that will satisfy user’s needs.

• Account of equipment, procedures, resources, people, etc - how to embed software product within its operational environment, eg: new compensation method prg needs new form, gives new report.

Q 2(b). How you will support the Object-Oriented Analysis and Design paradigm over the structure Oriented Analysis and Design paradigm?

(4)

Structured Object-OrientedMethodology SDLC Iterative/IncrementalFocus Processes ObjectsRisk High LowReuse Low HighMaturity Mature and Wide spread Emerging (1997)Suitable for Well-defined projects with

stable user requirementsRisky large projects with changing user requirements

Analysis Structuring Requirements DFD Decision Table ER Analysis

Requirement Engineering Use case model Object model

Design DB design GUI design

Physical DB design GUI design

Q3(a). Write a note on different traditionla methods of system development. (6)

Analysis/Structured Design (SASD):• Top-down functional decomposition.• Analyses system in terms of a network of processes connected by data flow

messages.• Functional cohesion and low coupling.• Does not support any OO concepts (separates data and process specification)• More recent versions have added state-transition diagrams and bottom-up

analysis driven by event identification (more potential for OO specifications)

Structured Systems Analysis and Design Method (SSADM):

• Composite method derived from structured analysis, structured design and data analysis.

• Process analysis is separated from data analysis functionally related processing structures.

• Most of the views expressed about IE also apply to SSADM.

Structured Analysis and Design Techniques (SADT):

• Uses top-down decomposition to analyze systems.• Specification uses network diagrams of processes connected by data flows, control

messages, and mechanisms.• Encourages modeling of real world problems, but constructs separate activity and

data models.• Does not support type-instance concepts.• Separation of process specification from data makes it unsuitable for an OO approach.

Jackson System Development (JSD):

• System models based on networks of concurrent communication processes.• Type-instance concept.• Classification and property inheritance are not supported.• System control is modeled in terms of time-ordering of actions associated with entities.• More recent versions have placed more emphasis on data modeling object model that combines data and operations.• Much in common with OO methods.• No object classification, instead entity roles.

Q3(b). Discuss and compare OMT and OOSE object oriented methodologies. (4)

OMT [Rumbaugh et al.,1991] consists of• building three complementary models of the system• adding implementation details to the models• implementing the models

OMT includes a set of phases [processes] and diagramming techniques. It has four phases:

• Object-oriented analysis builds a real-world model• System design determines overall architecture of system• Object design decides upon data structures and algorithms• Implementation translates design into programming language

OOSE:

• Originated from Objectory (Object Factory for software development)• Aim to fit the development of large real-time system • Covers entire life cycle• Stress traceability among the different phases (Backward & forward)• Usecase concept is core

UNIT- II

Q 4(a). What do you mean by requirement model? Discuss it with suitable diagram? (5)

The Requirement Model consist of

• A use case model• Interface description• A Problem domain model

The use case model involves the use of actors and use cases. Actors show what interact with a system. Their actions are non-deterministic. A user is different from an actor. A user is an actual person who uses the system while an actor represents a certain role that a user can play. A use case represents the functionality of a system. Each use case is a specific way of using the system. Every execution of the use case is an instance of the use case. When a user inputs a stimulus, the use case instance executes and starts a transaction belonging to the use case. The use case instance exists as long as the use case is operating. A use case class is a description that specifies the transactions of the use case. The set of all use case description specifies the complete functionality of the system. A use case is a complete flow of the system which has a state and behavior. Here the object model should consist of problem domain objects that help in the development of requirement model.

©

Q 4(b). What do you mean by system development. Also discuss different models of system development. (5)

The work that occurs when we develop computer support to aid an organization. System development is model building. It starts when a requirement of system identified and Specification can be used for contract and to plan and control the development process. It is a complex process handle poorly. OOSE can used from start to end of system life cycle. It is based on three technologies:

• Object oriented programming• Conceptual modeling• Block design

It consists of five different models:

• The requirement modelAims to capture the functional requirements

• Analysis modelGive the system a robust and changeable object structure

• Design modelAdopt and refine the object structure to the current implementation environment

• Implementation model Implement the system

• Test modelVerify the system

Seamless transition between the models is important. The method layer define the transformation rules. For maintainability traceability is very important between the models.

Models are tightly coupled to the architecture, and aim is to find concepts which are simple to learn and use. It simplify our understanding of the system and provide us with a changeable model of the system. These models are sufficiently powerful to express the information which is required to model the system. These models are sufficiently defined that different people can discuss the system in terms of these concepts without being misunderstood.

Q5 (a). Write a short note on model architecture. (4)

System development includes the development of different models of a software system. It aim is to find powerful modeling language, notation or modeling technique for each model. It consists of set of modeling techniques defines architecture upon which the system development method is based. The architecture of a method is the denotation of its set of modeling techniquesArchitecture can be view as the class of models that can be built with a certain modeling notationModeling technique is described by means of syntax, semantics and pragmatics:‹#›

• Syntax (How it looks)• Semantics (What it means)• Pragmatics (heuristics or rules of thumb for using modeling technique)

Features of modeling techniques:

• Easy to use• Contain few but powerful modeling objects to enable easy learning• Help to handle complexity of the system• To build these models method are required to show how to work with modeling

techniques• The specific system architecture is formulated in terms of the modeling object used• Specific system architecture is the result obtained after applying a method to a

system.

Q 5(b). What do you mean by analysis model. How requirement model structured in analysis model. (6)

When a SRS document has been mutually agreed upon by both customer and developer, we start the actual development process. This starts with an analysis model. The aim of this model is to structure the system independently of the actual implementation environment. This means that we focus on the logical structure of the system. It is here that we define the stable robust and maintainable structure is also extensible.

Although it is possible to use the object model developed in the requirement model as a base for the actual construction of the system but this does not result in a robust structure. It is, however, our analysis model that is more stable and maintainable system structure that will be robust for the entire SDLC.

Changes will come but will affect this logical structuring. We also want minimum changes to this ideal, logical and stable structure. The analysis model has three dimensions as shown in diagram:

These three dimensions are as:

(a). information (data) on x-axis:

This dimension specifies the information held in the system. Along the x-axis we describe the system internal state.

(b). behavior (functions) on y-axis:

On this axis, we specify the behavior that this system will adopt. We specify when and how the system will change state.

(c). presentation (outside world) on z-axis:

This dimension provides the details for presenting the system to the outside world.

The main features of analysis model are:

• Requirement model aims to define the limitations of the system and to specify its behavior• Development of actual system starts with analysis model• Focus on the logical structure• Define the stable, robust and maintainable structure that is also extensible• Creating analysis model corresponding to assigning functionality of use cases to objects

The object models are:

• Entity object: Information about an entity object is stored even aftera use case is completed.

• Control object: A control object illustrates functionality that is not contained in any other object in the system

• Interface object: Interface objects interact directly with the environment

UNIT- III

Q6(a). Define the term “Design”. Also discuss the objectives of design and elaborate why design is so difficult. (6)

It is specification about what, and Design is the start of the how inputs to the design process. The main specification document, including models etc. and the outputs of the design process consists of a design document that describes how the code will be written. Includes design models.

Design goals:

• Correctness: It Should Lead To A Correct Implementation‹#›

• Completeness: It Should Do Everything. Everything? It should follow thespecifications.

• Changeable: It Should Facilitate Change—Change Is Inevitable.

• Efficiency: It Should Not Waste Resources. But better a working slow design than a fast design that does not work.

• Simplicity: It Should Be As Understandable As Possible.

Why design is so difficult:

Because here analysis focuses on the application domain. Design focuses on the solution domain. Design knowledge is a moving target and the reasons for design decisions are changing very

rapidly. It consists of halftime knowledge in software engineering and cost of hardware rapidly sinking.

Q6(b). Elaborate the term “Traceability”. (4)

It refines the analysis model in light of actual implementation environment. The explicit definition of interfaces of objects, semantics of operation. Additionally, different issues like DBMS, programming language etc. can be considered. The model is composed of “BLOCKS ” which are the design objects. One block is implemented as one class. The blocks abstract the actual implementation. Traceability is extremely important aspect of the system. Changes made will be only local to a module. It provides high functional localization (high cohesion).

Q7(a). What the reasons for having construction phase in object oriented software engineering? Explain the procedure of converting analysis model into construction model.

(5)Construction Phase: All about “BUILDING” the system from model of analysis & requirement phase. It consists of Design and Implementation.

Implementation: It start from elaboration & continues to construction. The main reason of why construction consists of transition to source code; analysis model not sufficient. The actual system must be adapted to the implementation environment. It must explore into more dimensions.

Analysis to Design Model:

Artifacts of Construction:

‹#›

Q 7(b). What do you mean by object oriented testing. Also discuss object oriented testing.(5)

According to Hetzel, software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required result. However, testing still remains an art as we have limited understanding of testing principles. In object oriented systems, class is the smallest unit for testing. Object oriented test cases will concentrate on the state of a class. We can do both white box and box testing here.

Object oriented concept includes:• Verification• Validation• Debugging• Certification• Clean Room Software Engineering• Error

•Testing Techniques•Regression Test•Testing Focuses•Operation test•Full-scale test•Stress test•Overload test• Fault• Failure• Testing Level

• Unit testing• Integration Testing• System Testing

•Negative test•Test based on requirements•Ergonomic tests•Testing of the user documentation•Acceptance testing

• Stubs• Drivers• Test bed• Equivalence set• Equivalence partitioning

UNIT-IV

Q8(a). Consider the Order System of an application. It has the following conditions: (7)

• First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have multiple orders.

• We would keep Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder.

• The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive ().

So draw the class diagram based on the above mentioned case.

Q 8(b). Give different reasons where to use class diagrams. (3)

Class diagram is a static diagram and it is used to model static view of a system. The static view describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and deployment diagrams. Class diagrams are not only used to visualize the static view of the system but they are also used to construct the executable code for forward and reverse engineering of any system.

Generally UML diagrams are not directly mapped with any object oriented programming languages but the class diagram is an exception.

Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So from practical experience class diagram is generally used for construction purpose.

So in a brief, class diagrams are used for:

Describing the static view of the system. Showing the collaboration among the elements of the static view. Describing the functionalities performed by the system.

Construction of software applications using object oriented languages.

Q 9(a). What do you mean by building blocks of UML? Also discuss different building blocks in detail. (7)

UML describes the real time systems it is very important to make a conceptual model and then proceed gradually. Conceptual model of UML can be mastered by learning the following three major elements:

UML building blocks Rules to connect the building blocks Common mechanisms of UML

The building blocks of UML can be defined as:

Things Relationships Diagrams

(1) Things:

Things are the most important building blocks of UML. Things can be:

Structural Behavioral Grouping Annotational

Structural things:

The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things.

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class.

Collaboration:

Collaboration defines interaction between elements.

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node:

A node can be defined as a physical element that exists at run time.

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

Grouping things:

Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:

Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one Annotational thing available.

Note:

A note is used to render comments, constraints etc of an UML element.

(2) Relationship :

Relationship is another most important building block of UML. It shows how elements are associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects the other one.

Association:

Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects.

Realization:

Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it a complete one.

UML includes the following nine diagrams:

1. Class diagram2. Object diagram3. Use case diagram4. Sequence diagram5. Collaboration diagram6. Activity diagram7. Statechart diagram8. Deployment diagram9. Component diagram

Q 9(b). Write a short note on UML modeling techniques. (3)

Structural modeling:

Structural modeling captures the static features of a system. They consist of the followings:

Classes diagrams Objects diagrams Deployment diagrams Package diagrams Composite structure diagram Component diagram

Structural model represents the framework for the system and this framework is the place where all other components exist. So the class diagram, component diagram and deployment diagrams are the part of structural modeling. They all represent the elements and the mechanism to assemble them.

Behavioral Modeling:

Behavioral model describes the interaction in the system. It represents the interaction among the structural diagrams. Behavioral modeling shows the dynamic nature of the system. They consist of the following:

Activity diagrams Interaction diagrams Use case diagrams

Architectural Modeling:

Architectural model represents the overall framework of the system. It contains both structural and behavioral elements of the system. Architectural model can be defined as the blue print of the entire system. Package diagram comes under architectural modeling.