Abstract

This paper presents an introduction to category theory with an emphasis on those aspects relevant to the analysis of the model theory of linear logic. With this in mind, we focus on the basic definitions of category theory and categorical logic.

An analysis of cartesian and cartesian closed categories and their relation to intuitionistic logic is followed by a consideration of symmetric monoidal closed, linearly distributive and *-autonomous categories and their relation to multiplicative linear logic. We examine nonsymmetric monoidal categories, and consider them as models of noncommutative linear logic. We introduce traced monoidal categories, and discuss their relation to the geometry of interaction. The necessary aspects of the theory of monads is introduced in order to describe the categorical modelling of the exponentials. We conclude by briefly describing the notion of full completeness, a strong form of categorical completeness, which originated in the categorical model theory of linear logic.

No knowledge of category theory is assumed, but we do assume knowledge of linear logic sequent calculus and the standard models of linear logic, and modest familiarity with typed lambda calculus.

Introduction

Category theory arose as an organizing framework for expressing the naturality of certain constructions in algebraic topology. Its subsequent applicability, both as a language for simply expressing complex relationships between mathematical structures and as a mathematical theory in its own right, is remarkable. Categorical principles have been put to good use in virtually every branch of mathematics, in most cases leading to profound new understandings.

Roughly a category is an abstraction of the principle that the morphisms between objects of interest are just as important as the objects themselves.

INTRODUCTION

The unified modeling language (UML) is a standardized language for modeling software systems. Although small systems are easy for a single person or a small group to comprehend and develop, large systems are more difficult to design successfully, since there are often many people and entities controlling different aspects of the system and defining how they should work from their own professional specialty or prerogative. For example, a large company requesting a new piece of software might assign the job to a project manager who has a thorough understanding of the overall system requirements, whereas a software developer assigned to work on the system is likely to care more about the ways that individual portions of a system work on a detailed level and less about the practical requirements of users and management. Similarly, an end user of the system is likely to care about how the user interface is organized and that the software is built to facilitate ease of use for everyday users, rather than that a particular software component was designed exquisitely or that the project fulfills the stated requirements that its originator decided on.

INTRODUCTION

We have now seen the basic tools we will use for the development process in creating mobile applications. The next step is to begin defining a methodology for building real applications and to show the implementation of the methodology in building these real applications.

Through the first four chapters, we discovered that, because of the condition of the mobile user and nature of the mobile application, the mobile application may interface with the user through a variety of devices and channels. In this chapter, we will take a closer look at the fundamentals of user interfaces to software applications, primarily mobile applications. We will focus on changing a paradigm shift in the application developer's thinking, moving him or her from thinking that an application will be used using a mouse, keyboard, and a monitor to thinking that an application may be used by a subset of any system input and output channel through which the user may receive stimuli from a system and respond to it. Finally, we will look at how to create user interfaces in layers so that we apply the principal of separation of concerns to orthogonal aspects of user interfaces. For demonstration purposes, we will use the XForms standard of W3C as an example for an XML-based tool designed to create the proper abstractions in user interface design.

INTRODUCTION

Proper testing and quality control of software has been said to be one of the most neglected areas of software development. Whereas this streamlining of testing and quality control can reduce the budget and the time frame for delivery of projects, the quality of the delivered product is ultimately sacrificed. Although lack of testing and quality control can be the cause of failure, or at least customer dissatisfaction, of many software products, it has been tolerated in the world of PC applications. This is mostly due to the tolerance that the users have to buggy software with stability and functionality issues. However, this tolerance does not exist in the world of mobile application development. Mobile devices are always looked upon, even if they are not, as embedded devices. To the users, there is no difference between a way a PDA, a cell phone, and a VCR should operate: The user interface must be simple and there is zero tolerance for problems relating to security, stability, performance, and all of those other things that these same users have built an immunity toward during the usage of PCs.

INTRODUCTION

We have used the term active transactions in this text only for the lack of a better term that encapsulates the active participation of a computing system in interacting with the user. What we refer to as active transactions in this text includes all those behaviors exhibited by the system that are started autonomously by the application without the immediate and synchronous invocation of the software by the user. A subset of active transactions is often referred to as push-based technologies. Although the term “push” is better used in defining the implementation of the application, one part of the application could “poll” or “pull” and still exhibit active participation in interacting with the user.

What is important to note right away is that active transactions are not limited to push. Let us look at some examples of what we may mean by active transactions:

• An active mobile application that collects end-of-day field results can scan through the records of a salesperson's visits and if he or she has failed to fill out a time sheet with the appropriate visits, the application locates the salesperson by contacting him or her at all pertinent contact points. For example, the application may call the salesperson on the phone and ask him or her to say how many hours were worked and where the work was performed. The salesperson may have simply forgotten to log his or her hours; this process would not only contact the salesperson but also give the salesperson the opportunity to provide the required information during the same session. […]