Web Application 101 Design Training Class

1. Web Application 101 DesignTraining Class

2. Agenda 2 1 Course #2 – Requirements Analysis. Course #1 – SDLC Process. 3 Course #3 – N-Layer Architecture. 4 5 6 7 Course #4 – Presentation Layer Design. Course #5 – Business Services Layer Design. Course #6 – Data Access Services Layer Design. Course #7 – Putting it All Together.

3. Course #1 SDLC Process

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

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

6. Different SDLC Models • To manage the increasing level of software complexity a number of SDLC modelshave 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.

7. Phases of the SDLC

8. Iterative SDLC Model • The Iterative SDLC Model is a good compromise for many projects. • Due to the size of the project • Due to the maturity level of the organization • And still enforce a level of rigor and discipline required for building a new project

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

10. Some YouTube Entertainment…………… The Rise and Fall of Waterfall • http://www.youtube.com/watch?v=X1c2--sP3o0

11. Course #2 Requirements Analysis

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

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

14. Example Business Scenario

15. Decomposing a Business Scenario…….into text based Use Cases • The User must be able to log into a secure portal (using username and password). • The User must be able to register on the portal (providing name, address, and credit card #). • The User must be able to select a Product and place an Order for a Product. • The User must be able to select a Shipping Address and confirm their Order. • The User must be to receive a Confirmation and Tracking Number once an Order is placed. • The Credit Card System shall provide the capability to acceptcredit card transactions. • The Credit Card System shall respond within 500ms. • The Credit Card System shall be able to process at least 100 transactions/second. • The System shall be available99.99% of the time. • The System shall support all modern web browsers (that includes IE6+, Firefox 3+, Safari 2+)

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

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

18. Decomposing Nouns…….into Business Entities • 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 • 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”) • And finally we can leverage UML Class Diagramsto design our Business Entities.

19. Decomposing Business Entities…..into a UML Class Diagram

20. Decomposing Subjects and Verbs…….into Business Services • 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 • 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) • And finally we can leverage UML Class Diagramsto enhance the design of our Business Entities by adding class methods (to form our Business Services).

21. Decomposing Business Entities…..into a UML Class Diagram

22. Improved Business Services • Previous Business Services Model mixed data and operations together. • 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

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

24. Improved Business Services • First list all the Domains from your Use Cases. • 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) • And finally we can leverage UML Class Diagramsto design Canonical Model (to form our SOA based Business Services and Object Model).

25. Improved UML Class Diagram – Canonical Model Service Model Object Model

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

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

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

29. Course #3 N-Layer Architecture

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

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

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

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

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

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

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

37. N Layer Application Architecture - .NET RIA Design Client Layer (Desktop/Mobile/Browser) User Interface, (Minimal) Client Side Validation, AJAX, UI Rules AJAX jQuery CSS Forms HTTP/HTTPS POST Event Based Design Presentation Layer (PL) User Interface, UI Event Handlers, UI Rules, Navigation SilverLight MVC 2 ASP.NET Local POCO, SOAP, REST Canonical Object Model Microsoft Enterprise Library Reusable Application Blocks Design By Contract Business/Services Layer (BLL) Business Logic, Business Rules, Workflow, Data Validation Application Framework Custom Reusable Library Unity Framework (IoC) Workflow Foundation Comm. Foundation Governance , Standards, Policies, Best Practices, Security, Steering Committees, Tools, etc. Canonical Object Model Canonical Object Model Reference Architecture Frameworks, Design Patterns, etc. Optional SOAP, REST SOAP, REST Entity Driven Design Data Access/Services Layer (DAL) CRUD Data Persistence Integration Tier Orchestration (Workflow*, Rules*) Entity Framework (ORM) LINQ ADO.NET Data Model .NET DB Factories SOAP, .X12, ETC Cache Operational Database External Systems Interfaces, Feeds, Printers Business Entity Media GovernedBy Guided By

38. N Layer Application Architecture – Silverlight RIA RIA Design Silverlight Application Framework Client Layer (Desktop/Mobile) User Interface, Rules*, Navigation, State Silverlight SOAP, REST Presentation Model Design By Contract RIA Business/Services Layer RIA Web Services & Logic, Rules*, Workflow* Workflow Foundation Comm. Foundation SOAP, REST Canonical Object Model Design By Contract Business/Services Layer (BLL) Web Services & Logic, Rules*, Workflow* Workflow Foundation Comm. Foundation Application Framework Custom Reusable Library Governance , Standards, Policies, Best Practices, Security, Steering Committees, Tools, etc. Canonical Object Model Reference Architecture Frameworks, Design Patterns, etc. Canonical Object Model Optional SOAP, REST SOAP, REST Entity Driven Design ADO.NET Data Access/Services Layer (DAL) CRUD Data Persistence Integration Tier Orchestration (Workflow*, Rules*) Design By Contract Workflow Foundation Comm. Foundation Data Model .NET DB Factories SOAP, .X12, ETC Cache Operational Database External Systems Interfaces, Feeds, Printers Business Entity Media Guided By GovernedBy * Rules are retrieved from a central repository. Includes validation by ruleset.

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

40. Course #4 Designing the Presentation Layer

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

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

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

44. 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! Browser Response (HTML) Client Layer Request (POST) Presentation Layer Controller View Request Handler Forward Service UI Logic Invoke Model Data Binding Presentation Layer Services Layer Object Model Canonical Model Business Services Model

45. 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. Controller Model (canonical) View Services Model requestHandler invokeService navigateView Data Model getProperty

46. 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 Model Updates and Data Binding Presenter View Request Handler IView Presenter Service Event Handler Invoke Application Controller Redirect Navigation/Work Flow Presentation Layer Services Layer Object Model Canonical Model Business Services Model

47. 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. View Presenter Model (canonical) requestHandler requestHandler Services Model invokeService Data Model getProperty

48. 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. Model (canonical) View changeEvent notify updateView getProperty

49. 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: • Identify events from the User Interface design • Create table of nouns and verbs for User Interface events • Identify the Entities that will get bound the User Interface • Identify presentation state variables that need to be maintained • Design the Presentation Layer object model class • Design the Controller class • Implement the classes and refactor Application Logic/Rules accordingly • Let’s walk thru a simple example……………..

50. 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 First Name: Last Name: Address: City: State: Zip: Is Member? Member #: Register