Isidro Ramos Polytechnic University of Valencia -SPAIN-

1. User Interface Modeling and Specification in an Object Oriented Environment for Automatic Software Development Isidro Ramos Polytechnic University of Valencia -SPAIN-

2. Contents : • Motivation. • Introduction. • User Interface Development Environments. State of the Art. • Generic Architecture. • IDEAS: Interface Development Environment within OASIS. • Ontological Model of IDEAS. • Conclusions.

3. Motivation: • Fill the existing gap in most of the current software development methodologies. • Incorporate a user-oriented development. • User Interface Generation within a methodological and formal support.

4. Introducción II: • Development Process integrated in an object oriented software development environment: • OASIS: Object oriented Model • UML: Object oriented Methodology. • IDEAS: Enriches the model by integrating a specific model for user interface generation. • This approach includes graphical diagrams to represent the different aspects of the user interface.

5. Analysis Design Implementation Introduction: Main Goal: Present a formal and methodological approach for the specification of user interfaces integrated in the software development process. Object-Oriented approach which covers the phases of User Interface Model: 1) Task Model 2) User Model 3) Domain Model 4) Dialog Model * Object-Oriented Specification Language OASIS-UI 5) Presentation Model * Model-Based Code Generation

6. User Interface Software Tool.Classification: Language-BasedTools:Require to program in a special purpose language. Interactive Graphic Specification Tools:They allow an interactive user interface design. Model-Based Generation Tools:They use a model or high-level specification to generate the UI automatically. Main Features: Use of Declarative Models to describe all the aspects related to the user-system interaction. Automatic Generation of the UI starting from the models. User Interface Development Environments. State of the Art. Model: Declarative Specification of the structure and behavior of a software element. Declaratives because they do not contain procedural code but descriptions with high level of abstraction.

7. Advantages of the Model-Based approach: User-centered development process. Centralised UI specification. Design tools for an interactive and automated development. UI design reuse. Criteria for a UI tool to be considered a Model-based development environment: (1) It must include a high level, abstract and explicitly represented (declarative) model about the system under development. (2) It must clearly establish a technologically well supported relation between (1) and the final running UI. User Interface Development Environments. State of the Art II.

8. Generic Architecture:

9. User Interface Development Environments. State of the Art III.

10. IDEAS: Interface Development Environment within OASIS

11. DEVELOPMENT PROCESS Domain Modelling Solution Specification Use Cases System Design (OASIS) User Interface Design (OASIS+IU) Domain Model (ARCA) Task Analysis Application Code Generation User Interface Code Generation Task Model User Interface Model User Model Final Application Dialog Model Presentation Model

12. Abstraction level i Vertical structuring refine Abstraction level i+1 Model Traceability Horizontal structuring viewj viewk viewi Model Development

13. traceability reification The development process Abstract Model Abstract Specification Design Model Desing Specification Methodological Approach Formal Support (Oasis)

14. Model Architecture Dynamic view Functional view Deontic view Structural view Ontological model requirement level entities actions / actors actands bussiness policies implements to Abstract model analysis level bussiness objects abstract syncronization abstract valuations bussiness rules implements to Design level design objects design syncronization design valuations desing rules Design model deontic logic Formal support Semantical modeling dinamic logic STD ,CCS

15. REQUIREMENTS MODEL

16. User Interface Models : Domain Model: • It represents the system entities, its attributes, methods and relationships. • Model used by Object Oriented Methodologies to describe the Information System. • Strong relation with UI Models.

17. The Ontology • What is an ontology? • The specification of a conceptualization (knowledge sharing) • A “ set of terms of interest in a particular information domain (T) and the relationships (R) among them” (ontological commitments) • T = {t1,t2,...tn} ; R = {r1,r2,...rn} • ti = (tti, teri); tti  TT ; • ri = (tri, tii tfi) and tri  T R; • TT = {predicator thing, action, actor, rule} • TR = {execute, actand, use, extend, etc.} • FRISCO + UML ( extended use case)

18. Client Rent << extends >> Rent a Car Car Agency Administrator TopNumberOf Cars Client The Task/Domain ModelRequirements LevelExample: Rent a Car

20. User Interface Models I: Task Model: • It defines the ordered set of activities and actions the user has to perform to achieve a concrete purpose or goal. • Artifact: essential for task development. • Artifact: modeled as objects and represented in the domain model. • Strong relation between the task model and the domain model. • Task Description: • Objective. • Ordered set of actions necessary to achieve the goal. • Artifacts involved in the task.

21. Task Model: Template (Example: Car Rental) • Task: Rent a car. • GENERAL FEATURES: • GOAL: The administrator rents a car to the client. • PRECONDITION: - The car is available. • - The car is in good conditions. • - The client has not more cars than permitted • SUCCESS CONDITIONS: - The administrator checks the car’s availability and state. • - The administrator brings the client´s state up to date. • - The client receives the solicited car. • FAILURE CONDITIONS: - The car is not available. • - The client already has remted the maximum number of cars permitted. • PRIMARY ACTORS: Client, Car. • SECONDARY ACTORS: Administrator. • TRIGGER ACTION: The client request to rent a car. • NORMAL SCENARIO: • .The client request to rent a car. • .The administrator checks the state and the availability of the requested car . • .The administrator checks that the client has not rented the top number of cars permitted. • .The administrator gives the client the car. • .The client receives the requested car. • VARIANTS: • .The car is not available. • .The car is not in good state. • .The client already has the top number of cars permitted to rent. • RELATED INFORMATION: • Priority: High • Duration: 15 mins. • Frequency: 10/day.

22. User Interface Models III: User Model: • It describes the characteristics of the different types of users. • Purpose: Support the creation of individual and personalised User Interfaces. • Adapted UI: The user model represents the different roles of a user (supervisor, administrator, employee). • Adaptative UI: Depends on the type of user (child, adult, handicapped). • User characteristics: • Application Independent (child, adult, handicapped). • Application Dependent (supervisor, administrator, employee).

23. User Model II: For each kind of user, the set of tasks he/she can perform is established. For each kind of user in relation with a concrete task, a projection /specialitation on the actions within the task that he/she can perform is established. Depending on the user’s particular characteristics (child, adult, etc.), the information and the interaction established by the Dialog Model to show the information contained in the Domain Model is adapted to the user. User Interface Models III:

24. USER MODEL Scenarios(Tasks): e1=a11 ... a1n1 AI ={aij , i={1..m} j={1 ..nm} } e2=a21 ... a2n2 ei A* .... E={e1, ..., em}  A* em=am1 ... amnm A*={aij , ai1j1, ... aikjk / a  A}  : A*  A* A* (A) = {, {a11}, {a12}, ... , {a11, a12},...} (E) = {, {e1}, ... , {en}, ... , {e1,e2},... {e1, ..., em} } Users: U = {u1, ... , uk } User Model: (1)- R: U (E) P. Ej.: R(U1) = {e1, e2}; R(U2) =  ; R(U10) = {e1, ... , em} (2)- ei = ai1 , ... , aini P (A) : E Ex.: P (A) ( ) =  P (A) (a  Re) = if a  (A) then a  P (A) (Re) else P (A) (Re) (3)- User Type : MDial.(str.)  : MDial.(behav.) R’: U View (MDom.) MDom.(str.) E A*

25. ANALYSIS MODEL

26. The Interface Model (Analysis level)collaboration view1 aRental: RentalCar administrator Request Car If ¬(totalContract < nrocarClient) “Client exceeds top of cars” ReturnCar Communication protocol with the user

27. The Interface Model Analysis Level: (X,P)-analysiscollaboration view2 administrator aRental: RentalCar aClient: Client aCar: Car01 RequestCar GiveCar ChargeToAccount ReturnCar ReceiveCar DischargeCar responsabilities of the object community for achiving the task

29. The Interface Analysis Model: (A,alfa)-analysis role view1 Car01 Client registrationNumber fare state conditions GiveCar ReturnCar identification totalcontrats ReceiveCar ReturnCar 0,1 RentalClient 0,* RentalObject - Abstract action vocabulary - Class by aspect (role)

32. Role Object Structure(object role pattern) Instance of class Car ClassCore ClassRole RentalCar Rental Object TaxPayment Active ClassRole1 ClassRole2 Instance of Sale Object SaleCar

33. Abstract Specification • An activivity class • Several resource classes

34. OASIS class template a) Type ( A, X, alfa, P ) A : Attributes X : Events alfa : cuasi-functions (dynamic logic) P : Process

35. participants c: Cliente as alquilador ; v: Vehiculo01 as objeto_alquiler; Activity Type Class Specification Class AlquilarVehiculo participants c: Cliente as alquilador ; v: Vehiculo01 as objeto_alquiler; constants attributes plazoLimAlquiler : nat; nroVehCliente : nat; events solicitarVehiculo(nroDias) calling with members c.cargarVehiculo(); v.entregarVehiculo(nroDias); recibirVehiculo(fechaEntrega) calling with members c.descargarVehiculo(); v.devolverVehiculo(fechaEntrega); preconditions solicitarVehiculo if (c.totalContrato < nroVehCliente) exception(“Cliente excede tope de vehiculos ”); end class AlquilarVehiculo

36. Class Vehiculo01 played by Vehiculo(objetoAlquiler) Resources Class Type Specification Class Vehiculo01 played by Class Cliente Vehiculo (objetoAlquiler) identification identification nit : (nit); codigo : (codigo); constant attributes constant attributes nit :nat; codigo : nat; nombre : string modelo : nat; variable attributes marca : String; totalVehiculos : nat(0); variable attributes events tarifa : nat; cargarVehiculo( ); disponible : bool(true); descargarVehiculo( ); estadoActual : string; valuations events [cargarVehiculo] totalVehiculos += 1; entregarVehiculo( ); [descargarVehiculo] totalVehiculos += -1; devolverVehiculo( ); end class Cliente valuations [entregarVehiculo] disponible = ‘false’; [devolverVehiculo] disponible = ‘true’ end Class Vehiculo01

38. Design Phase : - Analysis - Dialog Model OASIS+IU Specification Interface Model - Design - Object Oriented User Interface Specification Language