Functional View of the Hypermedia Process Model
Luis OLSINA
Faculty of Engineering
Universidad Nacional de La Pampa
also at Ciencias Exactas, UN La Plata - Argentina
E-mail olsinal@ing.unlpam.edu.ar
TelFax +54 302 30497 / 22372
ABSTRACT
In this paper we discuss aspects of the conceptual architecture and the functional view of the proposed hypermedia process model. Most of the current methods such as OOHDM or RMM and design model such as HDM focus mainly in design and implementation stages leaving aside the modeling of tasks and views that are essential in an integrated development process. Even if their models are basic components to our methodological and informational view we have a strong need of a broader engineering-based software approach. To abstract the inherent complexity of software processes we deal with views of the proposed conceptual model as a way to reduce it. Our architecture classifies the perspectives in functional, methodological, informational, behavioral, and organizational views. To design this we have applied a mixture of expression-oriented descriptive and prescriptive process model strategy; i.e. the actual or desired processes are just described and represented in a somewhat formal way. This allows us to understand, to communicate, to standardize and to reuse hypermedia processes.
KEYWORDS: Process Modeling, Functional View, Hypermedia Flexible Process Model, and Web-based Information Systems.
1. INTRODUCTION
Hypermedia developments are rapidly growing both in terms of the use of the Web-based Information System and in terms of the complexity of artifacts to be designed and integrated. Despite this, the basically used strategy to develop applications has been rather an ad hoc one; i.e., code-and-fix or just-do-it strategy as stressed by Goldberg et al [6]. We have a strong need of a broader engineering-based software approach so we have thought that for the current-technological challenges the study of renewed development process and its abstraction into a hypermedia process model is a vital research area.
Five years ago, Curtis et al said "process modeling is young, and the span of the research agenda is still being formulated". Even if we know those previous research efforts in traditional Software Engineering about process modeling [3, 4, 8, 18], we could consider it a new concern in the Hypermedia community [12, 14]. Curtis et al [3] enumerate five basic research concerns for process modeling, ranging from understanding aids to automated execution support. These objectives are:
As noted above, the necessity of having an engineering approach is being observed, i.e. a disciplined and systematic employment of Software Engineering principles that help to deal with artifacts, processes and resources. Our current research concern in designing a Hypermedia Flexible Process Model (HFPM) is centered mainly in the first point, with indirect effects on the second and third points. Fourth a fifth concerns are future research concerns.
To deal with the inherent complexity of processes we propose views (also quoted as perspectives or sub-models) on a conceptual model of the hypermedia development process domain. A conceptual model represents a canonical conceptual framework of classes and relationships of the problem domain. We represent key concept for process modeling such as task, artifact, resource, agent, role, process constructor and condition among others. A view is a particular approach to specify and to communicate information about the model. Our taxonomy, enlarging on Curtis´ classification, represents five views, i.e. functional, methodological, informational, behavioral, and organizational perspectives. We argue that a methodological view is a very essential one to specify the different process constructors to be employed for a given description task [16, 17]. For instance, we have integrated in a customized process model the main constructors of OOHDM [21] because of the clear separation of concerns between conceptual, navigational and abstract interface modeling tasks, as will be shown further on.
Regarding the views of our process model, the functional view represents what tasks (or processes) should be prescribed in each phase, what hierarchical activities structure there exists for each task, what conditions (pre- and post-conditions) will be accomplished, and what inputs and outputs (artifact and control flows) will be required.
The informational view is centered on those artifacts produced or required by the tasks, on the structure of the artifacts and their interrelationships, and on the strategies of configuration management and traceability models.
The methodological view represents the process constructors to be applied to the different tasks specified in the process description. For a specific process description we can have one or more methods that give support to the task, and for a method in particular we can have one or more tools that support it.
The behavioral view represents the dynamics of the process model. For instance, the sequencing and synchronization of tasks, the information about how the activities are carried out, that is, parallelisms, iterations, feedback loops, beginning and termination conditions, among other issues. We can also specify the life cycle of an entity like an artifact, process or agent with formalisms such as FSM, Statecharts, Petri nets, etc.
In the organizational view we are considering what agents and their associated resources participate-plan-execute-control what tasks; what roles (and skill attributes) are assigned to agents, what communication strategies and groups' dynamic are applied, among other aspects.
On the one hand, to build the HFPM we have taken into account some ideas from classical lifecycles such as the waterfall model and the spiral model [2] and some ideas from the newest process models that fit better with O-O constructors; e.g., the recursive-parallel [1] or the fountain proposal. However, these lifecycles do not fit well for hypermedia developments because there are tasks, resources, roles and behaviors that belong specifically to the hypermedia processes. Speaking in a wider sense, we claim that, given the nature of hypermedia development artifacts with remarked interface-interaction-navigation attributes, a planned mixture of iterative, incremental, concurrent and opportunistic style is the appropriate one for this kind of process.
On the other hand, from the early 90's a well-known number of criteria, models and techniques that give emphasis to the structuring and producing hypermedia application have been published [among others 5, 7, 13]. Some hypermedia methods have almost recently emerged, namely: RMM [9], EORM [10] and OOHDM. They focus mainly on design and implementation issues but do not treat early life-cycle tasks, or participatory development strategies, or maintenance stages. However, it is convenient to say that as much in RMM as in OOHDM, an underlying hypermedia process is recognized; this is that an incremental and iterative behavior is defined.
Therefore the goals in this paper are to present the conceptual architecture which will bring insight about the problem domain, and to discuss the development phase of the three-phased Hypermedia Flexible Process Model and the advantages of this broader approach. This phase is composed of abstract tasks. This clear breaking down into phases and tasks on the functional view, produces greater visibility to hypermedia project, it also facilitates human understanding and communication and promotes hypermedia process standardization and reuse. In designing the HFPM we have applied a mixture of expression-oriented descriptive and prescriptive process model strategy, to follow the Lonchamps terminology [11]. The real or desired processes are just described and represented in a more or less formal way. Finally, we consider some concluding remarks and future directions.
2. THE CONCEPTUAL ARCHITECTURE
Figure 1 represents the primitive classes and relationships diagram that abstracts the conceptual model of the HFPM, useful to understand and to support process-modeling domain. This gives us a basic repository (an O-O static model) of the fundamental set of responsibilities and collaborations among entities. In process engineering, key concepts for process modeling are handled, such as process itself, task, artifact, resource, agent, role, process constructor, process description, process view, goal, condition, process language, process architecture, process-centered software engineering environment, among others. Important efforts have been made with the purpose of establishing a solid conceptual base [3, 4, 11, 20].
We think that in our conceptual model, the representation into classes and relationships, contributes to specify the problem domain in a clear and powerful way. The classes (or key model concepts) represent behavior and state. They support operations and encapsulate attributes. For instance, a class "Artifact" can have attributes such as its identity, its creation and approval date, the given version, the associated document link, etc. and it can respond to an agent request by means of creation, destruction, modification operations, both of the content and of its attributes.
On the other hand, classes support different relationship mechanisms. The relations can be given among entities of a class itself, or among different classes. We can name inheritance, aggregation, and association mechanisms. For instance, we could depict an inheritance hierarchy for the "Role" class; a compound "Artifact" is related by an aggregation mechanism; classes are also related to each other by means of association mechanisms (and use relationship as a particular case of the association).
In this way, a class of "Agent" type associated or playing a type of "Role" performs a type of "Task". (For instance: an agent "Gustavo" controls the task "design of navigational contexts" when he plays the role "project coordinator". An agent "Luis" executes the task "navigational contexts design" when he is associated to the role "project developer" and an agent "Marina" participates in the task "validation" when she occupies the role "participant user". The reader can observe that the agents have different rights, and a delegation mechanism can be settled down).
In the figure 1 we consider explicitly the essential relationships among classes. However, with seven primitive classes we could have a seven factorial of potential relationships. For this reason, when designing a process model, a division of concerns into views, as previously proposed, can diminish the complexity in process modeling.
We will make a brief description of fundamental classes and relationships of the conceptual model, extracted from [17], and we will appreciate how this artifact or document facilitates the understanding of the process-modeling domain. A "Task" represents a unit of work that is assigned to an "Agent" for its performance. A "Task" contains a "Process Description", which can include (in a formal, semi-formal or informal way) a collection of alternatives to specify the same unit of work. Also, the process description can be specified in different formalisms that will be understandable for the different involved "Agents". Agents are entities that perform processes. (The agent can be as much a human entity as a computerized tool or device. Task taxonomy in correspondence with the agents is, namely: manual, automatic and interactive). On the other hand, artifacts are persistent objects that represent the product of performing a task. An artifact can be a simple or compound object and it could be subject to a configuration management system.
If we continue reading some diagram classes and relationships we can say that an "Agent" performs a "Task" contained in the "Process Description" using some "Process Constructor". For the fulfillment of the task the "Agent" is entitled to invoke the "Operations" that are part of the "Process Constructor". The responsibility of this class is to feed the "Process", whose purpose is to produce an "Artifact" in conformance to the established "Goal". The "Process" is carried out under certain "Condition". The class "Agent" has a many-to-many relationship with the class "Resource". A resource can associate several agents and an agent can use several resources. For example, a person that is a resource can associate several agents, and an agent can use several resources like a person, computer hardware and software, physical space, etc. An agent can use a composition of resources of the same type (e. g. people's team, etc.).
Finally, the definition of this conceptual model and the distinction among different types of abstractions and concerns is of paramount importance for process modeling for several reasons. Firstly, because it represents the key abstractions of the problem domain, containing common behaviors and making explicit a set of relationships. This favors the distribution of responsibilities and identification of collaborations. Secondly, it favors the outline of views, that is to say, the division of concerns in sub-models of the process model. As previously described, to diminish the complexity, it is convenient to separate different types of information of the processes to specify, to communicate and to control portions of the model. In our research, we define the functional, informational, behavioral, organizational and methodological views. A functional perspective focalizes mainly in the "Task" class and its relationships; an informational view focalizes it in the "Artifact" class, its components and relationships; a methodological view concentrates on the "Process Constructor" class, and so on.
3. THE FUNCTIONAL VIEW OF THE HFPM
Next, we will focus on the functional view, stressing in a medium-level of granularity the development phase. A phase is a grouping of strongly related tasks carried out in certain order. There are three cohesive phases in the HFPM [16]. These three phases can be observed generally as common denominator of all defined software processes, independently of the application type and of the size of the project. These are, namely: the definition phase (called exploration phase in our model), the development phase, and the maintenance phase (called operational phase in our model).
The exploration phase is wherein initial concepts and users' needs are elicited; next, if necessary, it is possible to perform a feasibility study and, then, we can preliminarily plan the hypermedia project. The development phase is the core of the dynamic modeling. It is the essential phase for re-planning, eliciting, controlling, analyzing, designing, authoring, validating, integrating, quality assuring and documenting tasks. When a customized process model is performed, an intensive use of logical and physical modeling is made. The operational phase consists essentially of documentation, distribution, configuration and change management, artifact maintenance, and product evolution tasks.
3.1 Specifying Tasks of the Development Phase
The nature of hypermedia applications is emphasized by interface-interaction-navigation attributes, which affect the way we abstract and perform hypermedia processes. In this part we will focus on the development phase only (for the sake of conciseness), breaking down the "Task" class into its subclasses as shown in figure 2.
We will describe only the essential responsibilities representing super-task, subtasks, inputs and outputs, and also some brief additional comments about methodological and informational aspects and concepts if necessary. To do this, we will use a static template (a textual script), that does not comprise behavioral aspects among tasks such as iterations, increments, and parallelisms (that is part of the behavioral view). We do not deal in this work with aspects of the tasks such as conditions (pre and post-conditions), and detailed description task.
Task Class: Software Requirement Modeling, Alias: H
Goal: to elicit, to analyze, and to specify the users' needs, necessary attributes or features of a software system comprising functional and non-functional requirements.
Super-tasks: System Requirement Modeling, Domain Modeling.
Subtasks: Use-Case-like Modeling, Interface Modeling, Glossary Modeling, Non-functional Requirement Modeling (performance, security, portability, etc).
Inputs: Preliminary Requirement Specification and Feasibility Study Document (both from exploration phase), Physical Models (such as Prototypes and Sketches).
Outputs: Software Requirement Specification (functional and non-functional requirement specification), Interface Sketches, and Rapid-Functional Prototypes (RFP) [15].
Comments: 1) this task essentially describes the system, the environment and its relationships, reflecting an external view of the software system. In our customized HFPM we have applied some adaptation to hypermedia applications from Jacobson's well-known requirement model.
2) The H's super-task called "System Requirement Modeling" has also subtasks in order to deal with Hardware Requirement Modeling and System Architectural Design.
Task Class: Conceptual Modeling, Alias: I
Goal: to analyze and to specify the semantics of the problem domain.
Super-tasks: Domain Modeling
Subtasks: Analyze Problem Domain, and Specify Domain Models
Inputs: Software Requirement Specification, Navigation Models, and Physical Models.
Outputs: Conceptual Models.
Comments: 1) this task reflects an internal view of the hypermedia system. The conceptual models produced should be of a implementation-independent nature. For instance, in OOHDM the agents use primitives constructors such as classes, attributes (multiple-typed ones), relationships and sub-systems. The conceptual models produced are classes and instances diagram and primitives specification cards. The latter is an important technique that helps documentation and maintenance tasks introducing information for traceability issues. This can be made to different tasks (H, I, J, K, E) and serves as input to D-process.
2) Other constructors from RMM (based on E-R paradigm) or EORM (based on O-O paradigm) can be used.
3) The difference between use-cases (which are classes) of the requirement model and classes of the conceptual model is that classes communicate between each other inside the system, while use-cases are not able to communicate with other use-cases inside the same system for simplifying reasons.
Task Class: Navigational Modeling, Alias: J
Goal: to design, to structure and to specify navigational spaces in order to have a hypermedia application that considers a set of intended user profiles.
Super-tasks: Design Modeling, Domain Modeling, and System Architectural Design
Subtasks: Analyze Intended Users' Tasks, Identify Navigational Contexts, Analyze Navigational Transformations, Specify Navigational Classes, and Specify Navigational Transformations.
Inputs: Use-Case-like Model and Interface Model (from Software Requirement Specification), Architectural Design Specification, Conceptual Models, Physical Model, User and Task Analysis Model, Navigational Patterns Catalog.
Outputs: Static and Dynamic Navigational Models
Comments: 1) The navigational context is a way to organize the navigation in an implementation-independent manner. It is a design primitive or pattern that is composed of nodes, links and other navigational contexts (maybe nested). Schwabe et al said: "identifying navigational contexts is important because they are high level architectural constructs that help organizing navigation in such a way that we can describe the navigational structure of a WIS not only as a set of pages but also as a set of contexts in which those nodes will be accessed" [22]. This constructor allows to represent a coherent unit of related concepts and to establish appropriate semantic relationships fostering user orientation.
2) HDM, OOHDM, RMM and EORM methods offer process constructors that somehow support this task.
3) In OOHDM a navigational model is a view of the conceptual model. Many navigational models may be built from the same conceptual model.
Task Class: Abstract Interfaces Modeling, Alias: K
Goal: to analyze and to specify interfaces in an implementation-independent way, taking into account what events will intervene in the action language, what interfaces objects the user will perceive, and what transformations will be carried out.
Super-tasks: Design Modeling, and System Architectural Design.
Subtasks: Analyze User Interface Models, Identify Interface Objects, Analyze Interface Transformations, Specify Interface Objects, Events and Transformations.
Inputs: Static and Dynamic Navigational Models, Architectural Design Specification, Physical Models such as Interface Sketches and Rapid-Functional Prototypes, User Interface Models, User Interface Patterns Catalog.
Outputs: Static and Dynamic Abstract Interface Models
Comments: In OOHDM there is a clear separation among navigational and abstract interface models. Instead of other methods (RMM, HDM) there exists explicit models to specify, in an implementation-independent way, user-interface interactions and the effect of each user-generated event. We may also specify different interface models from the same navigational model.
Task Class: Design Pattern Employment, Alias: P
Goal: to reuse previous hypermedia design experience by the systematic employment of catalogs that document essential and recurrent aspects of hypermedia design problems and their solutions.
Super-tasks: Design Modeling, System Architectural Design, and Authoring.
Subtasks: Navigational Patterns Employment, User Interface Patterns Employment, Architectural Patterns Employment, Capture and Record new Findings.
Inputs: Documented Patterns.
Outputs: Navigational Patterns Catalog, User Interface Patterns Catalog, Architectural Patterns Catalog, and Records of new Findings.
Comments: 1) Schwabe et al [22] have documented into different categories, a set of design patterns useful to help designing architectural, navigational, and user interface aspects of a WIS. Besides the well-known design patterns previously cataloged [19], the authors have included new patterns such as "Node as a Single Unit", "Page Creation Method", "Link Creation Method", "Information-Interaction Decoupling", and "Behavioral Grouping".
2) The design patterns are independent of any methodology.
Task Class: Cognitive Criteria Employment, Alias: T
Goal: to assist the design of Web-based information spaces and their user interfaces by means of cognitive criteria so that it facilitates the quick comprehension of reading hyper-documents by the final user.
Super-tasks: Design Modeling, Authoring Criteria.
Subtasks: Coherence Criteria Employment, Orientation Criteria Employment, Navigation Criteria Employment, and Records of new Findings.
Inputs: Documented Cognitive Criteria, and Physical Models.
Outputs: Document about Coherence Criteria, Document about Orientation Criteria, Document about Navigation Criteria, and Records of new Findings.
Comments: 1) One of the major goals of reading hyper-documents is comprehension from the point of view of the final user. In cognitive science, the readability of a document is characterized by the mental effort spent in building the mental model, which represents the objects and relationships of the hyper-document. Thüring et al [23] propose a set of cognitive design issues or criteria that can be used to improve design, and respond to these questions: a) How to increase local and global coherence? b) How to improve orientation? c) How to facilitate navigation? d) How to reduce additional effort for user-interface adjustment? They identify a series of ten design issues, and from this, a series of eight principles.
2) They are independent of any methodology and should be prescribed by any hypermedia process model.
Task Class: Physical Modeling/Integration, Alias: E
Goal: physical modeling implies the creation, development and evolution of the content and structure of hypermedia components or artifacts by means of tools. Integration acts onto the assembly of these different components to produce the entire functionality of the hypermedia system.
Super-tasks: Authoring
Subtasks: Rapid-Functional Prototyping, Evolutionary Prototyping, Sketching (or Storyboarding), and Component Integration.
Inputs: Software Requirement Specification, Hardware Requirement Specification, System Architectural Specification, Conceptual Models, Static and Dynamic Navigational Models, Static and Dynamic Abstract Interface Models, Patterns Catalog, Cognitive Criteria Documents, Validation and Test Documents, Document about Quality Assurance Criteria, Multimedia Data Captured and Edited, Artifacts to Reuse, and Management Controls.
Outputs: Rapid-Functional Prototypes, Evolutionary Prototypes, Sketches, and Deliverable Products.
Comments: 1) The physical modeling process is mainly achieved by a systematic use of prototyping that we consider as a software development strategy. This strategy essentially promotes the learning, construction, demonstration and validation cycle (E-F-G tasks) based on the experimental feedback loop between developers and users. It helps discover and specify functional and non-functional requirements, experiment analysis and design alternatives, and to make grow an evolutionary base of the future system.
2) Our proposal hierarchically classifies the strategy in three concrete classes: rapid-functional prototyping (RFP), evolutionary prototyping (EP), and O-O flexible prototyping that inherit the behavior from both RFP and EP [15].
3) The E's super-task called "Authoring" has also subtasks in order to deal with Multimedia Data Capture and Edition, System Integration, and Authoring Criteria.
Task Class: Documentation, Alias: D
Goal: to organize, record, and manage the different artifacts (or references to them) of the overall activities of the three phases.
Super-tasks: System Management
Subtasks: In general the set of tasks in order to document logical and physical models, evaluation and tests among others issues.
Inputs: the document or artifacts of the different activities of the three phases.
Outputs: the different artifacts or documents recorded in different media and required by other tasks.
4. DISCUSSION
As observed in the development phase there are technical, managerial and participatory tasks. To build the HFPM we have applied a mixture of expression-oriented descriptive and prescriptive process model strategy. This allows us to understand, to communicate and mainly to standardize hypermedia processes. To explain this we would like to quote Lonchamps concepts and terminology that will help us to summarize best the utilized strategy: "People dealing with software processes may adopt two different attitudes of mind:
In order to describe processes in prescriptive and descriptive attitudes people can aim at:
So that to facilitate human understanding and communication -the first basic research concern as noted in the Introduction Section, we consider necessary a common representation of the hypermedia lifecycle which in turn can promote standardization. In order to do this we see the task of designing a process model as a two-dimensional workspace, i.e. observing and studying existing hypermedia development processes, and abstracting and prescribing desired processes. This task evolves into feedback loops among those spaces feeding and enhancing the target model, i. e., the HFPM.
On one hand, we have participated in well-succeeded hypermedia projects gaining an empirical and technical insight about the different aspects of them. This expertise and the study of other well-designed hypermedia applications have helped us to answer some questions about "how software is (or has been) actually developed" (the expression-oriented descriptive process modeling strategy side).
On the other hand, we have abstracted and represented hypermedia processes in a conceptual model useful not only to hypermedia process models but also to software process models in general. From this basic repository we have defined a set of views, for instance, the functional view that prescribes a set of tasks as previously seen. We have prescribed these tasks that could be desirable to take into account in any hypermedia instantiated project. In the same way we could prescribe desired aspects of the process model pertaining to other perspectives (the expression-oriented prescriptive process modeling strategy side). These are the rationales behind the mixture of strategies in the designing of the HFPM.
5. CONCLUSIONS AND FUTURE DIRECTIONS
Hypermedia developments are incessantly growing but the widespread used strategy to produce applications has been rather an ad hoc so far. So we have argued about the necessity to explicitly and systematically use a well-defined hypermedia process supported by engineering principles. Onto this direction we have focused on the designing of a hypermedia process model and particularly on aspects of the functional view. We have employed a mixture of expression-oriented descriptive and prescriptive process model strategies to design the proposed HFPM and we have presented the rationale behind this broader approach.
A division of concerns in views on the conceptual model helps us to focus on some perspectives in somewhat an independent way. We are now formalizing and refining some views and arranging them into process architecture. This will also imply an O-O Hypermedia Process Modeling Methodology that includes the meta-process. On the other hand, within the prescriptive approach there are two important goals that people may aim: guiding and enacting. An initial area of research is to design and develop Process-Centered Software Engineering Environments that takes into account some of these views in order to support guidance and/or enactment of hypermedia processes. These are also our future research concerns.
ACKNOWLEDGMENT
This research was conducted as part of the author's Ph.D studies. The author would like to acknowledge Dr. G. Rossi for his valuable material that helped to improve this work. Luis Olsina is partially supported by the "Programa de Incentivos de la Secretaría de Políticas Universitarias del Ministerio de Cultura y Educación de la Nación, Argentina".
REFERENCES