Software Engineering

SN#

Concept Name

Details of how your extracted this concept.

CON1

CON2

CON3

CON4

Hint : Based on the knowledge you gained in Lab #1 lecture populate all required functional requirements for this change request in Table 2 . Add more rows to this table as needed. Make sure the requirements maintain the 10 characteristics of good requirements as discussed in the Lab#1 lecture. These requirements will be used to write unit tests and your code should verify these requirements.

Requirement#

Functional Requirement Details

FR1

FR2

FR3

FR4

FR5

FR6

FR7

FR8

FR9

FR10

Hint : Explain the methodology that you have used to locate each significant concept (use either dependency search or grep search) that was part of your change request. Use appropriate sub section below while capturing details.

Hint : Using Table 3 for dependency search, list all the files in the order that you have visited them (1st column). Explain how you have found each file (2nd column).

You can simply read the source code or any other software tools that you want to use. In the 3rd column, mention if the class is related to the concept. Use one of the following terms:

· Use “Unchanged” if the class has no relation to the concept but you have visited it.

· Use “Propagating” if you read the source code of the class and it guided you to the location of the concept, but you will not change it.

· Use “Located” if the class will be changed.

In the 4th column, write what you have learned about the class/file.

Class/file name

Tool used

Mark

Explanation

Hint: Draw a partial class dependency graph (use starUML) here. It must contain all the classes that you visited and all the dependencies among these classes that you understood. Mark the classes that were “Located” with red text, “Propagating” with orange text and “Unchanged” with black text.

Hint : Populate Table 4 if you use grep search for your concept location.

List all the queries (2nd column) you have tried for each concept (1st column). The number of matching files by each query should be recorded in the 3rd column. List the “located” classes/files in the fourth column and the tool used for this query in the fifth column. In the last column explain what you have learned about the “located” classes/files. The explanation should describe why you believe this class is a “located” class. List only the located class, not all the files you found in your Grep Search.

Concept

Query

#Results

Target class/file

Tool used

Explanation

Hint: Do a complete impact analysis based on the result of section 2. Using Table Z to list the classes that you visited. At the beginning rows, include the class where you have located the concept, i.e. the class that will be changed (1st column). Explain how you have found each of the classes, i.e. which tools have you used (2nd column).

In the 3rd column, use one of the following terms:

· Use “Unchanged” if the class has no relation to the concept but you have visited it.

· Use “Propagating” if you read the source code of the class and it guided you to the location of the concept, but you will not change it.

· Use “Impacted” if the class will be changed.

In the column 4, briefly explain what you have learned about each class that made you believe this class is given the mark Unchanged, Propagating, or Impacted.

Briefly list any other tools you would like to have in Visual Studio so that impact analysis would be faster.

Class name

Tool used

Mark

Explanation

Hint: Draw a partial class interaction graph (use starUML). It must contain all the classes that you visited and all the interactions among these classes that you understood. Mark the classes that were “Impacted” with red text, “Propagating” with orange text and “Unchanged” with black text.

Hint : Provide detailed entries for describing how you performed prefactoring for this change request. Write down the type of your refactoring in the 2nd column (e.g. “Extract a superclass” or use the terms on https://sourcemaking.com/refactoring ).

If no refactoring is needed, leave this table empty and in the first row/column indicate N/A

File Name

Refactoring Issue

Lines of Code

Added

Deleted

Total

Hint: Use Table 7 to indicate the number of files for each of the category.

Use Table 8 to indicate the number of lines of changes you made in the source code. In column 1 indicate the actual file name, and in Column 2 indicate what you changed e.g., “Added new function,” “Added a new class,” or “Added new function, and deleted some old code.” Add more rows as needed. You have to list all the changed files.

Code Files

Visited#

Changed#

Added#

Propagating#

Unchanged#

Added to Changed Set#

#

#

#

#

#

#

File Name

Task

Lines of Code

Added

Deleted

Total

Hint : Provide detailed entries for describing how you performed postfactoring for this change request. Write down the type of your refactoring in the 2nd column (e.g. “Extract a superclass” or use the terms on https://sourcemaking.com/refactoring ).

If no Postfactoring is needed, leave this table empty and in the first row/column indicate N/A

File Name

Refactoring Issue

Lines of Code

Added

Deleted

Total

Hint: Describe how you performed verification for this change request. Use the knowledge you gained from both the lab and software engineering course lectures related to unit test and verification. For QT unit testing use the following tutorial: http://doc.qt.io/qt-5/qttestlib-tutorial1-example.html

You have to write unit test suite for QT related changes you did and also the other code statements you added/modified. The test suite must verify all the requirements you added in “Function requirements” section.

Example: How to populate Table 10 and the details you need to capture after this table

Assume you added this function in TestMe.cpp file: Here you added7 statements.

Printsum(int input1, int intput2) {                       

int sum = input1 + input2;

If (sum> 0)

return “Positive sum”;

Else

return “Negative sum”;

}

UT#1: Verify positive sum

Assume you have developed Unit test case something like this in Visual Studio or other tools for the above function:

namespace TestTestMe

{

TEST_CLASS(UnitTest1){

public:

TEST_METHOD(TestMethod1){

// input1 = 8; input2=10;

string sumstring = printSum(8,10);

Assert::AreEqual(“Positive sum”, sumstring);

}

};

}

Now, when the code runs, the following highlighted code lines will be executed/covered i.e.5 lines

Printsum(int input1, int intput2) {                       

int sum = input1 + input2;

If (sum> 0)

return “Positive sum”;

Else

return “Negative sum”;

}

Therefore, statement coverage % = Lines Executed/Total Lines Added = 5/7 = 71%

File Name

Coverage of Application

Unit Test Failed

(Just indicate the SN#)

Bugs

Found

Total statements added

Total statements covered

Statement coverage %

Example: TestMe.cpp

7

5

71%

UT#1

0

Example

Hint: You should specify and record the cases you use in the verification section of your report (e.g. “After implementing the change request X. I drew a dashed line out of the canvas and failed to do so. Then I drew a dashed line inside the canvas successfully. So this capability worked correctly for my test cases.”). Refactoring is not required this time. ** Repository and report parts still follow the late policy in the syllabus.

Hint: Attach or cut and paste the code of the classes that you changed. Highlight the code that was changed or added. Use YELLOW for modified code RED for deleted code