Transcript Lecture Presentation (requires Microsoft PowerPoint)

Web Application 101 Design
Training Class
Copyright© 2011 On The Edge Software Consulting
Agenda
1
Course #1 – SDLC Process.
2
Course #2 – Requirements Analysis.
3
Course #3 – N-Layer Architecture.
4
Course #4 – Presentation Layer Design.
5
Course #5 – Business Services Layer Design.
6
Course #6 – Data Access Services Layer Design.
7
Course #7 – Putting it All Together.
Copyright© 2011 On The Edge Software Consulting
2
Course #1
SDLC Process
Copyright© 2011 On The Edge Software Consulting
3
Course Objectives

Learn what is an SDLC process.

Learn some of the common models and methodologies used to manage and
drive the SDLC process.

Learn the phases of the SDLC process.

Learn the benefits/goals of each of the phase of the SDLC process.
Copyright© 2011 On The Edge Software Consulting
4
Introduction - SDLC

System/Software Development Life Cycle.

Is a process used by a systems analyst to develop an information system, including
requirements, validation, training, and user (stakeholder) ownership.

Any SDLC should result in a high quality system that meets or exceeds customer
expectations, reaches completion within time and cost estimates, works effectively and
efficiently in the current and planned Information Technology infrastructure, and is
inexpensive to maintain and cost-effective to enhance.
Copyright© 2011 On The Edge Software Consulting
5
Different SDLC Models

To manage the increasing level of software complexity a number of
SDLC models have been created:





Waterfall (oldest and the best known)
Rapid Prototyping (separate prototypes are merged in an overall design)
Spiral (defined in 1986 that combines the features of Waterfall and Prototyping)
Iterative/Incremental (develop through repeated cycles (iterative) and in smaller
portions at a time (incremental))
SDLC models can be described that range from agile to iterative to
sequential.



Agile methodologies, such as XP and Scrum, focus on light-weight processes which
allow for rapid changes along the development cycle.
Iterative methodologies, such as Rational Unified Process, focus on limited project
scopes and expanding or improving products by multiple iterations.
Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete
and correct planning to guide large projects and risks to successful and predictable
results.
Copyright© 2011 On The Edge Software Consulting
6
Phases of the SDLC
Copyright© 2011 On The Edge Software Consulting
7
Iterative SDLC Model

The Iterative SDLC Model is a good compromise for many projects.
o
Due to the size of the project
o
Due to the maturity level of the organization
o
And still enforce a level of rigor and discipline required for building a new project
Copyright© 2011 On The Edge Software Consulting
8
Agile SDLC Model

The Scrum/Agile SDLC model has become popular in the past 5
years.

To promote collaboration across the team members

To engage the business in the development process

To demonstrate incremental progress to the business
Copyright© 2011 On The Edge Software Consulting
9
Some YouTube Entertainment……………
The Rise and Fall of Waterfall

http://www.youtube.com/watch?v=X1c2--sP3o0
Copyright© 2011 On The Edge Software Consulting
10
Course #2
Requirements Analysis
Copyright© 2011 On The Edge Software Consulting
11
Course Objectives

Learn what a Use Case is.

Learn how to break a Business Scenario into Use Cases.

Learn how to decompose Use Cases into Actors, Nouns, and Verbs.

Learn how to design Business Entities using Nouns from a Use Case.

Learn how to design Business Services using Verbs from a Use Case.

Learn what Non Functional Requirements (NFR) are.

Example Code: applying what we learned in this course.
Copyright© 2011 On The Edge Software Consulting
12
What is a Use Case?

A use case in software engineering and systems engineering is a description of a
system’s behavior as it responds to a request that originates from outside of that
system. In other words, a use case describes "who" can do "what" with the system
in question. The use case technique is used to capture a system's behavioral
requirements by detailing scenario-driven threads through the functional
requirements.

A well written Use Case must be initiated by an Actor (or sometimes referred to as a
Subject) and seen through to completion by an Actor.

An Actor does not have to be a person but can also be an system or 3rd party.

A Use Case can be represented in text and/or in a UML via a Use Case Diagram.

When expressed in text:


As a <role> I need <functionality>
So <value statement>
A Use Case does not specify “how” the behavior is implemented!
Copyright© 2011 On The Edge Software Consulting
13
Example Business Scenario
The Acme Corporation business has asked the Business Architecture Team, Enterprise
Architecture Team, and IT Team to replace a legacy green screen terminal application with a new
modern web based application. The business application is a product order application that is
expected to increase the sale of products offered by Acme Corporation. The web application will
be used by new Acme Corporation customers to place orders and make payments for new and
existing products offered by Acme Corporation. The customers will access the product order
application over the Internet via a secure customer portal using their desktop browser. The
commonly used modern desktop browsers will be supported. The web application will be
available in English and Spanish. All users must be first registered in the Acme Corporation’s
system prior to accepting and processing orders for their products. The user registration
information, which will be saved in a database, will include the user’s demographic information,
address information, and preferred credit card information. Once registered in the system the
user can select a product from a product catalog, display the product’s details, which includes
images, product description, and price as well as place orders for new or existing products
offered by Acme Corporation. The system will require and enforce that valid data be entered in
all screens within the web application. The user can purchase products from Acme Corporation
by first selecting one or more desired products to purchase, entering their shipping information,
and finally by entering a valid credit card (Visa, Master Card, and Amex). The system will integrate
with a 3rd party credit card processing payment system to authorize and process the credit card
payment request. Once the user has placed an order the user will be informed of the transaction
and given a tracking number via an email notification.
Copyright© 2011 On The Edge Software Consulting
14
Decomposing a Business Scenario…….into text
based Use Cases
1. The User must be able to log into a secure portal (using username and password).
2. The User must be able to register on the portal (providing name, address, and credit card #).
3. The User must be able to select a Product and place an Order for a Product.
4. The User must be able to select a Shipping Address and confirm their Order.
5. The User must be to receive a Confirmation and Tracking Number once an Order is placed.
6. The Credit Card System shall provide the capability to accept credit card transactions.
7. The Credit Card System shall respond within 500ms.
8. The Credit Card System shall be able to process at least 100 transactions/second.
9. The System shall be available 99.99% of the time.
10. The System shall support all modern web browsers (that includes IE6+, Firefox 3+, Safari 2+)
Copyright© 2011 On The Edge Software Consulting
15
Decomposing Use Cases…..into a list of
Actors/Nouns/Verbs
Actor
Nouns
Verb
Traceability
User
Username,
Password
Log In
1
User
Name, Address,
Credit Card
Register
2
User
Product
Select
3
User
Product
Order
3
Credit Card System
Credit Card
Transaction
Accept
6
Copyright© 2011 On The Edge Software Consulting
16
Decomposing Use Cases…..into a UML Use Case
Diagram
uc Example Use Cases
Users
(Subj ects)
Nouns
(Entities)
{Credentials}
Verbs
(Operations)
Log In
{Demographic Info}
User
Register
Copyright© 2011 On The Edge Software Consulting
17
Decomposing Nouns…….into Business Entities
1. First list all the Nouns from your Use Cases.
•
These form the Business Entities (or business data) that the system will operate on.
•
You may have to roll these up to form logical domains.
 This forms your Application Domain Model (as course grained entities)
 Username and password => UserCredentials
 User name and address => UserDemographics
 Credit card number => CreditCard
2. Then for each Business Entity define the properties/attributes that make up the Entity.
•
Be aware of relationships between Entities (ask yourself if there is a “has a” or “is a”)
3. And finally we can leverage UML Class Diagrams to design our Business Entities.
Copyright© 2011 On The Edge Software Consulting
18
Decomposing Business Entities…..into a UML
Class Diagram
class Example Class Diagrams
User
-
userID :int
credentials :UserCredentials
creditcard :CreditCard
demographics :UserDemographics
Valid User credentials
must exist for the User.
1
1
1
1
1
0
UserDemographics
UserCredentials
-
userID :int
password :char
username :char
If the User does not
specify a Credit Card
then the User will be
required to pay with a
Check.
-
userID :int
address :char
city :char
firstName :char
lastName :char
postalCode :char
state :char
emailAddress :char
Valid demographics
must exist for the User.
Copyright© 2011 On The Edge Software Consulting
19
CreditCard
-
userID :int
expireDate :Date
number :char
name :char
Decomposing Subjects and Verbs…….into
Business Services
1. First list all the Actors from your Use Cases.
•
These can form additional high level business entities (or business objects) that the
system will operate on
2. Then for each Actor define the operations (from the Verbs) that can be performed on the
Actor.
•
An Actor can perform an operation with data (course grained)
•
Operations are methods in your Actor classes that use Nouns as parameters
•
Operations define the behavior of your system (executing the business logic)
•
In code: Noun = Actor.Verb(Noun) => Status = User.register(UserDemographics)
3. And finally we can leverage UML Class Diagrams to enhance the design of our Business
Entities by adding class methods (to form our Business Services).
Copyright© 2011 On The Edge Software Consulting
20
Decomposing Business Entities…..into a UML
Class Diagram
class Example 2 Class Diagrams
Mix of attributes and
operations.
User
-
userID :int
credentials :UserCredentials
demographics :UserDemographics
creditcard :CreditCard
+
+
logIn(UserCredentials) :void
register(UserDemographics) :void
1
1
1
1
UserDemographics
UserCredentials
-
userID :int
password :char
username :char
1
-
Copyright© 2011 On The Edge Software Consulting
userID :int
address :char
city :char
firstName :char
lastName :char
postalCode :char
state :char
emailAddress :char
21
0
CreditCard
-
userID :int
expireDate :Date
number :char
name :char
Improved Business Services
1. Previous Business Services Model mixed data and operations together.
2. Let’s take a similar approach except we will use a SOA based approach
•
SOA is a “architecture style” and not a framework or product
•
Separate (and reusable) Object Model that just defines our data
•
Separate (and reusable) Services Model that just defines our business logic
•
Create a custom and standard Canonical Model
 Object Model + Services Model = Canonical Model
Copyright© 2011 On The Edge Software Consulting
22
Improved list of Actors/Nouns/Verbs – add a
Business Domain
Actor
Domain
Nouns
Verb
Traceability
User
Security
Username,
Password
Log In
1
User
User
Name, Address,
Credit Card
Register
2
User
Product
Product
Select
3
User
Product
Product
Order
3
Credit Card
System
Purchasing
Credit Card
Transaction
Accept
6
Copyright© 2011 On The Edge Software Consulting
23
Improved Business Services
1. First list all the Domains from your Use Cases.
2. Then for each Domain define the operations (from the Verbs) that can be performed on the
Domain.
•
An Actor in a Domain can perform an operation with data
•
Operations are methods in your Domain classes that use Nouns as parameters
•
Operations define the behavior of your system (executing the business logic)
•
In code: Noun = Domain.Verb(Noun)
•
Status = UserService.register(UserDemographics)
3. And finally we can leverage UML Class Diagrams to design Canonical Model (to form our
SOA based Business Services and Object Model).
Copyright© 2011 On The Edge Software Consulting
24
Improved UML Class Diagram – Canonical Model
Service Model
Object Model
class Example Class Diagrams
class Example 3 Class Diagrams
User
-
userID :int
credentials :UserCredentials
creditcard :CreditCard
demographics :UserDemographics
Valid User credentials
must exist for the User.
1
1
SecurityServ ice
+
1
0
UserDemographics
UserCredentials
-
userID :int
password :char
username :char
If the User does not
specify a Credit Card
then the User will be
required to pay with a
Check.
1
1
-
logIn(UserCredentials) : boolean
userID :int
address :char
city :char
firstName :char
lastName :char
postalCode :char
state :char
emailAddress :char
CreditCard
-
UserServ ice
+
register(User) : boolean
userID :int
expireDate :Date
number :char
name :char
ProductServ ice
+
+
Valid demographics
must exist for the User.
Copyright© 2011 On The Edge Software Consulting
25
order() : void
select() : void
What is a Non Functional Requirement?

A non-functional requirement (or NFR) is a requirement that specifies criteria that
can be used to judge the operation of a system, rather than specific behaviors. This
should be contrasted with functional requirements that define specific behavior or
functions.

Are the constraints that a system must work within.

Examples of NFR’s include:
 Accessibility

Availability

Backup (and data retention)

Disaster Recovery (and mean time to recovery MTTR)

Performance (and response time)

Price/Cost

Security (such as data in flight, data at rest, authentication, authorization)
Copyright© 2011 On The Edge Software Consulting
26
Some Existing Example Designs……applying what we just
learned

UserService.cs: This service is used to get the current user information,
along with the list of users in current system. The following methods are
defined in this service



CurrentUserInfo(): To provide the information of the current user accessing this
application. It returns following information about the user

First name

Last name

Role
UsersList(): To provide the list of all the users currently listed in the Active
Directory

Username

Firstname

Lastname
IsValidUser(): This method validates if the current user is authorized to use this
application.
Copyright© 2011 On The Edge Software Consulting
27
Some Existing Example Designs……applying what we just
learned

CreateUpdateWorkOrder(): This method is used to Create new Work Order to the System. Or to
Update the existing Work Order
 Input parameters
 Priority
 Approach
 MainOrFace
 Status
 Issue
 CloseDate
 AssignedTo
 ProblemDescription
 AssociatedMantis
 Action
 Reported_By
 Output parameters: If the action was Create in the input parameters, it would Create the new
work order, and returns the work order number created, or otherwise update the existing work
order in the DB. This method also returns the error code in case of any error occurred on the
DB. The Work order number would be a sequence number generated from the Oracle DB

Copyright© 2011 On The Edge Software Consulting
28
Course #3
N-Layer Architecture
Copyright© 2011 On The Edge Software Consulting
29
Course Objectives

Learn the difference between an N Layer and an N Tier architecture.

Learn what coupling and cohesion are in an N Layer architecture.

Learn the benefits of an N Layer architecture.

Learn each of the layers of an N Layer architecture.

Learn the importance of an Application Framework in an N Layer architecture.
Copyright© 2011 On The Edge Software Consulting
30
Introduction - N Layer Application Architecture

Layers and Tiers

Layers are about how your code is organized.

Tiers are about the where your code/processes are run (on physical hardware).

You can deploy an N-Layer application on a single or multiple tier server solution.
 Things to Keep in Mind



Distributing your application across tiers is required to strike a balance between performance,
scalability, fault tolerance, and security.
Crossing a boundary/tier is expensive. It is on the order of 1000 times slower to make a call across
a process boundary on the same machine than to make the same call within the same process. If
the call is made across a network it is even slower.
In general terms tiers should be minimized. Tiers are not a good thing, they are a necessary evil
required to obtain certain levels of scalability, fault tolerance or security.
Copyright© 2011 On The Edge Software Consulting
31
Some Common Terms - Coupling

Loose Coupling:
 Problem: How to support low dependency, low change impact, and increased reuse?

Solution: Assign a responsibility so that coupling remains low.

Coupling is a measure of how strongly one element is connected to, has knowledge
of, or relies on other elements. An element with low (or weak) coupling is not
dependent on too many other elements.

A class, for example, with high (or strong) coupling relies on many other classes. Forced local changes
because of changes in related classes.

Harder to understand in isolation.

Harder to reuse because its use requires the additional presence of the classes on which it is dependent.
Copyright© 2011 On The Edge Software Consulting
32
Some Common Terms - Cohesion

Cohesion:
 Problem: How to keep objects focused, understandable, and manageable, and as a
side effect, support Low Coupling?
 Solution: Assign a responsibility so that cohesion remains high.
 Cohesion is a measure of how strongly-related or focused the responsibilities of a
single module are. If the methods that serve the given class tend to be similar in
many aspects, then the class is said to have high cohesion. In a highly-cohesive
system, code readability and the likelihood of reuse is increased, while complexity is
kept manageable.
 Cohesion is decreased if:


The functionalities embedded in a class, accessed through its methods, have little in common.

Methods carry out many varied activities, often using coarsely-grained or unrelated sets of data.
Disadvantages of low cohesion (or "weak cohesion") are:

Increased difficulty in understanding modules.

Increased difficulty in maintaining a system, because logical changes in the domain affect multiple
modules, and because changes in one module require changes in related modules.

Increased difficulty in reusing a module because most applications won’t need the random set of
operations provided by a module.
Copyright© 2011 On The Edge Software Consulting
33
Benefits - N Layer Application Architecture

Benefits of a Layered Architecture:
 Improves maintainability of code by minimizing the impact of change between layers.
 Technology should be an implementation detail (thru encapsulation).
 Should help enforce a separation of concerns (by loosely coupling code).
 Should enable the reuse of code across multiple layers.
 Should improve developer productivity.
 An N-Tier physical architecture can be supported (if desired).
 Enables test driven development (thru mock objects using dependency injection).

Drawbacks of a Layered Architecture:
The problem with layers and various other strategies for loosely-coupling your
applications is the addition of needless complexity.
If your application architecture is done incorrectly you run the risk of over
architecting an application to allow for various changes that are unlikely to
happen and are not based on actual requirements.
Copyright© 2011 On The Edge Software Consulting
34
Description - N Layer Application Architecture


Client Layer:

Typically a web browser (but does not need to be) that is responsible for the user interface display.

Minimal data validation (but need to avoid duplicating rules and implementations).

Minimal user interface/application logic.

Supports client side UI Widget Library.
Presentation Layer (PL):

Dynamic page generation (but can also use a Rich Internet Application RIA technology).

Handles user interface events (synchronous and asynchronous).

Implements user interface/application logic (UI Rules).

Handles application navigation.

Typically uses Model View Controller (MVC) or like design pattern.

Supports server side UI Widget Library.
Copyright© 2011 On The Edge Software Consulting
35
Description - N Layer Application Architecture


Business Services Layer (BLL):

Implements business logic (that can be reused across applications if desired).

Implements business rules (that can be reused across applications if desired).

Typically leverages Service Orientated Architecture (SOA) principles and design patterns.
Data Access Layer (DAL):

Implements all create, read, update delete (CRUD) operations for persistence of business entities.

Hides (encapsulates) persistence technology and frameworks.

Typically uses Data Access Object design pattern (enforced thru a common abstract base class).

Typically uses Object Relational Mapping (ORM) framework for OLTP applications.
Copyright© 2011 On The Edge Software Consulting
36
N Layer Application Architecture - .NET
RIA Design
AJAX
jQuery
CSS
Client Layer (Desktop/Mobile/Browser)
User Interface, (Minimal) Client Side Validation, AJAX, UI Rules
Forms
Canonical Object Model
Optional SOAP, REST
SOAP, REST
Entity Driven Design
Entity Framework (ORM)
LINQ
ADO.NET
Data Access/Services Layer (DAL)
CRUD Data Persistence
Data Model
.NET DB Factories
Integration Tier
Orchestration
(Workflow*, Rules*)
Frameworks, Design Patterns, etc.
Canonical Object Model
Reference Architecture
Business/Services Layer (BLL)
Business Logic, Business Rules, Workflow, Data Validation
Microsoft Enterprise
Library
Design By Contract
Unity Framework (IoC)
Workflow Foundation
Comm. Foundation
Local POCO, SOAP, REST
Reusable Application Blocks
Canonical Object Model
Application Framework
Presentation Layer (PL)
User Interface, UI Event Handlers, UI Rules, Navigation
Custom Reusable Library
Governance
, Standards, Policies, Best Practices,
Security, Steering Committees, Tools, etc.
Event Based Design
SilverLight
MVC 2
ASP.NET
HTTP/HTTPS POST
SOAP, .X12, ETC
Cache
Operational
Database
External Systems
Interfaces, Feeds, Printers
Business Entity
Media
Governed By
Copyright© 2011 On The Edge Software Consulting
Guided By
37
N Layer Application Architecture – Silverlight RIA
RIA Design
Silverlight
Client Layer (Desktop/Mobile)
User Interface, Rules*, Navigation, State
SOAP, REST
Presentation Model
Design By Contract
RIA Business/Services Layer
Canonical Object Model
Optional SOAP, REST
SOAP, REST
Data Access/Services Layer (DAL)
CRUD Data Persistence
Data Model
.NET DB Factories
Integration Tier
Orchestration
(Workflow*, Rules*)
SOAP, .X12, ETC
Frameworks, Design Patterns, etc.
Web Services & Logic, Rules*, Workflow*
Reference Architecture
Business/Services Layer (BLL)
Canonical Object Model
Design By Contract
Workflow Foundation
Comm. Foundation
SOAP, REST
Custom Reusable Library
Design By Contract
Workflow Foundation
Comm. Foundation
Application Framework
RIA Web Services & Logic, Rules*, Workflow*
Canonical Object Model
Governance
, Standards, Policies, Best Practices,
Security, Steering Committees, Tools, etc.
Workflow Foundation
Comm. Foundation
Entity Driven Design
ADO.NET
Silverlight
Application
Framework
Cache
Operational
Database
External Systems
Interfaces, Feeds, Printers
Business Entity
Media
Governed By
* Rules are retrieved from a central repository. Includes validation by ruleset.
Copyright© 2011 On The Edge Software Consulting
38
Guided By
Application Framework

Purpose:
 Reusable application agnostic / application independent framework
 Reusable based classes (placeholders for reusable logic and for future refactoring)
 Encapsulates common utility functions
 Enable consistency within the architecture
 Enable easy onboard of future architects and developers
 One goal should be to separate application dependencies out of the framework

Application Framework:
 Base Classes
 Logging Wrapper
 Tracing Wrapper
 Exception Wrapper
 Reference Data Service
 Application Independent Helper /Utility Classes (security, custom tags, custom
components, etc)
 Common canonical model
Copyright© 2011 On The Edge Software Consulting
39
Course #4
Designing the Presentation Layer
Copyright© 2011 On The Edge Software Consulting
40
Course Objectives

Learn the MVC and MVP design patterns.

Learn how to identify presentation layer events to create an Event Driven
design.

Learn common verbs for the Presentation Layer.

Learn some of Presentation Layer best practices.

Example Code: applying what we learned in this course.
Copyright© 2011 On The Edge Software Consulting
41
Designing the Presentation Layer……

The Presentation Layer continues to be the most challenging layer to design.

There are lots of skills required:
 UI Designer



Web Developer

Who must work with the Services Developer during integration
There are lots of technologies that must be learned:
 HTML, CSS, JavaScript

AJAX (push and pull)

JSON

UI component libraries

Design Patterns
How do we make this layer easier to design, build, and test?
Copyright© 2011 On The Edge Software Consulting
42
Introduction to the MVC/MVP Design Patterns in Web
Applications

The appropriate amount of time must be spent designing the Presentation
Layer and the designer must use the appropriate design pattern(s).

The MVC and MVP are popular design patterns used to build the Presentation
Layer.

This design pattern helps to enforce separation of concerns so you don’t mix
presentation logic, business logic, and data access logic together.

Model View Controller and Model View Presenter:
 Model: manages the behavior and data from the application layers

View: manages the display of data

Controller/Presenter: handles page events and navigation between pages
Copyright© 2011 On The Edge Software Consulting
43
The MVC Design Pattern - Component Diagram
Browser renders HTML (generally) and
generates user events caused by mouse clicks
or keyboard entry.

The Controller class (sometimes from a
framework) handles the browser events and
delegates to your Post Back code.

The Post Back code calls the appropriate
Business Service, which returns the Domain
Model to the Post Back code. The Business
Service plus the Domain Model forms the basis
for your Canonical Model.

The Post Back code keeps an instance of the
Domain Model in the Presentation Model and
then navigates to View where the View is
bound to the data and rendered back to the
Browser.

Notice the clean separation of the Presentation
Layer and Services Layer. The Services Layer
can be reused!
Response (HTML)
Browser
Client Layer

Request (POST)
Presentation Layer
Request Handler
Controller
Service
Forward
View
UI Logic
Invoke
Model
Data Binding
Presentation Layer
Services Layer
Object Model
Canonical Model
Business Services
Model
Copyright© 2011 On The Edge Software Consulting
44
The MVC Design Pattern - Sequence Diagram
Controller
Model
(canonical)
The Controller class (which should be
reusable across clients and sometimes from a
framework) handles the browser events and
delegates to your Post Back code.

The Post Back code calls the appropriate
Business Service, which returns the Domain
Model to the Post Back code.

The Post Back code copies (or has) an
instance of the Domain Model to the
Presentation Model and then navigates to View
where the View is bound to the data and
rendered back to the Browser.

Some MVC frameworks allow you to inject
instances of your Model (both Presentation
and Domain as well as the Service) into the
Controller class.
View
Services Model
requestHandler

invokeService
navigateView
Data Model
getProperty
Copyright© 2011 On The Edge Software Consulting
45
The MVP Design Pattern - Component Diagram
Response (HTML)

Browser renders HTML (generally) and
generates user events caused by mouse clicks
or keyboard entry.

An implementation of the View for the HTML
page handles the browser events and
delegates to Post Back code in your Presenter
class.

The Post Back code in the Presenter calls the
appropriate Business Service, which returns
the Domain Model to the Post Back code . The
Business Service plus the Domain Model
forms the basis for your Canonical Model.

The Presenter calls back to the View (via an
Interface Contract) to update the View and then
redirects to the next View using an Application
Controller that renders HTML back to the
Browser.
Browser
Request (POST)
Client Layer
Presentation Layer
View
Contract
Presenter
Service
IView
Model
Updates and
Data Binding
Request Handler
View
Presenter
Event Handler
Invoke
Application Controller
Presentation Layer
Navigation/Work Flow
Services Layer
Object Model
Canonical Model
Business Services
Model
Copyright© 2011 On The Edge Software Consulting
46
Redirect
The MVP Design Pattern - Sequence Diagram
View
Model
(canonical)
Presenter
requestHandler

The Controller class (which should be
reusable across clients and sometimes from a
framework) handles the browser events and
delegates to your Post Back code.

The Post Back code calls the appropriate
Business Service, which returns the Domain
Model to the Post Back code.
requestHandler
Services Model
invokeService
Data Model
getProperty
Copyright© 2011 On The Edge Software Consulting
47

The Post Back code copies an instance of the
Domain Model to the View Model and then
navigates to View where the View is bound to
the data and rendered back to the Browser.

Some MVC frameworks allow you to inject
instances of your Model (both Service and
Domain) into the Controller class.
The MVC and MVP Design Patterns – Some Challenges
Model
(canonical)

What happens if the Model changes?

One challenge in the design patterns is that
there is no simple way to inform the View to
update itself if the Model changes. Recent
frameworks like AJAX Push and the use of the
Observer design pattern do form the
foundation to help solve this problem.

Another challenge is the ability to test the
components when using the design patterns.
You must be able to individually test each of
the components and sometime mock
frameworks are required to simulate the
behavior of MVC and the MVP Frameworks. In
general the MVP design pattern (because it’s
View is interface driven) is more easily testable
then the MVC design pattern.
View
changeEvent
notify
updateView
getProperty
Copyright© 2011 On The Edge Software Consulting
48
Presentation Layer Design – Event Driven Design
Methodology

We will walk thru an Event Driven Methodology in this course. This
approach allows us to cleanly and easily design the Controller class
and supporting Presentation Layer object model.

The steps in the Event Driven Methodology include:

1.
Identify events from the User Interface design
2.
Create table of nouns and verbs for User Interface events
3.
Identify the Entities that will get bound the User Interface
4.
Identify presentation state variables that need to be maintained
5.
Design the Presentation Layer object model class
6.
Design the Controller class
7.
Implement the classes and refactor Application Logic/Rules accordingly
Let’s walk thru a simple example……………..
Copyright© 2011 On The Edge Software Consulting
49
Event Driven Design Methodology – Example
Application/Requirements
First Name:

Example is a simple User Registration screen.

Demographics includes: first name, last name,
address, city, state, zip, and membership number.

Data requirements: first name, last name, city 1-20
characters not null, address 1-40 characters not null,
state valid 2 character USPS state code, zip 5 or 8
character USPS postal code, membership 20
characters not null (see UI rule below).

If membership checkbox is checked membership
number is enabled else disabled.

Avoid screen refreshes if possible.

When click the Registration button register the user
in the system and display an Approval screen
Last Name:
Address:
City:
State:
Zip:
Is Member?
Member #:
Register
Copyright© 2011 On The Edge Software Consulting
50
Event Driven Design Methodology – Step 1



The first step is to identify events from the User Interface design.

Identify any mouse clicks on the User Interface widgets.

Identify any User Interface behavior as a result of other events (UI Rules) either
from mouse clicks or keyboard entry.
In our example the following events can be generated:
1.
When the user clicks the Submit button then [something happens].
2.
When the user clicks the Is Member checkbox then [something happens].
3.
When the page loads then [something happens].
This looks familiar to the Actor/Noun/Verb exercise we learned in the
Requirements Analysis course!
Copyright© 2011 On The Edge Software Consulting
51
Event Driven Design Methodology – Step 2

And then create a table of nouns and verbs for the events.
Actor
UI Widget
Verb
UI Rule
User
Submit Button
click
N/A
User
Is Member
Checkbox
click
N/A
UI
Membership
Number
enable
When Is Member Checkbox is
checked enable Membership
Number else disable
Membership Number
System
Page
loads
N/A
Copyright© 2011 On The Edge Software Consulting
52
Event Driven Design Methodology – Step 3

Identify the Business Entities that are bound to the User Interface.

We are working with the User Entity.
Copyright© 2011 On The Edge Software Consulting
53
Event Driven Design Methodology – Step 4

Identify the state that needs to be maintain in the User Interface.

We need to maintain a list of States.

We need to maintain whether the Member Number field is enabled.

Decide the lifetime of the state variables and determine if they should be
application, request, or session scope.
Copyright© 2011 On The Edge Software Consulting
54
Event Driven Design Methodology – Step 5

Design the Presentation Layer Object Model (or View Model).





The Presentation Layer object model keeps our state variables.
The Presentation Layer object model keeps instances to our Canonical
Object Model.
This allows our Canonical Object Model, updated from the User
Interface, to be passed to our Services Layer (keeping a clean
separation of concerns between our presentation layer and services
layer).
The Canonical Object Model SHOULD NOT be a representation of
screens from your User Interface.
Our Presentation Layer Object Model would be modeled as
follows……..
Copyright© 2011 On The Edge Software Consulting
55
Event Driven Design Methodology – Step 5
class Example 5 Class Diagrams
Presentation Layer Object Model
UserRegistrationView Model
-
enableMembership :boolean
zipCodes :List
user :User
1
Canonical Object Model
1
User
-
id :int
credentials :UserCredentials
creditcard :CreditCard
demographics :UserDemographics
membership :Membership
1
1
1
1
1
1
1
UserDemographics
UserCredentials
-
userID :int
password :char
username :char
-
userID :int
address :char
city :char
firstName :char
lastName :char
postalCode :char
state :char
emailAddress :char
Copyright© 2011 On The Edge Software Consulting
56
1
CreditCard
-
userID :int
expireDate :Date
number :char
name :char
Membership
-
userID :int
number :char
isMember :boolean
Event Driven Design Methodology – Step 6

Design the Presentation Layer Controller class.




Take the Event Table and create methods for your Controller class.
These methods will be called in response to your User Interface events.
Use a consistent naming convention (just like we modeled our Service Model methods).
For example:
 In code: Status = onVerbControl(Noun)
 Status = onClickSubmitButton(UserDemographicsPresentationModel)
 Status = onClickMemberCheckbox(UserDemographicsPresentationModel)
 Status = onPageLoad()
 The return status can be used to direct page navigation or work flow.
 Could we AJAX any of the events to improve the design?
Our Presentation Controller class would be modeled as follows…….
Copyright© 2011 On The Edge Software Consulting
57
Event Driven Design Methodology – Step 6
class Example 6 Class Diagrams
UserRegistrationController
+
+
+
-
onClickSubmitButton(UserDemographicsPresentationModel) : int
onClickMemberCheckbox(UserDemographicsPresentationModel) : int
onPageLoad() : int
membershipNumberUIRule(UserDemographicsPresentationModel) : int
NOTE: This is only a
MODEL. There may be
platform or framework
considerations that
need to be given to the
model when
generating actual
code.
Copyright© 2011 On The Edge Software Consulting
58
Presentation Layer Design – Other
Considerations (1)

What verbs should I use in the Presentation Layer?

Use the ones already defined from the Document Object Model (DOM)!

For example:
1.
onclick => use the Click verb
2.
onfocus => use the Focus verb
3.
onselect => use the Select verb
4.
onkeyup => use the KeyUp verb
5.
Etc……..
Copyright© 2011 On The Edge Software Consulting
59
Presentation Layer Design – Other
Considerations (2)

What are User Interface Rules?


Logic that gets executed in response to User Interface events that cause changes to the
User Interface or changes to the Presentation Layer state.
How do I design User Interface Rules?

Design can be done using server side methods using AJAX.

Design can be done using client side JavaScript (but done with careful thought) and
possibly leverage frameworks such as jQuery to add effects or encapsulate access to the
DOM.
Copyright© 2011 On The Edge Software Consulting
60
Presentation Layer Design – Other
Considerations (3)


Data Validation Rules are often a subject of continued debate.

Implement on the client?

Implement on the server?

Implement in which layer(s)?
To help answer these questions follow these guidelines:

Implement data validation rules once so they can be reused and you don’t introduce
double development time.

At a minimum implement in the Services Layer to promote reusability and eliminate
data quality problems.

Do not decorate your Canonical object model code with data validation rules.

If possible leverage a Framework or Business Rule Engine (BRE).
Copyright© 2011 On The Edge Software Consulting
61
Presentation Layer Design – Some Best Practices (1)

The View will not implement any application logic (but be implemented in the Controller
class).

The View will not utilize scriplets to implement data binding, page conditionals, or other
application logic.

When possible implement the View using xhtml (eliminates any possibility of scriplets and
enforces well formed HTML).

The View should contain the minimal amount of JavaScript required and leverage the MVC
framework for form posts, data validation, and data binding.

The Controller’s publics interface functions should directly map to all of the possible page
events (purely even driven design) such as page initialization, button click handlers, form
posts, etc. All non event handler functions should be declared private in the Controller
class or implemented as reusable public functions in a Utility class.

The Controller will not implement any business logic and should be simply a consumer of
business services that implements the appropriate application logic.
Copyright© 2011 On The Edge Software Consulting
62
Presentation Layer Design – Some Best Practices (2)

The Controller should not directly call a DAO function unless it is to access read only
reference/static data. All other DAO calls should be implemented thru a business façade.

The Controller should always extend from your own Application Framework base class to
encapsulate common application logic or other utility functions.

The Controller event handler functions should only handle Application/Functional
(checked) exceptions. All other System (unchecked) exceptions should be handled by a
global exception handler.

The Model should always extend from your own Application Framework base class to
encapsulate common serialization or other utility functions.

If necessary create a presentation tier specific Model (one that has UI specific attributes
such as model attributes that are of a UI library type such as Struts LabelValueBean). This
UI Model should then contain an instance variable for the cross tier Model with the proper
accessory methods.

Always externalize styles in a style sheet (CSS) versus hard coding them in the markup.
Copyright© 2011 On The Edge Software Consulting
63
Presentation Layer Design – Some Best Practices (3)

Always externalize JavaScript in a file (JS) versus embedding the script in the page (for
reusability and maintainability). Externalizing JavaScript into files can also provide a
performance benefit by reducing page size and providing for cacheable JavaScript files.

Complex application or presentation logic should be implemented using custom tags or
page fragments that can be included in the core page markup.

Only the minimal amount of data validation (is empty, basic type checking, etc.) should be
implemented in JavaScript. All other data validation rules should be implemented using a
server side validation library or business rules engine. Server side validation libraries (tied
to the web tier) should also be avoided to support a robust reusable services design and
leverage a business rules engine to perform data validation. Server side validation logic
implemented in the business tier ensures high data quality when designing reusable
business services.
Copyright© 2011 On The Edge Software Consulting
64
Presentation Layer Design – Some Best Practices (4)

Use JSON as the standard technology to interface Java Objects to JavaScript libraries (see
document references).

Use AJAX to avoid full round trips to the server and eliminate full page refreshes.

Use a commercial or open source AJAX library rather then use a proprietary library. The AJAX
library should support partial page updates and directly integrate with the MVC framework.

Avoid using cookies directly for storing session state in most applications and leverage the HTTP
session on the application server.

Avoid using hidden form variables to store application state (due to potential security
violations).

Use an HTTP POST versus HTTP GET to avoid form submits HTTP GET restrictions and exposing
URL’s to the browser address bar.

Avoid the use of ASP page parameters as this can lead to cross site scripting security issues.
Copyright© 2011 On The Edge Software Consulting
65
Presentation Layer Design – Some Best Practices (5)

Utilize the HTTP session is little as possible to save application state.

For performance intensive business service (or long running service) use a loosely coupled
message based design.

Reference/static data that is displayed in a page (typically via drop downs) should be cached in
the Data Access Tier or database.

Implement optimizations as suggested by Yahoo YSlow (see document references):

Make Fewer HTTP Requests
Use a Content Delivery Network
Add an Expires Header
Gzip Components
Put CSS at the Top

Move Scripts to the Bottom


Avoid CSS Expressions
Make JavaScript and CSS External
Reduce DNS Lookups
Minify JavaScript
Avoid Redirects
Remove Duplicate Scripts

Configure ETags








Copyright© 2011 On The Edge Software Consulting
66
Presentation Layer Design – Some Best Practices (6)

ASP’s and HTML pages should be documented just like code (comment for every
major functional UI component).

All JavaScript functions should be documented with a proper header comments
and include comments for every major functional block of code).

ASP’s should use the ASP comment tag so the comments are not compiled and
included in the HTML page output (to decrease the page size and improve
performance).

The page, request, and session scoped variables should be documented in the
header of the ASP.

Also see the Best Practices that are documented on the EA Sharepoint site…………..
Copyright© 2011 On The Edge Software Consulting
67
Course #5
Designing the Business Services Layer
Copyright© 2011 On The Edge Software Consulting
68
Course Objectives

Learn what a Business Service is.

Learn what Service Orchestration is.

Learn how to decompose requirements to design a Business Service.

Learn how Transaction Management is handled in a Business Services.

Learn some of the Business Services Layer best practices.

Lab: Design the Business Services Layer for the simple Business Scenario.
Copyright© 2011 On The Edge Software Consulting
69
Introduction to the Business Services Layer

What is the Business Services Layer?


What is a Business Service?


The business services layer is usually one of the tiers in a multi-layer architecture. This
layer separates the business logic from other modules, such as the data access layer and
the presentation layer (user interface). By doing this, the business logic of an application
can often withstand modifications or replacements of other layers.
Some form of encapsulated behavior that resolves a business request. The encapsulated
behavior can implement business logic, business rules, or business workflow and be
requested synchronously (request-reply) or asynchronously (fire and forget).
What is a Business Rule?

Is a statement that defines or constrains some aspect of the business. It is intended to
assert business structure or to control or influence the behavior of the business.
Copyright© 2011 On The Edge Software Consulting
70
Introduction to Business Services Orchestration

What is a Business Process and Orchestration?

A Business Process is the highest level business function in the Business Services Layer
that is generally called by one or more applications.

A Business Process executes a series of lower level (reusable) Business Services thru a
service orchestration.

The service orchestration is the arrangement and management (work flow) of the
business services and business rules that are executed at runtime to implement the
business process.
Copyright© 2011 On The Edge Software Consulting
71
Design By Contract

What is Design By Contract?

Prescribes that software designers should define formal, precise and verifiable interface
specifications for software components, which extend the ordinary definition of abstract
data types with pre-conditions, post-conditions and invariants.

One of the core principles behind a SOA.

Common in Web Services and defined by a WSDL.

At a minimum mandates that all services be first defined by an Interface or Abstract
class.

Interfaces are also required to support Dependency Injection.

Must account for changes and have a solid service versioning strategy.
Copyright© 2011 On The Edge Software Consulting
72
Services Driven Design Methodology – Example
Application/Requirements

Example is a simple User Registration screen that
supports the following business functionality.

As a user when the Register button is clicked the
following business logic should be run.
First Name:
Last Name:
Address:
1.
Validate all data meets data validation rules.
City:
2.
Create a User in the system.
State:
3.
If User is a Member then
Zip:
Email:
Is Member?
Member #:
Register
Copyright© 2011 On The Edge Software Consulting
73
a.
Create a Membership in the system.
b.
Send an email to User with Member details.
Business Services Interface Design
1. As a <role>
I need <functionality>
So <value statement>
2. As a user I need to register a user so a user and membership can be created in the system.
3. Domain, actor, verb, noun decomposition:
•
An Actor in a Domain can perform an operation with data
•
Operations are methods in your Domain classes that use Nouns as parameters
•
Operations define the behavior of your system (executing the business logic)
•
In code: Noun = Domain.Verb(Noun)
•
Status = UserService.register(User)
We can leverage UML Class Diagrams to model our Service Interface Design.
Copyright© 2011 On The Edge Software Consulting
74
Business Service Design – UML Class Diagram
class Example 7 Class Diagrams
«interface»
UserServ iceInterface
UserServ ice
+
+
+
+
+
+
registerUser(User) :void
validateUser(User) :void
createUser(User) :void
registerUser(User) :void
validateUser(User) :void
createUser(User) :void
«interface»
MembershipServ iceInterface
MembershipServ ice
+
+
+
+
createMembership(int, Membership) :void
validateMembership(int, Membership) :void
createMembership(int, Membership) :void
validateMembership(int, Membership) :void
«interface»
EmailServ iceInterface
EmailServ ice
+
+
«interface»
BusinessRulesServ iceInterface
BusinessRulesServ ice
+
+
send(EmailInfo) :void
send(EmailInfo) :void
runDataValidationRules(RuleSetInfo) :void
Copyright© 2011 On The Edge Software Consulting
75
runDataValidationRules(RuleSetInfo) :void
Business Process and Orchestration Design


How do we design and implement a Business Process and
Orchestration?
1.
Model in UML and implement in classes and functional logic/programming.
2.
Model in UML to create a BPEL (Business Process Execution Language) and implement
in a BPEL Engine.
3.
Model in Visual Studio and implement using Microsoft Windows Work Flow.
4.
Model in IBM Business Process Modeler and implement using IBM Process Server.
5.
There are a number of other products on the market…..
We can leverage UML Activity and Sequence Diagrams to model our
Business Process and Orchestration.
Copyright© 2011 On The Edge Software Consulting
76
Business Process and Orchestration Design – UML
Activity Diagram
act Example 7 Class Diagrams
Register User
T ransaction Boundary
encompasses the entire
business process.
T hrow Data Validation
Exception
Data Validation Rules
Exception Handler
Run Data Validation Rules
Exception
T hrow Create User Failed
Exception
Create User Exception Handler
Exception
Create User
If Membership
T hrow Create Membership
Failed Exception
Create Membership
Exception Handler
[No]
[Yes]
Exception
Create Membership
T hrow Send Membership
Exception
Send Membership
Exception Handler
Exception
Email Membership
End Register User
Copyright© 2011 On The Edge Software Consulting
77
Business Process and Orchestration Design – UML
Sequence Diagram
sd Example 7 Class Diagrams
UserService
BusinessRulesService
MembershipService
EmailService
Application
registerUser(User)
createUser(User)
validateUser(User)
runDataValidationRules(RuleSetInfo)
{if member}
createMembership(MembershipInfo)
validateMembership(MembershipInfo)
runDataValidationRules(RuleSetInfo)
send(EmailInfo)
Register User
Orchestration all
running within a single
transaction context
Copyright© 2011 On The Edge Software Consulting
78
Transaction Management and Transaction Boundaries

What is Transaction Management?

A business transaction is a single logical unit of work within a business context that
needs to be completed in its entirety.

A business transactions lifetime can span across one or more business services or one
ore more business processes.

The total lifetime of a business transaction is equal to the longest running synchronous
business service operation within the business service or orchestration.

The boundaries of a transaction should be defined and configured externally (outside of
code) in your business services and business processes. In some cases a framework or
platform may provide transaction management services that your architecture can
leverage.

A Data Access Component does NOT define a transaction boundary and in fact a Data
Access Component should NOT have any transaction logic or transaction technology
within its implementation.
Copyright© 2011 On The Edge Software Consulting
79
Business Services Layer Design – Some Best Practices (1)

Business services should not import any presentation tier packages or packages that inject
undesired dependencies that cross pollute the implementation.

Business service functions should always represent application or domain “real world”
business use cases.

Business services should be designed and programmed for reusability across applications.

Business services should always be exposed via a well defined contract using interfaces or
interface description languages such as WSDL.

The Business services should always extend from your own Application Framework base
class to encapsulate common application logic or other utility functions.

For performance reasons expose business services as a local service and alternatively as a
remote service, preferably as a Web Service.

For adaptability expose course grained business service functions (via Data Transfer
Objects) versus fine grained API’s.
Copyright© 2011 On The Edge Software Consulting
80
Business Services Layer Design – Some Best Practices (2)

A dependency injection (DI) framework should be used to inject code dependencies. A DI framework
can eliminate most infrastructure code such as the implementation of factories, singletons, and
service locators.

Avoid coding infrastructure code such as Transaction Management and Security code in the
implementation of your business services.

Inject mock objects (such as DAO’s or External Interfaces) so you can unit test your business services
independently of the entire application or application server.

Always program to business/service or data access object interfaces and not concrete
implementations.

Use a Session Façade to provide a service access layer that hides the complexity of underlying
interactions, and consolidates many logical communications into one larger physical communication.

Use a Business Delegate to reduce coupling between presentation tier clients and business services.
The Business Delegate hides the underlying implementation details of the business service.

Use the Decorator Pattern to make it possible to extend (decorate) the functionality of a class at
runtime.
Copyright© 2011 On The Edge Software Consulting
81
Business Services Layer Design – Some Best Practices (3)

For long running service functions implement using a message based pattern (such as a
Message Queue) to loosely couple the client from the service execution.

Declare transaction boundaries declaratively and not programmatically.

Business services should not be aware of or assume transaction boundaries.

Transaction management cleanup should always be implemented in a finally block.
Copyright© 2011 On The Edge Software Consulting
82
Course #6
Designing the Data Services Layer
Copyright© 2011 On The Edge Software Consulting
83
Course Objectives

Learn the common CRUD verbs used in the Data Services Layer.

Learn how to apply the Data Access Object design pattern to the Data
Services Layer.

Learn some of the Data Services Layer best practices.

Lab: Design the Data Services Layer for the simple Business Scenario.
Copyright© 2011 On The Edge Software Consulting
84
Introduction to Data Access Services

What are Data Access Objects or Data Services?

They persists business entities into a data store such as a database.

They are defined using standard CRUD (verbs)operations

Create: add or insert operation

Read: read operation (and finder operation)

Update: update operation

Delete: delete operation

They should be transaction agnostic.

They should not expose persistence technology to their client.

They should hide their persistence technology details in their implementation.

There should be a DAO for each core business entity in your system.

They should work with core business entities (Entity Driven Design) and not be fine
grained in nature.
Copyright© 2011 On The Edge Software Consulting
85
Data Access Object Design Pattern
Copyright© 2011 On The Edge Software Consulting
86
Using Data Access Services from within a Business
Service
Client
Begin Tx
Interface + Implemtation
Business Service 1
Facade
Business
Rules
Config
or
Annotations
TO
Interface
Interface
Interface
Interface
DAO 1
DAO 2
DAO 3
Service 2
Transaction Mgr
Dependency
Injection:
DAO1, DAO2,
DAO3, and
Service 1 and 2
TO
System
Exception
Transaction Boundary
Application
Exception
End Tx
Config
or
Annotations
Copyright© 2011 On The Edge Software Consulting
87
Data Access Services Architecture
Client
System
Exception
Lookup
VO
Factory
Interface
Interface
Optimistic
Cache
Locking
Data Access Object
(SQL, SP, etc.)
Config
CRUD operations
Database/File System
Copyright© 2011 On The Edge Software Consulting
88
DI (if available)
SQL/Queries
or
Annotations
Entity Driven Design Methodology – Example
Application/Requirements

Example is a simple User Registration screen that
supports the following business functionality.

As a user when the Register button is clicked the
following business entities should be persisted.
First Name:
Last Name:
Address:
1.
Persist a User Entity in the database.
City:
2.
If User is a Member then
a.
State:
Zip:
Email:
Is Member?
Member #:
Register
Copyright© 2011 On The Edge Software Consulting
89
Persist a Membership Entity in the database.
Data Access Object Design
1. We will start by defining our persistence domain and verb:
 We will use the standard CRUD verbs in our design.
 We will persist a User business entity and Membership business entity in our design
 In code: Status = ServiceDomain.Verb (Entity)
1. Status = UserDataAccessService.create (User)
2. Status = MembershipDataAccessService.create (Membership)
We can leverage UML Class Diagrams to model our Data Access Service Design.
Copyright© 2011 On The Edge Software Consulting
90
Data Access Service Design – UML Class Diagram
class Example 8 Class Diagrams
UserDataAccessObj ect
+
+
+
+
create(BaseEntity) : boolean
read(int) : BaseEntity
update(BaseEntity) : int
delete(Integer) : int
«interface»
DataAccessObj ectInterface
+
+
+
+
MembershipDataAccessObj ect
+
+
+
+
create(BaseEntity) : boolean
read(int) : BaseEntity
update(BaseEntity) : int
delete(Integer) : int
Copyright© 2011 On The Edge Software Consulting
91
create(BaseEntity) : boolean
read(int) : BaseEntity
update(BaseEntity) : int
delete(Integer) : int
Data Access Services Layer Design – Some Best Practices
(1)

Use an approved persistence technology or ORM framework.

Follow the industry standard DAO design pattern.

A DAO should not expose any implementation or persistence technology details (such as
JDBC, ODBC, Stored Procedure, Database dialect, or ORM framework code) in the method
signatures.

A DAO’s method implementation should encapsulate all technology details and specifics. A
well designed DAO method should be able to be re-implemented using a different
implementation technology (SQL, Stored Procedure) and database dialect without
impacting its method signature or calling client.

A DAO should not implement any transaction management code and not be aware or
define any transaction boundaries.

The DAO should always extend from your own Application Framework base class to
encapsulate common data access logic.
Copyright© 2011 On The Edge Software Consulting
92
Data Access Services Layer Design – Some Best Practices
(2)

Externalize your SQL into external property or configuration files.

A DAO’s method should correspond to CRUD (create/read/update/delete) operation.

Use a common DAO method naming convention for all CRUD operations:

Create operation: EntityName.create ()

Read operation: EntityName.findByXXX()

Update operation: EntityName.update()

Delete operation: EntityName.deletByXXX()

Use course grained (Transfer Object/Value Object/Object Model) API’s for all
create/update CRUD operations (unless you need a high performance fine grained API for
a single attribute update operation, delete operation, or for read/finder operations).

Use the Optimistic Record Locking design pattern (most ORM frameworks support this
using a simple configuration parameter) for all update operations (unless it is guaranteed
that multiple system/users cannot asynchronously update the same record at the same
time).
Copyright© 2011 On The Edge Software Consulting
93
Data Access Services Layer Design – Some Best Practices
(3)

All database cleanup (prepared statements, result sets, etc.) should be cleaned up in a
finally block

Do not throw vendor specific exceptions and wrap vendor specific error codes reported by
vendor exceptions in application specific (vendor neutral) error codes.

Use prepared statements.

Do not assemble SQL statements using the String concatenation (+ operator) but instead
use a StringBuffer class.

Static/reference data that is frequently accessed should be cached by the DAO, either as
an internal implementation detail of the DAO or by using database capabilities. When
database portability and database independence needs to be achieved then caching
should be implemented outside of the database. Off the shelf caching libraries or the ORM
frameworks capabilities should be leveraged in the caching solution.

Make sure the database isolation levels are set appropriate for your database and
application
Copyright© 2011 On The Edge Software Consulting
94
Course #7
Putting It All Together
Copyright© 2011 On The Edge Software Consulting
95
Course Objectives

Learn where a Conceptual/Solutions Architecture fits into the Design phase.

Review the complete design for our User Registration Example Application.

Learn the importance of an Application Framework and how this can simplify
our future designs.

Learn what to consider in a design to include Operational Support.

Reference materials.
Copyright© 2011 On The Edge Software Consulting
96
But wait……..shouldn’t we have done a Conceptual
Architecture first?
Detailed Design Here!
Conceptual/Solutions Architecture Here!
(using a UML Component diagram)
Copyright© 2011 On The Edge Software Consulting
97
Conceptual Architecture Model – UML Component
Diagram
Copyright© 2011 On The Edge Software Consulting
98
What Does Our Complete Design Look Like for our
Presentation Layer?

Our Presentation Layer Design:

Presentation Layer was designed using an Event Driven Methodology.

Presentation Layer was designed using the MVC design pattern.

Presentation Layer was designed using its own Object Model that referenced our
Canonical Object Model.

Design included: 2 Markup pages, 1 Object Model class, and 1 Event Controller class.

Design artifacts: UI Wireframe, UML Class diagram.
Copyright© 2011 On The Edge Software Consulting
99
Presentation Layer Design – UI Design and Data
Requirements

First Name:
Last Name:
Address:
City:
State:
Zip:
Email:
Is Member?
Member #:
Register
Copyright© 2011 On The Edge Software Consulting
100
Example is a simple User Registration screen.

With defined data validation rules.

With defined UI rules.

With navigation to an Approval screen upon successful
registration of the User.
Presentation Layer Design - Event Driven Design
class Example 6 Class Diagrams
UserRegistrationController
+
+
+
-
onClickSubmitButton(UserDemographicsPresentationModel) : int
onClickMemberCheckbox(UserDemographicsPresentationModel) : int
onPageLoad() : int
membershipNumberUIRule(UserDemographicsPresentationModel) : int
NOTE: This is only a
MODEL. There may be
platform or framework
considerations that
need to be given to the
model when
generating actual
code.
Copyright© 2011 On The Edge Software Consulting
101
What Does Our Complete Design Look Like for our
Business Layer?

Our Business Services Layer Design:

Business Services Layer was designed using a Design By Contract Methodology.

Business Service Layer leveraged a core Business Orchestration.

Design included: 2 Business Service interface classes and 2 Business Service
implementation classes.

Design included: 2 utility interface classes and 2 utility implementation classes.

Design artifacts: UML Activity diagram, UML Class diagram, UML Sequence diagram.
Copyright© 2011 On The Edge Software Consulting
102
Business Service Layer Design – Design By Contract
class Example 7 Class Diagrams
«interface»
UserServ iceInterface
UserServ ice
+
+
+
+
+
+
registerUser(User) :void
validateUser(User) :void
createUser(User) :void
registerUser(User) :void
validateUser(User) :void
createUser(User) :void
«interface»
MembershipServ iceInterface
MembershipServ ice
+
+
+
+
createMembership(int, Membership) :void
validateMembership(int, Membership) :void
createMembership(int, Membership) :void
validateMembership(int, Membership) :void
«interface»
EmailServ iceInterface
EmailServ ice
+
+
«interface»
BusinessRulesServ iceInterface
BusinessRulesServ ice
+
+
send(EmailInfo) :void
send(EmailInfo) :void
runDataValidationRules(RuleSetInfo) :void
Copyright© 2011 On The Edge Software Consulting
103
runDataValidationRules(RuleSetInfo) :void
End to End Business Transaction and Orchestration –
UML Sequence Diagram
sd Example 8 Class Diagrams
UserService
:UserDataAccessObject
BusinessRulesService
MembershipService
:MembershipDataAccessObject
Application
registerUser(User)
validateUser(User)
runDataValidationRules(RuleSetInfo)
createUser(User)
create(BaseEntity) :boolean
opt Membership Business Rule
[if membership is true]
createMembership(MembershipInfo)
runDataValidationRules(RuleSetInfo)
validateMembership(MembershipInfo)
create(BaseEntity) :boolean
send(EmailInfo)
DataVakidationException
CreateUserFailedException
CreateMembershipFailedException
SendMembershipFailedException
Register User
Orchestration all
running within a single
transaction context
Copyright© 2011 On The Edge Software Consulting
104
EmailService
What Does Our Complete Design Look Like for our Data
Access Layer?

Our Data Access Services Layer Design:

Data Access Service Layer was designed using an Entity Driven Methodology.

Data Access Service Layer was designed using the Data Access Object design pattern.

Design included: 1 abstract DAO class and 2 Data Access implementation classes.

Design artifacts: UML Class diagram.
Copyright© 2011 On The Edge Software Consulting
105
Data Access Service Layer Design – Entity Driven Design
class Example 8 Class Diagrams
UserDataAccessObj ect
+
+
+
+
create(BaseEntity) : boolean
read(int) : BaseEntity
update(BaseEntity) : int
delete(Integer) : int
«interface»
DataAccessObj ectInterface
+
+
+
+
MembershipDataAccessObj ect
+
+
+
+
create(BaseEntity) : boolean
read(int) : BaseEntity
update(BaseEntity) : int
delete(Integer) : int
Copyright© 2011 On The Edge Software Consulting
106
create(BaseEntity) : boolean
read(int) : BaseEntity
update(BaseEntity) : int
delete(Integer) : int
What Does Our Complete Design Look Like for our
Canonical Model?

Our Canonical Model Design:

Canonical Object Model was designed by decomposing our Business Requirements
using a Subject/Noun/Verb analysis paradigm.

Design included: 5 Object Model classes.

Design artifacts: UML Class diagram.
Copyright© 2011 On The Edge Software Consulting
107
Object Model Design (Presentation Layer Model and
Canonical Model)
class Example 5 Class Diagrams
Presentation Layer Object Model
UserRegistrationView Model
-
enableMembership :boolean
zipCodes :List
user :User
1
Canonical Object Model
1
User
-
id :int
credentials :UserCredentials
creditcard :CreditCard
demographics :UserDemographics
membership :Membership
1
1
1
1
1
1
1
UserDemographics
UserCredentials
-
userID :int
password :char
username :char
-
userID :int
address :char
city :char
firstName :char
lastName :char
postalCode :char
state :char
emailAddress :char
Copyright© 2011 On The Edge Software Consulting
108
1
CreditCard
-
userID :int
expireDate :Date
number :char
name :char
Membership
-
userID :int
number :char
isMember :boolean
Summary of our Complete Design

We modeled the behavior and structure of our entire application using
all the basic UML models (Component, Use Case, Class, Activity,
Sequence) where each model served its own purpose and function
during the Design phase.

We designed a pretty basic application using 8 application classes, 4
interfaces, 1 abstract class, and 5 object model classes (total of 18
classes plus 2 markup pages).

How can we further improve our design or simplify our design?
Copyright© 2011 On The Edge Software Consulting
109
How can we improve or simplify our design?

We could (and should) refactor common code into an Application
Framework and as reusable classes that are application independent.

Our Application Framework could contain:

1.
A common base class for our Event Controller class, Object Model classes, Business
Services, and Data Access Services. Might not have implementation but in the future
this can be a placeholder for other refactored code.
2.
An abstract class that implements the CRUD operations for our Data Access Service.
3.
A common and reusable Email Service.
4.
A common and reusable Business Rules Service.
5.
A common and reusable Logging Service.
6.
A common and reusable Tracing Service.
We will reduce the number of classes we have to design in our next
application by 2 interfaces, 7 classes, and 1 abstract class.
Copyright© 2011 On The Edge Software Consulting
110
How can we improve building Operational Support into
our design?

Operational support for an application does not happen by accident ,
is not build in automatically, but must be architected into the solution
from the beginning of your Architecture and Design phases.

Care and thought must be given to the following:

Can you log and trace a transaction from end to end(UI to persistence)?

Where do the log files get saved to?

Where do the trace files get save to?

How easy is it to configure different logging and tracing levels?

How easy is it to configure log rotation settings?

What happens to your logging if you cross tiers in your architecture?

Do you have a common logging or tracing (or debug) statement format?

Can your log or trace files be easily searched, aggregated, and reported on?

Can your exception/crash logs be tracked to a desired trouble ticket?
Copyright© 2011 On The Edge Software Consulting
111
Other Reference Materials
Copyright© 2011 On The Edge Software Consulting
112
What Did You Learn In These Courses?
1.
2.
3.
4.
5.
Business Requirements Analysis:
a)
Decompose requirements into Subjects, Nouns, Verbs and build a Canonical Model.
b)
UML Use Case Diagrams (for modeling requirements)
c)
UML Component Diagram (for high level solution architecture)
Presentation Layer Design:
a)
MVC and MVP Design Patterns
b)
Event Driven Design Methodology
c)
UML Class Diagrams (for modeling structure)
Business Services Layer Design:
a)
Design By Contract Methodology
b)
Business Services , Business Orchestration, and Transaction Management
c)
UML Activity Diagram and UML Sequence Diagram (for modeling behavior)
Data Access Services Layer:
a)
Data Access Object Design Pattern
b)
Entity Driven Design Methodology
Others:
a)
Importance of an Application Framework and Operational Support
b)
Industry Best Practices
Copyright© 2011 On The Edge Software Consulting
113
Copyright© 2011 On The Edge Software Consulting
114
Resources

http://davidhayden.com/blog/dave/archive/2004/12/10/680.aspx

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

http://en.wikipedia.org/wiki/Non-functional_requirement

http://msdn.microsoft.com/en-us/library/ff647543.aspx
Copyright© 2011 On The Edge Software Consulting
115