Created by: R. Krüger, A. Biller, S. Pflüger
- AS - FA54 - Gruppe 2 - Quiz
- Table of Contents
- Documentation
- Project Outline
- Contributor Roles
- Kanban Board
- UML - First Draft
- Frontend Design
- Backend Development
- Database Integration
- Test Coverage
- Final Touches
- Ergebnisprotokolle
- Protokoll 1 - 13.02.2017 - 15.02.2017
- Protokoll 2 - 16.02.2017 - 17.02.2017
- Protokoll 3 - 06.03.2017 - 07.03.2017
- Protokoll 4 - 09.03.2017 - 10.03.2017
- Protokoll 5 - 27.03.2017 - 28.03.2017
- Protokoll 6 - 29.03.2017 - 30.03.2017
- Protokoll 7 - 31.03.2017 - 01.04.2017
- Protokoll 8 - 07.04.2017 - 09.04.2017
- Protokoll 9 - 14.04.2017 - 16.04.2017
- Protokoll 10 - 24.04.2017 - 25.04.2017
- Protokoll 11 - 26.04.2017 - 27.04.2017
- Protokoll 12 - 28.04.2017 - 15.05.2017
- Project Workflow Guides
- Credits
(Created by gh-md-toc because with all this work to be done we just can't be bothered updating this table of contents manually every time someone adds more stuff to the chapters in here)
C# / WPF / MVVM / Windows - Quiz application with multiple choice questions to prepare students trying to get their drivers licence for sportboats in inland waters for their test. The project requirements can be found here.
- Rico Krüger - Datenbanken
- Andreas Biller - Frontend
- Severin Pflüger - Backend
The task management of our work on the project is done here. The workflow guidlines of our team for the use of the board, creating issues, working with github, pushing with continuous integration scripts, try test-driven-development, using markdown and some helpfull IDE shortcuts are listed at the bottom of this guide.
The first draft of our projects object relations was done quickly and without knowing the first thing about how to write a windows application, use embedded databases in C#, work with object oriented design patterns, use lambdas and delegates, how tho bind data to views or work as a team with separated responsibilities towards on a common codebase using github. Needles to say, it wasn't very good. Still, here's the picture and here's the file. Made with Dia. The second first draft of our apps UML shown above was finished shortly thereafter. This draft was created from this simple textfile here with the help of PlantUML. Documentation for PlantUML can be found here. Requires the Java Runtime Environment and Graphviz to be installed on your system, but is well worth it. Give it a try sometimes.
We will use the model-view-viewmodel design pattern for our project. For a very short but good video tutorial that explains all the basic key elements involved in using MVVM with C# and WPF, go here.
In general, model is the simplest one to understand. It is the client side data model that supports the views in the application.
- It is composed of objects with properties and some variables to contain data in memory.
- Some of those properties may reference other model objects and create the object graph which as a whole is the model objects.
- Model objects should raise property change notifications which in WPF means data binding.
- The last responsibility is validation which is optional, but you can embed the validation information on the model objects by using the WPF data binding validation features via interfaces like INotifyDataErrorInfo/IDataErrorInfo
The main purpose and responsibilities of views is to define the structure of what the user sees on the screen. The structure can contain static and dynamic parts.
- Static parts are the XAML hierarchy that defines the controls and layout of controls that a view is composed of.
- Dynamic part is like animations or state changes that are defined as part of the View.
- The primary goal of MVVM is that there should be no code behind in the view.
- It’s impossible that there is no code behind in view. In view you at least need the constructor and a call to initialize component.
- The idea is that the event handling, action and data manipulation logic code shouldn’t be in the code behind in View.
- There are also other kinds of code that have to go in the code behind any code that's required to have a reference to UI element is inherently view code.
ViewModel is the main point of MVVM application. The primary responsibility of the ViewModel is to provide data to the view, so that view can put that data on the screen.
- It also allows the user to interact with data and change the data.
- The other key responsibility of a ViewModel is to encapsulate the interaction logic for a view, but it does not mean that all of the logic of the application should go into ViewModel.
- It should be able to handle the appropriate sequencing of calls to make the right thing happen based on user or any changes on the view.
- ViewModel should also manage any navigation logic like deciding when it is time to navigate to a different view.
- A clean separation of different kinds of code should make it easier to go into one or several of those more granular and focused parts and make changes without worrying.
- That means you can remain agile and keep moving out to new releases quickly.
- With MVVM each piece of code is more granular and if it is implemented right your external and internal dependences are in separate pieces of code from the parts with the core logic that you would like to test.
- That makes it a lot easier to write unit tests against a core logic.
- Make sure it works right when written and keeps working even when things change in maintenance.
- It sometimes overlaps with maintainability, because of the clean separation boundaries and more granular pieces of code.
- You have a better chance of making any of those parts more reusable.
- It has also the ability to replace or add new pieces of code that do similar things into the right places in the architecture.
TODO: Describe the design process from first view drafts to finished product and the many pitfalls along the way. Maybe elaborate, how little help our teacher was. Add lots of screenshot to make it look pretty.
TODO: Write about our apps main model object relations and their development process. Also a good spot to add our apps updated class diagram and show how our app evolved from our first draft, once work on it is finally done.
TODO: Write about the way we implement and how we query for the data in the embeded database we use. Show how we switch them and how we save our user data. Maybe some database alternatives we could have used.
TODO: Write about our projects test coverage, the framework used and give a short overview about CI/TDD and show some principles / best practices of test-driven-development and continuous integration here.
TODO: Finish the documentation, link some sources and references, add some screenshots, spellcheck and proofread it, make a presentation, take a vacation... in short, get this shit done. And then move on to something that's more fun. And praise the sun!
| Protokollnummer: | 1 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 13.02.2017 - 15.02.2017 |
AS-Blöcke:
- 13.02.2017
- 14.02.2017
- 15.02.2017
| Diese Blöcke erledigte Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: Klassendiagramm erstellt, Klassendiagramm überarbeitet, Versionskontrolle eingerichtet, Git-Workflow festgelegt, Kanban-Board für Projekt erstellt, Projektrollen verteilt, Dokumentation und Protokollierung begonnen |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: Klassendiagramm erstellt, Versionskontrolle eingerichtet, Projektrollen verteilt, Aufgabenpackete festgelegt, Informationen zum Themengebiet gesammelt, Dokumentation und Protokollierung begonnen |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: Klassendiagramm erstellt, Versionskontrolle eingerichtet, Projektrollen verteilt, Aufgabenpackete festgelegt, Informationen zum Themengebiet gesammelt, Dokumentation und Protokollierung begonnen |
| Protokollnummer: | 2 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 16.02.2017 - 17.02.2017 |
AS-Blöcke:
- 16.02.2017
- 17.02.2017
| Diese Blöcke erledigte Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: Aufgabenpackete festgelegt, Informationen zum Themengebiet gesammelt, Dokumentation und Protokollierung fortgesetzt |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: Aufgabenpackete festgelegt, Informationen zum Themengebiet gesammelt, Dokumentation und Protokollierung fortgesetzt |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: Aufgabenpackete festgelegt, Informationen zum Themengebiet gesammelt, Dokumentation und Protokollierung fortgesetzt |
| Protokollnummer: | 3 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 06.03.2017 - 07.03.2017 |
AS-Blöcke:
- 06.03.2017
- 07.03.2017
| Diese Blöcke erledigte Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: Implementierung begonnen, View zur Ausgabe der Testklassen erstellt |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: Simple Quiz Auswertung, Zwei Fragen gemockt, um Solve() und Evaluate() zu testen |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: krank |
| Protokollnummer: | 4 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 09.03.2017 - 10.03.2017 |
AS-Blöcke:
- 09.03.2017
- 10.03.2017
| Diese Blöcke erledigte Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: Ausgabe der Testdaten im View, gitignore zur Vermeidung von Mergekonflikten angelegt, gitconfig für Aliase angelegt, Änderung der Protokolle von Wöchentlich auf alle 2 Tage |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: Embedded Datenbank angelegt |
| Protokollnummer: | 5 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 27.03.2017 - 28.03.2017 |
AS-Blöcke:
- 27.03.2017
- 28.03.2017
| Diese Blöcke erledigte Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: Verbindung zu den Daten aus dem Backend herstellen, Datenausgabe im View, updated gitignore um mdf Datenbank in Github zu speichern, Eventhandling für Propertychanges in Quiz einbauen, view_test zur Erklärung von DataBinding und INotifyPropertyChanged für Teammitglieder erstellt |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: krank |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: |
| Protokollnummer: | 6 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 29.03.2017 - 30.03.2017 |
AS-Blöcke:
- 29.03.2017
- 30.03.2017
| Diese Blöcke zu erledigende Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: NUnit Test-Framework eingebunden, Datenbank wieder hinzugefügt, gitignore angepasst, Weitere Recherche: WPF, XAML Objects, Events, Actions, Delegates, ICommand, Data Binding, MVVM-Design Pattern |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: krank |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: |
| Protokollnummer: | 7 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 31.03.2017 - 01.04.2017 |
AS-Blöcke:
- 31.03.2017
- 01.04.2017
| Diese Blöcke erledigte Aufgaben des Frontend-Entwicklers: |
|---|
| tasks: Questionaire View Page erstellt, View Pages in Main Window Frame anzeigen, Page Switch Methode implementiert, Quit Application Methode implementiert, Settings View Page erstellt, Start View Page erstellt, Fontawesome für Icons eingebunden, Project Files reorganized, Some View Bugfixes |
| Diese Blöcke erledigte Aufgaben des Backend-Entwicklers: |
|---|
| tasks: krank |
| Diese Blöcke erledigte Aufgaben des Datenbankspezialisten: |
|---|
| tasks: |
| Protokollnummer: | 8 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 07.04.2017 - 09.04.2017 |
Wochenende:
- 07.04.2017
- 08.04.2017
- 09.04.2017
| Dieses Wochenende erledigte Aufgaben des Frontend-Entwicklers:* |
|---|
| tasks: Results View Page erstellt, Question Data Binding zwischen View und Dummy Question Object im Backend hergestellt, Question View Model erstellt, Projektzustand erreicht, bei dem Teammitglieder ihre Fortschritte im View sehen können, Code kommentiert, Beispielprojekt entfernt |
| Dieses Wochenende erledigte Aufgaben des Backend-Entwicklers:* |
|---|
| tasks: |
| Dieses Wochenende erledigte Aufgaben des Datenbankspezialisten:* |
|---|
| tasks: |
| Protokollnummer: | 9 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 14.04.2017 - 16.04.2017 |
Wochenende:
- 14.04.2017
- 15.04.2017
- 16.04.2017
| Dieses Wochenende erledigte Aufgaben des Frontend-Entwicklers:* |
|---|
| tasks: Antworten aus Liste anzeigen, Antwort Klasse aus Question.AnswerList im QuestionViewModel für ObservableCollection hinzugefügt, Klasse User für Settings und History erstellt, Benutzereingaben aus dem View ans QuestionViewModel und dann von da aus an das Model übergeben, Commands mit ICommand implementiert, Dokumentation erweitert |
| Dieses Wochenende erledigte Aufgaben des Backend-Entwicklers:* |
|---|
| tasks: |
| Dieses Wochenende erledigte Aufgaben des Datenbankspezialisten:* |
|---|
| tasks: |
| Protokollnummer: | 10 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 24.04.2017 - 25.04.2017 |
AS-Blöcke:
- 24.04.2017
- 25.04.2017
| Diese Blöcke (bzw. nach der Schule) erledigte Aufgaben des Frontend-Entwicklers:* |
|---|
| tasks: (Schule: HTML und CSS, neues Projekt ToDo-Liste begonnen, JQuery eingebunden) Zuhause: Projektplanung und Zeitplan aktualisiert, User in Datei gespeichert, User aus Datei geladen, Dummy-Fragebogen erstellt, Models Questionaire + Question + Answer erwitert, User und History fürs Speichern erweitert, Vor- und Zurück-Buttons für Navigation eingebaut |
| Diese Blöcke (bzw. nach der Schule) erledigte Aufgaben des Backend-Entwicklers:* |
|---|
| tasks: Verbindung Backend zur Datenbank herstellen |
| Diese Blöcke (bzw. nach der Schule) erledigte Aufgaben des Datenbankspezialisten:* |
|---|
| tasks: Verbindung Backend zur Datenbank herstellen |
| Protokollnummer: | 11 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 26.04.2017 - 27.04.2017 |
AS-Blöcke:
- 26.04.2017
- 27.04.2017 (Präsentation)
| Diese Blöcke (bzw. nach der Schule) erledigte Aufgaben des Frontend-Entwicklers:* |
|---|
| tasks: (Schule: 26.04.2017: Zuhause geblieben, um Projekt rechtzeitig fertigzustellen - Schule: 27.04.2017: Projekt Zuhause weiter fertiggestellt, krank) Zuhause: Fragen aus Fragebogen generiert, Fragen vor u. zurück navigierbar, Wrap zu unbeantworteter Frage, Navigation u. Darstellung Auswertung am Ende, Bilder im View einbinden, Kanban-Board-Screenshot für Doku gemacht, Commit-History-Screenshot für Doku gemacht |
| Diese Blöcke (bzw. nach der Schule) erledigte Aufgaben des Backend-Entwicklers:* |
|---|
| tasks: Dummy Questionaire mit Constructor aus DB ersetzen |
| Diese Blöcke (bzw. nach der Schule) erledigte Aufgaben des Datenbankspezialisten:* |
|---|
| tasks: Fragebögen aus Datenbank auslesen, zweite Datenbank einbinden |
| Protokollnummer: | 12 |
|---|---|
| Klassenbezeichnung: | FA54 |
| Gruppenname (Zahl): | 2 |
| Datum: | 28.04.2017 - 15.05.2017 |
Freizeit-Blöcke:
- 28.04.2017 - 14.05.2017
- 15.05.2017, 23:55 Uhr (Abgabe)
| Diese Blöcke (bzw. nach der Schule/Arbeit) erledigte Aufgaben des Frontend-Entwicklers:* |
|---|
| tasks: Auswahl der Fragebögen aus Dropdown-Liste ermöglicht, User Klasse für Fragebogenauswahl erweitert, Dokumentation erweitert, Debug-Fragen-Limit in den Settings hinzugefügt, User lokal speichern und wieder laden, Darstellung der History, Löschen der History, Bugfix Kalkulation der Ergebnisse, Code Cleanup (Master und MainviewModel Klassen entfernt), Abgabeversion (bis auf optische Fehler) fertiggestellt |
| TODO: |
| --- |
| optische Bugfixes (WordWrap zu lange Fragen und Antworten, Layout für variable Bildschirmauflösungen optimieren, Antwortenliste scrollbar, Klick auf Antwort wählt Radiobutton aus, Fragenummern +1 in Display, Newlines am Antwortenende entfernen, etc.), Debug-Settings wieder ausbauen (limitiere Fragen auf n mit Eingabefeld in Settings, etc.), Refactoring und Code-Cleanup, Push-Script zum Testen erstellen, Unit-Tests schreiben, Test-Coverage dokumentieren, neues UML-Diagramm der App erstellen, Doku beenden, Projekt abgeben, JS und JQ Aufgaben lösen, JS und JQ Aufgaben abgeben |
| Diese Blöcke (bzw. nach der Schule/Arbeit) erledigte Aufgaben des Backend-Entwicklers:* |
|---|
| tasks: |
| Diese Blöcke (bzw. nach der Schule/Arbeit) erledigte Aufgaben des Datenbankspezialisten:* |
|---|
| tasks: |
| TODO: |
|---|
| tasks: weitere Funktionalität herstellen (Fragebogen IDs aus DB wählen und in User initialisieren, Darstellung der History, Datenbank wechseln), optische Bugfixes (WordWrap zu lange Fragen und Antworten, Layout für variable Bildschirmauflösungen optimieren, Antwortenliste scrollbar, Klick auf Antwort wählt Radiobutton aus, Fragenummern +1 in Display, Newlines am Antwortenende entfernen, etc.), Debug-Settings wieder ausbauen (limitiere Fragen auf n mit Eingabefeld in Settings, etc.), Refactoring und Code-Cleanup, Push-Script zum Testen erstellen, Unit-Tests schreiben, Funktionalität der anderen Datenbank-Fragen in App herstellen, Test-Coverage dokumentieren, neues UML-Diagramm der App erstellen, Doku beenden, Projekt abgeben |
* TODO: Insert Meinung über die Unterrichtsmethoden / Zeitplanung / Teamarbeit (ganzes Projekt in AS-Blöcken zu schaffen? Backend-Models mit Verbindung zur DB erst einen Tag vor Abgabe) / usw. hier
- Create issues for tasks.
- Add labels and assign someone to issues.
- Add issues as cards to new.
- Create a local working branch for an issue assigned to you.
- Move the card to in progress when you work at it.
- If your work is done, move the card to test.
- Write some tests and test your code.
- If a feature is reasonably tested, move the card to review and create a pull request for your branch.
- After reviewing the branch in the pull request is finished the card can be moved to done.
- We'll regularly merge all pull requests for cards in done with the master adding the following to the merge message using the issue number like this #11 to reference and close it:
fix <#issue> - Then delete the merged branch, switch to the local master branch and pull the updated master to our local master branch.
- Now create a new working branch from the updated local master and start working on another issue.
Clone the project locally...
git clone <url>
...or pull the master when new changes of a contributor have been merged to it. Make sure you are in your local master branch.
git checkout master
git pull origin HEAD
Then check out a new working branch.
git checkout -b <branchname>
Make your changes. Then add your changes to the working branch.
git add --all
Now commit the changes and give a short description of what you have done in the message.
git commit -m "<message>"
Then push the commit of your working branch to the project repository.
git push origin HEAD
The code will be reviewed by us regularly and if all is well and the tests were green the working branches will be merged into the master. Rinse and repeat.
To work in this way you need to merge your changes locally into the local master and then push this updated master to the remote running the test suit in the process. Finish your changes in your local branch, switch to the local master, pull the remote master into it (to add all possible changes made by other members of the team), then merge your branch into your master and resolve all conflicts that may occur. Only then push your updated local master back to the remote master at github. If you know (or research) how to do this you should be good to go. If not, stick to the workflow described above.
If you know what you are doing you may push your merged commits directly to the master if you are using the continuous integration script. This scrip will hook into the git push command and first run all the unit tests of our project and if a test fails (i. e. you broke something or the tests need to be improved further) will exit and stop the push. You then can try to fix either your code or the tests to push to the master, or you just check your changes out to a new branch and push that, so we all can have a look at the problem and try to fix it.
TODO: Describe this better.
- write a failing test
- write code/refactor it until test is green
- update tests or write another failing test for a new feature
- rinse and repeat
You can view all branching commits with a fancy ascii graph in your console with:
git log --graph
You can view all your local branches with:
git branch
If you pull the recent master after your working branch has been merged, you can show merged local branches with:
git branch --merged
And then you can delete merged local branches with:
git branch -d <branchname>
If a working branch is obsolete but not merged with the master you can force-delete it with:
git branch -D <branchname>
Styling information for the README.md can be found here.
You can create a new table of contents from the html-headers of the chapters in this README.md file in your console with the included golang script. Just execute it in your git bash by running:
./gh-md-toc README.md
Then copy and paste the output into the space where the old Table sits, shift + tab it to the left side and save the updated README.md file. Then commit the changes to github.
Make your life easier with these handy shortcuts while working in visual studio:
Enter the following, followed by a double tab. You'll get a quick Console.WriteLine(); for debugging your code. For our application you should rather use Trace.WriteLine() or Debug.WriteLine() and set a breakpoint on the same line, though.
cw
Type the following, followed by a double tab to create a standard constructor for the class you currently write in.
ctor
Want to use a private List<T> somename without first looking up and including the needed collections namespace? Just write the name or command and when visual studio complains about it (with a red wiggly line under the word) press the following key combination (control and dot) to quickly open up and select from the quick actions menu. Do that by hitting enter. There's your using System.Collections.Generic;. And the compiler warning is gone.
"CTRL" + "."
Want to implement an interface in your class? Maybe inherit from ICommand? Just write its name next to the classname, like you would normally do. Then do the previous shortcut again and rid yourself of the initial compiler warning, adding the namespace. You're still not satisfied? Hit control and dot once more followed by enter. And thereyou are, your basic interface has methods, ready to throw NotImplementedException() exceptions. Pretty neat.
"CTRL" + "."
I'm sure there's more. Feel free to also add your own favorite little time savers here, so all of us can share them.
“It's so quiet this high up, the feeling you get
is that you're one of those space monkeys.
You do the little job you're trained to do.
Pull a lever. Push a button.
You don't understand any of it, and then you just die.”
Chuck Palahniuk, Fight Club