M18 - Case Study

8/10/2019 M18 - Case Study

1/32

Module 18: Case Study

Java Course

8/10/2019 M18 - Case Study

2/32

2

Module Objectives

At the end of this module, participants will be able to: Describe the application architecture used by the case study

application

Identify and describe the deliverables that must be provided in order

to complete the case study

Identify and describe the roles, responsibilities, and deliverables of adeveloper during this case study

8/10/2019 M18 - Case Study

3/32

3

Case Study Overview

The case-study application is a simple Employee databaseapplication.

Participants will be expected to complete the implementation the

requirements of the application based on the provided design

documentation.

Spring, Subversion, Tomcat, Tortoise, and Subclipse will be

used in the Case Study.

The License Agreements of these OSS are found in the

Appendix section of this module.

8/10/2019 M18 - Case Study

4/32

4

Case Study Inputs

A developer handbook (this presentation) containing high levelarchitecture and design information.

Partially implemented skeleton of the application to serve as a

guide and sample on the rest of the requirements.

8/10/2019 M18 - Case Study

5/32

5

Case Study Outputs

Design, document and implement the physical data modelrequired to support application requirements.

Create TCERs required by the interface layer according to its

documentation.

Complete implementation of JUnit test classes based on the

TCERs generated for the repository and service objects.

Complete implementation of the repository and the service

objects based on the requirements of the interface layer and the

JUnit test classes.

8/10/2019 M18 - Case Study

6/32

6

Application Overview

The application is a simulation of an Employee databasecontaining records of an Employees basic profile, projects and

skills.

The application provides the ability for a user to search for

employees via their names or their projects and to obtain details

on their project history and skill set.

8/10/2019 M18 - Case Study

7/327

Application Use-Cases

8/10/2019 M18 - Case Study

8/328

Application Overview Repositories are the various data

access classes that provide CRUD(Create, Read, Update, Delete)functionality for value objects that needto be maintained

Services represent the business layerof the application and is a

representation of the various use-casesof the application

Domain Objects represent the logicaldata model for the application.

Spring MVCis used to implements theapplications web presentation layer

Spring Framework is used for itsdependency injection feature thatallows different implementations acrossall layers to be plugged in withoutreferencing them in code MySQL Database

Repositories

HRS Services

Spring MVC SpringDepe

ndencyInjection

DomainObjects

8/10/2019 M18 - Case Study

9/329

Sequence Diagram

JSP Controller Service Repository Database

Web page sends request tocontroller handler

Controller handler callsservice API

Service API callsrepository methods

Repository queriesdatabase

Return Result

Return Result

Return data model

Determine what pageto display

8/10/2019 M18 - Case Study

10/3210

Logical Data Model

The applications logical data model represents the relationshipsbetween the different domain objects

The service and repository methods return objects of these

types

EmployeeDetail

Employee

EmployeeProjectDetail

EmployeeSkill

Project

ProjectRole

* Contains

1

1

N

N

1

1

N

8/10/2019 M18 - Case Study

11/32

11

Logical Data Model

EmployeeDetaila combination of the different domain objects.This represents information about a specific employee, theemployees project history and the employees skill set.

Employeebasic information about a single employee.

EmployeeSkill information on a specific skill of an employee.

EmployeeProjectDetail a collection of project roles of anemployee for a specific project.

Projectbasic information about a single project.

ProjectRolebasic information about a specific project role.

8/10/2019 M18 - Case Study

12/32

12

Current State of the Application

The applications presentation layer is currently implementedand functional

The service layers are currently implemented as stubs

Presentation Layer

JSP

Controllers

Service

s(Stub)

Data Layer

Repo

sitory

MySQL Database

For implementation

8/10/2019 M18 - Case Study

13/32

13

TODOs

Design, document, and implement a database schema thatrepresents the information and relationships the applications

logical data model at a database level.

Design and implement repository classes that will provide

access to the information stored in the database.

Re-implement the stub service classes in order to make use ofthe repositories to access its data instead of returning dummy

data.

8/10/2019 M18 - Case Study

14/32

14

TODOs

Complete the Functional Test plan. A partially implemented testplan is already provided for you:

Create TCERs for each class/API implemented

Create JUnits for each class/API implemented

8/10/2019 M18 - Case Study

15/32

15

Hints

Make sure you understand the definitions and the relationshipsdescribed by the logical data model. This will greatly influence

the way that you design the database schema.

Pay careful attention to the requirements of the service layer.

This will determine what kind of data the service layer will accept

from the controller, and what kind of data will be returned. Thiswill influence how you design your repositories (DAOs).

Make sure the design and interface across layers are properly

understood. Know what parameters to send, and what values to

expect (refer to the sequence diagram).

8/10/2019 M18 - Case Study

16/32

16

Spring Dependency Injection

The application makes use of Springs dependency injectionfeature extensively across all layers.

The framework allows objects to have their dependencies

injected into them instead of requiring objects to declare their

object dependencies in their own code.

By freeing the object from having to declare its dependencies, it

can focus on its functional and business behavior while

minimizing implementation specific code.

8/10/2019 M18 - Case Study

17/32

17

Example: DAOs and Datasources

DAO (Data Access Object) implementations typically require aDataSourcereference in order to access the database.

The DataSource object is used to establish connections with a

specific database instance.

DAO

DataSourceMySQL Database

8/10/2019 M18 - Case Study

18/32

18

Dependency Declaration

One approach would be for the DAO itself to have code thatconstructs a DataSource that connects to a specific database

instance.

This approach will lock the DAO to that specific database

instance. If the database changes, the DAO would have to be

recoded and recompiled.

8/10/2019 M18 - Case Study

19/32

19

Dependency Injection

The dependency injectionapproach injects the

DataSource into the DAO

through external configuration

files.

The DAO class itself is not

concerned how it gets a

DataSource object and does

not have any implementation

specific code needed to get a

DAO reference.

The DAO can have different

DataSource implementations

injected as required without

having to change its code

DAO

DataSource

DataSource

ImplementationMySQL

Database

DataSource

ImplementationOracle

Database

8/10/2019 M18 - Case Study

20/32

20

Dependency Injection

Dependency injection is configured through XML-basedconfiguration files.

Each configuration file defines beans which are objects that we

want the Spring framework to manage.

The dependencies between beans are configured through thexml (called wiring beans).

8/10/2019 M18 - Case Study

21/32

21

Example: Create a Bean

The following declares a bean named dataSource, which represents an

instance of a dataSource object.

8/10/2019 M18 - Case Study

22/32

22

Example: Create a Bean

The following xml configuration shows how to inject a bean as the dependency of

another bean. In this case a repository (DAO) bean is injected a reference to adatasource bean:

8/10/2019 M18 - Case Study

23/32

23

Example: Create a Bean

In order to obtain a reference to a bean in code, we use the

ApplicationContext and pass it the location of the xml config files.

ApplicationContext context = newClassPathXmlApplicationContext("classpath:repository-config.xml");

Once a context is retrieved, it can be used to obtain a reference to anybean that is inside the declared inside the xml.

service = (SearchService)context.getBean("searchService");

8/10/2019 M18 - Case Study

24/32

24

Application Config Files

The application has two configuration files:

config/repository-config.xml This contains beans for the data layer ofthe application. This is currently populated with stub classes which willneed to be modified and replaced with the beans required for the datalayer (services, datasources and repositories) of the application that youwill be implementing.

Web-INF/mvc-config.xmlThis contains controller definitions and wiresthe various services to the web-ui controller. This document need not bemodified.

There should be no need to create additional configuration files. Justplace any beans where appropriate

8/10/2019 M18 - Case Study

25/32

25

The succeeding slides

will show the schedule of activities

Schedule

8/10/2019 M18 - Case Study

26/32

26

Schedule

8/10/2019 M18 - Case Study

27/32

27

Schedule

8/10/2019 M18 - Case Study

28/32

28

Schedule

8/10/2019 M18 - Case Study

29/32

29

DAY 20: Removal of Open Source Software

Everyone is expected to remove the following OSS from the

workstation:

Eclipse 3.4 Subeclipse 1.4.x

JDK 1.6 Subversion 1.5.x

MySQL 5.0 Tomcat 6.0.16

Spring 5.0 Tortoise 1.5.3.13783

Schedule

8/10/2019 M18 - Case Study

30/32

30

Appendix

Spring Version : 2.5.5

License : http://www.apache.org/licenses/LICENSE-2.0.html

Subversion

Version : 1.5.2

License : http://subversion.tigris.org/license-1.html

Tomcat

Version : 6.0.16

License : http://www.apache.org/licenses/LICENSE-2.0

8/10/2019 M18 - Case Study

31/32

8/10/2019 M18 - Case Study

32/32

32

Questions and Comments