Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Object Oriented Design - Midterm Exam 3 Solution - Spring 2002 | CSE 687, Exams of Engineering

Syracuse UniversityEngineering
Prof. James Fawcett

Material Type: Exam; Professor: Fawcett; Class: Object Oriented Design; Subject: Computer Engineering; University: Syracuse University; Term: Spring 2002;

Typology: Exams

Pre 2010

Uploaded on 08/09/2009

koofers-user-w5u-1
koofers-user-w5u-1 🇺🇸

9 documents

1 / 13

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSE687 Object Oriented Design MidTerm Exam A1 Spring 2002
Midterm A1 – Instructor’s Solution
Name:_________________________________ SUID:____________________
This is a closed book examination. Please place all your books on the floor
beside you. You may keep one page of notes on your desktop in addition to
this exam package. All examinations will be collected promptly at the end of
the class period. Please be prepared to quickly hand in your examination at
that time.
If you have any questions, please do not leave your seat. Raise your hand
and I will come to your desk to discuss your question. I will answer all
questions about the meaning of the wording of any question. I may choose
not to answer other questions.
You will find it helpful to review all questions before beginning. All questions
are given equal weight for grading, but not all questions have the same
difficulty. Therefore, it is very much to your advantage to answer first those
questions you believe to be easiest.
pf3
pf4
pf5
pf8
pf9
pfa
pfd

Partial preview of the text

Download Object Oriented Design - Midterm Exam 3 Solution - Spring 2002 | CSE 687 and more Exams Engineering in PDF only on Docsity!

Midterm A1 – Instructor’s Solution Name:_________________________________ SUID:____________________ This is a closed book examination. Please place all your books on the floor beside you. You may keep one page of notes on your desktop in addition to this exam package. All examinations will be collected promptly at the end of the class period. Please be prepared to quickly hand in your examination at that time. If you have any questions, please do not leave your seat. Raise your hand and I will come to your desk to discuss your question. I will answer all questions about the meaning of the wording of any question. I may choose not to answer other questions. You will find it helpful to review all questions before beginning. All questions are given equal weight for grading, but not all questions have the same difficulty. Therefore, it is very much to your advantage to answer first those questions you believe to be easiest.

  1. Given the declarations: class D : public B { … private: std::string s; std::istream &is; } write a copy constructor for class D. You may assume there are no other data members in class D. D::D(const D &d) : B(d), s(d.s), is(d.is) { }
  1. Please describe how the Liskov Substitution Principle applies to your Project #3, statement attached on last page. The Liskov Substitution Principle says that: “Functions that use pointers or references statically typed to some base class must be able to use objects of classes derived from the base through those pointers or references without any knowledge specialized to the derived classes.” Project #3 states that: ”The base processing class provides a protocol for derived classes to define application specific processing on all the files encountered in a scan.” The design strategy here is to provide component scanner software that uses a base processing class pointer to carry out an operation on each component encountered during a scan. Suppose you design a Scan class that has a next function to provide access to the next component in the scan, and a done function that returns a Boolean value that is true only when all of the components have been scanned. Then we might write something like this: processing *pProc = &derivedObj; // defines operation while(!scan.done()) pProc->operation(scan.nextComp()); Each derived class defines an operation, e.g., display, status check, build, etc. We depend on Liskov substitution working correctly so that the derived class instance correctly calls the operation of the derived object we’re using. The scanner doesn’t need to know anything about the operations provided. We could modify or add new operations without affecting the scanner, but that’s another principle (Open/Closed Principle).
  1. Given the code fragments below, where the ellipsis (…) represents code that has not been disclosed to you: class X { … }; class Y { public: Y(const X& x); … }; what can you say about the compilation and execution of each of the following statements? Describe all of the operations that occur during execution. X x1, x2; Y y2 = x1; Y y[4] = { x1, x2, X() }; First statement: Requires default X constructor so that must be defined if any other X constructors are defined. When executed, two objects are constructed using the default constructor. Second statement: If the Y(const X& x) constructor, declared in the class declaration, is defined then this will compile. When executed, only this function is called. Third Statement: Given that the first statement compiles, this will compile if, and only if, Y() is defined by the class, since it is needed to construct the last member of the array, and the compiler will not generate one since there is already a constructor declared in the class. When executed, the following sequence of operations occurs: - Y(const X& x) is called for the first array element - Y(const X& x) is called for the second array element - X() is called, then Y(const X& x), then ~X() is called for the third element - Y() is called for the fourth element of the array - ~Y() is called five times for y2 and y[4] - ~X() is called twice for x1 and x
  1. Given the classes: class A { public: virtual void fun1(int); virtual int fun2(); void fun3(); … }; class B : public A { public: void fun1(int); virtual void fun4(); … } show how you invoke fun4 using a pointer of type A*.

B b;

A* pA = &b;

if(dynamic_cast<B*>(pA))

dynamic_cast<B*>(pA)->fun4();

  1. Define a base class B and two derived classes D1 and D2 so that B provides a function, showTypes, that displays the type of B and the type of any class that derives from B. a client uses the function as shown below. B should not have to know the names of the derived classes: D1 d1; d1.showTypes(); // shows type of base and type of d1; D2 d2; d2.showTypes(); // shows type of base and type of d2; template class B { public: void showTypes() { cout << "\n " << typeid(T).name(); // derived type cout << "\n " << typeid(*this).name(); // same format } }; class D1 : public B { }; class D2 : public B { };

CSE687 Object Oriented Design MidTerm Exam A1 Spring 2002

  1. What is Object Oriented Design? Object Oriented Design is the process of decomposing software requirements using classes and class relationships, e.g., using, composition, inheritance, and polymorphism.  A class’s design encapsulates its data and implementation behind a public interface, allowing clients to be ignorant of the implementation details of the class. This protects its operations by allowing only class members to directly alter its state.  Using relationships occur when a class is passed as the argument of a member function of another class. It is the fundamental method of establishing useful dependencies between software components.  Composition is a process of layering a design by making an instance of a class a data member of another class. The outer class gains all the public functionality of its member simply by composition.  Inheritance is the process of extending the functionality of a base class by deriving other classes from it and overriding base virtual functions to provide derived class specific processing. A derived class also may extend the operations of the base class by introducing new public member functions.  Polymorphism is used to create loosely coupled components by using a base class protocol and dynamically binding clients to derived class objects. The client simply uses the base protocol and is not bound to derived names or even need to know any of the details that distinguish one derived class from another. awards scholarship fellowship Graduate School National Government student uses uses awards Government^ National^ scholarship^ fellowship^ Graduate School student uses uses

Project #3 – Software Repository due Monday, April 08

Purpose: The purpose of this project is to build a program that manages a structured set of files. The files will be grouped into modules, programs, and systems:  A module is represented by a file, called a manifest, that contains the path^1 to each of its source, documentation, and test files. A module’s manifest may also refer to another module’s manifest file if this module uses that module’s services.  A program is represented by a manifest file that contains paths to each of its modules and its documentation and test files.  A system is represented by a manifest file that contains paths to each of its programs, documentation, and test files. All source code, documentation, and test files will be stored in directories named code, documentation, and test, under a Repository directory. All module, program, and system manifests will reside in module, program, and system directories, respectively. Your REPOSITORY project will provide a base processing class that, given the name of a manifest, scans that manifest and, recursively, all the manifests and files it refers to, performing some default operation on them^2. The base class will provide a protocol for derived classes to define application specific processing on all the files encountered in a scan. Typical applications are display, checking status, or building an executable. You should provide a scanning module that uses a pointer to the base processing class to apply processing actions to each file encountered on a scan. The scanning module should not have to know the type of the processing object it points to, but simply apply its processing actions to every file. Requirements: Your REPOSITORY program:

  1. shall compile and link from the command line, using VC++ 6.0, as provided in the ECS cluster and operate in the environment provided there^3.
  2. shall provide an executive module that reads the name of a manifest and the type of operation to be used and applies that operation to the named manifest and every manifest it refers to, either directly or recursively. The operations shall include:
    • display the name of each manifest’s component, e.g., system, program, or module name, and the names of every file referred to by a manifest
    • extract all the files associated with the named manifest, either directly or indirectly, to a specified directory
    • build a program or library file from all the files referred to by the named manifest either directly or indirectly^4
  3. shall accept the name of a new manifest file to be created and allow the user to specify all of the manifests and files it refers to.
  4. shall be delivered with manifests and files that represent all the code you provide for your REPOSITORY program.
  5. shall provide the means for new operations, as in part 2, to be added to the REPOSITORY program without changing any of the existing modules you provide, except for the executive. That is, your server modules should satisfy the open/closed principle: they should be open for extension, but closed to modifications. (^1) The paths to use are specified below. (^2) Note that, if we define a component as anything represented by a manifest, e.g., module, program, or system, then scanning is just a process of walking the tree defined by all the component’s lower level components and files. (^3) See notes on project submissions, handed out during the first class. (^4) You will need to supply compile.bat and run.bat files or dsp file for each manifest so that this operation can be carried out. Of course, the bat or dsp files should be referred to by the manifest.