nmbs “ibis” mobile architecture

ae nv/saInterleuvenlaan 27bBE – 3001 Heverlee

tel +32 16 39 30 60fax +32 16 39 30 [email protected]

NMBS “Ibis” mobileArchitectureUA – Capita Selecta Software Engineering24/11/2008

Stéphane Tombeur [email protected] [email protected]

ae nv/saInterleuvenlaan 27bBE – 3001 Heverlee

tel +32 16 39 30 60fax +32 16 39 30 [email protected]

mailto:[email protected]

mailto:[email protected]

Agenda

Software architecture ≠ software design Business Case

Build the next generation mobile sales platform for train passengers

Functional Description Solution Architecture How did we design the

solution architecture? A problem/solution approach

© AE 2008 2

What is Software Architecture?

What word(s) pop(s) up when you think about software architecture?…

What is Architecture?

Business Architecture

It all starts with a business process… Who is involved and how are they involved? What is the information model?

Application Architecture

Once we have a clear vision on the business process… Mapping process onto application(s) Describing use-cases Specifying components

Technical Architecture

Once we have a clear description of what is requested… Build or buy? How to build the application considering the requirements?

Business Case

Build the next generation mobile sales platform for train passengers

Business Case

© AE 2008 9

Replace previous generation of devices called ‘Ivette’ Limited autonomy ( < 4hrs ) Not ‘personal’ – handed over to other operator after each shift Fixed functionality, no extra functions possible End-of-life (10 yrs) Automate a number of paper forms Extend a wider array of services to passengers

Information Internet ticketing Flexible payment

‘Business agility’, ability to react to new market drivers with new kinds of tickets

Need for 3000 devices

Functional Description

That looks interesting. What does it do when I press this button?


© AE 2008 11

Ibis is a train manager’s multi-purpose personal assistant Sell tickets Write fines for not having a ticket Provide information to the customer Write train reports

Passenger numbers Damage and incident reports

Train security personnel can also use Ibis They see other features enabled by their login Write shift and incident reports

A day in the life of a train manager

© AE 2008 12

AccountingProcesses Ibis output

Manages Ibis backofficeINA Web app

INA UserPrepares Ibis data

Main datastoreOracle db cluster

Ibis front-enddatastore

Sql ServerTrain ManagerUses Ibis in the field

Train stationProvides wificonnectivity


© AE 2008 13

Ibis user can Work offline Synchronize wirelessly in train stations Register payments in a secure store Accept Visa/MasterCard as payment Use a large (Full VGA) touchscreen to interact with the device Print (thermal) tickets, receipts and train schedules Use the device as a cellphone for voice or SMS Verify internet-sales tickets with a barcode reader Provide good customer service on the train


© AE 2008 14

The Ibis device is Built on a custom hardware platform Built on a custom version of Windows Small and lightweight An electrical device with a battery

Ibis Solution Architecture

Ok, so you need to do all these different things... Now get to work!

Solution Architecture

© AE 2008 16

Managed SQL CE API.NET classes to perform replication

Ibis Mobile DeviceTrain Manager Personal Assistant

Ibis BootstrapperManages synchronization, updates and Ibis startup

Ibis ApplicationMain application

UI layerMVC-based WinForms application

View Controller

Domain layerClass library with data, exceptions and user messages

Model

Business layerClass library with business logic

Sales Component

Print Component

Train Reports Component

...

Data Access layerDB-software specific helper classes, DB-software agnostic DAC classes

SQL Server CEDatabase system software

Ibis DatabaseSQL CE database file


Train ManagerUses Ibis in the field

Requirement

Highly complex business logic

Design decision: Separation of business logic from rest of app

Impact on architecture: Layered application Separate functional components Domain objects get passed through layers

© AE 2008 17

Requirement

The application needs to be updated ‘in-the-field’

Design decision: The application will update itself through the same

technique as data synchronisation

Impact on architecture: Split application into starter exe (bootstrapper) and UI exe

© AE 2008 18


© AE 2008 19






View Controller


Model


Sales Component

Print Component


...






Systems Management

© AE 2008 20

Software updates A device is put into the field with the latest version of the

application The main application cannot update itself due to file

locking Bootstrapper starts ‘kiosk’ application Bootstrapper checks for update at startup (if in train

station) Uses SqlCe ‘CAB deployment’ feature to overwrite

application files User can ‘drop out’ of application to bootstrapper

environment to synchronise data and update the software System software update is not done in the field

Requirement

The user interface has a lot of screens, some may be added later, some implement similar functionality...

... and previously we decided on ‘separation of concerns’

Design decision: We will implement the UI with the Model-View-Controller

design pattern

Impact on architecture: Separate layer for UI Reuse of domain objects

© AE 2008 21


© AE 2008 22






View Controller


Model


Sales Component

Print Component


...






Requirement

The device has a finite amount of memory... ... and in v1 of the ‘compact’ CLR, garbage collection

was not optimal

Design decision: We will cache screen definitions for speed, but we must be

careful not to use up all the RAM

Impact on architecture: Views are grouped according to functional modules Startup of module -> load all the screens Change module -> destroy all the screens first

© AE 2008 23

Presentation Layer

Requirement

We knew up-front that the database implementation would change (SqlServerCe -> OracleLite)

Design decision: Separate data access logic and objects

Impact on architecture: Data access layer Domain objects instead of readers

© AE 2008 25


© AE 2008 26






View Controller


Model


Sales Component

Print Component


...






Requirement

Screens are complex... ... but a lot of screen functions are similar

Design decision: Create reusable screen components

Impact on architecture: Views are composite Presentation logic becomes more generic

© AE 2008 27

Requirement

Screen layout must be consistent A lot of screens do the same basic stuff

Design decision: Centralize layout and parts of presentation logic

Impact on architecture: Use base class for screens Use base class for controllers

© AE 2008 28


© AE 2008 29

Datum Keuzevak

Tijd Keuzevak

Requirement

Some data just needs to be ‘read’ and never ‘written’, but it must be _fast_!

Design decision: Allow read-only operations straight to the database

Impact on architecture: Implement Fast Lane Reader design pattern

© AE 2008 30


© AE 2008 31






View Controller


Model


Sales Component

Print Component


...






Fast-Lane Reader DAO

Requirement

Murphy is always looking over the train manager’s shoulder...

... sometimes it just goes wrong

Design decision: User actions must be ACID

Impact on architecture: Use transactions Start them from the business layer

© AE 2008 32

Requirement

Data = $$$ Sensitive data needs to be protected if the device is

stolen or if it crashes

Design decision: Encrypt credit card numbers Double bookkeeping

Impact on architecture: Use PKI to encrypt without a thief being able to unlock the

numbers (at least in his own lifetime) Database on compact flash + synchronized to server Log all financial transactions to secure storage

© AE 2008 33

Recap to Business Architecture

Can all business processes be automated? 100%?

Systems Management

© AE 2008 35

Example of a process that cannot be fully automated: Provisioning & Inventory Biggest challenge is keeping data ‘personal’

Device is essentially a cash register Amount in pocket must equal amount in register

Each device is ‘personal’, user takes it home (e.g. to recharge) ‘Hot’ spares are located throughout the country in train stations When a device breaks down, a service center locates the nearest spare

and instructs ground personnel to switch during stopover Spare needs to be ‘initialized’ with user’s login When personal device is fixed, it is put in ‘hot spare location’ and

scheduled to be switched again (user gets back his/her own device) Data from spare can be synched back to personal device, but doesn’t

need to be Data is linked to user id and device id Back office can reassign data from spare to personal device

Key Challenges

© AE 2008 37

It’s all about money Cash register needs to be 100% correct with

what’s in pocket What happens if a ticket isn’t printed correctly or

needs to be cancelled Tamper proof / Protecting OS against users Sensitive credit card data on device

Asymmetrical key encryption of CC numbers

Credit card safety requirements Algorithm + stoplist


Hardware (dZine – www.dzine.be) CPU: Intel PXA255 @ 400MHz Memory: 64MB RAM + 64MB Flash + CF Module Screen: Full VGA (640x480) 6,4” touchscreen Connectivity: USB, Bluetooth, Wifi, GSM/GPRS

Thermal Printer ISO 7816 smart card reader Contactless smart card reader Barcode scanner Magstripe reader Battery lasts long enough for a full shift with smart

power management

© AE 2008 38

http://www.dzine.be/


System software Custom build of Windows CE 4.2 Sql Server Ce (+ Sql Server 2000)

• Database replication through subscriptions• File replication through CAB deployment

(Sql Server 2000 ->) Oracle database server replication Connected to back-office through Wifi in train stations

• Cisco access points• RADIUS authentication (login + MAC)

.NET Compact Framework 1.0 SP1 Custom hardware drivers & libraries, e.g.

• Printer driver• Secure store API

© AE 2008 39


Application software 1 tier, 3 layers (UI, Business logic, Data Access) All integration to back-end done through database

replication Extensive business logic

• Ticket validation• Printing component (P/Invoke to Win32 DeviceContext API)• NMBS ‘Sabin’ like price calculation component (P/Invoke)• Separate components for hardware interaction through P/Invoke

.NET CF Windows Forms UI is MVC derived from UIP Application Block 1.0

• Presentation logic in V(iews)• Navigation and calling busines logic in C(ontrollers)• Screen data in M(odel) or ‘Data Transfer Objects’

Separate data access logic

© AE 2008 40

Layered architecture

Data Access layer

Data Access layer

Data access objects (DAO) Manages all access to the database Transforms query results into the desired objects Ensures complete encapsulation of data access

Data transfer objects (DTO) Context specific objects that reflect the information model Classes that encapsulate only data, no behavior

Fast Lane Reader Only for read only data

Fast Lane Reader

Business layer

Business layer

Contains all business logic Stateless!

Uses DTOs from DAO and other services in the business layer to execute specific task

Translates input from presentation layer into DTOs for data access layer

Domain layer

Domain layer

Accessible from every module Responsabilities:

Localization Messageboxes Exception managment

Presentation layer

Has its own architecture! Each Core Module is seen as a Task Management of Tasks is done by a TaskManager

• Starting a Task• Closing a Task• Switching Between Tasks

Each Task is made of the following:• A User Process Controller (UPC)• One or Several Forms

UPC Controls navigation between forms UPC Holds the state of the Graphical User Interface (GUI)

Systems Management

How do you keep 3000 machines running in the field and on-the-move?

5 / 7

Development Cycle

© AE 2008 51

Starting point was ‘this is the same as any 3-tier layered enterprise application’, because NMBS wanted highly detailed specs Business of selling tickets and other train manager activities is

highly complex Integration with other apps (mostly HW in this case)

Development was distributed into ‘Phases’ from the start Within a ‘phase’, we did iterations with a formal handover and

acceptance procedure after each iteration Mostly, spec was done up-front, so you could say it was

‘iterative waterfall’ Analysts were part of the team, and delivering specs + code at

the end of the iteration made it ‘kind of’ agile, as often specs would change as a result of how development went

Development Cycle

© AE 2008 52

Biggest challenge during dev was testing ... No back office available until very late in the cycle Unit testing was quite a challenge on CF 1.0 Emulation was not an option Extensive manual test scripts based on specs, tested

regularly throughout cycle

... and moving targets Every few weeks, a new build of the OS Every few months a new HW platform ... until the HW was shipped to Barco for production Not all that different from an ‘enterprise class’ application,

where integration with other apps is often the moving target

Development Cycle

© AE 2008 53

Tools Visual Studio 2003 (first beta, then RTM) Visual SourceSafe Platform Builder .NET Compact Framework 1.0, later SP1 Sql Server 2000 + Sql Server Ce + managed SqlCe SDK ActiveSync, CAB wizard, wceload Oracle db server + Oracle Lite + managed oLite SDK

Key Challenges

Small things that tend to blow up your targets

7 / 7

Key Challenges

© AE 2008 55

Ergonomics The working conditions for a user are far from ideal We needed to fit a lot of information and

functionality on a small(ish) screen Memory vs Speed tradeoff with a lot of screens Easy to use menus Good color scheme Consistent UI layout according to eye movement Need for a lot of custom UI controls

Key Challenges

Platform and tool evolution

We’ve come a long way since 2004, so how would we build it today?

7 / 7

Platform & Tool Evolution

© AE 2008 58

Windows Mobile Managed WindowsMobile SDK A lot more managed ‘system’ interaction

.NET Compact Framework 3.5 More controls (more than double the number in 1.0) WCF, Linq, Compression API, etc... Input panel API Better implementation of Dispose / GC Access to bitmaps and fonts (for printing)

Sync Services for ADO.NET More flexible and a lot more fine-grained than old SqlCe synch API Better integration with VS2008 (local database cache) Synch intelligence can be on client, less load on server N-tier synchronisation (proxy)

Sync Framework At base of sync services, support for file & folder synchronisation


© AE 2008 59

SQL Server Compact 3.5 SP1 Same db for desktop and mobile,so a lot easier to

manage for developers More features on db-runtime level

Visual Studio 2008 CLR Profiler for Mobile Unit testing for mobile applications

Office Mobile Problem was cost, so probably not an option this

time either But document templates and printing would be a

very nice feature (e.g. Word 2007 xml)


© AE 2008 60

Bottom line A lot of the concepts from the time of winCE 4.2

and .NET CF 1.0 still stand today Evolution is towards

more built-in features smarter frameworks and tools stability

Guesstimate: now 15-20% less development time for the same application (2k MD in total) More frameworks and features, less custom development More stable applications and tools (ActiveSync was a big

productivity-killer back then) But the time gain would also be due to better software

engineering practices and processes

Key Challenges

© AE 2008 61

Replication of data Provisioning / tracking of devices Update an application from within itself Connection stability Making the device ‘personal’ -> replicating the right

data to the right device Single connection to db available


© AE 2008 62

What if we went with an UMPC or tablet PC instead of custom, mobile hardware? 5 years is an eternity in HW and battery related

technologies, so UMPC’s and tablet PC’s would be an option now

Full-fledged .NET framework possible Maybe even WPF or Silverlight? Can be used for other applications as well Platform services for update, synch etc...

nmbs “ibis” mobile architecture

Documents