Use Case – MVC & Framework CS 537 Advance Software Engineering Group 2 Kunal Naik Harshil Shah Henil Patel Jwalant Desai Ankur Patel.

Use Case – MVC & Framework

CS 537 Advance Software EngineeringGroup 2Kunal Naik

Harshil ShahHenil Patel

Jwalant Desai Ankur Patel

Troubles with RequirementsWhen faced with what they believe

is a problem, most engineers rush into offering solutions.

—ALAN M. DAVIS

Example from Bruce Blum’s SE Holistic View

Requirement Error

likely to be the most common class of error.

to be the most expensive errors to fix. likely to consume 25 percent to 40

percent of the total project budget. the most common type of systems

development error and the most costly to fix.

Requirements Management Tools Rational RequisitePro Borland Caliber RM Telelogic

DOORS(IBM®Rational®DOORS®)

Troubles with Requirements Continue

Traditionally, requirements gathering Takes too long

Documents the wrong thing Makes assumptions about activities

that haven't happened yet Is often completed just in time to do

it over again, thanks to swift and dramatic changes in the business

Requirements Manual- Snap Shot

Requirement Definition

6.7.1.4.2 The system must provide the capability to capture all of the customer transactions for the fiscal year.

6.7.1.4.3 The system will provide restricted remote inquiry access (via dial-in) to view images and data separately or simultaneously.

6.7.1.4.4 The system will barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned.

6.7.1.4.5 When a workflow is initiated, the system must be able to prefetch the documents that are in electronic image format by document type or grouping of documents by process.

6.7.1.4.6 The system must create an entry in the journal file whenever a letter is created.

6.7.1.4.7 The system must maintain a list of current, open work processes and identify the work process to be executed and the workflow queue for the process. When particular documents are scanned, the system will determine whether there is a process open for that Social Security Number (SSN). If there is an open process, the system will route the document to the appropriate workflow queue, display the work process script, and highlight the current work process.

Format of Requirement Doc3. Third Topics Specific Requirements

3.1 Functional Requirements3.1.1 Functional Requirement 1

3.1.1.1 Introduction3.1.1.2 Inputs3.1.1.3 Processing-----------

3.1.2 Functional Requirements2-----------

3.2 External Interface Requirements3.2.1------------

3.3 Performance Requirements-------

3.4 Design Constraints---------------

4. Fourth Topics

Requirements Definition

Requirements are the effects that the computer is to exert in the problem domain, by virtue of the computer's programming.

—BENJAMIN L. KOVITZ

Requirements Characteristics A requirement is something that a computer

application must do for its users. It is a specific function, feature, quality, or

principle that the system must provide in order for it to merit its existence.

Requirements constitute part of the scope of a software development project.

The requirements also dictate how the system should respond to user interaction.

It should do specific things when poked or prodded by the user in a certain way.

Category of Requirements

Functional Non Functional Quality Requirements Confidential Requirements Integrity requirements Reliability requirements Performance, User Interface,

Architectural

Issues with common Req. gathering methods

User Interviews The requirements analyst is usually writing

madly, trying to keep up with the users' remarks and trying to think of the next question to ask.

two people have conflicting views on the same process or business rule.

Then, when people at various levels of management are interviewed, the playing field becomes even more interesting.

Conflicting views become a multidimensional puzzle, with pieces that change their shape as the game proceeds

JRP

JRP

Joint Requirements Planning(JRP) Sessions

to conducting all the user interviews at the same time in the same room.

Contract-Style Requirements ListsLegal terms OR technical jargons, Philosophical requirements

Issues with common Req. gathering methods

Prototypes (What it is) Prototypes are mock-ups of the

screens or windows of an application that allow users to visualize the application that isn't yet constructed.

reduced overall costs dramatically.Issues with Prototypes Users with detail-oriented minds pay

more attention to the details of the screens than to the essence of what the prototype is meant to communicate.

Moving to Use Cases

Traditional Mode of expressing functionality software

Requirements specifications Functional decompositions Data-flow diagrams (DFDs) Entity-relationship diagrams (ERDs) Prototypes

It’s all About Interactions

Users care about what goes in and what comes out, as in a black box.

Requirements Specifications

Functional Decomposition

Functional decompositions are a remnant of the older analysis and design approaches

Data Flow Diagrams

DFDs are useful for technical people but tend to confuse users

Entity Relation Diagrams

ERDs are critical for database design, but they are not meant for user consumption

Prototypes

Prototypes were long held to be the elixir for good requirements capture, but now we realize that they can help much more with proof-of-concept tasks

The Origin of Use Cases

Use cases were introduced to the IT world by Ivar Jacobson (1992) and his team at Ericsson in Sweden.

Their book, Object-Oriented Software Engineering took the computing industry by storm and use cases have been increasing in popularity ever since.

Use Case Objectives :

Three aspect of Use case Different Actors Identification of Use case Views of Representation

Software development process

Use Case Use case answer “ What will

system can do ?” They capture the functional

requirement of the system.

Use Case Scenario : A scenario is a sequence of

event which happened when a user interact with the system

Actor : Actor is a who of the system. In other word end user.

Use case : Use case is a task or goal perform by user.

Actors Primary Actor : Primary actors are

the users who ware the active participants & they initiate the user case.

Secondary Actor :Secondary Actors are those who only passively participates in the user cases.

Identification of Use Case Method 1: Actor based

Identify the actor related to system Identify the scenario these actor

participate in Method 2: Event based

Identify the external event that a system must response to

Relate the events to actors and use cases

Identification of Use Case Method 3: Goal based

Find user goal [ Prepare actor-goal list ]

Define a use case for each goal

Use Case

Views of representation

1) Use case Diagram 2) Detail step table about how the

use case works

Use Case Diagram

Use Case Table

34

Relationships between Use Cases

1. Generalization - use cases that are specialized versions of other use cases.

2.Association - Relationship between instance of two classes

Relationships between Use Cases

3. Include - use cases that are included as parts of other use cases. Enable to factor common behavior.

4. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.

36

1. Generalization The child use case inherits the

behavior and meaning of theparent use case.

The child may add to or override the behavior of its parent.

parent

child

37

registration

graduateregistration

non-graduateregistration

More about Generalization

Generalization Hazards Combining generalizations of actors

and use-cases can be dangerous

Undergrad Student

Graduate Student

Submit Exam

Submit Thesis

Undergrad Student

Graduate Student

Submit and Get Grade

Submit Thesis

Submit Exam

Bad: Undergrad can submit thesis

Good: Only graduate student can submit thesis

2.Association

Relationship between instance of two classes

Its denoted by a straight line An association represents a structural

relationship that connects two classifiers

The name of an Association should be a verb

40

3. Include

The base use case explicitly incorporates the behavior of another use case at a location specified in the base.

The included use case never stands alone. It only occurs as a part of some larger base that includes it.

base included<<include>>

41

More about Include Enables to avoid describing the

same flow of events several times by putting the common behavior in a use case of its own.

updatinggrades

outputgenerating

verifyingstudent id

<<include>>

<<include>>

42

4. Extend

The base use case implicitly incorporates the behavior of another use case at certain points called extension points.

The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case.

base extending<<extend>>

43

More about Extend Enables to model optional behavior

or branching under conditions.

Exam copy

request

Exam-grade

appeal

<<extend>>

Example

45

A More Complicate Example

Delivery boy

Continue

Continue

Delivery boy

Advantages of Use case Good way to start identifying objects from

scenario. Test plan can be immediately generated

based on use-case. Easier user validation Help technical writers in structuring the

overall work on the users manuals at an early stage

Better Traceability throughout the system development process

Quality of the software is improved by identifying the exception scenario’s earlier in the development process

Problem with use case What is a correct use case? Explosion of different scenarios. Too often to informal.

MVC and Frame Work

Harshil ShahHenil Patel

Layered Application Design Structure

application in two layers Interaction Layer

Processing Layer

Interaction Layer Interface to clients Receive requests and perform

required translations and transformations

Delegate request to processing layer for processing

Respond to clients

Processing Layer Process request by performing

business logic Access database Integrate with Enterprise

Information Systems

Why Layered Application Design? Divide completely responsibilities

Separate business logic from presentation Any change in business logic will not

affect presentation and vice versa Create a common “place” for pre-

processing and post-processing of requests and responses Logging, translations, transformations,

etc.

MVC Pattern

Model View Controller Pattern

1) Model

Model (Business Process Layer) Model the data and behavior behind

business process Responsible for actually doing

Performing DB queries Calculating the business process Processing orders

Encapsulate data and behavior which are independent of presentation

2) View

View (Presentation Layer) Display the information according to

client type Display the result of business logic Not concerned with how the

information was obtained, or from where

3) CONTROLLER

Controller (Control layer) Serve as logical connection between

the user’s interaction and the business services on the back

Responsible for making decisions among multiple presentations

Request enters the application through control layer, It will decide how the request should handled and what information should be returned.

Web Application It is often advantageous to treat each

layer as an independent portion of your application.

Do not confuse logical separation of responsible with actual separation of components.

Some of the layers can be combined into single components to reduce application complexity.

Evolution of MVC Architecture 1. No MVC 2. MVC Model 1 (Page-centric) 3. MVC Model 2 (Servlet-centric) 4. Web application frameworks

Struts

Model 1 Architecture

No MVC Model 1 Architecture

Model 1 Architecture (Page-centric)

Bro

wser

JSP

pages

Java Bean

1

Request

4

Response 2

3

Servlet

Container

Enterprise

Information Systems

(EIS)

Page-centric Architecture Composed of a series of interrelated JSP

pages JSP pages handle all aspects of the

application: presentation, control, and business process

Business process logic and control decisions are hard coded inside JSP pages JavaBeans, scriptlets, expressions

Next page selection is determined by By hyperlink <a href=“find.jsp”> By submitting a form <form

action=“search.jsp”>

Page-centric Architecture

Options.jsp

Query.jsp Report.jsp

Database

Page-centric: Simple Application One page displays a menu of

options, another has queries to obtain data, and the last one presents different kinds of reports Separate presentation and content Maintain dynamic nature of JSP Need to sync up request parameters

Page-centric: Component Page Diagram

Header.jsp

Details.jsp

Footer.jsp

DATA

CS537 Group 2

[Groups][Logoff]

Page-centric: Component Page Create headers, footers and navigation

bars in JSP pages Easy to maintain Flexibility and reusability

<%@ include file = “header.jsp” %> Use include if the file changes rarely

<jsp:include page=“header.jsp” flush=“true”> Use jsp:include if the file changes constantly

Page-centric Scenario

Model 2 Architecture (Servlet-centric)

Why Model 2 Architecture? What if you have a large

application? Application control is decentralized All this leads us to Model 2

architecture of designing of JSP pages

Servlet-centric Arhcitecture

JSP pages are used only for presentation Control and application logic handled

by a servlet (or set servlets) Servlet serves as a gatekeeper

Provides common services such as authentication, authorization, login etc

Servelt act as central controller Event dispatcher Perform redirecting

How many servlets in Servlet-centric Aprroach? It depends upon the granularity of

the application One master servlet Combination of two

Master servlet first process data Master servlet than delegates the child

servlets according to its functionality

Servlet-centric Scenario

Model 1 (Page-cnetric) Business logic may get lost in the

display pages Decentralized architecture Page selection is done by each

pages JSPs are harder to debug than

straight java code

Model 2 (Servlet-centric)

Loosen the coupling between the pages and improves the abstraction between presentation and application logic Use JSPs for pure data display and

input collection activities Most of the business logic can be

debugged through the servlet before passed to JavaBeans and JSP

Centralized architecture

Decision… Use page-centric

If the application is simple enough that links from page to page.

Use servlet-centric Each link or button click requires a

great deal of processing and decision making about what should be displayed next.

Decision… How mapping between requests and

responses are done can help you to decide Each request maps to one and only one

response No need for controller.

Each request spawns a great deal of logic and a varity of different views can result

A servlet is ideal

MVC in Web Application

1. Process request2. Create/update beans3. Store beans in request, session,

or application scope4. Forward request to JSP page5. Extract data from beans and

display

Dispatching and Saving Data

Dispatching and Saving Data in both Model 1 and Model 2 Architectures

Flow Control : Dispatching Requests

How to control the flow?

Use Forward or Include methods: Call forward to completely transfer control to destination page Call Include to insert output of destination page and then continue on

Storing Data in a JavaBean in Request

Stored data that servlet looked up and that JSP will use in this request

Servlet: store data BeanClass value = new BeanClass(..); request.setAtrribute(“bean”,value) JSP: retrive data<jsp:useBean id = “bean” class

=“BeanClass” scope=“request” />

Storing Data in Session Storing data that servlet looked up and

that JSP will use in this request and in later requests from the same client.

Servlet : store data Beanclass value = new Beanclass(..); HttpSession Session=request.getSession(true); Session.setAttribute(“bean”,value); JSP : retrieve data <jsp:useBean id=“bean” class “Beanclass” Scope =“session”/>

Storing Data in Servlet Context Store data that servlet looked up and that JSP

will use in this request and in later request from any client

Servet : store data BeanClass value=new BeanClass(..);

getServletContext().setAttribute(“bean,value);

JSP:retrieve data <JSP:useBean id=“bean” class=“BeanClass ”

scope=“application”/>

Web Application Frameworks Based on MVC Model 2 architecture Web-tire application share common

set of functionality. Dispatching HTTP Request Invoking model methods Selecting and assembling views. Provide classes and interfaces that

can be used / extended by developers

Why web application framework? De-coupling of presentation tire and

business logic into separate components Provides a central point of control. Provides rich set of features Facilitates unit testing and maintenance Availability of compatible tools Provides Stability Simplifies input validation

Why web application framework?

Frameworks define re-usable components to make this job easier.

A good framework defines how components work to create a usable application.

References

Prof. Jiang Guo’s Slides (Home Page of CS537) Core Servlets and Java Server Pages, Vol 1, by Marty

Hall and Larry Brown. http://www.asp.net

Thank you