3. Web Engineering (Lecture Notes)

IT702 – Advanced Web Technologies (Jul – Nov 2016)

29-08-2016

Web Engineering Basics, Need, Concepts and Trends

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

Terminology… 

a distributed application application that accomplishes a Web Application – a certain business need based on the technolo t echnologies gies of WWW and that consists of a set of Web-specific resources. E.g.. Websites ebsites,, blogs, blo gs, wikis, WhatsApp etc…  E.g



an infrastructure i nfrastructure or system enabling enabling the operation of a Web System – an Web application. a pplication. E.g.. The entire backend b ackend suppor s upportt for Websites ebsites,, including includin g logistics, logis tics,  E.g security, transactions, failure-safe operation etc..


© Dr. Dr. Sowmya Kamath S, Dept of IT NITK Surathkal

25-Aug-16

1


29-08-2016

Web Applications 

WebApps encompass: complete ete Web Web sites si tes  compl  



 

Simple information i nformation Web Web sites Complex e-Commerce or other sites with embedded functionali ty and data retrieval Complex Web sites that are interoperable with other legacy software and systems

specialized functionality within Web Web sites information infor mation processing processing applications that that reside on the Internet or on an intranet or ExtraNet.


25-Aug-16

Categories of WebApps



25-Aug-16

2


29-08-2016

Attributes of WebApps



Concurrency. user s may access the WebApp at one time; patterns  A large number of users of usage among end-users will vary greatly. greatly.



Unpredictable load. u sers of the WebApp may vary by orders order s of magnitude  The number of users from day to day.


25-Aug-16

Attributes of WebApps (contd.) 

Performance. WebApp user must wait too long (for access, for server-side  If a WebApp processing, for client-side formatting and display), he or she may decide to go elsewhere.



Network intensiveness.  A WebApp resides on a network and must serve the needs of a diverse community of clients. clien ts.



Aesthetics.  When an application has been designed to market or sell products or ideas, aesthetics aesthetics may have have as much to do with success as technical design. Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

3


29-08-2016


Availability. availability is unreasonable unreasonable,, users  Although expectation of 100 percent availability of popul p opular ar WebApps often demand access on a “24/7/365” basis. basis.



Data driven. pr imary function of many WebApps is to use hypermedia to  The primary present text, graphics, audio, and video content conten t to the end-user end-user..



Security.  to protect sensitive content and provide secure modes of data transmission  strong security measures must be implemented throughout the infrastructure that supports suppor ts a WebApp WebApp and within the application itself Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16


Content sensitive.  The quality and nature of content remains an impor tant determinant of the quality qu ality of a WebApp.



Continuous evolution. application software that evolves over a series serie s of  Unlike conventional application planned, chronologically-spaced releases,Web applications evolve continuously.



Immediacy.  WebApps often exhibit a time to market that can be a matter of a few days or weeks. 

With modern tools, sophisticated Web pages can be produced in only a few hours.



25-Aug-16

4


29-08-2016

Complex Web Systems - Range of Complexity


25-Aug-16

Complex Web Systems - Characteristics 

ubi quitously useable usea ble WebApps Today’s focus is on large-scale and ubiquitously  Many users, languages, cultures.  Access mechanisms. version s.  User Agents, versions.



Presents large volume volume of interrelated information infor mation (including (including different diff erent media) and processes.  Appropriate presentation. finish one thing before starting another.  Progression through activities – finish  Intuitive system feedback.



25-Aug-16

5


29-08-2016

Complex Web Systems – Characteristics (contd.) (contd.) 

Growing and increasing complexity iterations/versions/refinements (calls (calls for Reuse)  Many product iterations/versions/refinements  Many developers and operators, complex handling of temporal media (e.g.. publishing of company news, (e.g news , earlier versions ver sions of Web Web pages) pages ) Personalization, Security issues  Customization, Personalization,



and a lot more...  E.g. “Up-to-date” by following trends


25-Aug-16

Web Application Development Development - Current Practices 

Still Ad-Hoc instead of a disciplined procedure Copy-and-Paste te Paradigm  Copy-and-Pas



Lacks rigor, systematic approach  Gap between Design Model and Implementation Model 



   

completed system is often not what the user wants

Short lifecycle l ifecycle of a Web Application Application -> Maintenance and Evolution issues -> Reuse issues Time and cost overruns Does not meet performance perfor mance requirements requirements Lacks scalability and maintainability, maintainability, hence limited useful life Resources are wasted



25-Aug-16

6


29-08-2016

Complex Web Systems- Project Failure Rates

Ref: IEEE Software, www.computer.org/software


25-Aug-16

Complex Web Systems - Project Failure Rates (contd.)

Ref: IEEE Software , www.computer.org/sof tware



25-Aug-16

7


29-08-2016

Problems with Complex Web System Projects

(Source: Epner, Epner, M., Cutter Consortium) Con sortium) Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

WebApp Development Development vs. Software Development



Web-based systems: static or o r dynamic content  Are often document-oriented containing static    

More emphasis on “look and feel” “content-driven” Need to cater to users with diverse skills and capabilities

typically constrained to a short shor t development time making it difficult to apply the same levels of formal for mal planning and testing used in software development.



25-Aug-16

8


29-08-2016

WebApp Development Development vs. Software Sof tware Development Development (contd.) 

Web-based systems:  Differ by means of their access and delivery medium  Have different life spans  Have differing development requirements 



Developers are vastly varied in terms of their background, skills, knowledge, and system understanding. understanding.

Web-based systems:  Should be scalable perfor mance requirements requirements – must must be able to cope with  Have varying performance uncertain, random heavy heavy demands demand s on services  Must be secure  Are subject to assorted legal, social, and ethical scrutiny Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

Traditional vs. Web 

In Traditional Traditional Projects:         

Quality product at low lowest est cost 10-100 team members 12-18 month horizon $ millions Requirements-based; structured phases; document-driven OO methods Rigid processes Complex; poor reusability Experienced, professional developers



In Web Web Projects: Projects :      

  


Usable product in shortest time 3-10 team members 3-6 month horizon $ thousands Agile methods; prototypes Component-based methods; multimedia; visual programming Ad-hoc processes Standardized; high reusability Multimediaa designers; Multimedi desi gners; Web Web programmers; marketers

9


29-08-2016

Web Engineering (WebE)

The application of systematic, disciplined, and quantifiable approaches to the design, production, deployment, operation, operation, maintenance and evolution of Web-based software products. ---Gaedke, 2000


25-Aug-16

Key Knowledge Knowledge Areas



25-Aug-16

10


29-08-2016

Overall WebE Development Process Context Analysis Requirement Analysis Product Model

Process Model

Project Plan

Web App Development

t n e m e g a n a M t c e j o r P

e c n a r u n s s o i t A a & t l n o e r m t u n o c o C y D t i l a u Q

Web App Maintenance

Context Analysis


11


29-08-2016

WebE Context Analysis 





Context holder s and their broader requirements and  Identify the stake holders experiences.  Identify the corporate requirements in relation to look and feel, performance, security and gov governance. ernance. Content what information infor mation needs to be on the web site, how to get this  Establish what information and how often this information infor mation is changing (immediate, short term, medium term) fu nctions the Web site needs to provide ( immediate, short  Identify the functions term, medium term). Users - potential users, their characteristics and needs. needs. Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

Requirement Analysis


12


29-08-2016

WebE Requirements Analysis 

Many taxonomies exist to describe requirements, but most divide them into two groups: 

Functional – – describes describes the capability capability’’s purpose 



Use-case diagrams, activity diagrams, group specifications, data dictionary, dictionary, site view specifications, style guidelines.

Non-functional – – describes describes the capability’ capability’ss properties proper ties 

Usabalility modeling, acceptance modeling, ….


25-Aug-16

WebE Requirements Requirements Analysis (contd.) Functional Requirement Types 











Data Requirements  How information is stored and managed Interface Requirements Requirements  How the user is going to interact with the application Navigational Requirements through the application  How the user is going to navigate through Personalization Requirements  How the application will adapt itself according to user or environment profile Transactional Requirements behaves internally inter nally  How the application behaves Security Requirements Requirements Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

13


29-08-2016

WebE Requirements Requirements Analysis (contd.) Non-Functional Requirement Types  

 

 

Content Quality Usability ity,, Portability Portabili ty,, Scalability  Usabil  Reliability, Efficiency, Maintainability System Environment User Interface  Self-explanatory & intuitive Evolution Project Constraints


25-Aug-16

Requirement analysis – An Example 

Revision and formalization of the collected requirements, producing in output output a set of semi-formal semi-for mal specifications, typically typically in terms ter ms of:  Group specification  Use-case specifica specification tion  Data dictionary specification  Site view specification  Style guidelines specification

Ref: WebML Acer Usecase



25-Aug-16

14


29-08-2016

RA Specification Speci fication Types. Types. Group specification 

Clustering of users into groups (formally described) Group Description:

Groups Hierarchy:

Group name:

Corporate

Description :

marketing and communication personnel inserting, modifying, and deleting mkt materials.

Profile data:

First name, last name, email, office address. Profile data are provided expli citly by the user.

Super-group:

Corporate.

Sub-groups: Relevant use cases: Mar-Com manager

Supervisor

Objects - read mode: Admin

Mar-Com Mar-Co m Manager

Objects - content mgmt mode:

None. “Login”, “Add a news item”, “Modify a news item”, “Delete a news item”, “Add a news category”, “Modify a news category”, “Delete a news category”, "Modify profile data".

Product and Product News. Product News.


25-Aug-16

RA Specification Types. Use-case specification 

1.

Formal Formal description of units of interaction i nteraction with the application application by users of a given group (e.g., thru tables or UML diagrams) Use Us e cases cases li list st for for a user user (us (use e case case dia diagr gram am))

Add a news item

Add a news category

Login Modify a news item

Modify a news category Remove a news item

Remove a news category

Mar-Com Manager



25-Aug-16

15


29-08-2016

RA Specification Speci fication Types. Types. Use-case specification 2.

Single Sing le use case case specif specifica icatio tion n (table (table or activ activity ity diag diagram) ram) User

Application Server

Initial Request

Send Form

Input Credentials

Accept Credentials

Select Home Page

Database

Verify Credentials

Elaborate Page Default Home Page List Index of Home Pages

Serve Request

Receive Home Page


25-Aug-16

RA Specification Speci fication Types. Types. Use-case specification 2.

Single Sing le use case case specif specifica icatio tion n (table (table or activ activity ity diag diagram) ram) Title

Login of user belonging to multiple groups

Purpose

To express how users with more than one role access the functions of the applications.

Pre-condition

A user that belongs to multiple groups is registered. For each group, the site view serving the requirements of the group members is defined.

Post-condition

The user successfully logs into the application and accesses the site view corresponding to one of his groups.

Workflow

The following steps must be performed: 1.The user receives an input fo rm asking for username and password; 2.The user inputs his credentials; 3.If the credentials are correct, the user is authenticated, the list of groups the user belongs to is determined, and the list of names and URLs of the home pages of the site view of such groups is displayed to user; 4.The user chooses one entry from the list, and enters into the selected site view.



25-Aug-16

16


29-08-2016

RA Specification Speci fication Types. Types. Data dictionary specification 



List of the main information infor mation objects identified during data requirements collection Each entry can be specified by:  Name  Synonyms NewsItem  Description Piece of news A corporate or product product piece of news  Sample instances TravelMate 610 launched, launched, 20th 2 0th June 01  Properties Title, Body, Image, Date, …  Relationships NewsToProduct  Components None  Super-concept None  Sub-concepts Highlighted news Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

RA Specification Speci fication Types. Types. Sitemap specification  

IN: list of user groups, groups, list of use cases, data dictionary dictionary OUT: list of needed site maps, specified by:  Name  Description  Target User Groups  Implemented use cases compo se the  Site view map: a table illustrating the different areas that compose site view. Each area is specified by:    

Area Name Area Description Accessed/Managed Objects Priority level



25-Aug-16

17


29-08-2016

Site View

News Content Management

Description

Includes the pages through which the Mar-Com Managers will access content management functions, for inserting or updating content about news categories and news items.

User Groups

Mar-Com Managers

Use Cases

“Login”, “Add a news category”, “Edit a news category”, “Remove a news category”, “Add a news item”, “Edit a news item”, “Remove a news item”.

1.2.d Site view specification example Site Map specification

Site View View Map Area Name

Area Description

Objects

Priority

News Content In the default page, the user accesses the list of countries NewsCategory Management for which he is content manager and selects a country to NewsItem administer. In the News Category page, the user accesses the list of news categories for the selected country. Here, the user can perform content management functions over news categories, according to the use cases “Add a news category”, “Edit a news category”, “Remove a news category”. Otherwise, he can select one category, and access the list of the the available news news items in the selected category. In the News page, the user can perform content management functions over a selected news item according to the use cases “Add a news item”, “Edit a news item”, “Remove a news item”. 25-Aug-16

High

V. Style guidelines specification  

 





Rules for the presentation of pages: Specification of standard page grids: rows, columns and cells arrangement Content positioning specification: banners, logo, menus positioning Graphical guidelines: guidelines: rules for graphic items like fonts, colors, borders and margins Device-specific Device-specific and browser-specific guidelines

Example: Mock-ups: sample representations of a few typical application pages pages (for a specific device and rendition language) Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

18


29-08-2016

RA Specification Speci fication Types. Types. Style guidelines specification 800 px

Page Area 1st Column

2nd Column

Main Menu Area Main Content Area

Foot Area 150 px


25-Aug-16

Modeling/Design


19


29-08-2016

Why Create Models? 

Define an abstract view of a real-world entity  



Tool of o f thought tho ught  



Finding & discovering objects/concepts in a domain Assigning responsibilities responsibilities to objects

Reduce complexity Document design decisions

Means of communication communication


25-Aug-16

The Role of Model in the Development 

s s e n n e v i r d l e d o m f o e e r g e d





Models as sketch  For communicating ideas and alternatives i nto practicality/implementation. practicality/implementation.  No significant thoughts into Models as blueprint  All design decisions (maybe of a particular area) are laid out programming should be pretty  Essence: Completeness – programming straightforward  Issue of reverse engineering Models as program  Applications are automatically generated.  Essence: models become the source code



25-Aug-16

20


29-08-2016

Model - Code Interplay

Code only

Code

Code Visualization

Roundtrip Engineering

Model-centric / Model-driven

Model

Model

Model

Code

Code

Code

Model only

Model

"Models as Code"


25-Aug-16

Model-Driven ...  

Systematic development on basis of models Models become the first hand ar tifacts in the software development development cycle



Key concepts  abstraction from implementation detail  systematic transformations



Related Term Terminology inology Engineer ing (MDE),  Model Driven [Software] Engineering  Model Driven [Softwar [Software] e] Development (MDD/MDSD), (MDD/MDSD), D riven Architecture Architecture (MDA)  Model Driven Web Engineering (MDW (MDWE) E)  Model Driven Web Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

21


29-08-2016

Model Driven Architecture (MDA) 



defined and developed by the Object Management Group (OMG) (March 2001) MDA is: vendor-neutral approach to interoperability using OMG's  open, vendor-neutral modeling specifications: 



Unified Modeling Language (UML), Meta-Object Facility (MOF) and Common Warehouse Model (CWM)

Main ideas:  Addresses the complete system development life cycle specification from implementation im plementation  Separate specification  Specify a system that is independent of a platform  Transform a platform-independent (PIM) system specification into a specific platform (PSM)  Code generation Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

Developing WebApps WebApps in the MDA 





Platform Independent Independent Model (PIM)  PIM represents business functionality and behavior without technology details Platform Specific Model (PSM)  Applies a standard mapping to create or generate a PSM from the PIM Code Model  Create or generate the code for each PSM.



Platform Independent Model

Platform Specific Model

Code Model

25-Aug-16

22


29-08-2016

Content Structure Model Relation

Class name

Class attributes Composition Class operations

Invariant

Derived attribute


25-Aug-16

Content Behavior Behavior Model Mo del Initial State

Condition Final State



25-Aug-16

23


29-08-2016

Navigation Structure Model


25-Aug-16

Navigation Access Model

25-Aug-16


24


29-08-2016

Presentation Structure Model


25-Aug-16

Presentation Behavior Model



25-Aug-16

25


29-08-2016

Implementation

Implementation Implement ation Approaches Model View Controller (MVC) 





Model  responds to state queries  exposes application functionality  notifies views of changes View the models  renders the from models mod els  requests updates from  sends user interaction to controller  allows controller to select view Controller  defines application behavior  maps user actions to model updates (one for each functionality) f unctionality)  selects view for response (one Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

26


29-08-2016

Implementation Implement ation Approaches Model-View-Controller 

Adaptation of o f MVC for the Web ser ver  stateless connection between the client and the server  notification of view changes  re-querying the server to discover modification of application’s state


25-Aug-16

Implementation Implement ation Approaches Client/Server (2-Layer)

Client Client

Server Web/App W eb/App Server

Services

Database

Dynamic HTML

Static HTML



25-Aug-16

27


29-08-2016

Implementation Implement ation Approaches Client/Server (2-Layer)


25-Aug-16

Implementation Implement ation Approaches N-Layerr Architectu N-Laye Architectures res Client Firewall Proxy Web W eb Server

Presentation Layer Business Layer

Application Server (Business Logic, Connectors, Personalization, Data Access)

Backend (Legacy Application, Enterprise Info System)

Data Layer DBMS

B2B



25-Aug-16

28


29-08-2016

Implementation Implement ation Approaches N-Layerr Architectu N-Laye Architectures res


25-Aug-16

Testing and Deployment


29


29-08-2016

Testing and Usability 





Testing the application versus versus its design  Checking the conformance of the requirements  Oriented to functional aspects Usability versus its user  Design and verifying the confor mance of the application versus ability and capability of interaction  Oriented to non-functional aspects Testing and Usability are orthogonal aspects  In some cases they slightly overlap!


25-Aug-16

Testing Phases Link Testing 

Finding broken links  Can be automated through a spider 





Doesn’t work for pages with no incoming links.

Finding orphan pages lin ks back to the navigation navigation structure.  Orphans are pages with no links f rustrated and leave.  Users get frustrated Capturing statistics navigation. tion.  Depth & breadth of naviga  Distance between two related pages.  # of links.  Load times. Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

30


29-08-2016

Testing Phases Browser Testing 



Browsers vary by:  Manufacturer  Version  Operating system  Device JavaScript on/off)  Configuration (stylesheets, JavaScript  W3C Standard compliance Important questions to ask:  How is state managed?  Can a (dynamic) web page be bookmarked?  Can users open multiple windows? tur ned off?  What happens when cookies and/or scripting is turned Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal

25-Aug-16

Testing Phases Security Testing 

A systematic test scheme is strongly encouraged. encouraged.



Testing for correctness is not sufficient  Is confidential data inadvertently exposed? inp ut incomplete data?  What happens if we input  What happens if we inject malicious code?  SSL-encrypted pages 

Is our SSL certificate working?



What happens if I try to access a protected page/site in a non-secure way (i.e., http://)?



25-Aug-16

31


29-08-2016

Testing Phases Load Testing 

Does the system meet required response times and throughput?



Load profile - expected access types, visits per day, transaction types, transactions per session, etc.



determine the range of values for response times and throughput (upper and lower limits)



Evaluate the results to look for bottlenecks and potential problems to support future scalability.


25-Aug-16

Testing Phases Stress Testing



How does the system behave under abnormal/extreme conditions? m eets the target responses times and throughputs  If the system meets  If the system responds with an appropriate error message. (i.e. graceful degradation)  If the system crashes (it should NOT!) recovers to normal n ormal operation.  How quickly the system recovers



25-Aug-16

32


29-08-2016

Testing Phases Continuous Testing 

Simulates usage over a long period of time



Testing for errors that “pop up” because resources aren’t released by an operation.  Unreleased database connections  Other memory leaks



Typically, running the operation a few times doesn’t produce an error, hence the need for continuous testing.


25-Aug-16

Usability 

ISO/IEC standard definition (1998): 





“[T]he extent to which a product can be used u sed by specified users within a specified usage context to achieve specified goals effectively effectively,, efficiently, and satisfactorily.”

Specific focus on response times, efficiency, consistency in text layout, navigation, colors, page structure, page elements, readability….. Web Content Accessibility Accessi bility Guidelines Guideli nes 2.0 (WCAG, 2008) published by the the W3C’s W3C’s WAI (Conformance Levels Levels - A, AA, AAA) https://www.w3.org/TR/WCAG20/ https://www.w3.org/WAI/WCAG20/quickref/ Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal


25-Aug-16

33


29-08-2016

Further reading… 

Murugesan,S and A.Ginige, A. "Web Engineering: Introduction and Perspectives”, Idea Group Publishing, 2005.  http://www.idea-group.com/downloads/excerpts/01%20Suh.pdf



M.J. Escalona and N. Koch, Requirements Engineering Engi neering for Web Web Applications - A Comparative Com parative Study, Study, JWE Vol.2, Vol.2, N. 3  http://www.rintonpress.com/xjwe1/jwe-2-3/193-212.pdf



Web Engineering, IEEE MultiMedia, Jan. – Mar. 2001 (Part (Par t 1) and April – – Mar. – June 2001 (Part 2).  http://csdl2.computer http://csdl2.computer.org/persagen/DLPublica .org/persagen/DLPublication.jsp?pubtype=m&ac tion.jsp?pubtype=m&acron ron ym=mu Usability Engineering, IEEE Software, Software, January – February February 2001. Web Engineering, Engineeri ng, Cutter IT Journal, Jour nal, 14(7), July 2001.

 



25-Aug-16

34

3. Web Engineering (Lecture Notes)

Recommend Documents