1. Jornadas Sistemas Computacionales
Ingeniería de Software en
Dispositivos Móviles
M.C. Juan Carlos Olivares Rojas
Morelia, Michoacán a 30 de abril de 2008

2. 2
Agenda
Introducción
Solución
Conclusiones
Planteamiento del
Problema

3. Evolución de la Computación
• Los paradigmas en la computación han
evolucionado a través del tiempo:
• 50’s-70’s: “Una computadora múltiples
usuarios”
• 80’s-90’s: “Una computadora un usuario”
• 2000’s: “Un usuario múltiples computadoras”

4. ¿Qué es el cómputo móvil?
• Parte de la computación que está
relacionada con la “movilidad” de los datos,
las aplicaciones y los dispositivos.
• Se debe tener movilidad y conectividad
desde cualquier punto. Es decir el cómputo
debe de ser omniprescente o ubiquo.
• En inglés recibe el nombre de mobicomp o
ubicomp

5. Dispositivos Móviles

6. Dispositivos Móviles
SmartphoneSmartphone
CommunicatorCommunicator
PalmSizePalmSize
HandheldHandheld
TabletTablet
NotebookNotebook
LaptopLaptop
Movilidad
(tamaño)
Propósito primario de uso
Comunicación Procesamiento de datos

7. Tipo de red
WWAN
(Celulares)
WLAN
(Wireless
LAN)
WPAN
(Bluetooth)
Estándar
GSM/GPRS/E
vDo
IEEE
802.11b/g/a
IEEE 802.15
Ancho de
Banda
9.6/170/2000
Kb/s
1, 2, 11, 54
Mb/s
721 Kb/s
Frecuencia
0.9/1.8/2.1
GHz
2.4 y 5 GHz
Infrarrojos
2.4 GHz
Rango 35 Km 70 - 150 m 10 m
Redes inalámbricas

8. Áreas de aplicación

9. Ejemplos de Aplicaciones

10. ¿Qué no es cómputo móvil?

11. 11
Introducción
Grado de penetración de los dispositivos móviles en nuestra sociedad
Llaves
0%
Cartera
Celulares
Tarjetas
Llaves del trabajo
Periódico
Espejo
MP3/Walkman
Videojuego
Cámara
Credenciales
80% 90% 100%50% 60% 70%10% 20% 30% 40%
Siempre
Frecuentemente

12. Estadísticas
• 2,000 millones de celulares (400 millones de
celulares con capacidad de Internet) vs. 500
millones de computadoras conectadas a
Internet (54% laptops y 46% escritorio)
• “Para el año 2009, más de la mitad de los
microprocesadores fabricados en el mundo
estarán destinados a dispositivos móviles.”

13. Estadísticas
• Ajax 22% 20,900
• Flex 2% 21,100
• Perl 6% 21,300
• J2ME 4% 22,000
• .NET 16% 24,500
• COBOL 4% 29,800

14. Estadísticas
• DOS 13% 17,300
• Linux 39% 19,500
• Apple 7% 19,600
• Win 89% 19,800
• Win CE 9% 21,800
• AS400 6% 24,200
• Unix 28% 25,800
• Mainframe 4% 32,400

15. Estadísticas
• Diseño Gráfico 21% 15,600
• Redes 35% 17,500
• UML 45% 21,000
• BI 25% 21,800
• ERP 58% 21,800
• Testing 20% 23,600
• Mejora de Procesos 31% 24,900
• EDI 3% 31,700

16. Certificaciones
• Oracle 28,600
• Sw. Quality Eng. 29,000
• Solaris 29,100
• MS System Eng. 29,200
• SEI 29,500
• IBM DB2 29,500
• SAP 30,200
• Seguridad 33,200
• IBM Websphere 33,900
• PMI 40,300

17. Ingeniería del Software
• El desarrollo de software es un proceso
artesanal dado que a la programación de
computadoras se le denomina arte.
• El objetivo fundamental de la ISw es lograr la
calidad del software.
• La ISw es un conjunto de “mejores prácticas”
que si no se llevan a la práctica no sirven de
nada.

18. Construcción de una casa para “wendo”
Puede hacerlo una sola persona
Requiere:
Modelado mínimo
Proceso simple
Herramientas simples

19. Construcción de una casa
Construida eficientemente y en un tiempo
razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas

20. Construcción de un rascacielos
I. Introducción: Modelado de SW
No cualquier persona o grupo de persona lo realiza.
Imposible sin técnicas de Ingeniería

21. Tipos de Software
• Pressman clasifica el software de la
siguiente manera:
– Software empotrado
– Software para PCs
– Software de Inteligencia Artificial
– Software de Gestión
– Software de Tiempo Real
– Software Científico
– Software de Sistemas

22. 22
Agenda
Introducción
Solución
Conclusiones
Planteamiento del
Problema

23. Problemática

24. 24
Problemática
La gran mayoría
de las
aplicaciones
móviles no están
diseñados
tomando en
cuenta las
características y
limitaciones de los
dispositivos
móviles
800
600

25. Problemática
• Se tiene la creencia de que se trata de
desarrollos tradicionales pero en “chiquito”.
• Las herramientas y entornos de
programación intentan ser semejantes a los
utilizados en aplicaciones tradicionales.
• Se tiene una gran heterogeneidad de
dispositivos y sistemas operativos

26. Problemática
• 96% de los internautas poseen celular:
– Nokia 26%
– SonyEricsson 23%
– Motorola 21%
– LG 6%
– Ericsson 5%
– Samsung 4%
– Siemens, BenQ, Blackberry 1% c/u
– Otros 8%
26Fuente AMIPCI-AMECE

27. Problemática
• PalmOS
• Windows CE (Windows Mobile)
• Symbian
• Linux embedded
• RIMOS
27

28. Problemática
• Existen pocos
estudios formales y
metodologías para el
desarrollo de
aplicaciones móviles.
• Los libros
tradicionales de ISw
no tratan este tópico.
28

29. Tipos de aplicaciones
• Stand-alone (autónomas)
• Online (clientes ligeros, desarrollos
Web móviles)
• Smart client (aquellos que son
sensibles al contexto)

30. Herramientas
• J2ME (Java 2 Micro Edition)
• .NET Compact Framework
• Aplicaciones Nativas (C, C++): eMbedded
Visual Tools: está conformada por
eMbedded Visual Basic y eMbedded Visual
C++. SDK de Symbian, etc.

31. .NET CF
ProgramaciónProgramación
Smart DeviceSmart Device
ProgramaciónProgramación
Smart DeviceSmart Device
Controles ASP.NETControles ASP.NET
MobileMobile
Controles ASP.NETControles ASP.NET
MobileMobile
Navegador WebNavegador Web
móvilmóvil
Navegador WebNavegador Web
móvilmóvil
.NET Compact.NET Compact
FrameworkFramework
.NET Compact.NET Compact
FrameworkFramework
Código LocalCódigo Local
Páginas WebPáginas Web
remotasremotas
Sistema OperativoSistema OperativoSistema OperativoSistema Operativo

32. J2ME

33. Linux embedded

34. Linux embedded

35. 35
Agenda
Introducción
Solución
Conclusiones
Planteamiento del
Problema

36. Solución
• Estudiar las capacidades y limitaciones de
los dispositivos móviles para saber que se
puede hacer en el dispositivo y que cosas
son imposibles de implementar.
• Desarrollar una interfaz adecuada que
minimice las acciones por parte del usuario
y que se adapte al tamaño de las pantallas
de despliegue. Las interfaces deben ser
intuitivas.

37. Solución
• El acceso a los datos debe de ser en forma
estructurada utilizando XML, o bien si se
permite un manejador de BD empotrado.
• Utilizar herramientas de profiling para medir
el rendimiento.
• Hacer hincapié en el reuso.
37

38. Solución
• Utilizar servicios Web (SOA) para la
implementación de los procesos de negocio.
Esto permite consumirlo en diversas clases
de aplicaciones.
• Se debe construir tarde (entender todos los
requerimientos).
• Usar datos reales. Nada de datos de prueba,
se necesitaría invertir dos veces más tiempo.
38

39. Solución
• Realizar refactorización de código para mantener
las aplicaciones más entendibles o bien consumir
menos espacio en aplicaciones Web.
• Usar implementaciones reales. No utilizar
emuladores.
• Mezclar siempre programadores con probadores
de software. Probar con muchos usuarios de
distintos tipos.

40. Solución
• Evitar lo más posible el copy & paste (utilizar
métodos de refactorización).
• Tomar en consideración todos los warnigs,
de preferencia tratarlos como errores.
• Codificar con propósito. Realizar funciones
que se van a ocupar. No realizar código de
más.
40

41. Solución
• Se deben tomar en cuenta factores de
usabilidad, accesibilidad y ergonomía de las
interfaces de usuario.
• Los mensajes de salida deben de ser
breves. Se deben considerar interfaces en
donde el usuario escriba menos.
• Reducir el número de interfaces. Entre
menos más fácil de usar y encontrar errores.
41

42. Solución
• Utilizar patrones de diseño en la solución. Se
recomienda utilizar el patrón MVC (Modelo-
Vista-Controlador). Existen muchos tipos de
patrones para problemas conocidos.
42
Implementación del
Patrón Singletón
Patrón MVC

43. Solución
• Activar las opciones de optimización de los
compiladores que de manera
predeterminada vienen desactivada por que
lo hacen más lento.
• Realizar código que sea portable para
utilizarlo en distintas plataformas.
• Las aplicaciones deben basarse en
estándares (en Web utilizar MobileOk)
43

44. Solución
• Utilizar conexiones a las BD el menor tiempo
posible (cerrar conexiones innecesarias)
• De ser posible, utilizar procedimientos
almacenados. Paginar los Recordsets.
• Las aplicaciones para dispositivos móviles
deben de estar optimizadas en dos aspectos
cruciales: tamaño y velocidad.
44

45. Optimización del tamaño
• Evitar el uso de objetos siempre que sea
posible.
• Cuando usamos objetos, debemos
reciclarlos siempre que se pueda.
• Limpiar objetos explícitamente cuando se
dejen de usar. Los recolectores de basura
no son del todo eficientes.
45

46. Optimización del tamaño
• Usar un ofuscador para reducir tamaño y
hacer ilegible nuestro código.
• Realizar empaquetamiento de las clases a
través de un archivo jar o mecanismos
similares.
• La optimización de velocidad es muy
importante. A continuación se muestran
ejemplos muy sencillos.
46

47. Optimización de velocidad
• Eliminar evaluaciones innecesarias:
for(int i=0; i<size(); i++)
a = (b+c) / i;
• Optimizado:
int tmp = b+c;
int s = size();
for(int i=0; i<s; i++)
a = tmp / i;
47

48. Optimización de velocidad
• Eliminar subexpresiones comunes:
b = Math.abs(a) * c;
d = e / (Math.abs(a) + b);
• Optimizado:
int tmp = Math.abs(a);
b = tmp * c;
d = e / (tmp + b);
48

49. Optimización de velocidad
• Aprovechar las variables locales:
for (int i=0; i <1000; i++)
a = obj.b * i;
• Optimizado:
int localb = obj.b;
for (int i=0; i <1000; i++)
a = localb * i;
49

50. Optimización de velocidad
• Expandir los ciclos:
for(int i=0; i <1000, i++)
a[i] = 25;
• Optimizado:
for(int i=0; i <100; i++) {
a[i++] = 25;
a[i++] = 25; //8 veces más
}
50

51. Optimización de velocidad
• Si se usan métodos gráficos solo actualizar las
partes de la pantalla que cambian.
• Evitar la creación de objetos intermedios. Por
ejemplo: cada vez que se concatena una cadena
se crea un objeto intermedio. En Java en lugar de
String se recomienda StringBuffer.
• Utilizar metodologías de software libre (ej. La
Catedral y el Bazar de Erick S. Raymond)
51

52. 52
Agenda
Introducción
Solución
Conclusiones
Planteamiento del
Problema

53. Conclusiones
53
• El cómputo móvil llegó para quedarse y es
toda una realidad (ya no es una tecnología
emergente).
• El cómputo móvil apenas se empieza a
desarrollar por lo que existen muchas áreas
de oportunidad ($).
• La mayoría de las aplicaciones son para el
área de entretenimiento.

54. Conclusiones
54
• El cómputo móvil no va sustituir otra clase
de cómputo pero si está modificando el
actual.
• Se deben tomar consideraciones muy
particulares para el desarrollo de software en
dispositivos móviles ya que no es cierto que
sean “aplicaciones en chiquito”.

55. 55
¿Preguntas?
• jcolivar@itmorelia.edu.mx
• juancarlosolivares@hotmail.com
• http://antares.itmorelia.edu.mx/~jcolivar/