This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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?
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
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
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
Managed SQL CE API.NET classes to perform replication
Train ManagerUses Ibis in the field
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
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
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
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’
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?
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
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
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
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?
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
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
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
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...