Web Engineering Part I Web Application Chapter I Introduction of Web Application 1.) History and Nations World wide Web ist omnipräsent ISO OSI Modell, Server / Client Modell 2.) Categories of Webapplication
document centered: interactive: transaction-oriented: workflow based: collaborative: portal oriented: ubiquitous: semantic web: Uni-Startseite Formularbasierte Seiten, Auswahllisten online banking / online shopping B2B, e-goverment e-learning, Wiki Portalseiten (freenet, yahoo) mit PDA auf Sight-Seeing-Tour web 2.0, soical software 3.) Charakteristics of Webapplication Presentation: Hypertext: content: informativ Design, selbsterklärend Navigation, Risiko des Orientierungsverlustes Informationen: Texte, Graphiken, Video : aktuell, korrekt,
social context: technical context: Laptop), natural context: interkulturell spontane Besuche, multikulturell unbekannte Hardware: Bandbreite, System (PDA, Auflösung 24/7 Erreichbarkeit, Private Daten sicher machen, project member: geringes Durchschnittsalter, IT experte, Designer, Domainadmin..., open source / open content technical infrastructure: inhomogen (Server unter Entwickleraufsicht, Browser nicht unter Kontrolle), Fehlerhaft da schnelle Marktreife gewünscht process: flexibel, parallel integration: internal integration, external integration (Web Services) permanent evolution konkurrenzdruck: short product life cycle, time to market, --> fast pace 4.) Qualitiy of Web Applications: External Qualities: correctness (Korrektheit) reliability (Zuverlässigkeit) robustness Aktualität Benutzerfreundlich
Effizient Sicherheit Internal Qualities: Portabilität Interoperability Wartbarkeit (maintainability) --> Trade Off Circle Man kann nicht in allem gut sein, Schwerpunkt finden 5.) Web Engineering Web Crisis: document-centered view misconception that web applications are simple no use of know-how of relevant disciplines --> Web Engineering is a specialization of Software Engineering -> see Web charakteristics Chapter II Architecture of Web-based Systems 1.) Software Architecture characteristics of Software Architekture: functional and non functional architecture is a specific view co-existing of several architecture views Component body export import Connector between im/export protocol discription --> high cohesion: for elements within a component --> low coupling: between components 2.) Architectural Styles
Blackboard Architecture gute für neue Probleme ohne Lösungsansätze Layered Architectures layer provides services to upper level only users services from immediate lower level advantage: changes in one layer effekts only one other layer presentation: application layer: data layer: Tier vs. Layer: implementations interaction with the user what the system actually does, business rules / processes deals with data organisation, supports application layer layers are a conceptional construct, tiers are
1 Tier all is centralsized 2 Tier (client/server) presentation layer at the client -> indipendent client
3 Tier (middleware) layers are seperated data layer may also be a 3 Tier system MVC Model View Controll Controll: manage User inputs (function calls, view selection) Modell: data handling displays data => different views for the same data => different input controller => hierachical application of MVC Service-oriented architecture (see last chapter) 3.) Web Application architecture n-tier architecture adding a Webserver to the presentation layer seperate development of GUI, logic and data business logic and application indipendent from technology
MVC on n-tier Chapter III Technologies: Modeling of Web Application 1.) MDA, MDE, MDD Model-Driven Development (MDD) Model-Driven Engineering (MDE) Vom Problem --(analyse & Design)--> zum Modell --(Code)---> zum Programm Model-Driven Architecture (MDA) Vom Problem --(analyse & Design)--> zum platformunabhängigen Modell (PIM) -(refine)--> zum platformabhängigen Modell (PSM) --(Code)---> zum Programm 2.) Modeling Dimensiones Web Applications
Levels: Content, Hypertext, Presentation Aspects: less behaviour in static, los in interactive Phases: no general process (content first, layout first, test first) --> evolution in all levels, aspects and phases 3.) UWE - UML-based Web Engineering light-weight extension of UML UML profile UML Meta Modelling Aproach
m3: Meta Meta Modelling -> Sprache um Sprachen zu definieren, zb Klassen,Attribute m2 : Meta Modelling -> Sprache um Modelle zu erstellen (UML:Class, UML: State) m1 : UML Modell, eine Klasse m0 : Runtime instance, ein Object UML extensions Variante 1: definieren einer neuen Sprache Variante 2: heavy weight extension: unkontrollierte erweiterung Variante 3: light weight extension: UML Profil, controlled extension with sterotypes stereotypes: erweitern die UML Metaklasse zusätzliche Metaattribute zusätzliche Grenzen -> UWE Requirements: actors, functions based on view of actors requirement: in Web it's navigational cause of stereotype <<navigation>> Use Case diagram activity diagram
-> UWE Content Modeling Strukturell: UML Klassendiagramm Verhalten: UML State Chart --> UWE Hypertext Modeling model of nodes (documents and pages) and navigation path structure model: which classes can be visited by by navigation access model: structure model with access elements hypertext structure: << navigation class >> << navigation link >> access structure: << menu >> <<index>> <<guided Tour>> <<query>>
Hypertext structure model Hypertext Access model --> UWE Presentation Modeling <<page>> <<presentation unit>> presentation elements: <<anchor>> <<text>>
--> UWE Customization Modeling bestimmte Regel: Wenn a zutrifft darf b angezeigt werden WEB ML Web Modeling Language Site = Structure + Composition + Navigation + Presentation Aufbau: --> Web ML Data Design structure model Vereinfachtes ERM -> structure
--> Web ML Hypertext Design navigation + composition Web ML content Unit: atomare einheit (Indexunit, Dataunit, Comboboxunit) page: Besteht aus mehreren Infos, zb content Units, mit subpages side view: view for the user, made of pages, a set of pages --> Web ML Concepts Content units Content units have INput and OUTput parameters Contextual Links oriented connection between two units, allowing to transport information Non Contextual Link no information is transported operation unit content manipulating operation (delete, create...) -> Outputlink: OK, KO
--> Web ML Presentation Model Mittels XSLT Stylesheets wird aus XML Beschreibungen eine Seite gebaut -> automatische generierung Chapter III Implementation URL: scheme://host/path?query Technologien: --> HTML --> CGI Common Gateway Interface external programs written in any language communication by STDIN, STDOUT CGI executed in seperated process on webserver --> PHP Personal Homepage PHP Hypertext Preprocessor php as CGI programm php as server module +permanent database connection -fehleranfällig, da variablen dynamisch erstellt werden --> XML - Extensible Markup Language Basic Notions Well-formedness DTDs Validity XML Schemas Processing XML documents SAX Parser DOM Parser Translating XML documents
the definition of external document formats document type definition (DTD) XML schema definition (XSD) analysis of imported documents for well-formedness and validity A well-formed XML document is valid, if it contains a proper document type definition the document obeys the constraints of that DTD <Letter> <To> <Recipient>Peter Müller</Recipient> </To> </Letter> --> DTD - Document Type Definition <!ELEMENT Letter (To*, Subject, Body)> <!ELEMENT To (Recipient, Address+)> <!ELEMENT Recipient (#PCDATA)> Nachteile: no XML syntax (DTDs are no XML documents) no (complex) data types no inheritance (Vererbung) --> xsd XML Schema Definition Komplexer Datentyp: may have complex values (sequences, sets, ) sequence: fixed order of elements choice: complextype only one element may occur <xsd:element name="address" type="addrtyp" /> einfacher Datentyp: <xsd:element name="street" type= xsd:string />
--> XML Parser Läd well-formed SML in den Speicher und stellt es den Clients bereit Prüft validität SAX Event based -> Code wird nacheinander analysiert, Stück für Stück Events werden während des scannens erstellt + flexibel, schnell - kein Standard
DOM Document Object Modell Idee: copy hierarchical XML data structure into main memory Erstellt aus dem XML Dokument zuerst einen Baum access to data by tree traversal DOM tree can be manipulated by application -but high memory consumption -requires to use tree data structure --> XSL Transformation: change of data structures translation of received documents into internal format adaption of documents towards a new structure description dynamic creation of documents selection / filtering of relevant data presentation of documents adding of layout information export in external representation XML Path Language (XPath) to locate certain information in an XML document zb: /Brief//Produkt[@id="ma_101"] -->XSLT XSLT beschreibt Tree-Transformation (transform, extend, change) Transformation mithilfe von Stylesheets
<xsl:template match="/"> <X> <xsl:apply-templates select="a/c" /> </X> <A/> </xsl:template> --> Java Java Servlet A servlet is a Java programming language class executed in a servlet container can be loaded dynamically into and run by a Webserver interact with HTML clients via request/response doget() dopost() doput() Beispiel: import java.io.ioexception; import javax.servlet.servletexception; import javax.servlet.http.httpservlet; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; response.setcontenttype("text/html"); PrintWriter out = response.getwriter(); out.println("<html>"); out.println("<head>");
out.println("<title>circles!</title>"); Servlet-Container servlet container manages servlets lifecycle --> JavaBeans components business logics separated in JavaBeans JavaBeans are Java classes --> Java Server Pages (JSP) HTML document with embedded Java code translated into Java servlets when used for the first time JSP ist unabhängig von der Business-logig und wird bei gebrauch compiliert
--> JavaServer Faces (JSF) clean separation between presentation and behavior UI components independent of specific presentation technique (UIForm -> HTMLForm, TelnetForm Erweiterungen: create custom UI components create custom validators, converters Specification, not an implementation --> Java Applets counterpart to java servlets on client-side embedded inside a web-page runs in the context of the browser defined lifecycle: init, start, stop, destroy
--> CSS simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents CSS vs XSLT HTML Elemente konfigurieren aber Dokumentstruktur kann nicht geändert werden XSLT for complex transformation of documents. duplicate elements remove elements --> XHTML - Extensible HyperText Markup Language Neudefinition von HTML nach den stregen XML Regeln --> Java Script ermöglicht interaktion in HTML Seiten lightweight programming language Skriptsprache wird daher interpretiert und nicht compiliert ist direkt im HTML eingebettet Anwendungsbeispiele: validate data, create cookies, get User info --> DHTML interaktive Websites JavaScript, CSS, HTML, DOM --> AJAX -Asynchronous JavaScript and XML
JavaScript allows to fetch and update partial DOM trees XMLHttpRequest objects for communication between server and client
--> GWT - Google Web Toolkit (GWT) open source Java-based development framework for AJAX applications GWT compiler translates Java application to browsercompliant JavaScript and HTML asynchronous communication between client and server via RPC mechanism Client side code: Java Klasse mit Google Libaries, Oberflächenprogrammierung Server side code: Java Klasse, Java Servlet GWT : RPC code service interfaces Vorteile java development - faster testing and easier debugging in hosted mode AJAX better user-perceived performance because of asynchronous communication UI widgets and layout - browser independent development approach MVC in implementation Technologies CGI: model als programm, view als Stream output -> Designer muss programmiern PHP: model + view zusammen in.php -> keine klare Trennung Servlet: model + view zusammen als Output -> programmierer macht beides bei seperater Logik: Programmiere und Designer können nicht parallel arbeiten mit JavaBean: Designer muss Java können JSP + JavaBean: Trennung von Businesslogik und Design JSF: Controller XML, view JSP, Model JavaBean
GWT: Controller und View are mixed XML: View: --> XSLT macht XHTML mit CSS Model: XML mit DOM, SAX Chapter V: Web Services Web Services are the latest attempt to master the complexity of enterprise application integration Web Services are a standardization effort for developing and deploying middleware systems. --> Distributed information systems (Verteilte Informationssysteme) Unterschieden in Design (layers, Bottom Up vs Top Down) architecture (1-n Tier)
-> Top Down Design das System ist in mehrere Module eingeteilt die Module sind nicht eigenständig, sind auf einander angewiesen tightly coupled (fest gekoppelt)
-> Bottom Up Design Ziel: Alte Systeme mitbenutzen mittels intermediate layer (middleware) middleware dient als Brücke die ein Interface bietet -> Architecture One-tier architectures: fully centralized Two-tier architecture ( client/server) client/server systems introduced: the notion of service (client invokes a service on server) the notion of service interface Probleme: Bei mehreren Verbindungen kennt nur der Client alle Systeme Client ist für Datenaustausch verantwortlich -> großer Client nötig Three-tier architecture (middleware) Client (presentation) <-> Middleware (application) Middleware + reduziert Anzahl Layer + erleichtert Zugang zu unteren Systemen - ist eine weitere zusätliche Ebene - kann fehlerhaft sein <-> Data layer Middleware higher levels of abstraction bietet Inteface und läßt komplizierte Sachen andere Programme machen versteckt Hardware und Plattformdetails
Beispiel: RPC as programming abstraction (hiding low level details of hardware, networks, and distribution) Middleware as Infrastructure: middleware platforms are very complex software systems Synchron and asynchron middleware Object Request Broker (ORB): in charge of the interaction between components CORBA is often implemented on top of RPC The Common Object Request Broker Architecture (CORBA) is part of the Object Management Architecture (OMA) standard, a reference architecture for component client systems CORBA was an attempt to modernize RPC by making it object oriented and providing a standard Web Service Technologies Service: A service is a software module deployed on network accessible platforms provided by the service provider. Service Description: The service description contains the details of the interface and implementation of the service. This includes its data types, operations, binding information and network location.
SOAP Service orientated Architecture Protocoll A message format for one-way communication describing how a message can be packed into an XML document The body is used for application level data. The header is used for infrastructure level data (e.g. transactional messages) Extension mechanism that provides a way to pass information in SOAP messages independent of application data The body is intended for the application specific data contained in the message Process SOAP Headers
Remote Procedure Call: Request with input parameters Remote Procedure Call: Response with output parameters A binding of SOAP to a transport protocol is a description of how a SOAP message is to be sent using that transport protocol SOAP uses the same error and status codes as those used in HTTP so that HTTP responses can be directly interpreted by a SOAP module SOAP, in its current form, provides basic mechanisms for: encapsulating messages into an XML document mapping the XML document to a SOAP message and turn it into an HTTP request transforming RPC calls into SOAP messages simple rules on how to process a SOAP message WSDL - Web Services Description Language Abstract description: the type system used to describe parameters / return values (based on XML Schema) Concrete descritption: binding the interface to a transport protocol
WSDL elements: <types>: data types for message content <message>: grouping and <type> of data to be transmitted <porttype>: abstract set of <operation>s with <input> and <output> <message>s <binding>: concrete protocol and data format of the messages associated with the operations of <porttype> <port>: network address of a <binding> <service>: a collection of <port>s UDDI Universal Description, Discovery and Integration UDDI defines a data model and a protocol for publishing and finding Web Services. 3 aspects: basic information categorization technical data An entry in an UDDI registry is an XML document composed of different elements (labelled as such in XML), the most important ones being: businessentity: Beschreibung der Organisation des Serviceanbieters businessservice: Liste aller angebotenen Services des businessentities bindingtemplate: Beschreibung der technischen Gegebenheiten die angeboten werden tmodel: zusätzliche (meist technische) Informationen
Web Service Architecture ist bottom up can be seen as synchronious middleware Top Down wäre wenn man den aus Richtung des business Prozesses entwickelt. Chapter VI: Web Services Research Does the service description meet the requirements (query)? WSDL: Problem describing a service with WSDL
Data Types: Common language (Ontology) depicted as UML class diagram Behavior: Operation contracts Pre-condition: Characterizes situation or information that musst be provided by a requestor to execute a service Post-condition: Characterizes situation after successful execution of the service Provider muss mindestens das als Reslutat zurückliefern was der Requestor nachfragt. Mehr Informationen anzubieten ist auch akzeptabel, sie werden dann ignoriert. Provider muss vom Requestor alle nötigen Informationen bekommen. Is the Implementation correct? Wie wird sichergestellt, dass vom Model zum Programm alles richtig übersetzt wird 1.) test Pre-Condition 2.) execute programmiere 3.) test Post-Condition
Überprüfen des Models: Visual Contract (Abkommen) Behavioral Aspects: Visual Contract Model (Class diagram) Wie überprüft man die Implementation? Idea: Transformation into Java and JML (Java Modeling Language) Model-Driven Monitoring: Tool Support
Aufwandsschätzung Schätzung der Zeit von der Kalkulationssicht trennen Schätzrisiko = die Unsicherheit der Schätzung Festpreisrisiko = kaufmännischer Zuschlag Top Down: Bereicbnung mittels mathematischer Algorhythmen Bottom Up: Aufwände getrennt ermitteln und summieren Bottom Up Schätzungen: Einzelschätzung: ein einzelner Experte schätzt Delphi-Methode: mehrere Experten schätzen unabhängig von einander Schätzklausur: mehrere Experten schätzen in einem Workshop zusammen Nettoaufwand: die einzelnen Aufgaben Bruttoaufwand: Querschnitzaufwand ( PL, QM, Reisen,..) Gesamtbuget: Bruttoaufwand + Risikozuschlag und Gewährleistung optimale Teamgröße: Wurzel aus ( Beratermonate) Top Down Schätzung (Use Case Points, UCP) Funktionale Größe der Anforderungen werden in Punkten (Points) ausgedrückt A-Aufwand: funktionaler Aufwand Aktoren: geringe Auswirkung (Stammdaten, Händler, Geschäftspartner) T-Faktor: technologische Rahmenbedingungen M-Faktor: management Faktor, organisationsaufwand PF: Produktivitätsfaktor Komplexität eines Use Cases bestimmen durch das Zählen der Schritte, Dialoge und Szenarien. Einordnen der Schritte, Dialoge, Szenarien in die Kategorien: Einfach, Mittel, Hoch UCP + gut für Neu- und Individualentwicklung - schlecht für Produktanpassung, Wartung