pa165-java's People
pa165-java's Issues
Facade Implementation Rules
- Everything that should happen in the system must be available through these interfaces (create entities, deleting them etc);
- Other points about the Facade and Service layers:
- All the classes must be wired via dependency injection. Your service objects should obtain an instance of the EntityManager that way;
- All the facade interfaces must not reference entities, but Transfer Objects only;
- All service interfaces must reference only entities, not Data Transfer Objects;
- You can use Dozer framework to map entity instances to transfer objects. The mapping may be done on Facade Layer;
- Facade layer is used to drive transactions;
- Facade layer will use Service layer and Service layer will use DAO layer;
Milestone 1 requirements
- create a project in a Github repository that is publicly accessible (for read) choose a short and descriptive name. Create some project wiki to publish other information for your project.
- on the project wiki there will be a project description, a use case diagram and a class diagram for entity classes. There will be at least two user roles in the use case diagram. Associations between entities will be present in the class diagram.
- create 4 entity classes for your project.
- create a DAO layer interface (with proper javadoc).
- create the JPA implementation of the DAO classes (CRUD operations are enough for the first checkpoint).
- create unit tests for DAO classes (use in-memory database).
- every team member should work with different entities on different parts of the project (e.g. member 1 will create implementation of DAO for entity A, but member 2 will create unit test for entity A). In every class there will be javadoc @author with the name of the class author. Also you must commit into Git only the changes that you made yourself. If you commit on behalf of somebody else this will not be regarded as his work!
- the project will be built using maven, and make sure you have all dependencies correctly configured, so it is possible to build it using just the command line.
Unit Tests for Service Layer
It is vital to have extensive unit test coverage for service layer. All the test should contain mocked DAO objects!
- getTotalKilometers method
- getAllJourneys method
- others
Make the repoitory public or move it elsewhere
Lecturers / tutors require us to have a repository easily accessible by all member of the course, because we will be doing peer reviews (see notes to Milestione 1). We could either make this repository public (I have nothing against it) or move it to the school server http://gitlab.fi.muni.cz
User Interface
- To start the web application you have to configure maven plugin (tomcat7 or jetty). It is very important that it’s super easy to start the web application from command line. So for example using tomcat7 plugin, the following sequence of commands should start the web application: “mvn clean install && cd web && mvn tomcat7:run”
- The web application must be available on the following HTTP context http://localhost:8080/pa165
- Your application should use in-memory database. This means that after application restart (killing web container and starting it again with mvn tomcat7:run) the data may be reset.
- Implement the user interface using Spring MVC or Angular JS.
- The user interface should allow to carry out all business functions of your system.
- You should fill in all the necessary data automatically. So for example you can use Web Listener to load data during Web Application startup.
- Make sure there are validations implemented on user interface.
- Your user interface should use either Facade layer or REST layer to access the system. Do not directly access database and do not directly use Service layer.
- The web interface layer may reside in separate maven module (if this is helpful).
- Each member of the team must implement (mostly independently, without copy-pasting) part of user interface. Including controller and view.
some bugs and todo
- (TODO) implement create, update, delete/disable operations from web
- (TODO) Serviceman -> Add InspectionInterval (#404)
- (BUG) Serviceman -> vehicle detail (#500 Null pointer exception) => (maybe?) Inspection intervals for individual vehicle do not display in vehicle detail (under serviceman menu)
- (BUG) available vehicles not shown for logged user but for user id 1 (hardcoded in line 44 template.tag)
Service - getAllJourneys
Create method getAllJourneys(Date from, Date to, double employeeId):List(). This method will search for all journeys within given time span and with given employee ID.
Move diagrams used in Wiki to external Gist
Now, they are part of the source code, more specifically dev
branch. Should be the diagrams part of this repository, or we should create a separate one (aka Gist)? What do you think?
Unit Tests for Facade Layer
We should implement simple unit tests for Facade layer. One simple test per method. Just to prove the facade works.
REST layer
- Your application should have a basic REST interface.
- At least one entity and operations on that entity must be exposed.
- This is mainly to demonstrate you can implement this, it’s not necessary to have all application functions accessible through this interface.
- The REST must be accessible at http://localhost:8080/pa165/rest
- it is not required to have the interface secured.
- You should include a README file with instructions how to test the REST interface (e.g. CURL commands for command line).
Switch to GitHub flow from the Git flow
On the last meeting, we have agreed to use some kind of Git flow instead of GitHub flow, i.e. use dev
branch as the main branch and master
branch for the stable releases. I have told you, that I don't care whether the branch on which are we working on is actually called master
or dev
, but I changed my mind.
-
GitHub interface is suited for GitHub flow rather than GitFlow. Perfect example is that if you open the project, you are by default on
master
branch rather thandev
branch, which is for us as developers much more interesting. Another issue is that if we stick to the Git Flow, we will seeCompare & Pull Request
on thedev
branch.
-
I believe that Git flow is more for the bigger teams with separate roles, as Developers, QAs, testers and so on.
I suggest to switch to the proper GitHub flow, i.e. use master
as most up-to-date branch, pull requests for merging code into master
and tags for stable releases.
Read more about diffence between Gitflow and GitHub flow for instance here: https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/
Service - getTotalKilometrage
Create method getTotalKilometrage(double vehicleId):double. This method will sum init state of tachometer and all rides for given vehicle. Return value is total kilometers.
Make project multimodule
Change layout of your project to Multimodule Maven project (tutorial here http://maven.apache.org/guides/getting-started/index.html) Your project should have 3 separate modules:
- DAO layer
- Service Layer and Facade Layer implementation
- API layer - just DTOs and facade interfaces!
Services for entities
create all services for DAO classes
Journey - contraints
Single journeys with same vehicle should not cover.
Implement Facades
TASK: Select an Actor and the use case from the Use Case Diagram and implement it using Facade. You will also need to implement appropriate service(s) and extends DAOs (and eventually also entities) accordingly.
Assigned work:
- - Employee facade - @JozeFe - PR #39
- - Journey facade - @msmidik - PR #40
- - Vehicle facade - @Qerts - PR #41
- - Inspection facade - @trebi - PR #42
DEADLINE: Thursday evening.
Before you start working, please write here to the comments, or to the Slack, which facade and which use cases will you implement. Remember, we need to implement at least two non-trivial use cases, fully cover our services with unit tests (mocking DAOs), be aware of exceptions: services should work only with DataAccessException
s; and finally implement some really simple (unit? integration?) test for facade.
Here is the drawing with my proposal of possible facades and their methods:
Tasks after seminar on 18th of October
- Everyone - create at least one EntityDao.
- Everyone - create at least one test for EntityDao, which is not his own
- @JozeFe - Design general Dao and create one Entity and Entity's Dao. Entity: Employee
- @msmidik - Look on a way to design repository for some existing Entity, e.g. http://docs.spring.io/spring-data/data-commons/docs/1.6.1.RELEASE/reference/html/repositories.html Entity: Vehicle + VehicleCategory
- @trebi - Set up test framework, create one Entity and Tests for it using in-memory database. Entity: Journey, DaoTest: Employee
- @Qerts - Entity: InspectionInterval + Inspection
Set up Travis-CI
Set up Travis-CI, so it "runs mvn package" on any pull request made to branch "dev" (ideally, with merge still allowed when build fails) and to branch "master" (ideally, mege should not be possible until build passes).
Submit evaluations of other teams
Evaluation Checklist:
- You can assign maximum 10 points to the project you are reviewing.
- -3 points if it is not possible to compile the project using “mvn clean install”. You must either make this work or ask the team to fix this ASAP because it’s hard to check the code without this.
- -1 point for each minor occurrence of a team member not contributing enough.
- -1 points for incorrectly implementing equals/hash code.
- -1 points for every minor occurrence of missing methods/tests (e.g. missing important method on a DAO object or a missing test for that method).
- If a team member was not contributing at all, or very little, you should explicitly say this in your evaluation report. Tutor will follow up on this information.
Each member evaluates a project of another team. To find out which project do you evaluate, check:
https://docs.google.com/spreadsheets/d/193LHasHryuDqN60cBUvBN8iH74GZgc7AQRreKV7FJKo/edit?usp=sharing
Proper exceptions in DAO layer
Make sure that DataAccessException or its subclass is thrown in case of any exception on a the DAO layer.
- Employee
- Inspection
- InspectionInterval
- Journey
- Vehicle
- VehicleCategory
Security
- There should be at least 2 roles in the system (e.g. Administrator, User). Each role should have some differences in user interface or in capabilities.
- There should be login form (not HTTP Basic)
- Registration is NOT required. You can prefill the users and their passwords in the database.
- Password should not be saved in the database in open form.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.