Stuff

ChangeReqLab_merged.txt

@@ -0,0 +1,224 @@
+[ChangeReqLab]
+CASE Study Lab
+
+Introduction: Software changes are started by creating a change request. A change request can
+be a new feature, a bug fix and improvements.
+User stories are short and simple descriptions of features written from the perspective of the
+person who desires the new capability.
+Objectives:
+• To write a user story for an existing software feauture.
+• Select a user story for your mandatory individual portfolio assignment.
+Classwork:
+• Each Team creates a GitHub Fork of the project repository [JHotDraw].
+• In future lab exercises, each team member follow [GitHub flow] to collaborate on projects.
+• Select an existing feature in JHotDraw and write the user story. See this list of [existing
+features]
+• Use [GitHub Projects]
+• Create a Card for your User Story and put it in the TODO Backlog.
+Portfolio Work:
+• Write the User Story for your selected JHotDraw feature. Note this is a an artifact for your
+portfolio.
+
+1
+
+[CLLab]
+Concept Location Lab
+
+Introduction: Dynamic program analysis is the analysis of computer software that is performed
+by executing programs on a real or virtual processor. For dynamic program analysis to be effective,
+the target program must be executed with sufficient test inputs to produce interesting behavior.
+Use of software testing measures such as code coverage helps ensure that an adequate slice of the
+program’s set of possible behaviors has been observed
+Objectives:
+• Apply the IDE Debugger to locate feature concepts at runtime.
+• Create a list of initial set of classes of the concept location results.
+Classwork:
+• Use the IDE Debugger to localize the classes that involves your Change Request. Features
+are often started from the controller classes. Note, if your feature involves a large number of
+classes then localize only the domain classes that are related to the to domain concepts.
+Portfolio Work:
+• Write the initial set of classes in table format as a result of your concept location based on
+your selected feature. The table format is as below:
+Domain Class
+
+Responsibility
+
+1
+
+[AnalysisLab]
+Impact Analysis Lab
+
+Introduction: Change impact analysis (IA) can be defined as ”identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change”.
+Objectives:
+• Apply static and dynamic analysis to find the estimated impacted set of classes based on
+your Change request.
+Classwork:
+• Find The Estimated Impact Set of classes by following the activities illustrated in Figure 7.9
+in [Raj13].
+
+Portfolio Work: Use Table 1 to list the packages and the number of classes you visited after you
+located the concept. Write short comments explaining what you have learned about each package
+and how they contribute to your feature?
+
+1
+
+Package name
+
+# of classes
+
+Comments
+
+Table 1: The list of all the packages visited during impact analysis.
+
+2
+
+[CILab]
+Impact Continues Integration Lab
+
+Introduction: In software engineering, continuous integration (CI) is the practice of merging
+all developers’ working copies to a shared mainline several times a day [Tho]. Grady Booch first
+proposed the term CI in his 1991 method although he did not advocate integrating several times
+a day [Boo]. Extreme programming (XP) adopted the concept of CI and did advocate integrating
+more than once per day – perhaps as many as tens of times per day [Bec99].
+Objectives:
+• Understand what CI is.
+• Setup a simple CI pipeline.
+Classwork:
+1. Go to [Building and testing Java with Maven]
+2. Add a *.yml file to your repository path <YOUR_PROJECT>/.github/workflows/ to tell
+GitHub Actions CI what to do.
+3. Configure the *.yml to automatically build your project for each pull request (use maven).
+4. To use shared jars from GitHub Packages you need create a .maven-settings.xml file in
+the project root folder, see [Working with the Apache Maven registry]
+5. Configure the *.yml to execute tests automatically.
+
+References
+[Bec99] Kent Beck. Embracing change with extreme programming, 1999. [HTML].
+[Boo]
+
+Grady Booch. Object Oriented Design: With Applications. [HTML].
+
+[Tho]
+
+ThoughtWorks. Continues Integration. [HTML].
+
+1
+
+[RefactLab]
+Refactoring Lab
+Jan Corfixen Sørensen
+Introduction: Refactoring is a disciplined technique for restructuring an existing body of code,
+altering its internal structure without changing its external behavior. Its heart is a series of small
+behavior preserving transformations. Each transformation (called a ”refactoring”) does little, but a
+sequence of these transformations can produce a significant restructuring. Since each refactoring is
+small, it’s less likely to go wrong. The system is kept fully working after each refactoring, reducing
+the chances that a system can get seriously broken during the restructuring.
+Objectives:
+• Identify and understand Bad Code Smells.
+• Apply refactorings to get rid of Bad Code.
+Classwork:
+• Make sure you have your own feature branch, using “git checkout -b your-feature development”.
+• Please follow the feature branch workflow [GitHub flow].
+• Install [sonarlint].
+• Find Code smells in JHotDraw based on your change request and sonarlint (shouldn’t be a
+problem).
+• Apply one or more suitable Refactoring Patterns to get rid of the bad code smells 1 .
+Portfolio Work:
+• Describe the code smell that triggered your refactoring, see Chapter 4 in [Ker05]. Describe
+what you plan to change by refactoring. Describe the strategy of the refactorings. Which of
+the refactorings from [Ker05] did you apply and what was the reasoning behind it?
+• Remember to describe the strategies and purpose of the Refactorings.
+
+1 See http://refactoring.com/catalog/
+
+1
+
+[ActLab]
+Actualization Lab
+Jan Corfixen Sørensen
+Introduction: The actualization phase consists of the implementation of the new functionality,
+its incorporation into the old code, and change propagation that seeks out and updates all places
+in the old code that require secondary modification.
+Objectives:
+• Understand and explain Clean Architecture in context of Actualization
+• Understand and explain Clean Code Principles in context of Actualization
+Portfolio Work:
+• Provide examples of the SOLID principles in context of the CASE study.
+• Explain Clean Architecture in context of the CASE Study.
+•
+
+1
+
+[ActLab]
+Actualization Lab
+Jan Corfixen Sørensen
+Introduction: The actualization phase consists of the implementation of the new functionality,
+its incorporation into the old code, and change propagation that seeks out and updates all places
+in the old code that require secondary modification.
+Objectives:
+• Understand and explain Clean Architecture in context of Actualization
+• Understand and explain Clean Code Principles in context of Actualization
+Portfolio Work:
+• Provide examples of the SOLID principles in context of the CASE study.
+• Explain Clean Architecture in context of the CASE Study.
+•
+
+1
+
+[TestLab1]
+Testing
+
+Introduction: In computer programming, unit testing is a software testing method by which
+individual units of source code—sets of one or more computer program modules together with
+associated control data, usage procedures, and operating procedures—are tested to determine
+whether they are fit for use. Unit tests are typically automated tests written and run by software
+developers to ensure that a section of an application (known as the ”unit”) meets its design and
+behaves as intended. In procedural programming, a unit could be an entire module, but it is
+more commonly an individual function or procedure. In object-oriented programming, a unit is
+often an entire interface, such as a class, but could be an individual method. By writing tests
+first for the smallest testable units, then the compound behaviors between those, one can build up
+comprehensive tests for complex applications.
+Objectives:
+• Understand the importance of testing.
+• Implement unit tests.
+Classwork:
+1. Add maven dependency to [JUnit4] if it is not already done.
+2. Create JUnit 4 tests for most important domain logic methods of your feature. Note: Swing
+and JUnit extensions often works best with JUnit 4.
+3. Write JUnit tests for best case scenario
+4. Write JUnit tests for identified boundary cases
+(a) A unit test should test a single code-path through a single method. When the execution
+of a method passes outside of that method, you have a dependency and should apply
+mocks/stubs to avoid the dependency, see [mockito.org].
+5. Use JAVA Assertions to test invariants, see [JAVA Asserts].
+(a) Assertions should be used to check something that should never happen
+(b) Note, an assertion should stop the program from running, but an exception should let
+the program continue running.
+Portfolio Work:
+• At class level write unit tests of important business functionality of your selected Feature.
+Document how you have verified your Feature.
+
+1
+
+[TestLab2]
+Behavior Driven Testing
+
+Introduction – User Stories and BBD
+User stories are short and simple descriptions of capabilities written from the perspective of the
+person who desires the new capability. “As a [user type], I want [some goal] so that
+[some reason].” An alternative includes: “As a [user type], I want [some goal]
+
+because [why].”
+Mapping User Stories to BDD:
+
+Figure 1: Example of how to map User Story to BDD scenario.
+
+Portfolio:
+• Map your User Stories to BDD Given-When-Then Scenarios
+• Use [JGiven] to automate your BDD Scenarios
+• For domain specific assertions use the [AssertJ library].
+For Swing applications use the [AssertJ-swing] to automate the Scenarios.
+
+1
+
+