W6: Pattern: Facade

The pattern Facade is part of structural design patterns.

Some subsystems contain several classes which are in close relation to each other. Since most classes of this subsystem are not commonly used without any other classes, there is no need to access them. The Facade then defines an consistent programming interface from which selected methods can be accessed.

Those methods are called delegate methods which keep the full access inside the subsystem. Thus handling of a Facade appears to be very easy.

Advantages

• less dependency (hidden subsystem)
• less complexity (consistent interface)
• easy to expand

Disadvantage

• adds another layer (more indirect)

Android App (small) example: WaveEffect

WaveEffect in action

before

after

Code example (WaveEffect and how it affects SpriteMapObject)

WaveEffect and SpriteMapObject before and after

W5: Refactoring

This Week we learned about Refactoring. So everyone of us has to do a little hands on training with the IDE and Movie-Rental Service. Look at our Repositories at Github to see how we mastered it:

Sedar

Fabian

Jannik

IDE

Eclipse offers several functions for refactoring your code. One such function is renaming variables.

W4: Testing

Android App

Our Android App features several Classes for equations and other complex algorithms. To Debug those we’ve chosen to use Unit4 on our testcases. See our code coverage below:

Website

We use karma tests for our website, because it is written in Angular. Below you can see the code coverage of our tests.

We are testing our code after every push in our gitlab-ci pipeline. You can see a snippet of the testing done in a docker container

For viewing our test code, visit the project page at https://react.it.dh-karlsruhe.de/gitlab/react/website/tree/master/src/app.The test codes are in the typescript files ending with spec.ts.

Resource Server

To Test the Resource Server we decide to use J-Unit4 with MockUps by the dependency Spring-Boot-Test. The tests runs with the Maven Build tool in a Docker Container over a Gitlab Pipeline

The Code Coverage by this tests will be displayed below:

W3: Function Points

In this week we created our Function Points for our Use Cases. We used TinyTool for the calculations.

Here is the data we used for our whole Application:

In this table we organized our data we used for the calculator.

Here is the diagramm, which displays our Use Cases, by person hours and Function Points per Case:

Register/Login took much more time then the average because we had framework bugs, which we couldn’t solve (Google oAuth). So we reimplented that Use Case with Http BASIC Authentification.

EDIT: After a bit of crticism, we updated our velocity charts by using the right data. Now it should be easier to understand.

Here are the links to our Use Case Specification, which now have information about our Function Points.

Links to UCs:

• Point CRUD
• Player Move
• Capture Location
• LogIn/Register
• Play in Map View
• Play in AR Surface