Presentation is loading. Please wait.

Presentation is loading. Please wait.

Yolande Berbers DistriNet, taskforce “embedded systems”

Similar presentations


Presentation on theme: "Yolande Berbers DistriNet, taskforce “embedded systems”"— Presentation transcript:

1 Software development methodologies for embedded systems and mobile applications
Yolande Berbers DistriNet, taskforce “embedded systems” Department of Computer Science KULeuven, Leuven, Belgium

2 Context 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 The current software technology cannot always fulfill these higher requirements too late too expensive too many errors

3 Context 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

4 design methodologies addressing these problems
Overview 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

5 Embedded systems and mobile applications (ES 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

6 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

7 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

8 Characteristics of ES and MA (3)
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

9 Characteristics of ES and MA (4)
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

10 Gap between application software and platform
Immaterial, Functional, Logical aspects Abstract time, High level structuring constructs and primitives Simplifying synchrony assumptions wrt environment Application SW abstraction refinement How to implement assumption about instantaneous interaction between components or stronger between components and their environment, How to check that an essential property of the ASW is preserved by scheduling. Platform Non functional properties Execution times, interaction delays, latency, QoS Task coordination, resource management, scheduling

11 design methodologies addressing these problems
Overview characteristics of problem domain: embedded systems and mobile applications design methodologies addressing these 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

12 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

13 UML2.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 Active Class Active Object anInstance: Communication Supervisor <<ActiveClass>> Communication Supervisor

14 UML2.0: Active Classes and Active Objects
Internal structure of active objects: :Communication Tracking Supervisor DetailLog: CommLog Manager Input: MessageBuffer Log1: CommunicationLog Output: MessageBuffer

15 UML2.0: Communication Events and Triggers Signals Messages
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 An event is something that occurs in the system or in the environment. An event can provide a trigger to cause the execution of a behaviour. * change trigger: value that changes * signal trigger: receipt of an asynchronous signal * call trigger: an object calles an operation in an(other) object (synchronous) * a specified amount of time passing or reaching a specified deadline A signal can have attributes and operations to carry both information and behavior (asynchronous) A message can be implemented by a simple operation call or as a signal object that can be put in a queue * lost: receiver unknown * found: sender unknown

16 UML2.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 ‘Class/operation’ intended only for…

17 Profile 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

18 Profile 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) peer interpretation: client and resource are associated

19 design methodologies addressing these problems
Overview characteristics of problem domain: embedded systems and mobile applications design methodologies addressing these 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

20 MDA: 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

21 Platform-independence is central in MDA
Motivation 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 What makes a model platform-independent? What should be in this model? And how platform-independent is a model? So, I would like to talk about this methodological aspect before we have a look into how design can be represented

22 Related models in MDA development
Abstract platform request/response Abstract platform platform-independent design . . asynchronous messaging CORBA JavaRMI platform selection JMS We’re talking about distributed applications that eventually are implemented on top of middleware platforms And if we look at the development trajectory we expect when targeting different platforms, we are looking at this: different designs described at different points in the trajectory, related by realization With different design goals (e.g., varying level of portability or platform-independence) Any other MOM platform-specific design design design alternatives

23 design methodologies addressing these problems
Overview characteristics of problem domain: embedded systems and mobile applications design methodologies addressing these 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

24 AOSD: 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

25 Logging is not modularized
Copyright © aspectj.org 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

26 The prism analogy                                                                                               Copyrigth © Ramnivas Laddad, I want my AOP!

27 The symptoms Code tangling Code scattering
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

28 The 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 ?

29 Aspect 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 lifecycle OOP 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

30 AOSD development stages
Identify business (classes) and technical (aspects) concerns Implement each concern separately Weave concerns together                                                                                                   Copyrigth © Ramnivas Laddad, I want my AOP!

31 design methodologies addressing these problems
Overview 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 C and C++ in combination with POSIX Java and Java Virtual Machines Real Time Specification of Java (RTSJ) C# and .NET runtime environments

32 popularity of C for ES and MA
history of C designed 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

33 C 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

34 C: suitability for ES and MA
managing complexity: -- reliability: -- concurrency: -- dealing with time: -- interaction with HW: ++ efficiency: ++ speed of SW development: --

35 C++ history of C++ “solved” problems (??) 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

36 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

37 C++: suitability for ES and MA
managing complexity: + reliability: - concurrency: -- dealing with time: -- interaction with HW: ++ efficiency: ++ speed of SW development: -

38 interlude: 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

39 POSIX = Portable Operating System Interface for Computer Environments
IEEE standard (IEEE c) 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

40 originally designed for the “consumer electronics market”
Java 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)

41 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

42 Java 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

43 Java 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

44 Java 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

45 Java: suitability for ES and MA
managing complexity: ++ reliability: ++ concurrency: ++ dealing with time: - interaction with HW: - efficiency: -- speed of SW development: ++

46 RTSJ 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).

47 Thread Scheduling & Dispatching Synchronization and Resource Sharing
RTSJ: 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

48 RTSJ: suitability for ES and MA
managing complexity: ++ reliability: ++ concurrency: ++ dealing with time: ++ interaction with HW: ++ efficiency: -- speed of SW development: +

49 C#: Microsoft’s answer to Java
C# .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

50 designed for devices with limited resources
.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

51 C#: suitability for ES and MA
managing complexity: ++ reliability: ++ concurrency: ++ dealing with time: + interaction with HW: + efficiency: + speed of SW development: ++

52 overview 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

53 Embedded systems and Mobile computing are growing rapidly
conclusion surrounded by ‘invisible’ computers with natural interaction and intelligent behaviour versus 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


Download ppt "Yolande Berbers DistriNet, taskforce “embedded systems”"

Similar presentations


Ads by Google