Enterprise Java Development@TOPIC@
Gain experience designing and testing project implementations around layered boundaries.
Build the data access tier and initial business logic for an application.
Gain experience with database schema and Java Persistence API technologies.
Design and implement a set of business logic interfaces that address the functional requirements of the external users.
Design and implement a set of business objects to represent the data requirements in the system.
Design and implement a relational database schema that will store the state of the business objects.
Design and implement a data access tier that will handle mapping the business objects to the database using the Java Persistence API.
Design and implement the business logic classes that realize the business logic interfaces and leverage the data access objects to implement the scenario logic.
Unit test the different levels of the architecture.
Integration test the end-to-end solution according to a defined scenario.
eLeague is planning an on-line league site that will allow league coordinators to organize teams into divisions, schedule contests, and track scores. At the same time, eClub is planning an on-line club management site that will allow clubs to organize players, coaches, and managers into teams. eClub is designing their software such that it can be used with eLeague.
For eLeague, the coordinator starts by adding clubs and their primary point of contact. Venues and Teams are added to the league by club coordinators. Contacts (e.g., coach(s), manager(s), etc.) are added for teams. Prior to the start of the season, the league will create a new set of divisions and assign teams to the appropriate divisions for that season. Divisions are arranged by group (e.g., U11, Bantam, Masters, etc.) and level (e.g., AA, A, 1, 2, etc.). The league will then schedule contests for each division, matching a home and away team with a venue from the home team's club. For simplicity, we'll assume that the venue is exclusively available for scheduling by the league, but the league still must manage scheduling conflicts for the venue contests within the league. Scores are added for the home and away team after each contest. A team schedule and division standings will be generated from the information.
For eClub, individuals register with the site, supplying basic information. For simplicity, we'll keep eClub to minimal information. The individuals can be players or parents and/or coaches. There is additional information tracked for players and coaches. Players will need a position and jersey number. Coaches need a certification number. Parents/guardians will need no further information. After tryouts, the club will create a set of teams and assign a head coach, a manager, and players. The team and team points of contact will be used to form a registration with eLeague. From the club site, a team can get roster information, game schedules, and division standings. The schedules and division standings are obtained from eLeague and and are not duplicated within eClub to make sure they are up to date.
Both eLeague and eClub have come to you to develop the initial phase of their applications. You are tasked with implementing a low-cost prototype, based on current standards, to automated much of this activity. At this point in the project we are primarily looking to build the data access tiers for both eLeague and eClub (two separate systems). We will also add a minor amount of business logic to coordinate the data access between the individual data access objects.
For eLeague, the system is initialized with a starting set of information pertaining to clubs (league's external view), contacts, venues, and a season defined with divisions and teams. New information can be added and updated.
For eClub, the system is initialized with an empty database that is designed to hold internal club information for teams, coaches, and players. The teams will be assigned a division within the league and individuals associated with the team will be interested in seeing scores and standings relative to their team.
The work done during this project focuses on the business objects (BOs), the data access objects (DAOs) of the data access tier, some initial business logic interfaces (BL), and business logic implementations (BLImpl). The DAOs will be based on the Java Persistence API (JPA). How you partition the implementations of your projects is up to you. A candidate starting point is provided at the end of this project description.
There will be many choices while creating your solution to the two applications. It is intended that you always approach the eLeague application as "it is hard" and requires extra formal layers. To provide contrast, it is intended that you always approach the eClub application as "it is simple" and target as many simplification and shortcuts in the architectural layers as you can find. The point of this is for you to gain experience with the different approaches and to not make eClub a tedious clone of approaches taken in eLeague. The spec will describe both in a similar manner, but you should apply more of a "right approach" based on what was just stated.
The business objects encapsulate the core business data and rules of the application. You will design the business objects and then map them to the database. You are required to implement CRUD (Create, Read, Update, and Delete) capability with JPA but you only need to implement the CRUD methods that are necessary to complete the provided end-to-end scenario. You will be required to encapsulate all object to relational (O/R) mapping within the DAOs, descriptor files, and/or class metadata annotations. You will be given a set of test data to initially populate your applications and be the source of data for the ingest requirement. To use the data, you will ingest using a parser supplied by the instructor. There is a sample thread in the projects/eSport/eLeague directory that shows how to use the parser as well as other aspects technology within the project.
The database will have a functional schema and indexes to provide query performance. Business objects will be validated in the database using schema constraints and within the JVM using the Validation API.
The business logic will provide a set of classes with concise methods that map easily to the provided end-to-end scenario. The business logic will ensure proper use of the overall application, delegating some business logic functionality to the business objects and full O/R responsibility to the DAOs. eLeague will have an ingest requirement as well as the requirement to manipulate and add to what was ingested. eClub will start fresh and obtain all data from users and coordinate with eLeague. However, for project 1, eClub will be unable to fully implement data exchange with eLeague because remote interfaces will not be implemented until project2. Some of that must be stubbed at this point. You are only required to implement enough business logic methods that it takes to implement the end-to-end scenarios specified later within this specification.
The test acceptance for the first project will be the unit tests and an integration test that takes the business logic, data access tier, and business objects through a provided end-to-end scenario that will be consistent during the semester. You are required to supply the following tests:
A unit test that implements the steps of the provided eLeague end-to-end scenario
A unit test that implements the steps of the provided eClub end-to-end scenario
At least one unit test per architectural layer (BO, DAO, BL) that demonstrates your ability to test at that level.
The amount of work that you can implement within the bounds of this project spec could be endless if you attempted to account for everything and anything. It is very important that you limit your work to only what is necessary to implement (and test) the functionality required for the end-to-end scenario. That means you may have entities that are designed to be created but never modified while having other entities that go through a full lifecycle. When deciding to add or skip certain capabilities -- always ask yourself "does the business logic need this behavior to implement the end-to-end scenario".
Since the work is for separate applications, we will need to establish two separate application projects for this work; eLeague and eClub. The development can physically share resources (e.g., same database and application server), but should be easily separated. It is suggested that you form a root for the overall eSport work to coordinate integration testing, and then group the lower-level work under two mid-level projects; eLeague and eClub. See some suggested project layouts at the bottom of this specification. A sample set of projects that implement a thin eLeague thread has been made available. Please ignore the sibling eSportData project when using the example to craft your source tree. You will depend on projects within the sibling data tree -- not re-implement them and not copy them. See the Getting Started section towards the end of this specification for a more detailed sample project layout.
You will likely copy significant portions of the thin thread example and other class examples into your project. Be aware that the thin thread and other example pom.xml files inherit from the class root project that provide dependencyManagement and pluginManagement duties. You will either need to also inherit from the course dependencies/pom.xml or compensate by re-defining the management sections in the root pom.xml of your project.
Since students in the class will be producing parallel implementations for the applications and submitting them for evaluation, it is asked that you come up with unique names for your artifacts. This could be done by replacing the "e" in eSport, eLeague, and eClub with a unique name that corresponds to your newsgroup or college login (ex. jcsMarket, jcsSales, jcsBidbot). You should also use this same pattern for java packages (ex. jcs.sales, jcs.bitbot), DB tables (e.g., JCS_), etc.
There should be no use of System.out.println() in the code and all implementations must use a logging API with log4j as the logging provider. You may leave debug in your code, but this should be able to be turned on/off with the proper logging priority changes in the log4j.xml configuration.