Jowles Object Model

From HBMobile
Jump to navigationJump to search

Introduction

Why would we care about an Object Model?
Most of the work in any software development project is in trying to figure out the true requirements. Slinging code is (or can be) easy, interviewing end users to figure out what they want in a mobile phone and then deciphering their responses... well, that's a lot harder. What makes it even harder is that if you're doing any large project, you have to get all your developers thinking about the project in the same way. This is why I like Model Driven Architectures (User:Msh). MDA as it is described in the literature may be overkill for the Jowles project, but the theory sounds nice. I'm also a fan of Object-Orientation 'cause in my experience, encapsulation and inheritance are powerful tools for representing application models.
Okay... one more time... in English...
In short, the Jowles Object Model describes the behavior of system components in a language-neutral manner. Used correctly, Objects and Classes can make it easy to add new features to the system. We're all about giving people the ability to extend the stuff we've done here, so OO Models it is.

So... uh... what Does It Do?

Jowles is a web application that controls a mobile phone. Consisting of a Javascript enabled web client, a GSM module control daemon and a PHP-based testing and mocking Interface; each component is capable of being independently upgraded. The goal of the system is to provide a toolkit for experimentation.

So a long time ago, some really smart people noticed there was a lot of boiler-plate code in typical applications. The main loop, command line parameter checking, opening files, etc. It was all pretty similar. Someone got the great idea that you might speed up your programmers if you put all the common code in one place. From this simple idea we got shared object libraries, application frameworks and even Object Orientation. So... what is Jowles? It's everything that sits between your mobile application and the operating system.

Instances, Interfaces and Classes

Application

The Application represents the top level... uh... application that the UI interacts with. It understands concepts like communication modules, data networking interfaces and the like. The Application's main role is to serve as a collection for other components and to manage parsing and production of XML messages. A single Application object is created at launch time, and it's an instance of the Application class.

The Application contains:

  • One or more instances that respond to the Communication Module Service Interface. (Telit GM862, Siemens MC75 or SIP/RTP Softmodule)
  • One or more instances that respond to the Location Module Service Interface. (GPS Module)
  • One or more instances that respond to the Data Networking Service Interface. (PPP over GSM Data, GPRS, EDGE, WiFi, Wired Ethernet, etc.)
  • One or more instances that respond to the Messaging Service Interface. (SMS, MMS, email, WebMail, VoiceMail, etc.)
  • One or more instances of a Configuration Settings Class (including "Factory Defaults" and "Current Settings".)
  • A Call History collection that contains instances that respond to the Call Metadata Interface.
  • An Address Book that correlates names with voice numbers, fax numbers, modem numbers, email addresses, SIP URIs, etc.
  • An Inbox collection that contains instances that respond to the Message Metadata Interface.
  • A KeyStore that contains keys, shared secrets, certification requests and certificates.