Project1: eSport Data Access Tier and Initial Business Logic

2013-09-08 DRAFT

Goals

  • Build the data access tier and initial business logic for an application.
  • Gain experience with database schema and Java Persistence API technologies.
  • Gain experience designing and testing project implementations around layered boundaries.

Objectives

  • 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.

Business Description

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.

Technical Overview

The work done during this project will focus 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 into separate physical sub-modules is up to you. A suggested starting point is provided at the end of this project description.

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 full CRUD (Create, Read, Update, and Delete), capability with JPA. You are required to encapsulate all object to relational (O/R) mapping within the DAOs, descriptor files, and business object 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 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 use cases. 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 coordinate with eLeague for content. However, for project 1, eClub will be unable to fully implement interactions with eLeague because remote interfaces will not be implemented until project 2. 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 a set of unit tests and at least one functional test that takes the business logic, data access tier, and business objects through an end-to-end eLeague and eClub use case starting with the addition of a club to the league and completing with games be scheduled, scores being reported and standings being reported.

Assembly Overview

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 child 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 eSportData sub-project when using the example to craft your source tree. You will depend on projects within that tree -- not reimplement them and not copy them.

See the Getting Started section towards the end of this specification for a more detailed sample project layout.

Note:
Since the class will be producing parallel implementations for the applications and submitting them for evaluation, it is asked that you replace the "e" in eMarket, eSales, and eBidbot with a unique name that corresponds to your newsgroup or college login (ex. ejavaguyMarket, ejavaguySales, ejavaguyBidbot -or- jcsMarket, jcsSales, jcsfBidbot). You should also use this same pattern for java packages (ex. ejavaguy.sales, ejavaguy.bidbot -or- jcs.sales, jcs.bidbot), JNDI names, DB tables, etc.
Note:
There should be no use of System.out.println() in the code and all implementations must use a logging API with log4j 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.

Technical Details

Note:
Project development can take either a database-first or business-object first approach. The database-first approach simulates integration with a legacy database or development of an application with a very database-centric solution. The business object-first approach simulates a green-field implementation that has more modest database requirements. Whichever technique you chose is up to you, but the two must integrate in the end.
Note:
There are a lot of technical details presented with this specification. This is done to provide clarity and a starting point for design discussion. However, it is not done so to specify specific class or method naming, project layout, or order of work. You are free to make many technical adjustments to the ideas presented.
  1. Design 2 sets of database schema that account for the following information. Although we will deploy the 2 database schemas to the same database for the project, they should be designed to be independently deployed to separate databases. eLeague and eClub are two independent applications. This will primarily affect your attempt re-use tables or to make primary key assumptions between the two.
    1. eLeague Candidate Database SchemaeLeague Database Schema
      1. ELEAGUE_LEAGUE - this table is used to store singleton information for the entire application. Although JPA requires a primary key field, this table should have only one row. Right now, it is being depicted as referencing the current season.
        • LEAGUE_NAME - unique name for the league that will not change. It can be used as a primary key.
        • SEASON_ID - (1 to 0..1 relation to ELEAGUE_SEASON) - this references the most current season and will be NULL before the start of the first season.
        • COORDINATOR_ID - (1 to 0..1 relation to the ELEAGUE_CONTACT) - designates the overall coordinator for the league. They will be responsible for adding clubs, forming divisions, and scheduling contests.
      2. ELEAGUE_CONTACT - design a table that contains POC information for individuals responsible for the league, divisions, and teams. This information is primarily on-line information and need only contain a textual name and an e-mail address. There is no need for any more detailed information and we don't want to expose phone numbers.
        • ID - this is an artificial field to identify the contact.
        • CONTACT_NAME - this is a required, non-unique textual name for the individual. This will be posted the league site and can be updated.
        • EMAIL - this contains the e-mail contact information for the individual that will be posted to the web site. It its highly recommended for optimal operation of the league, but may not be available when contacts are initially entered. We should not treat this field as unique since family members have been known to share the same league e-mail address.
        • LOGIN - this is a field that can be used to represent the individual's login to the web site. This field is not required. However, if it is not supplied, it is assumed that they will not be personally accessing the site. This field can be updated, thus it would not work well as a primary key.
      3. ELEAGUE_SEASON - design a table to store the name and core information associated with a season. Seasons will never be removed as a part of normal operation.
        • ID - the unique ID for the season. This value is required, must be unique, and cannot be changed. It can be used as a primary key if desired. It can be a natural value (e.g., Fall2000) or an artificial value.
        • SEASON_NAME - the textual name for the season (e.g., "Fall 2000"). This value is required and must be unique. It could be used as a primary key if desired, but is thought to be more of a textual value that may require modification.
        • START_DATE
        • END_DATE
        • LEAGUE_ID - (N:1 relation to ELEAGUE_LEAGUE). This relationship allows all seasons to form a DB relationship to the league.
      4. ELEAGUE_DIVISION - design a table that represents a division for teams, for a single season. Divisions will be arranged by group (i.e., age) and level of play. Since group/level names cannot be relied on for any specific ordering, you may wish to add a competitive rank property (11, 21, 22, 23 might equate to U11-D1, U12-D1, U12-D2, U12-D3 with U11 and U12 being a group and D1, D2, and D3 being a level).
        • SEASON_ID - (N:1 relation to ELEAGUE_SEASON)
        • GROUP - a name for a class of teams, such as an age group (e.g., U11, Bantam, or Masters). This is required and does not change.
        • LEVEL - a name for the competitive level of play (e.g., DI, DII -or- AA, A, B, etc.)
        • COORDINATOR_ID - (N:1 relation to ELEAGUE_CONTACT) - this individual will be responsible for updating scores for contests within the division.
        • COMP_RANKING - a value that can be used to sort divisions by their competitive ranking rather than an ASCII sort of their group and level names.
      5. ELEAGUE_TEAM_SEASON - design a table that represents a team's participation in a division for a season.
        • TEAM_ID - (N:1 relation to ELEAGUE_TEAM) - a team will participate in 0 to many seasons and we will keep historical information of the teams from season to season.
        • SEASON_ID,GROUP,LEVEL - (N:1 relation to ELEAGUE_DIVISION) - a team will participate in only one division per season.
      6. ELEAGUE_TEAM - design a table that represents a team over time. We are interested in tracking points of contact for the team and divisional play. We do want to keep current and historical division play, but do not need to keep historical contact information.
        • ID - an artificial id for the team
        • TEAM_NAME - each team must have a name, but it need not be unique
        • CLUB_ID - (N:1 relation to ELEAGUE_CLUB) a team must belong to a club.
      7. ELEAGUE_TEAM_ROLE - design a table that describes the role played by a contact for a team. Contacts are usually a manager or coach. You can have multiple contacts for a specific team and they can even have the same role (e.g., someone can be coach and manager and two people can be a (assistant?) coach). However, no one can have multiple roles of the name type for a single team (e.g., you can be manger for 2 teams, but you can't manage the same team twice). Therefore we have the option of forming a compound primary key out of the role name, contact foreign key, and team foreign key.
        • ROLE_NAME - contains the type of role the contact plays for a team (e.g., manager, coach). This value is required and will not change.
        • CONTACT_ID - (N:1 to ELEAGUE_CONTACT). This reference is mandatory and will not change.
        • TEAM_ID - (N:1 to ELEAGUE_TEAM). This reference is mandatory and will not change.
      8. ELEAGUE_CLUB - design a table that represents a club for teams.
        • ID - an artificial primary key value
        • CLUB_NAME - the textual name for the club. This value must be supplied, may be changed, and must be unique.
        • REP_ID - (N:1 to ELEAGUE_CONTACT). This reference supplies the contact information for the club rep.
      9. ELEAGUE_VENUE - design a field that represents a venue for holding contests. Venues are owned by a club, but are given to the league to control their scheduling. Other than scheduling, the key information is to provide map, direction, and other information that would be helpful for visiting teams to locate the venue.
        • ID - this is an artificial value to identify a venue.
        • CLUB_ID - (N:1 to ELEAGUE_CLUB)
        • VENUE_NAME - a textual name used to identify a venue (e.g., YaYa park, field #3)
        • ADC_PAGE - this is a text field containing the ADC map, page, and grid where the venue is located.
        • DIRECTIONS - this is provided by the club and may be updated to reflect current direction information. Some clubs even add information about whether pets are allowed or whether there are bathrooms are available on-site.
        • ADDRESS_ID - (N:1 to ELEAGUE_ADDRESS) - this is required.
      10. ELEAGUE_ADDRESS - design a table to hold an address. Although it could be used for anything, it will primarily be used for people attempting to locate a venue by address information using Google Maps or their GPS Navigation.
        • ID - this is an artificial value to identify a specific address
        • STREET1
        • STREET2
        • CITY
        • STATE
        • ZIP
      11. ELEAGUE_CONTEST - design a table to hold contest information. Contents are scheduled at venues for a home and away team. They are for a specific date, start and end time, and should never overlap with another contest for the same venue. Contests are always for teams in the same division.
        • ID - this is an artificial value to identify a specific contest.
        • START_TIME - identifies the time of day the contest will start. This field may not be known when the contest is first identified or post-poned, so it is not required.
        • DURATION - identifies the amount of time allocated to the contest and can be used t determine the end time.
        • VENUE_ID - (N:0..1 relation to ELEAGUE_VENUE) This relationship may not be known when the contest is first identified or post-poned, so it is not required.
        • HOME_TEAM_ID - (N:1 relation to ELEAGUE_TEAM_SEASON) This relationship is required. Note that it is related to the team's season and not directly to the team's table.
        • AWAY_TEAM_ID - (N:1 relation to ELEAGUE_TEAM_SEASON) This relationship is required. Note that it is related to the team's season and not directly to the team's table.
        • SEASON_ID, GROUP, LEVEL - used to complete the compound foreign key values to the home and away teams. Since teams must be in the same division, we should be able to reuse these columns to enforce that rule.
        • HOME_SCORE - score for home team to be updated by the division coordinator.
        • AWAY_SCORE - score for away team to be updated by the division coordinator.
    2. eClub Candidate Database Schema eClub Database Schema
      1. ECLUB_INDIVIDUAL - design a table to contain information associated with an individual in the club.
        • ID - this is an artificial value used to identify an individual.
        • FIRST_NAME - this should be required, but may be updated
        • LAST_NAME - this should be required, but may be updated
        • EMAIL - this is optional
        • LOGIN - this is optional. Users without a login cannot login to update their information.
      2. ECLUB_PARENT_CHILD_LINK - design a table to hold a many-to-many link table representing parent/child relationships between individuals in the club.
        • CHILD_ID - (N:1 relation to ECLUB_INDIVIDUAL)
        • PARENT_ID - (N:1 relation to ECLUB_INDIVIDUAL)
      3. ECLUB_PLAYER - design a table to hold information specific to a player.
        • ID - (1:1 relation to ECLUB_INDIVIDUAL). This is both a primary and foreign key value.
        • JERSEY_NO - this is optional and can be updated over time.
        • POSITION - this is optional and can be updated over time.
        • DOB - this is the date of birth for the player used to help assign a player to a pool of teams. It is required, but may need correcting over time.
      4. ECLUB_COACH - design a table to hold information specific to a coach.
        • ID - (1:1 relation to ECLUB_INDIVIDUAL). This is both a primary and foreign key value.
        • CERT_LEVEL - this is optional and can be updated. It will have values like 1, 2, 3, etc.
        • CERT_NO - this is optional and can be updated. It will contain their coaching certification number.
      5. ECLUB_TEAM - design a table to hold information specific to a team within the club. Note that historical information for teams is not kept from season to season. For simplicity, we will only assign a single head coach (no assistant coaches). Note also the information below is internal to EClub. You may want to include an indentifer the league tracks this team by and store it here for querying the league about the team.
        • ID - this is an artificial value used to refer to a specific team.
        • TEAM_NAME - this is a required field used to hold a textual name for the team. It can be updated.
        • LEAGUE - this is an optional field that can be updated over time. It will identify which league they are playing in.
        • GROUP - this is an optional field that can be updated over time. It will identify which grouping the team is playing within a league (e.g., U11 or Bantam).
        • LEVEL - this is an optional field that can be updated over time. It will identify the level of play within a group (e.g., D1, D2).
        • MANAGER_ID - (N:0..1 relation to ECLUB_INDIVIDUAL). This is optional and can be updated over time.
        • HEAD_COACH_ID - (N:0..1 relation to ECLUB_COACH). This is optional and can be updated over time.
        • LEAGUE_TEAM_ID - This is an optional field that will get updated once the team is registered with the league. Since the League and Club databases are separate, we cannot re-use IDs between them.
      6. ECLUB_PLAYER_TEAM_LINK - design a table to hold the many-to-one linkage between players and teams. Teams have multiple players and we'll limit players to only one team so far. If we model this as a link table, it will be easier later on to allow a player to be on multiple teams.
        • PLAYER_ID - (N:1 relation to ECLUB_PLAYER)
        • TEAM_ID - (N:1 relation to ECLUB_TEAM)
      7. ECLUB_ECLUB - design a table to hold core club information.
        • ID - this is an artificial value used to refer to the club
        • CLUB_NAME - this is a required field that can be updated.
  2. Design a set of business objects to represent the data in the system.
    1. eLeague Candidate Business ObjectseLeague Business Objects
      1. Contact - design a class that encapsulates the points of contact in the system. This information will primarily be used to post point of contact information for teams, divisions, clubs, and the league to the web site.
        • id:long
        • name:String - textual name for individual to be known as.
        • email:String
        • login:String - may be assigned for individuals to login and be able to modify team, division, and contest information that they are responsible for.
      2. ContactRole - design a class that can be used to wrap a Contact for points of contact where their role must be qualified. This is the case for team points of contact where the individual can be one of manager or coach.
        • roleName:Enum(UNKNOWN, MANAGER, COACH)
        • contact:Contact
      3. Venue - design a class that holds information for a venue. It is shown as being as being made up of an embedded Address class, where the address class holds no primary key of its own. You may map the 2 table in alternate ways.
        • id:long
        • name:String
        • directions:String
        • adcPage:String
        • address:Address
        • club:Club
      4. Address - design a class that represents a location that can be driven to. This is being depicted as an embedded class, with no primary key value of its own. You may map it in other ways.
        • street1:String
        • street2:String
        • city:String
        • state:String
        • zip:String
      5. Club - design a class that represents a Club and all of its venues and teams.
        • id:long
        • name:String
        • teams:Collection<Team>
        • venues:Collection<Venue>
      6. Team - design a class that represents information for a team.
        • id:long
        • name:String
        • club:Club
        • contacts:Collection<ContactRole>
      7. TeamSeason - design a class that represents a team's division play within a season. It is anticipated that this class will have a compound primary key with the identifying information for the team and division. You will need to create an embeddable primary key to hold the information.
        • team:Team
        • division:Division
        • homeGames:CollectionContest
        • awayGames:CollectionContest
        • wins - a transient, read-only property calculated by contests the team has won this season.
        • losses - a transient, read-only property calculated by contests the team has lost this season.
        • ties - a transient, read-only property calculated by contests the team has tied this season.
      8. Division - design a class that represents divisional play between teams within a season. Since group/level names cannot be relied on for any specific ordering, you may wish to add a competitive rank property (11, 21, 22, 23 might equate to U11-D1, U12-D1, U12-D2, U12-D3). This class also may have a compound primary key (again, these are technical details you can decide).
        • season:Season
        • group:String
        • level:String
        • ranking:int
        • coordinator:Contact
        • teams:Collection<TeamSeason>
      9. Contest - design a class that represents a contest at a venue for a home and away team. Note that the start/end times or date of contest information may or may not map directly to database column. Some of these values may be derived from other values and therefore are "Transient" as far as O/R Mapping concerned. I will list the properties that callers of this class will be concerned about; whether they come directly from the database or are derived.
        • id:long
        • date:Date (or integrated in with startTime). Callers will want something they can use to provide the user with day-of-week, month, day output.
        • startTime:long, Calendar or Date - callers will want something they can translate to a user output that represents hh:mm
        • endtime:long, Calendar or Date - callers will want something they can translate to a user output that represents hh:mm. Schedulers will also need this to determine conflict.
        • location:Venue
        • homeTeam:TeamSeason
        • awayTeam:TeamSeason
        • isComplete - another field or negative scores can indicate a contest that has not yet completed.
        • homeScore:int
        • awayScore:int
    2. eClub Candidate Business ObjectseClub Business Objects
      1. Individual - design a class that encapsulates information for an individual in the club.
        • id:long
        • firstName:String
        • lastName:String
        • email:String
        • login:String
        • parents:Collection<Individual>
        • children:Collection<Individual>
      2. Player - design a class that encapsulates information for a player.
        • jerseyNo:int
        • position:String
        • dob:Date
        • individual:Individual
        • team:Team - we'll keep players to a single team for simplicity.
      3. Coach - design a class that encapsulates information for a coach.
        • certLevel:String
        • certNo:String
        • individual:Individual
        • team:Team - we'll keep head coaches to a single team for simplicity.
      4. Team - design a class that encapsulates information for a team.
        • id:String
        • name:String
        • league:String
        • group:String
        • level:String
        • leagueTeamId:int - a key value that identifies the team within the eLeague system.
        • manager:Individual
        • headCoach:Coach
        • players:Collection<Player>
      5. Club - design a class that encapsulates information for the overall club.
        • id:String
        • name:String
  3. Add validation API declarations to your business objects as appropriate. This need not be extensive or exhaustive. Just do enough to show use of declarative validation as a part of your application.
    1. Determine the validation groups you wish to use in your application (suggest business logic interface and persistence tier).
    2. Add validation annotations to your business objects and assign them to your designed groups as appropriate.
    3. Manually invoke validation from the business tier and integrate the validation into your persistence unit.
  4. Design and implement a mechanism to ingest a starting state for eLeague based on a provided data file and parser. You will implement two primary classes to support this requirement; the DAO(s) and an Ingestor.
    Note:
    The ClubDAO interface, in this case, is a DAO in the eLeague application that handles O/R mapping of business objects that relate to Clubs within eLeague. It is not a DAO in the eClub application.
    eLeague Ingest and JDBC DAO
    1. Design and implement a set of DAOs that can be used to ingest eLeague business data into the database using the the database schema you designed as a part of a separate requirement. These DAOs can optionally be tuned for ingest or simply reused from your CRUD-style requirements.
    2. Design and implement an Ingestor that will use an externally provided parser to obtain business data for eLeague and use the JDBC Ingest DAO to populate the database.
  5. Design and implement a DAO layer that will map the business objects between the object model and the database using the Java Persistence API (JPA). These DAOs will support all standard CRUD operations and can optionally implement the same interface as other potential DAO implementations. The implementation can make liberal use of JPA @Annotations, descriptor files, or a combination of both. Your interface should encapsulate the fact that an EntityManager is being used and the same EntityManager should be shared among other DAOs in the same Thread. Your DAOs should not attempt to control the transaction or they will NOT be portable to the EJB tier.
    1. eLeague DAOseLeague Candidate JPA DAOs
      1. LeagueDAO/JPALeagueDAO - encapsulates the use of JPA when mapping League and closely associated business objects (Season, Division, TeamSeason, Contest, and Contact) to/from the database.
      2. ClubDAO/JPAClubDAO - encapsulates the use of JPA when mapping Club and closely associated business objects (Venue, Address, Team, and Contact) to/from the database.
    2. eClub Candidate DAOseClub JPA DAOs
      1. MemberDAO/JPAMemberDAO - encapsulates the use of JPA when mapping Individuals and closely associated business objects (Player and Coach) to/from the database.
      2. OrganizationDAO/JPAOrganizationDAO - encapsulates the use of JPA when mapping Teams and closely associated business objects (Club) to/from the database.
  6. Add tuning to your database schema by augmenting the DDL files with indexes for foreign keys, joins, and where clauses. This need not be extensive or exhaustive. Just do enough to show that proper data model and database tuniung is part of the overall enterprise development process.
  7. Design an initial business interface and business logic for the applications. The core O/R mapping work will be done by the DAOs. However, it is the ultimate responsibility of these business logic implementations that either it or the business objects enforce the business rules of the application. The DAOs only perform O/R mapping and do not enforce such things as a schedule conflicts. The business logic is assumed to work within the context of a single, externally controlled transaction. Do not attempt to control the transaction of the EntityManager within these objects or you will NOT be portable to the EJB tier. You need only implement the behavior required to implement the end-to-end use case listed in the testing section. Some of the anticipated methods are listed below.
    1. eLeague Candidate Business LogiceLeague Business Logic
      1. LeagueMgmt/LeagueMgmtImpl - encapsulate the actions required to create Clubs and manage Seasons and Divisions.
        • createClub - league coordinators will need to create new clubs for the league. Once the club has been created, ClubMgmt can be used to perform management of the club details.
        • addSeason - league coordinators will need to create a new season for the league. The league cannot have 2 or more concurrent seasons and will know the most current season, if any.
        • addDivision - league coordinators will need to add divisions for a season. Club coordinators will be assigning their teams to the league's divisions for a season.
        • updateContact - leagues will need to update their primary and division points of contact.
        • getDivisions - users will need to know which divisions exist for the most current season. There will also need to be the capability to get historical information for previous seasons.
        • getDivisionStandings - users will want to get divisional standings information for the most current season. This would normally consist of an ordered list of teams based on wins (you can ignore ties) and their win, loss, tie totals. Note that this may involve the creation of a transient object that is calculated on-demand by business objects and may not be persisted in the database. There will also need to be the capability to get historical information for previous seasons.
        • getTeam - regular users and team/club officials will need to obtain team points of contact, schedule, and contest results for the most current season. There will also need to be the capability to get historical information for previous seasons.
      2. ClubMgmt/ClubMgmtImpl - encapsulate the actions required to manage Venues and Teams.
        • addVenue - you will need to create one or more venues for the league to schedule contests for your club. The only thing that the club manages for the venue is keeping directional information up to date.
        • addTeam - you will need to create teams that play for the club. Note that clubs span multiple seasons/divisions and may even sit out a season. Therefore, teams are usually added first and then later assigned to divisions.
        • assignTeamDivision - clubs will have to assign their teams to divisions after the league has created them for an upcoming season.
        • updateTeam - teams will need to be able to assign points of contact
        • updateContact - clubs and teams will need to update points of contact information.
      3. ContestMgmt/ContestMgmtImpl - encapsulate the actions required to schedule and manage contests between teams within the league.
        • scheduleSeason - league officials will need to create a home and away schedule for each team in the division with each team playing each other at least once and possibly more (for smaller divisions), up to a specified number (default to 10) number of games. Your scheduling can be extremely simple as long as it does not schedule conflicting contests. Ideally a team would not play more than once on a single day and you might want to limit contests to a specific set of days of the week. However, the fact that you have placed the scheduling within the correct architectural area is the key point. How simple you make the algorithm is totally up to you and will not impact your grade. You may decide how much scheduling gets done by the business object(s) and how much gets done by the business logic.
        • reportScore - division coordinators will need to be able to report the results of a contest.
      4. LeagueTestUtil/LeagueTestUtilImpl - a useful tool during testing that encapsulates how to get the application back into a known state prior to running a test or to inspect values not normally exposed through the normal business interfaces.
        • resetAll - sanely take the state of the system down to a coldstart.
        • populate - you might want the database populated with a known state prior to running a test. This may delegate to the LeagueIngestor.
        • get/doXXX - methods that are unsafe for the actual business logic, but are needed for development and test.
      5. LeagueIngestor - the Ingestor written as a part of a separate requirement is also logically considered part of this tier.
        • ingest - point an externally provided parser at a set of test data and use the DAOs to populate the system to a known state.
    2. eClub Candidate Business LogiceClub Business Logic
      Note:
      Keep in mind that this project has two notions of a club. From the league's perpective it manages schedules, scores, and high level contact information for teams within a club. From the club's perspective, there is the need to manage coaches, players, and parents associated with the team. For that reason -- I am calling the club an organization here to avoid some confusion.
      1. MemberMgmt/MemberMgmtImpl - encapsulates the actions required to manage individuals registering with the club.
        • createParent - parents will need to be able to register with the club.
        • createPlayer - parents will need the ability to register their minors as players. All players will need at least one parent.
        • addCoachRole - coaches will need to be able to register with the club. It is common that a coach is also a parent.
      2. OrganizationMgmt/OrganizationMgmtImpl - encapsulate the actions required to create teams and get team information. Some of this information will come from contacting eLeague in future projects.
        • createTeam - club officials will need to create teams.
        • assignPlayers - club officials will need to assign players to teams
        • assignCoach - club officials will need the ability to assign a coach to a team
        • assignManager - club officials will need to ability to assign a manager to a team
        • getTeamRoster - users assigned to a team will need the ability to get the roster for team. Rosters contain coach, manager, player, and parent information.
        • getTeamSchedule - users will need the ability to get the schedule for a team for the most current season. This information will come from eLeague in a future project. Team schedules should have contest dates, venue, and scores.
      3. ClubTestUtil/ClubTestUtilImpl - a useful tool during testing that encapsulates how to get the application back into a known state prior to running a test or to inspect values not normally exposed through the normal business interfaces.
        • resetAll - sanely take the state of the system down to a coldstart.
        • populate - it may be helpful to return the database to a known populated state between tests.
        • get/doXXX - methods that are unsafe for the actual business logic, but are needed for development and test.

Testing

  1. Provide a JUnit test for your business objects (BOs) that test the manipulation of the structure. An example test might be to try forming a contest between teams in separate divisions or schedule a contest that conflicts with a team and/or venue schedule. These tests should be packaged with the BOs.
  2. Provide a JUnit test for your JPA DAOs. This should test the implementation for the fundamental CRUD operations for each type of object. It is understood that some of the objects will be handled by cascades, so you might not have a set of methods handling each type of business object. This test should be packaged with the DAOs.
  3. Provide a JUnit test for your business logic to test the basic functionality of your business logic design, including ingest. The ingestor test should be able to reference a known data file and ingest records into the database using the JDBC DAOs. These tests should be packaged with the business logic implementation.
  4. Provide a set of JUnit test programs to verify the following end-to-end scenario in eLeague. This test should be implemented as a JUnit test and packaged with the business logic implementation.
    • reset (using LeagueTestUtil) -- reset the league database to an initial starting state.
    • ingest data (using LeagueIngestor) -- ingest the full XML test data file.
    • createClub (using LeagueMgmtImpl)
    • addVenue (using ClubMgmtImpl)
    • addTeam (using ClubMgmtImpl)
    • updateContact for team (using ClubMgmtImpl)
    • assignTeamDivision (using ClubMgmtImpl) - divisions already exist for current/next season within the test data.
    • scheduleSeason (using ContestMgmtImpl)
    • getDivisions (using LeagueMgmtImpl)
    • getDivisionStandings (using LeagueMgmtImpl)
    • getTeam with schedule and results (using LeagueMgmtImpl)
    • reportScore (using ContestMgmtImpl)
    • getTeam with schedule and results (using LeagueMgmtImpl)
    • getDivisionStandings (using LeagueMgmtImpl)
  5. Provide a set of JUnit test programs to verify the following end-to-end scenario in eClub. This test should be implemented as a JUnit test and packaged with the business logic implementation. Note that it is anticipated that you may only have time to create one team, with one player, manager, parent, and coach for the club.
    • reset (using OrganizationTestUtil) -- reset the organization database to an initial starting state.
    • createParent (MemberMgmtImpl)
    • createPlayer (MemberMgmtImpl)
    • addCoachRole (MemberMgmtImpl)
    • createTeam (using OrganizationMgmtImpl)
    • assignPlayers (using OrganizationMgmtImpl)
    • assignCoach (using OrganizationMgmtImpl)
    • assignManager (using OrganizationMgmtImpl)
    • getTeamRoster (using OrganizationMgmtImpl)
    • getTeamSchedule (using OrganizationMgmtImpl and later calls to eLeague in follow-on project)

Getting Started

The following sketch of two directory structures can be used as a starting point for your overall application. The first is a simplified project layout that collapses the number of sub-projects into a single "Impl" project. It is suggested that you use this layout if you are new to maven and want the simplest configuration possible. The second is a more robust layout and is closer to a multi-developer environment. Use the later structure if you want to better simulate a work environment where the work of multiple developers needs clearer separation.

Note:
All "e"Sport, "e"League, and "e"Club names should be changed to your specific name mangler. The same type of modification needs to occur for the java package names.
Note:
Other than a README, it is not anticipated that you will have any artifacts at the eSport layer. It should be used only as a convenience wrapper to perform goals across both projects. The root project can also be used for common property, dependencyManagement, and pluginManagement definitions. All concrete dependency and plugin instantiations should be defined in the leaf-level poms to avoid unwanted dependencies form the root or mid-level parents.
eSport
|-- pom.xml
|-- eLeague
|   |-- pom.xml
|   `--eLeagueImpl
|       |-- pom.xml
|       `-- src
|           |-- main
|           |   |-- java
|           |   |   `-- eleague
|           |   |       |-- bo
|           |   |       |-- dao
|           |   |       |-- jpa
|           |   |       |-- bl
|           |   |       |-- blimpl
|           |   `-- resources
|           |       `-- ddl
|           |           |-- eLeague-create.ddl
|           |           |-- eLeague-drop.ddl
|           |           `-- eLeague-tuning.ddl
|           |-- test
|               |-- java
|               |   `-- eleague
|               |       |-- bo
|               |       |-- dao
|               |       |-- bl
|               `-- resources
|                   |-- log4j.xml
|                   |-- META-INF
|                      `-- persistence.xml
|           
`-- eClub
    |-- pom.xml
    `--eClubImpl
        |-- pom.xml
        `-- src
            |-- main
            |   |-- java
            |   |   `-- eclub
            |   |       |-- bo
            |   |       |-- dao
            |   |       |-- jpa
            |   |       |-- bl
            |   |       |-- blimpl
            |   `-- resources
            |       `-- ddl
            |           |-- eClub-create.ddl
            |           |-- eClub-drop.ddl
            |           `-- eClub-tuning.ddl
            `-- test
                |-- java
                |   `-- eclub
                |       |-- bo
                |       |-- dao
                |       |-- bl
                `-- resources
                    |-- log4j.xml
                    `-- META-INF
                        `-- persistence.xml
eSport
|-- pom.xml
|-- eLeague
|   |-- pom.xml
|   +--eLeagueBO
|   |   |-- pom.xml
|   |   `-- src
|   |       |-- main
|   |       |   |-- java
|   |       |   |   `-- eleague
|   |       |   |       |-- bo
|   |       |   |       `-- bl
|   |       `-- test
|   |           |-- java
|   |           |   `-- eleague
|   |           |       `-- bo
|   |           `-- resources
|   |               `-- log4j.xml
|   +--eLeagueDAO
|   |   |-- pom.xml
|   |   `-- src
|   |       |-- main
|   |       |   |-- java
|   |       |   |   `-- eleague
|   |       |   |       |-- dao
|   |       |   |       |-- jdbc
|   |       |   |       `-- jpa
|   |       |   `-- resources
|   |       |       `-- ddl
|   |       |           |-- eLeague-create.ddl
|   |       |           |-- eLeague-drop.ddl
|   |       |           `-- eLeague-tuning.ddl
|   |       |-- test
|   |       |   |-- java
|   |       |   |   `-- eleague
|   |       |   |       `-- dao
|   |       |   `-- resources
|   |       |       |-- log4j.xml
|   |       |       `-- META-INF
|   |       |           `-- persistence.xml
|   +--eLeagueBLImpl
|   |   |-- pom.xml
|   |   `-- src
|   |       |-- main
|   |       |   |-- java
|   |       |   |   `-- eleague
|   |       |   |       `-- blimpl
|   |       |   `-- resources
|   |       `-- test
|   |           |-- java
|   |           |   `-- eleague
|   |           |       `-- bl
|   |           `-- resources
|   |               |-- log4j.xml
|   |               `-- META-INF
|   |                   `-- persistence.xml
`-- eClub
    |-- pom.xml
    +--eClubBO
    |   |-- pom.xml
    |   `-- src
    |       |-- main
    |       |   |-- java
    |       |   |   `-- eclub
    |       |   |       |-- bo
    |       |   |       `-- bl
    |       |-- test
    |       |   |-- java
    |       |   |   `-- eclub
    |       |   |       `-- bo
    |       |   `-- resources
    |       |       `-- log4j.xml
    +--eClubDAO
    |   |-- pom.xml
    |   `-- src
    |       |-- main
    |       |   |-- java
    |       |   |   `-- eclub
    |       |   |       |-- dao
    |       |   |       `-- jpa
    |       |   `-- resources
    |       |       `-- ddl
    |       |           |-- eClub-create.ddl
    |       |           |-- eClub-drop.ddl
    |       |           `-- eClub-tuning.ddl
    |       `-- test
    |           |-- java
    |           |   `-- eclub
    |           |       `-- dao
    |           `-- resources
    |               |-- log4j.xml
    |               `-- META-INF
    |                   `-- persistence.xml
    `--eClubBLImpl
        |-- pom.xml
        `-- src
            |-- main
            |   |-- java
            |   |   `-- eclub
            |   |       `-- blimpl
            |   `-- resources
            `-- test
                |-- java
                |   `-- eclub
                |       `-- bl
                `-- resources
                    |-- log4j.xml
                    `-- META-INF
                        `-- persistence.xml

Grading

Your project will be graded on completeness and quality of product. In order for you to receive full credit in each area, it must be a) complete, b) done well, and c) tested. The breakdown of grading will be as follows:

  • README provided that describes where each requirement satisfied: 10pts
  • projects cleanly builds with Maven: 15pts
  • managed schema to include declaration of key indexes (i.e., defined in a set of files and explicitly used to coldstart and initialize the database at defined times): 5pts
  • business objects: 10pts
  • use of validation API: 5pts
  • JPA DAO and JPA O/R Mapping: 25pts
  • Ingest: 10pts
  • Business Logic: 10pts

Each area will be judged according to the following breakdown. For areas where testing does not apply (e.g., README and build), those points will be assigned to quality:

  • complete: 60%
  • quality of implementation supplied: 30%
  • testing: 10%

Submission Guidelines

Please follow the project submission guidelines posted in the course overview.