Use Case – MVC & Framework CS 537 Advance Software Engineering Group 2 Kunal Naik Harshil Shah Henil Patel Jwalant Desai Ankur Patel.
Post on 04-Jan-2016
224 Views
Preview:
Transcript
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
top related