copyright© 2011 on the edge software consulting web application 101 design training class

Copyright© 2011 On The Edge Software ConsultingCopyright© 2011 On The Edge Software Consulting

Web Application 101 DesignTraining Class


Agenda

2

2 Course #2 – Requirements Analysis.

3 Course #3 – N-Layer Architecture.

4 Course #4 – Presentation Layer Design.

1 Course #1 – SDLC Process.

5 Course #5 – Business Services Layer Design.

6 Course #6 – Data Access Services Layer Design.

7 Course #7 – Putting it All Together.


Course #1SDLC Process

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.

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.

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.

6


Phases of the SDLC

7


Iterative SDLC Model The Iterative SDLC Model is a good compromise for many projects.

o Due to the size of the projecto Due to the maturity level of the organizationo And still enforce a level of rigor and discipline required for building a new project

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

9


Some YouTube Entertainment……………

The Rise and Fall of Waterfall http://www.youtube.com/watch?v=X1c2--sP3o0

10


Course #2Requirements Analysis

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.

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!13


Example Business Scenario

14

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.


Decomposing a Business Scenario…….into text based Use Cases

15

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+)


Decomposing Use Cases…..into a list of Actors/Nouns/Verbs

16

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


Decomposing Use Cases…..into a UML Use Case Diagram

17

uc Example Use Cases

Log In

User

Register

Users(Subjects)

Nouns(Entities)

Verbs(Operations)

{Credentials}

{Demographic Info}


Decomposing Nouns…….into Business Entities

18

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.


Decomposing Business Entities…..into a UML Class Diagram

19

class Example Class Diagrams

UserCredentials

- userID :int- password :char- username :char

UserDemographics

- userID :int- address :char- city :char- firstName :char- lastName :char- postalCode :char- state :char- emailAddress :char

CreditCard

- userID :int- expireDate :Date- number :char- name :char

User

- userID :int- credentials :UserCredentials- creditcard :CreditCard- demographics :UserDemographics

Valid User credentials must exist for the User.

Valid demographics must exist for the User.

If the User does not specify a Credit Card then the User will be required to pay with a Check.

1

0

1

1

1

1


Decomposing Subjects and Verbs…….into Business Services

20

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


Decomposing Business Entities…..into a UML Class Diagram

21

class Example 2 Class Diagrams

User

- userID :int- credentials :UserCredentials- demographics :UserDemographics- creditcard :CreditCard

+ logIn(UserCredentials) :void+ register(UserDemographics) :void

UserCredentials


CreditCard


Mix of attributes and operations.

UserDemographics


1

1

1

0

1

1


Improved Business Services

22

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


Improved list of Actors/Nouns/Verbs – add a Business Domain

23

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


Improved Business Services

24

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


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


Improved UML Class Diagram – Canonical Model

25


SecurityServ ice

+ logIn(UserCredentials) : boolean

UserServ ice

+ register(User) : boolean

ProductServ ice

+ order() : void+ select() : void

Object Model Service Model

class Example Class Diagrams

UserCredentials


UserDemographics


CreditCard


User

- userID :int- credentials :UserCredentials- creditcard :CreditCard- demographics :UserDemographics

Valid User credentials must exist for the User.

Valid demographics must exist for the User.

If the User does not specify a Credit Card then the User will be required to pay with a Check.

1

0

1

1

1

1


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)

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.

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

28


Course #3N-Layer Architecture

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.

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.

31

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.


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.

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

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.

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.

36


N Layer Application Architecture - .NET

37

Go

vernan

ce, S

tandards, Policies, B

est Practices,

Security, S

teering Com

mittees, Tools, etc.

Client Layer (Desktop/Mobile/Browser)User Interface, (Minimal) Client Side Validation, AJAX, UI Rules

Presentation Layer (PL)User Interface, UI Event Handlers, UI Rules, Navigation

Business/Services Layer (BLL)Business Logic, Business Rules, Workflow, Data Validation

Referen

ce Arch

itecture

Fram

eworks, D

esign Patterns, etc.

SilverLightMVC 2

ASP.NET

Guided ByGoverned By

App

licatio

n Fram

ework

Custom

Reusable Library

Event Based Design

Design By ContractUnity Framework (IoC)Workflow Foundation

Comm. Foundation

Entity Driven Design

Entity Framework (ORM)LINQ

ADO.NET

AJAXjQuery

CSS

RIA Design

Canonical Object Model

HTTP/HTTPS POST

Local POCO, SOAP, REST

Forms

Microsoft E

nterprise Library

Reusable A

pplication Blocks

Data Access/Services Layer (DAL)CRUD Data Persistence

OperationalDatabase

Business EntityMedia

Integration TierOrchestration

(Workflow*, Rules*)

.NET DB Factories

Cache

Optional SOAP, REST


Data Model

External SystemsInterfaces, Feeds, Printers

SOAP, .X12, ETC

SOAP, REST



N Layer Application Architecture – Silverlight RIA

38

Go

vernan

ce, S

tandards, Policies, B

est Practices,

Security, S

teering Com

mittees, Tools, etc.

Client Layer (Desktop/Mobile)User Interface, Rules*, Navigation, State

RIA Business/Services LayerRIA Web Services & Logic, Rules*, Workflow*

Business/Services Layer (BLL)Web Services & Logic, Rules*, Workflow*

Data Access/Services Layer (DAL)CRUD Data Persistence

Referen

ce Arch

itecture

Fram

eworks, D

esign Patterns, etc.

Workflow FoundationComm. Foundation

Guided ByGoverned By

App

licatio

n Fram

ework

Custom

Reusable Library

OperationalDatabase

Design By Contract

Design By Contract


Entity Driven DesignADO.NET

SilverlightRIA Design

Business EntityMedia

Integration TierOrchestration

(Workflow*, Rules*)


.NET DB Factories

Cache

SOAP, REST

Optional SOAP, REST

* Rules are retrieved from a central repository. Includes validation by ruleset.

Presentation Model SOAP, REST


Silverlight Application Framework

Data Model

External SystemsInterfaces, Feeds, Printers

SOAP, .X12, ETC

SOAP, REST


Design By Contract



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

39


Course #4Designing the Presentation Layer

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.

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?

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

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!

44

Browser

Controller View

Business Services Model

Object Model

Request (POST)

Forward

Response (HTML)

Invoke

Model Data Binding

Services Layer

Presentation Layer

Request Handler

Service UI Logic

Canonical Model

Client Layer

Presentation Layer


The MVC Design Pattern - Sequence Diagram 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.

45

Controller Model(canonical) View

requestHandlerinvokeService

navigateView

getProperty

Services Model

Data Model


The MVP Design Pattern - Component Diagram 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.

46

Browser

Presenter View

Business Services Model

Object Model

Request (POST)

Redirect

Response (HTML)

Invoke

ModelUpdates andData Binding

Services Layer

Presentation Layer

Event HandlerService

IView

Canonical Model

Client Layer

Presentation Layer

ViewContract

Application Controller

Presenter

Navigation/Work Flow

Request Handler


The MVP Design Pattern - Sequence Diagram 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 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.

47

View Presenter Model(canonical)

requestHandlerrequestHandler

invokeService

getProperty

Services Model

Data Model


The MVC and MVP Design Patterns – Some Challenges

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.

48

Model(canonical) View

changeEvent

updateView

getProperty

notify


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

49


Event Driven Design Methodology – Example Application/Requirements

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

50

First Name:

Last Name:

Address:

City:

State:

Zip:

Is Member?

Member #:

Register


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!

51


Event Driven Design Methodology – Step 2 And then create a table of nouns and verbs for the events.

52

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


Event Driven Design Methodology – Step 3 Identify the Business Entities that are bound to the User Interface.

We are working with the User Entity.

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.

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

55



56



Presentation Layer Object Model

UserCredentials


UserDemographics


CreditCard


User

- id :int- credentials :UserCredentials- creditcard :CreditCard- demographics :UserDemographics- membership :Membership

Membership

- userID :int- number :char- isMember :boolean

UserRegistrationViewModel

- enableMembership :boolean- zipCodes :List- user :User

1

1

1

1

1

1

1

1

1

1


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

57



58


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 themodel when generating actual code.


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

59



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.

60



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

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.

62



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



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.

64



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



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

66



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…………..67


Course #5Designing the Business Services Layer

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.

69


Introduction to the Business Services Layer What is the Business Services Layer?

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.

What is a Business Service? 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.

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.

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.

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.

1. Validate all data meets data validation rules.

2. Create a User in the system.

3. If User is a Member then

a. Create a Membership in the system.

b. Send an email to User with Member details.

73

First Name:

Last Name:

Address:

City:

State:

Zip:

Is Member?

Member #:

Register

Email:


Business Services Interface Design

74

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


• In code: Noun = Domain.Verb(Noun)

• Status = UserService.register(User)

We can leverage UML Class Diagrams to model our Service Interface Design.


Business Service Design – UML Class Diagram

75


UserServ ice

+ registerUser(User) :void+ validateUser(User) :void+ createUser(User) :void

MembershipServ ice

+ createMembership(int, Membership) :void+ validateMembership(int, Membership) :void

EmailServ ice

+ send(EmailInfo) :void

BusinessRulesServ ice

+ runDataValidationRules(RuleSetInfo) :void

«interface»UserServ iceInterface


«interface»MembershipServ iceInterface


«interface»EmailServ iceInterface


«interface»BusinessRulesServ iceInterface



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.

76


Business Process and Orchestration Design – UML Activity Diagram

77

act Example 7 Class Diagrams

Register User

Run Data Validation Rules

End Register User

Throw Create User FailedException

Create User Exception Handler

Throw Create User FailedException

Throw Create MembershipFailed Exception

Create Membership Exception Handler

Throw Create MembershipFailed Exception

Create User

Create Membership

Email Membership

Throw Send MembershipException

Send Membership Exception Handler

Throw Send MembershipException

Throw Data ValidationException

Data Validation Rules Exception Handler

Throw Data ValidationException

Transaction Boundary encompasses the entirebusiness process.

If Membership [No]

Exception

[Yes]

Exception

Exception

Exception


Business Process and Orchestration Design – UML Sequence Diagram

78

sd Example 7 Class Diagrams

UserService BusinessRulesService MembershipService EmailService

Application

{if member}

Register User Orchestration all running within a single transaction context

registerUser(User)

createUser(User)

validateUser(User)runDataValidationRules(RuleSetInfo)

createMembership(MembershipInfo)

validateMembership(MembershipInfo)

runDataValidationRules(RuleSetInfo)

send(EmailInfo)


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.

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.

80



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.

81



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.

82


Course #6Designing the Data Services Layer

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.

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.

85


Data Access Object Design Pattern

86


Using Data Access Services from within a Business Service

87

SystemException

ApplicationException

Business Service 1

DAO 1 DAO 2 DAO 3 Service 2

Transaction M

gr

Tra

nsac

tion

Bou

ndar

y

Begin Tx

End Tx

Facade

Interface Interface Interface Interface

Dependency Injection:

DAO1, DAO2, DAO3, and

Service 1 and 2

Interface + Implemtation

Business Rules

Client

TO

TO

Configor

Annotations

Configor

Annotations


Data Access Services Architecture

88

SystemException

Interface

Data Access Object(SQL, SP, etc.)

Interface

Factory

Client

Lookup

Database/File System

Cache

CRUD operationsConfig

SQL/Queriesor

Annotations

VO

DI (if available)

Optimistic Locking


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.

1. Persist a User Entity in the database.

2. If User is a Member then

a. Persist a Membership Entity in the database.

89

First Name:

Last Name:

Address:

City:

State:

Zip:

Is Member?

Member #:

Register

Email:


Data Access Object Design

90

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.


Data Access Service Design – UML Class Diagram

91


UserDataAccessObject

+ create(BaseEntity) : boolean+ read(int) : BaseEntity+ update(BaseEntity) : int+ delete(Integer) : int

«interface»DataAccessObjectInterface


MembershipDataAccessObject



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.

92



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

93



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

94


Course #7Putting It All Together

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.

96


But wait……..shouldn’t we have done a Conceptual Architecture first?

97

Conceptual/Solutions Architecture Here!(using a UML Component diagram)

Detailed Design Here!


Conceptual Architecture Model – UML Component Diagram

98

cmp Example 8 Class Diagrams

Canonical Model

«Canonical Mod...Membership

«Canonical Mod...User

Business Serv ices

«Business Service»UserServ ices

UserServiceInterface

«Business Service»Membership

Serv ices

MembershipServiceInterface

«Business Servic...EmailServ ices

EmailServiceInterface

Register User Presentation Components

«Presentation Object Model»User Registration Model

«ASP/JSP»User Registration

Page

«ASP/JSP»Approv al Page

«Event Handler»Controller Class

«UI Design»User Registration

Wireframe

«UI Design»Approval Page

Wireframe

This is our reusable Enterprise Canonical Object Model. See Sharepoint site for documentation.

This is our reusable Enterprise Canonical Services Model. See Sharepoint site for documentation.

Navigationbind to

«use»

«use»

UI Event (Post backs)

Invoke

Invoke

Invoke


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.

99


Presentation Layer Design – UI Design and Data Requirements

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.

100

First Name:

Last Name:

Address:

City:

State:

Zip:

Is Member?

Member #:

Register

Email:


Presentation Layer Design - Event Driven Design

101


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 themodel when generating actual code.


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.

102


Business Service Layer Design – Design By Contract

103


UserServ ice


MembershipServ ice


EmailServ ice


BusinessRulesServ ice


«interface»UserServ iceInterface


«interface»MembershipServ iceInterface


«interface»EmailServ iceInterface


«interface»BusinessRulesServ iceInterface



End to End Business Transaction and Orchestration – UML Sequence Diagram

104

sd Example 8 Class Diagrams

BusinessRulesService MembershipService EmailService

Application

:UserDataAccessObject :MembershipDataAccessObjectUserService

Register User Orchestration all running within a single transaction context

DataVakidationExceptionDataVakidationException

CreateUserFailedExceptionCreateUserFailedException

CreateMembershipFailedExceptionCreateMembershipFailedException

SendMembershipFailedExceptionSendMembershipFailedException

opt Membership Business Rule

[i f membership is true]

registerUser(User)

validateUser(User)runDataValidationRules(RuleSetInfo)

createUser(User)

create(BaseEntity) :boolean

createMembership(MembershipInfo)

validateMembership(MembershipInfo)runDataValidationRules(RuleSetInfo)

create(BaseEntity) :boolean

send(EmailInfo)


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.

105


Data Access Service Layer Design – Entity Driven Design

106


UserDataAccessObject


«interface»DataAccessObjectInterface


MembershipDataAccessObject



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.

107


Object Model Design (Presentation Layer Model and Canonical Model)

108



Presentation Layer Object Model

UserCredentials


UserDemographics


CreditCard


User

- id :int- credentials :UserCredentials- creditcard :CreditCard- demographics :UserDemographics- membership :Membership

Membership

- userID :int- number :char- isMember :boolean

UserRegistrationViewModel

- enableMembership :boolean- zipCodes :List- user :User

1

1

1

1

1

1

1

1

1

1


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?

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.

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?

111


Other Reference Materials

112


What Did You Learn In These Courses?

1. 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)

2. Presentation Layer Design:

a) MVC and MVP Design Patterns

b) Event Driven Design Methodology

c) UML Class Diagrams (for modeling structure)

3. 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)

4. Data Access Services Layer:

a) Data Access Object Design Pattern

b) Entity Driven Design Methodology

5. Others:

a) Importance of an Application Framework and Operational Support

b) Industry Best Practices113


Q & A

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

115

copyright© 2011 on the edge software consulting web application 101 design training class

Documents

sdlc process

number of sdlc models

scrumagile sdlc model

time incremental sdlc

development process

design training class

iterative methodologies

business services layer