User Interface Modeling and Specification in an Object Oriented Environment for Automatic Software Development Isidro Ramos Polytechnic University of Valencia -SPAINIWWOST’ 01 Valencia June 01
Contents : Motivation. b Introduction. b User Interface Development Environments. State of the Art. b Generic Architecture. b IDEAS: Interface Development Environment within OASIS. b Ontological Model of IDEAS. b Conclusions. b IWWOST’ 01 Valencia June 01
Motivation: b Fill the existing gap in most of the current software development methodologies. b Incorporate a user-oriented development. b User Interface Generation within a methodological and formal support. IWWOST’ 01 Valencia June 01
Introducción II: u Development Process integrated in an object oriented software development environment: H H OASIS: Object oriented Model UML: Object oriented Methodology. u IDEAS: Enriches the model by integrating a specific model for user interface generation. u This approach includes graphical diagrams to represent the different aspects of the user interface. IWWOST’ 01 Valencia June 01
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 Analysis User Interface Model: 1) Task Model 2) User Model 3) Domain Model Design 4) Dialog Model * Object-Oriented Specification Language OASIS-UI Implementation 5) Presentation Model * Model-Based Code Generation IWWOST’ 01 Valencia June 01
User Interface Development Environments. State of the Art. u User Interface Software Tool. Classification: H H H Language-Based Tools: 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. Model: Declarative Specification of the structure and behavior of a software element. u Main Features: Declaratives because they do aspects related H Use of Declarative Models to describe all the not contain to the procedural code but descriptions with high user-system interaction. level of abstraction. H Automatic Generation of the UI starting from the models. IWWOST’ 01 Valencia June 01
User Interface Development Environments. State of the Art II. u Advantages of the Model-Based approach: H H Centralised UI specification. H Design tools for an interactive and automated development. H u User-centered development process. 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. IWWOST’ 01 Valencia June 01
Generic Architecture: IWWOST’ 01 Valencia June 01
User Interface Development Environments. State of the Art III. IWWOST’ 01 Valencia June 01
IDEAS: Interface Development Environment within OASIS IWWOST’ 01 Valencia June 01
DEVELOPMENT PROCESS Domain Modelling Solution Specification Use Cases Task Analysis User Interface Model System Design (OASIS) User Interface Design (OASIS+IU) Application Code Generation User Interface Code Generation Domain Model (ARCA) Task Model User Model Dialog Model Presentation Model Final Application IWWOST’ 01 Valencia June 01
Model Traceability Horizontal structuring Abstraction level i viewj Abstraction level i+1 Model Development viewk refine Vertical structuring IWWOST’ 01 Valencia June 01
The development process Abstract Model traceability Design Model Methodological Approach Abstract Specification reification Desing Specification Formal Support (Oasis) IWWOST’ 01 Valencia June 01
Model Architecture Structural view Ontological model entities Dynamic view actions / actors Functional view actands Deontic view bussiness policies requirement level bussiness rules analysis level implements to Abstract model bussiness objects abstract syncronization abstract valuations implements to Design model design objects Semantical modeling design syncronization STD , CCS design valuations desing rules Design level deontic Formal dinamic logic support logic IWWOST’ 01 Valencia June 01
REQUIREMENTS MODEL IWWOST’ 01 Valencia June 01
User Interface Models : Domain Model: H It represents the system entities, its attributes, methods and relationships. H Model used by Object Oriented Methodologies to describe the Information System. H Strong relation with UI Models. IWWOST’ 01 Valencia June 01
The Ontology b What is an ontology? u u u u b 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 = {t 1, t 2, . . . tn} ; R = {r 1, r 2, . . . 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) IWWOST’ 01 Valencia June 01
The Task/Domain Model Requirements Level Example: Rent a Car Client Rent << extends >> Rent a Car Agency Administrator Top. Number. Of Cars Client IWWOST’ 01 Valencia June 01
IWWOST’ 01 Valencia June 01
User Interface Models I: Task Model: H H u 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: H Objective. H Ordered set of actions necessary to achieve the goal. H Artifacts involved in the task. IWWOST’ 01 Valencia June 01
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. IWWOST’ 01 Valencia June 01 Frequency: 10/day.
User Interface Models III: User Model: H H H 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: 4 Application Independent (child, adult, handicapped). 4 Application Dependent (supervisor, administrator, employee). IWWOST’ 01 Valencia June 01
User Interface Models III: User Model II: H For each kind of user, the set of tasks he/she can perform is established. H 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. H 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. IWWOST’ 01 Valencia June 01
USER MODEL Scenarios(Tasks): e 1=a 11. . . a 1 n 1 AI ={aij , i={1. . m} j={1. . nm} } e 2=a 21. . . a 2 n 2 ei A* . . E={e 1, . . . , em} A* em=am 1. . . amnm A*={aij , ai 1 j 1, . . . aikjk / a A} : A * A* E A* A* (A) = { , {a 11}, {a 12}, . . . , {a 11, a 12}, . . . } (E) = { , {e 1}, . . . , {en}, . . . , {e 1, e 2}, . . . {e 1, . . . , em} } Users: U = {u 1, . . . , uk } User Model: (1)- R: U (E) P. Ej. : R(U 1) = {e 1, e 2}; R(U 2) = ; R(U 10) = {e 1, . . . , em} (2)- ei = ai 1 , . . . , aini P (A) : E Ex. : P P (A) ( ) = (A) (a Re) = if a (A) then a P (3)- User Type : (A) (Re) else P (A) (Re) MDial. (str. ) : MDial. (behav. ) R’: U View (MDom. ) MDom. (str. ) IWWOST’ 01 Valencia June 01
ANALYSIS MODEL IWWOST’ 01 Valencia June 01
The Interface Model (Analysis level) collaboration view 1 a. Rental: Rental. Car administrator Request Car If ¬(total. Contract < nrocar. Client) “Client exceeds top of cars” Return. Car Communication protocol with the user IWWOST’ 01 Valencia June 01
The Interface Model Analysis Level: (X, P)-analysis collaboration view 2 administrator Request. Car a. Rental: Rental. Car a. Client: Client a. Car: Car 01 Give. Car Charge. To. Account Receive. Car Return. Car Discharge. Car responsabilities of the object community for achiving the task IWWOST’ 01 Valencia June 01
IWWOST’ 01 Valencia June 01
The Interface Analysis Model: (A, alfa)-analysis role view 1 Car 01 Client identification totalcontrats Receive. Car Return. Car 0, 1 Rental. Client registration. Number 0, * fare Rental. Object state conditions Give. Car Return. Car - Abstract action vocabulary - Class by aspect (role) IWWOST’ 01 Valencia June 01
IWWOST’ 01 Valencia June 01
IWWOST’ 01 Valencia June 01
Role Object Structure (object role pattern) class Instance of Car Class. Core Class. Role 1 Class. Role 2 Instance of Rental Object Rental. Car Active Tax. Payment Sale Object Sale. Car IWWOST’ 01 Valencia June 01
Abstract Specification b An activivity class b Several resource classes IWWOST’ 01 Valencia June 01
OASIS class template a) Type ( A, X, alfa, P ) A : Attributes X : Events alfa : cuasi-functions (dynamic logic) P : Process IWWOST’ 01 Valencia June 01
Activity Type Class Specification participants c: Cliente as alquilador ; v: Vehiculo 01 as objeto_alquiler; Class Alquilar. Vehiculo participants c: Cliente as alquilador ; v: Vehiculo 01 as objeto_alquiler; constants attributes plazo. Lim. Alquiler : nat; nro. Veh. Cliente : nat; events solicitar. Vehiculo(nro. Dias) calling with members c. cargar. Vehiculo(); v. entregar. Vehiculo(nro. Dias); recibir. Vehiculo(fecha. Entrega) calling with members c. descargar. Vehiculo(); v. devolver. Vehiculo(fecha. Entrega); preconditions solicitar. Vehiculo if (c. total. Contrato < nro. Veh. Cliente) exception(“Cliente excede tope de vehiculos ”); end class Alquilar. Vehiculo IWWOST’ 01 Valencia June 01
Resources Class Type Specification Class Vehiculo 01 played by Vehiculo (objeto. Alquiler) identification codigo : (codigo); constant attributes codigo : nat; modelo : nat; marca : String; variable attributes tarifa : nat; disponible : bool(true); estado. Actual : string; events entregar. Vehiculo( ); devolver. Vehiculo( ); valuations [entregar. Vehiculo] disponible = ‘false’; [devolver. Vehiculo] disponible = ‘true’ end Class Vehiculo 01 Class Cliente identification nit : (nit); constant attributes nit : nat; nombre : string variable attributes total. Vehiculos : nat(0); events cargar. Vehiculo( ); descargar. Vehiculo( ); valuations [cargar. Vehiculo] total. Vehiculos += 1; [descargar. Vehiculo] total. Vehiculos += -1; end class Cliente Class Vehiculo 01 played by Vehiculo(objeto. Alquiler) IWWOST’ 01 Valencia June 01
IWWOST’ 01 Valencia June 01
Design Phase : - Analysis - Interface Model - Design Dialog Model OASIS+IU Specification Object Oriented User Interface Specification Language IWWOST’ 01 Valencia June 01
Скачать презентацию User Interface Modeling and Specification in an Object
d44bbc19803e8e42fa24f10d879362f9.ppt