Transcript AE - LORE

NMBS “Ibis” mobile
Architecture
UA – Capita Selecta Software Engineering
24/11/2008
ae nv/sa
Interleuvenlaan 27b
BE – 3001 Heverlee
tel +32 16 39 30 60
fax +32 16 39 30 70
[email protected]
www.ae.be
Stéphane Tombeur
[email protected]
Jorne Delforge
[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
 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
© AE 2008  9
Functional Description
That looks interesting. What does it do when I press this button?
Functional Description
 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
© AE 2008  11
A day in the life of a train manager
Train Manager
Uses Ibis in the field
Sql Server
Oracle db cluster
INA Web app
Ibis front-end
datastore
Main datastore
Manages Ibis backoffice
Train station
Provides wifi
connectivity
Accounting
INA User
Processes Ibis output
Prepares Ibis data
© AE 2008  12
Functional Description
 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  13
Functional Description
 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
© AE 2008  14
Ibis Solution Architecture
Ok, so you need to do all these different things... Now get to work!
Solution Architecture
Train Manager
Uses Ibis in the field
Ibis Mobile Device
Train Manager Personal Assistant
Ibis Bootstrapper
Manages synchronization, updates and Ibis startup
Ibis Application
Main application
UI layer
MVC-based WinForms application
View
Controller
Domain layer
Class library with data, exceptions and user
messages
Model
Business layer
Class library with business logic
Sales
Component
Print
Component
Train Reports
Component
...
Data Access layer
DB-software specific helper classes, DB-software
agnostic DAC classes
SQL Server CE
Database system software
Managed SQL CE API
.NET classes to perform replication
Ibis Database
Managed SQL CE API
SQL CE database file
.NET classes to perform replication
© AE 2008  16
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
Solution Architecture
Train Manager
Uses Ibis in the field
Ibis Mobile Device
Train Manager Personal Assistant
Ibis Bootstrapper
Manages synchronization, updates and Ibis startup
Ibis Application
Main application
UI layer
MVC-based WinForms application
View
Controller
Domain layer
Class library with data, exceptions and user
messages
Model
Business layer
Class library with business logic
Sales
Component
Print
Component
Train Reports
Component
...
Data Access layer
DB-software specific helper classes, DB-software
agnostic DAC classes
SQL Server CE
Database system software
Managed SQL CE API
.NET classes to perform replication
Ibis Database
Managed SQL CE API
SQL CE database file
.NET classes to perform replication
© AE 2008  19
Systems Management
 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
© AE 2008  20
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
Solution Architecture
Train Manager
Uses Ibis in the field
Ibis Mobile Device
Train Manager Personal Assistant
Ibis Bootstrapper
Manages synchronization, updates and Ibis startup
Ibis Application
Main application
UI layer
MVC-based WinForms application
View
Controller
Domain layer
Class library with data, exceptions and user
messages
Model
Business layer
Class library with business logic
Sales
Component
Print
Component
Train Reports
Component
...
Data Access layer
DB-software specific helper classes, DB-software
agnostic DAC classes
SQL Server CE
Database system software
Managed SQL CE API
.NET classes to perform replication
Ibis Database
Managed SQL CE API
SQL CE database file
.NET classes to perform replication
© AE 2008  22
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
Solution Architecture
Train Manager
Uses Ibis in the field
Ibis Mobile Device
Train Manager Personal Assistant
Ibis Bootstrapper
Manages synchronization, updates and Ibis startup
Ibis Application
Main application
UI layer
MVC-based WinForms application
View
Controller
Domain layer
Class library with data, exceptions and user
messages
Model
Business layer
Class library with business logic
Sales
Component
Print
Component
Train Reports
Component
...
Data Access layer
DB-software specific helper classes, DB-software
agnostic DAC classes
SQL Server CE
Database system software
Managed SQL CE API
.NET classes to perform replication
Ibis Database
Managed SQL CE API
SQL CE database file
.NET classes to perform replication
© AE 2008  26
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
Solution Architecture
Tijd Keuzevak
Datum Keuzevak
© AE 2008  29
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
Solution Architecture
Train Manager
Uses Ibis in the field
Ibis Mobile Device
Train Manager Personal Assistant
Ibis Bootstrapper
Manages synchronization, updates and Ibis startup
Ibis Application
Main application
UI layer
MVC-based WinForms application
View
Controller
Domain layer
Class library with data, exceptions and user
messages
Model
Business layer
Class library with business logic
Sales
Component
Print
Component
Data Access layer
Train Reports
Component
...
Fast-Lane
DB-software specific helper classes, DB-software
Reader DAO
agnostic DAC classes
SQL Server CE
Database system software
Managed SQL CE API
.NET classes to perform replication
Ibis Database
Managed SQL CE API
SQL CE database file
.NET classes to perform replication
© AE 2008  31
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
 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
© AE 2008  35
Key Challenges
 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
© AE 2008  37
Solution Architecture
 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
Solution Architecture
 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
Solution Architecture
 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)
5/7
Systems Management
How do you keep 3000 machines running in the field and on-the-move?
Development Cycle
 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
© AE 2008  51
Development Cycle
 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
© AE 2008  52
Development Cycle
 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
© AE 2008  53
7/7
Key Challenges
Small things that tend to blow up your targets
Key Challenges
 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
© AE 2008  55
Key Challenges
7/7
Platform and tool evolution
We’ve come a long way since 2004, so how would we build it today?
Platform & Tool Evolution




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  58
Platform & Tool Evolution
 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  59
Platform & Tool Evolution
 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
© AE 2008  60
Key Challenges
 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  61
Platform & Tool Evolution
 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...
© AE 2008  62