Software development methodologies for embedded systems and mobile applications Yolande Berbers DistriNet, taskforce embedded systems Department of Computer.

Software Software development development methodologies for methodologies for embedded systems embedded systems and mobile and mobile applicationsapplications

Yolande BerbersYolande Berbers

DistriNet, taskforce “embedded DistriNet, taskforce “embedded systems”systems”Department of Computer ScienceDepartment of Computer ScienceKULeuven, Leuven, BelgiumKULeuven, Leuven, Belgium

22

embedded systems andmobileapplications what? characteristicsmethodologies UML MDA AOSDlanguages and platforms C/C++ POSIX Java/RTSJ C#conclusion

The current software technology cannot always fulfill these higher requirements

too late too expensive too many errors

The current software technology cannot always fulfill these higher requirements

too late too expensive too many errors

Context and problem statementContext and problem statement

• Embedded systems and mobile applications increasing market:

•50 X more embedded processors than PC•growth embedded market will continue, PC market: plateau

functionality and complexity: ever increasing (communication, multi-media, …)

quality requirements are growing (ISO 900x) time-to-market is getting ever smaller

33


Context and problem statementContext and problem statement

• Information systems even bigger increase in functionality and complexity comparable increase in quality requirements focus on methodological aspects of software production modern methodologies have proven benefits

• clear increase of productivity and quality improvement

• Why can the same not be said for embedded and mobile applications: not enough focus on methodological aspects need for adapted methodologies

44


OverviewOverview

• characteristics of problem domain:embedded systems and mobile

applications• design methodologies addressing these

problems• overview of languages and API’s

that address or just do not address these problems

55


Embedded systems and mobile applications (ES Embedded systems and mobile applications (ES and MA)and MA)

• embedded system = a product with a processor and software software is inextricably bound with the product

software is not sold separately

software gives the added value

product has a well defined functionality

many examples in today's consumer market

many examples in our global infrastructure

• mobile applications applications on mobile devices

are in communication with servers

• mobile applications span both mobile device and server SW

66


Characteristics of ES and MA (1)Characteristics of ES and MA (1)• can be large and usually very complex

not just proportional to the SLOC related to variety of code need for continuous maintenance

• environments change fast applications should run anywhere

• not just application for one platform• need for device-independent platform to develop applications• need for integration with many different back end or

middleware with particular attention for interoperability, coupling, footprint

• e.g. binary over HTTP: poor interoperability, tight coupling, but light footprint RPC framework: reasonable interop, tight coupling, light footprint messaging: reasonable interop, loose coupling, reasonable footprint XML Web Services: excellent interop., loose coupling, heavy footprint

77


Characteristics of ES and MA (2)Characteristics of ES and MA (2)

• should be reliable and safe user does not accept malfunctioning (different from

desktop)• functionality of product is what counts

embedded: often software cannot be easily changed• costly when product has to be recalled• gives bad name to companies when it happens

• different software components are active concurrently ES interacts with environment, consisting of concurrent

entities more and more ES and MA are distributed systems

88



• interactions with HW interface HW is not the usual desktop HW

• execute with resource constrains: limited processor power

• possible use of portals to offload tasks limited power usage limited memory

• need for lightweight libraries• need for reduced application footprint• no or minimal garbage collector

• slow, unreliable networks necessity of support of Offline mode use of remote facades (fine-grained object model but

coarse-grained access interface for improved network efficiency)

needs careful protocol design• e.g. server push instead of client pull

99



• privacy concerns data traveling over network needs to be encrypted

• special relation with user mobile applications are perceived differently than

desktops UI is a lot different

• consumer market products must be cheap

• limited memory• cheap processor

time-to-market is extremely small

1010


Gap between application software and platformGap between application software and platform

Application Application SWSW

Immaterial, Functional, Logical aspects

Abstract time,

High level structuring constructs and primitives

Simplifying synchrony assumptions wrt environment

abstraction

refinement

PlatformPlatform

Non functional properties

Execution times, interaction delays, latency, QoS

Task coordination, resource management, scheduling

1111


OverviewOverview



problems UML

• some new features of UML2.0• profile for schedulability, performance, and time

MDA: model driven architecture AOSD: aspect oriented software development

• overview of languages and API’s that address or just do not address these problems

1212


UML for ES and MAUML for ES and MA

• suitability of UML1 for ES and MA is limited because of insufficient support for concurrency, including

communication and synchronization no support for timing insufficient support for fault tolerance needed for reliability

• UML2.0 is a step in the right direction problem is: too many concepts are included, not clear how

they can be used and combined

• UML1.4 had already a profile for schedulability, performance and time is included in UML2.0

• following slides overview some new features of UML2.0 for concurrency, communication and synchronization

1313


UML2.0: Active Classes and Active ObjectsUML2.0: Active Classes and Active Objects

• A passive class executes when an other object performs operation on it

(sends a message to it)

• An active class owns an execution thread instances (objects) can initiate control activity

• in its own code• by sending messages

implemented as a process or thread

<<ActiveClass>>

Communication Supervisor

anInstance: Communication

Supervisor

Active Class Active Object

1414


UML2.0: Active Classes and Active ObjectsUML2.0: Active Classes and Active Objects

• Internal structure of active objects:

:Communication Tracking Supervisor. .

DetailLog:CommLogManager

Log1:CommunicationLog

Input:MessageBuffer

Output:MessageBuffer

1515


UML2.0: CommunicationUML2.0: Communication

• Events and Triggers 4 types of triggers related to 4 types of observable events:

• change trigger• signal trigger• call trigger• time trigger

• Signals = “asynchronous messages”

• Messages Synchronous Asynchronous Reply Create Lost Found

1616


UML2.0: Synchronization and ConcurrencyUML2.0: Synchronization and Concurrency

• A class or operation can define concurrency requirements

• A property set for a class affects all operations • Concurrency requirements:

Sequential• Intended only for use in a single thread of control

Guarded• Works in the presence of multiple threads of control• Needs an active collaboration of threads to achieve

mutual exclusion(threads need to lock and unlock objects or operations)

Concurrent• Works in the presence of multiple invocations of a

behavior to one instance and these can occur simultaneously

1717


Profile for schedulability, performance and timeProfile for schedulability, performance and time

• profile in UML specialized subset of UML that

• applies to a vertical market or application domain• may include custom or specialized notation and key

concepts• extends or specializes the UML using the “lightweight

extension mechanisms” (stereotypes, tagged values, constraints)

• Profile for schedulability, performance and time designed for real-time application domain

• standard means to capture real-time modeling concerns

1818


Profile for schedulability, performance and timeProfile for schedulability, performance and time

• modeling… resources time & concurrency schedulability, e.g. one of (or a combination of)

• statistical• worst-case/empirical

performance

• and whose info is analyzed and/or synthesized by model processors for automatic analysis (e.g. schedulability)

1919


OverviewOverview



problems UML




2020


MDA: Model Driven ArchitectureMDA: Model Driven Architecture

• Embedded systems and mobile applications need for software that runs on different platforms many design decisions assume some platform

characteristics

• => need for Model Driven Architecture defined by OMG as the next step beyond UML

2121


MotivationMotivation

• Platform-independence is central in MDA• Lack of methodological support for separation of

platform-independent and platform-specific concerns prevents exploiting separation PIM/PSM beneficially

(Platform Independent Model/Platform Specific Model)

• Platform-independence is not black-or-white some gaps are too large there are different levels of platform-independence platform characteristics considered throughout the

development

• The levels should be identified and defined

• Preferably, platform characteristics assumed in models should be explicitly defined

2222


Related models in MDA developmentRelated models in MDA development

platform selection

...platform-independent

design

platform-specific design

request/response

asynchronous messaging

JMS

Any other MOM

CORBA JavaRMI

design

design alternatives

...Abstract

platform

Abstract platform

2323


OverviewOverview



problems UML




2424


AOSD: Aspect Oriented Software DevelopmentAOSD: Aspect Oriented Software Development

• Embedded systems and mobile applications many different concerns, other than business logic

• e.g. privacy• e.g. support for Offline• e.g. good performance

• problem such concerns crosscut an application

• => Aspect Oriented Software Development

• Crosscutting concerns Many technical concerns are coded in multiple business

logic objects : they crosscut

2525


Logging is not modularizedLogging is not modularized

• where is logging in org.apache.tomcat ? red shows lines of code that handle logging not in just one place not even in a small number of places

Copyright © aspectj.org

2626


The prism analogyThe prism analogy

Copyrigth © Ramnivas Laddad, I want my AOP!

2727


The symptomsThe symptoms

• Code tangling Business objects simultaneously interact with several

technical concerns Simultaneous presence of elements from each concern's

implementation in the code

• Code scattering crosscutting concerns, spread over many objects, related

implementations also spread over all those objects Example : a system using a database

• performance concerns may affect all the objects accessing the database

2828


The architect’s under/over design dilemmaThe architect’s under/over design dilemma

• Predicting the future requirements is a difficult task

• Should an architect include a logging mechanism in a system that does not initially need it? Where should the logging points be ? What information should be logged ?

• Or miss future crosscutting requirements and need to change, or possibly re-implement many parts of the system ?

2929


Aspect Oriented ProgrammingAspect Oriented Programming

• Implement individual concerns in a loosely coupled fashion

• Combine these implementations to form the final system

• AOP is a logical evolution of OOP

• Aspect Oriented Software Design (AOSD) = Aspect Oriented support throughout lifecycleOOP AOP

Modularized implementations of common business concerns

Modularized implementations of crosscutting business and technical

concerns

Common concern's implementation called a class

Technical concern's implementation called an aspect

3030


AOSD development stagesAOSD development stages

• Identify business (classes) and technical (aspects) concerns

• Implement each concern separately• Weave concerns together

Copyrigth © Ramnivas Laddad, I want my AOP!

3131


OverviewOverview



problems• overview of languages and API’s

that address or just do not address these problems

C and C++ in combination with POSIX Java and Java Virtual Machines Real Time Specification of Java (RTSJ) C# and .NET runtime environments

3232


CC

• history of C designed 1969-1973 for writing UNIX comes from the traditional procedural family goal: suitable for systems programming

• small and compact• close to the hardware

• popularity of C for ES and MA large ES until 1995:

• only 10 to a few 100 SLOC• primarily to interface with hardware• little or no “intelligence”• C was a good language for this purpose

there is a lot of experience on C programmers of ESW

• in the past: often no computer scientists

3333


CC

• problems with C no support for managing complexity

• current ES: a lot more complex than 10 years ago reliability

• problems with weak syntax (e.g. while (x=3) …)• weak typing• pointers (important origin of bugs)

no support for concurrency

3434


C: suitability for ES and MAC: suitability for ES and MA

• managing complexity: --

• reliability: --

• concurrency: --

• dealing with time: --

• interaction with HW: ++

• efficiency: ++

• speed of SW development: --

3535


C++C++

• history of C++ design in 1983-1985 designed as an extension of C (that is why it is called C++) goal: combination of efficiency of C and Object Orientation

• “solved” problems (??) support for managing complexity

• C++ is OO• OO was introduced to manage complexity and to allow

for reuse reliable

• but pointers remain a problem• no automatic garbage collection• too many possibilities, too much freedom

3636


C++C++

• problems with C++ in general many properties with a complex behaviors many properties depend on implementation difficult to predict from basic principles many users choose to use only a subset

• because complete language is too complex and too unpredictable

• problems with C++ for ESW no support for concurrency

3737


C++: suitability for ES and MAC++: suitability for ES and MA

• managing complexity: +

• reliability: -

• concurrency: --

• dealing with time: --


• efficiency: ++

• speed of SW development: -

3838


interlude: concurrencyinterlude: concurrency

• applications that have concurrency: need processes or threads can be offered by a language

• e.g. Java, C#, Ada can be offered by an API, used by a non-concurrent

language• e.g. POSIX in combination with C and C++

• advantages of concurrent programming languages better readability and maintainability of code portable over different operating systems compiler can test on correct use a language offers one view on how to use concurrency, one

integrated way of embedding concurrency in the philosophy of a language, one way of solving concurrency problems

3939


POSIXPOSIX

• POSIX = Portable Operating System Interface for Computer Environments IEEE standard (IEEE 1003.1c)

first version 1985 offered as API of operating systems comes from the UNIX world is supported by all UNIX-variations, RTOS, …

POSIX-compliant

offers support for concurrency problem

• offers many (too many) different routines• that have (too) many parameters• programmer is confronted with many details• does not offer one way of doing concurrency

it is a basis on which ALL concurrency philosophies can be implemented

4040


JavaJava• originally designed for the “consumer electronics

market” • idea of byte-code• code had to be very reliable• ‘got its breakthrough through the web

• good things about Java known C-like (but better) syntax easier to write bug-free software

• no explicit pointers - no dangling pointers• automatic garbage collection

a lot richer than C with many built-in elements• concurrency• exception-handling• object orientation

easy to learn (a lot easier than C++) byte code for portability extensive class libraries with standardized API : high level

of abstraction (concurrency, networking, GUI)

4141


Java Java

• problems with Java for ES and MA no direct access to hardware (no pointers, but Java can

call C) size of code is not suitable for many ES

• JVM can be large• Class library is very large

JAR file for full library JDK 1.3: 15MB inefficiencies

• byte code interpretation: a lot slower than C/C++• dynamic loading, garbage collection: cost time

• interpreter of JIT: maybe not the optimal compiler unpredictable

• OOP leads to unpredictability• garbage collector can pre-empt a running task• Just-in-Time compilation slows down first access

• solutions: slimmed versions of Java and JVM

4242


Java 2 Standard Edition and Java 2 Micro EditionJava 2 Standard Edition and Java 2 Micro Edition

• Java Class Libraries: several “standard platforms” (APIs): Standard Java – full set of libraries for desktops /

workstations: J2SE (Java 2 Standard Edition)

Personal Java – subset for smaller devices was intended for Windows CE; is something of the past

Embedded Java – analogous, but memory conscious J2ME (Java 2 Micro Edition)

• new attempt for a slim Java JVM with less functionality (e.g. no floating point support) smaller API (a.o. UI)

• Configuration defines minimal JVM features and Java Class Library for a certain set of devices

• Profile defines APIs for a certain configuration, can mean an

extension of Java Class Library

• 2 configurations have been defined: CLDC, CDC

4343


Java 2 Micro Edition: CLDCJava 2 Micro Edition: CLDC

• CLDC = Connected Limited Device Configuration for devices with at least 192 kB RAM 16-bit or 32-bit processor most important target: gsm’s JVM becomes KVM without o.a.

• Floating point (but is included again in newest version); JNI, Reflection, Finalization, user-defined class loaders, Thread groups and daemon threads

Class libraries, subset of a.o. Java.io, Java.lang, Java.util Extra library: Javax.microedition.io (http, sockets) JavaCodeCompact: some Java Classes in C are compiled

and linked with KVM

• only one profile with CLDC: MIDP: Mobile Information Device Profile

adds API for LC displays, media player, API for games

4444


Java 2 Micro Edition: CDCJava 2 Micro Edition: CDC

• CDC = Connected Device Configuration for devices with at least 2 MB of memory 32-bit processor JVM: no restrictions Class libraries: subset

• 3 profiles Foundation Profile

• with API for resource-constrained devices without GUI• basis java.io, java.lang, java.net + javax.microedition.io

Personal Basis Profile• Idem + basis GUI (part of AWT)

Personal Profile• Idem but fuller AWT and support for applets

4545


Java: suitability for ES and MAJava: suitability for ES and MA

• managing complexity: ++

• reliability: ++

• concurrency: ++

• dealing with time: -

• interaction with HW: -

• efficiency: --

• speed of SW development: ++

4646


RTSJRTSJ

• RTSJ: Real-Time Specification for Java mission

• initiatiated in December 1998 – JSR-0001 Sun, IBM (lead participant) and vendors from RTOS

community

• January 2002 – Official final release V1.0

[To extend] The Java Language Specification and The Java Virtual Machine Specification [to provide] an Application Programming Interface that will enable the creation, verification, analysis, execution, and management of Java threads whose correctness conditions include timeliness constraints (also known as real-time threads).

4747


RTSJ: key domainsRTSJ: key domains

• Thread Scheduling & Dispatching• Synchronization and Resource Sharing• Memory management

including Physical Memory Access

• Asynchronous Actions Asynchronous Event Handling Asynchronous Transfer of Control Asynchronous Thread Termination

• Time, Clocks and Timers

4848


RTSJ: suitability for ES and MARTSJ: suitability for ES and MA


• reliability: ++

• concurrency: ++

• dealing with time: ++


• efficiency: --

• speed of SW development: +

4949


C# .NETC# .NET

• C#: Microsoft’s answer to Java modern language Equivalent with Java 1.5

• similarities with Java similar syntax and “feel” large class library Intermediate Language running on CLR (Common Language

Runtime) Garbage collection, Reflection, Support for concurrent

programming Platform independent philosophy , JIT compilation

• differences with Java easier transition from C++

• operator overloading, support for direct memory access in “unsafe” code

CLR in reality currently: only on Microsoft platforms: closed world

5050


.NET Compact Framework .NET Compact Framework

• designed for devices with limited resources PDA’s, smartphones, …

• offers subset of .NET class library

• had specific libraries for mobility

• similar to J2ME Connected Device Configuration, but no KVM

• runs only on Windows CE .NET devices

5151


C#: suitability for ES and MAC#: suitability for ES and MA


• reliability: ++

• concurrency: ++

• dealing with time: +

• interaction with HW: +

• efficiency: +

• speed of SW development: ++

5252


overview suitability of languages for ES and MAoverview suitability of languages for ES and MA

C C++ Ada Java RTSJ C#

Managing complexity -- + ++ ++ ++ ++

Reliability -- - +++ ++ ++ ++

Concurrency -- -- ++ ++ ++ ++

Dealing with time -- -- + - ++ +-

Interaction with HW ++ ++ +- - ++ +

Efficiency ++ + -- -- -- +

Speed of SW developm

-- - + ++ + ++

Platform independence

+- +- ++ ++ + -

5353


conclusionconclusion

• Embedded systems and Mobile computing are growing rapidly traditional design methodologies and languages do not

adequately address the specific characteristics of ES and MA

need for adapted design methodologies and modern languages

surrounded by ‘invisible’computers

with natural

interaction

andintelligent behaviour

versus

Software development methodologies for embedded systems and mobile applications Yolande Berbers DistriNet, taskforce embedded systems Department of Computer.

Documents

mobile applications

servers mobile applications

fast applications

embedded processors

mobile devices

software software

ma embedded system

pc growth embedded market