Daniel Pereiro

1
Desarrollo de aplicaciones Solución Borland

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

2
Contenido

• Desarrollo de aplicaciones
• Proceso de desarrollo de Software.
• Calidad en el desarrollo de aplicaciones.
• Mejorar el rendimiento de las aplicaciones.
• Solución Borland

3
Desarrollo de Software

• Actividades
• 1 Definir que queremos construir (capturar
  requisitos)
• 2 Analizar requisitos y diseñar el producto
• 3 Construir el producto
• 4 Probar el producto
• 5 Entregar/Desplegar

4
Por qué un proceso?

• Permite mejorar las tareas repetitivas hasta la
  entrega del software
• Dirige y controla de las tareas asignadas a los
  distintos perfiles
• Permite comunicación entre las partes interesadas
• La alternativa Caos Total

5
Procesos de desarrollo Software Excellence
Triangle
Best-in-class TECHNOLOGY
Effective PROCESSES
Skilled PEOPLE
6
Procesos de desarrollo de Software

• El objetivo de un proceso de desarrollo debe ser
  asegurar la calidad del Software.
• Orientado a
• Cumplir el 100 de los requisitos de usuario.
• Generar sólo la documentación necesaria.
• Procesos de desarrollo mas conocidos
• Unified Process (UP)
• Rational Unified Process (RUP) (Pesado)
• Extreme Programming (XP) (Ligero)
• Feature Driven Development (FDD) (Intermedio)

7
RUP (Rational Unified Process )

• Define las siguientes fases del desarrollo
• Se realizan una o varias iteraciones y dentro de
  cada una sigue un modelo en cascada.
• Use case-driven, architecture-centric, iterativo
  e incremental.
• Problemas
• Debe ser customized
• El proceso llega a ser el fin no el medio
• Se acaba implementando en cascada
• Las herramientas son complejas

8
Agile Processes

• Casi lo contrario a RUP
• Orientado a las personas y no a los procesos
• Cualquiera hace cualquier cosa!
• Adaptativo en lugar de predictivo
• Más centrado en el código que en la documentación

9
XP (Extreme Programming)Agile Processes

• Características
• Mantener las cosas tan sencillas como sea
  posible.
• Repetir de forma extrema las tareas que merecen
  la pena, como las pruebas.
• Trabajar en función de las necesidades del
  momento.
• UserStories como base del software a
  desarrollar.
• Usar cualquier cosa útil

• Principios
• Diseño simple
• Pequeñas releases
• Probar constantemente
• Refactoring
• Programar en parejas
• Cualquier programador cambia cualquier código
• Integración continua
• 40 horas semanales
• Cliente siempre presente

10
Usamos un proceso de desarrollo efectivo ?
11
Fases del desarrollo tradicional

• El vació entre las distintas fases de desarrollo
  tradicional requiere que el equipo realice
  manualmente la integración.
• Proceso lento, inflexible y la colaboración baja.
• tiempo, recursos, dinero.

12
Proceso iterativo
Test/Deploy
Analysis
tiempo
Construct
Design
13
Borland ALMApplication Lifecycle Management

• Solución modular pero fuertemente integrada.
• Todo el equipo es coordinado por el SCM.

VS.NET CBuilder
DEVELOP
StarTeam
MANAGE
Optimizeit For .NET
CaliberRM
DEFINE
TEST
Janeva InterBase
DEPLOY
14
LA VISIÓN DE BORLANDBuenas prácticas

• Alta integración entre fases de desarrollo.
• Gestión de requisitos (efectiva)
• Modelado visual (UML)
• Conocimiento (Patrones de diseño)
• Desarrollo iterativo (crecimiento incremental)
• Verificar la calidad del Software continuamente
• Control de cambios a todos los niveles,
  requisitos y código (visibles en tiempo real)
• Trazabilidad a través de todo el ciclo de vida.

15
LA VISIÓN DE BORLAND Reengineering The Process
Requirements Management CaliberRM
Analyze
Design
Develop
Deploy
Object-Oriented Analysis and Design Together
Integrated Development Environment VS.NET,
CBuilder
Unit Testing OptimizeIT
Configuration and Change Management StarTeam
16
Integración de herramientasMS Visual Studio .NET
17
Gestión de Requisitos Borland CaliberRM

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

18
Origen de errores en el Software
19
Síntomas mala gestión de requisitos

• Perdemos más tiempo gestionando documentos que
  requisitos
• Hemos generado una solución técnicamente
  perfecta, pero el cliente no la acepta
• No podemos medir el estado real del proyecto
• Al llegar un cambio, el análisis de impacto se
  realizaba manualmente o no se realizaba
• Se desconoce el motivo por el cual se implementa
  un componente...

20
Borland CaliberRM

• Es la totalmente configurable e integrable con
  otras herramientas.
• Entorno distribuido y colaborativo
• Notificaciones en tiempo real de cambios en los
  requisitos a los responsables
• Tratamiento de requisitos como objetos
• Repositorio centralizado
• Versionado de los requisitos
• Múltiples vistas sobre los requisitos
• Generación de documentación automática

21
Características principales

• Flexibilidad Definición tipos requisitos y
  atributos
• Integración
• Productividad Desarrollo / Pruebas
• Trazabilidad, auditorías, seguimiento
  dependencias
• Datamining
• API abierta Java, COM y .net (sig. versión)
• Acceso remoto (Cliente Web)
• Foros de discusión
• Glosario
• Seguridad
• Personalización de informes (Document Framework)

22
Información en CaliberRM
23
Requisitos en CaliberRM
Cada requisito tiene un identificador, se integra
en una jerarquía y tiene múltiples atributos
sobre los que registrar información importante
Numero jerárquico Determina su posición en la
jerarquía, puede cambiar cuando un requisito se
añade, elimina, etc.
Nombre del requisito Especificación corta del
requisito. Permite reconocerlo rápidamente
Identificador Identificador único del requisto
que no cambia ni puede reutilizarse.
Descripción del requisito Contiene una
descripción completa y no ambigüa del requisito.
24
CaliberRM - Integraciones
25
En la práctica
Why?
What?
How?
When?
Where?
26
Integración con Together CC
27
Integración con Visual Studio .net
28
Gestión de Configuración Borland StarTeam

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

29
La necesidad de un SCM

• Los errores corregidos suelen reaparecer
• Imposibilidad de reconstruir releases previas de
  software
• Cambios o desapariciones misteriosas de
  componentes
• Cambios múltiples sobre el software no son
  correctamente controlados
• No existe un modo de rastrear o auditar los
  cambios

30
Trabajo Colaborativo

• Arquitectura interna
• Permite acceso remoto, soporte a múltiples
  plataformas y clientes, configurable (SDK),
  control de acceso
• Workflow
• Definición de reglas de negocio, procesos, roles
  
• Desarrollo en paralelo
• Control de versiones
• Soporte completo a la gestión de la
  configuración, indicación de estados del
  repositorio, desarrollo en paralelo, acceso a
  proyectos PVCS y SourceSafe

31
Trabajo Colaborativo

• Gestión de cambios e incidencias
• Modulo de gestión de cambios integrado,
  integración con TestDirector, notificaciones de
  cambio integradas
• Gestión de requisitos
• Pequeño módulo de gestión de requisitos,
  integración con CaliberRM
• Gestión de tareas
• Gestión básica de tareas, integración
  bidireccional con MS Project

32
Trabajo Colaborativo

• Desarrollo colaborativo
• Acceso centralizado a assets del proyecto
  (ficheros, peticiones de cambio, tareas,
  requisitos,), notificaciones y discusiones por
  e-mail,
• Explotación de la información
• Ordenación y priorización de assets, histórico de
  cambios, baselining
• Reports
• Starteam proporciona informes personalizables a
  través del SDK StarTeam DataMart (análisis de la
  información)

33
Borland StarTeamEl proceso de desarrollo

• Proceso de gestión de requisitos
• Seleccionar un requisito aprobado como parte del
  proceso de check-in
• Enlazar versiones de ficheros con versiones de
  requisitos

• Proceso de gestión de cambios
• Seleccionar un cambio aprobado como parte del
  proceso de check-in
• Enlazar versiones de ficheros con versiones de
  propuestas de cambio

• Proceso de gestión de versiones
• Add, checkin y checkout
• Vistas, revisiones y etiquetas
• Discusiones y notificaciones por e-mail

StarTeam WorkFlow

• Proceso de gestión de tareas
• Seleccionar una tarea aprobada como parte del
  proceso de check-in
• Enlazar versiones de ficheros con tareas del
  proyecto

34
Arquitectura StarTeam
StarTeam Server
SGBD-ODBC
PVCS
VSS
Cliente StarTeam IDE Soporte SCC
StarGate SDK
StarDisk Integración con Explorer
Apps Java, VB, C,...
STCMD Comandos Unix o Win
JStar GUI via Java
Web Browser
35
Diseño y Optimización de aplicaciones

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

36
Algunos datos

• For every 1 you spend on development, you will
  spend 2 on maintenance.
• Only about 15 of software development effort is
  devoted to programing.
• Walker Royce

Qué hacemos el 85 restante?
Diseñar
Sistema extensible (Herencia-Polimorfismo). Un
buen diseño reducirá el mantenimiento
37
Necesidad de modelar

• El código es fácil de entender?
• El código es fácil de comunicar?
• Millones de líneas de código
• Diferentes lenguajes!
• Soluciones
• UML
• Patrones de Diseño

38
UML (Unified Modeling Language)

• Lenguaje para visualización, definición,
  construcción y documentación de Software.
• UML no es un lenguaje de programación visual.
• Autores Booch, Jacobson y Rumbaught.
• Compendio de otros lenguajes (U).
• Ventajas
• Comunicación entre desarrolladores.
• Diferentes vistas de un sistema.
• Independiente de lenguajes de programación.
• Representación visual de nuestro sistema.

39
Diagramas UML
Comportamiento del Sistema
Estructura del Sistema


Requisitos del Sistema
Diagrama Objetos
Diagrama Componentes
Diagramas Casos de uso
Diagrama Clases Paquetes
Diagrama Despliegue
Diagrama Secuencia
Diagrama Colaboración
Diagrama Actividades
Diagrama Estados
Aspectos estáticos
Aspectos dinámicos
40
UML y Vistas del sistema
Diagrama Estados
Diagrama Casos de uso
Diagrama Componentes
Diagrama Actividades
Diagrama Objetos
Vistas
Diagrama Secuencia
Diagrama Clases
Diagrama Colaboración
Diagrama Secuencia
41
Patrones de DiseñoOrigen

• En los años 70 Christopher Alexander escribió
  algunos libros documentando patrones para
  ingeniería civil y arquitectura.
• La comunidad del Software adopto la idea.
• Se popularizaron con el libro
• Design Patterns Elements of Reusable Software
• Conocidos como patrones de GoF (Gang of Four).
• Contiene diseños útiles apreciados en numerosos
  proyectos, que fueron identificados y
  documentados.
• Ninguno patrón fue inventado por los autores.

42
Patrones de DiseñoDEFINICIÓN

• Each pattern is a three-part rule, which
  expresses a relation between a certain context, a
  problem and a solution
• Christopher Alexander, A Pattern Language
• A pattern is an idea that has been useful in one
  practical context and will probably be useful in
  others
• - Martin Fowler, Analysis Patterns
• Un patrón es una solución de diseño, probada y
  documentada, de un problema que aparece
  repetidamente en un contexto particular y en
  consecuencia puede ser imitado para resolverlo.

43
Patrones de DiseñoDEFINICIÓN

• En esencia, son plantillas de diseño
  reutilizables
• Esqueleto básico adaptable, no una librería de
  clases.
• Útiles para programadores y arquitectos porque
• Documentan un mecanismo simple que trabaja bien
• Transfieren conocimiento (Vocabulario común)
• Describen soluciones como combinación de patrones
• Reutilizan diseños y decisiones de implementación
  

44
Patrones de DiseñoElementos básicos de un Patrón

• NOMBRE
• Descripción corta que identifica a un patrón
• Incrementa nuestro vocabulario, haciendo más
  fácil pensar sobre el diseño y comunicarlo a
  otros.
• PROBLEMA
• Describe cuando aplicar el patrón, el problema y
  su contexto.
• SOLUCIÓN
• Describe los elementos que forman el diseño, sus
  relaciones, responsabilidades y colaboraciones
  (Diagramas).
• CONSECUENCIAS
• El resultado de aplicar el patrón.

45
Patrones de GoFCasificación Por Proposito

• Creational patterns
• Abstracción sobre el proceso de instanciación de
  objetos
• Mejoran la flexibilidad y reduce el acoplamiento.
• Structural patterns
• Describe como clases y objetos pueden ser
  compuestos para formar grandes estructuras.
• Behavioral patterns
• Describe patrones de objetos y clases, y patrones
  sobre la comunicación ente ellos.
• Herencia para distribuir comportamiento entre
  clases y composición para distribuir
  comportamiento entre objetos.

46
Patrones de GoFCasificación Por Proposito

• Creational patterns
• Abstract Factory Pattern
• Builder Pattern
• Factory Method Pattern
• Prototype Pattern
• Singleton Pattern
• Structural patterns
• Adapter Pattern
• Bridge Pattern
• Composite Method Pattern
• Decorator Pattern
• Facade Pattern
• Flyweight Pattern
• Proxy Pattern

• Behavioral patterns
• Chain of Responsibility Pattern
• Command Pattern
• Interpreter Pattern
• Iterator Pattern
• Mediator Pattern
• Memento Pattern
• Observer Pattern
• State Pattern
• Strategy Pattern
• Template Method Pattern
• Visitor Pattern

47
Patrones de DiseñoOtras Categorias

• Distintas formas de catalogar patrones
• Design Patterns
• Architectural Patterns
• Analysis Patterns
• Creational Patterns
• Structural Patterns
• Behavioral Patterns
• Otra clasificación frecuente es (Layers Pattern)
• Presentation Tier Patterns
• Business Tier Patterns
• Integration Tier Patterns

48
Pattern Frame

• Diferentes niveles de abstracción
• Arquitectura, Diseño e Implementación.
• Diferentes puntos de vista
• Bases de datos, Aplicación, Despliegue e
  Infraestructura.
• http//msdn.microsoft.com/architecture/patterns

49
Web Presentation Patterns Model-View-Controller

• Desacoplar Lógica de negocio/Datos, Presentación
  y Control de flujo de la aplicación.
• Permite cambiar presentación sin modificar la
  lógica, múltiples vistas de un modelo, separar
  perfiles, etc.

50
Web Presentation PatternsObserver

• Permite alertar de un cambio de estado a otros
  objetos, sin introducir dependencias entre ellos.
• Desacoplar el modelo y la vista El modelo no
  requiere información de la vista, sólo notifica
  los cambios a los Observers que tiene
  registrados.

51
Web Presentation PatternsPage Controller

• La separación Vista-Controlador es implícita en
  ASP.NET.
• Usa un controlador por página.
• En algunos casos podemos ampliarlo añadiendo una
  clase BaseController que incorpora funciones
  comunes (como validar parámetros) y el resto
  heredan de ella.

52
Web Presentation PatternsFront Controller

• Centraliza todas las peticiones en un único
  controlador.
• Útil cuando la navegación entre páginas es
  dinámica y se basa en reglas configurables.

53
Web Presentation PatternsFront Controller - El
manejador

• Cada petición HTTP es procesada por una instancia
  de clase que implemente IHttpHandler (o otra
  interfaz del API).
• El manejador delega la creación del objeto
  Command correcto en la clase CommandFactory.

54
Diseño de aplicaciones Borland Together For .NET

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

55
Sincronización modelo código The hard way
56
Sincronización entre modelo y código

• Tecnología Together LiveSource
• Elementos UML de clases son la viva
  interpretación del código subyacente.
• Modelo-Código, Código-Modelo Siempre
  sincronizados.

57
Together for Visual Studio .NET

• Permiten la utilización del lenguaje de modelado
  UML dentro de Ms Visual Studio .net
• Presentación de Diagramas desde el código dentro
  de Visual Studio .net
• Ingeniería inversa desde cualquier código fuente
• Sincronización automática entre modelo y código
• Generación automática de Documentación
  actualizada
• Patrones de diseño (GoF, estándar,
  personalizados, )
• Exportación / Importación del modelo vía XMI

58
Together for Visual Studio .NET DIAGRAMAS UML

• Soporte de diagramas UML
• Class/Namespace diagram
• Use Case diagram
• Interaction (sequence and collaboration)
• Activity diagram
• Statechart diagram
• Component diagram
• Deployment diagram

59
Together for Visual Studio .NET
60
Together Design Pattern Support

• Reutilizar soluciones probadas
• Gang of Four (GoF) patterns
• Nuestros propios patrones!

61
Generación automática de documentación

• Muestra cada dato introducido
• Siempre esta actualizada
• Incluye todos nuestros diagramas
• Es navegable

62
Optimización de código Borland OptimizeIt For
.NET

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

63
Cuándo optimizamos el rendimiento?

• En todo momento
• La optimización debe hacerse de forma iterativa.
• Nadie conoce mejor el código que quien lo ha
  desarrollado.
• Nadie está mejor situado en el ciclo de
  desarrollo para solucionar problemas de
  rendimiento que el autor del código.
• Muchos de los problemas de rendimiento ocurren en
  la integración de componentes.
• Nota http//www.nunit.org

64
Qué código tenemos que optimizar?

• No es necesario optimizar todo el código (regla
  80/20).
• El reto es descubrir qué partes de nuestra
  aplicación suponen un cuello de botella o
  consumen la memoria ...
• Intentar optimizar cada línea de código supone un
  esfuerzo innecesario.
• Los depuradores clásicos no son suficientes!
• OptimizeIt permite una optimización de código
  inteligente y eficiente.

65
Optimizeit Profiler for .net

• CLR es responsable de la ejecución de toda la
  fontanería de nuestra aplicación.
• Este alto nivel de abstracción permite centrarse
  en la lógica de la aplicación.
• Posibles problemas excesiva actividad del GC,
  memory leaks o excesivos objetos temporales.

66
Optimizeit Profiler for .net

• OptimizeIt esta formado por dos aplicaciones
• Audit System -gt oiprof.exe
• User interface -gt OptimizeDotNet.exe
• Se comunican vía TCP por el puerto 1964 (por
  defecto).

67
Optimizeit Profiler for .net

• Soporta todos los lenguajes que generan código
  manejado para CLR (C, J, Visual Basic, JScript,
  etc).
• Permite analizar código ASP.NET.
• No requiere modificar el código.
• Exportar información (ASCII, HTML, o ASCII para
  analizar).
• Localiza el código fuente implicado.
• Ejecución desde línea de comandos (Script).
• Análisis de aplicaciones remotas.

68
Optimizeit Profiler for .net

• CLR Overview
• Memory Profiling
• CPU Profiling

69
Optimizeit Profiler CLR Information

• Gráfico del Tamaño del Heap
• Número de clases cargadas en CLR
• Actividad del Garbage Collector
• Número de Threads en ejecución

70
Optimizeit Profiler Memory Profiling

• Permite encontrar memory leaks
• Manejar el garbage collection
• Monitorización en tiempo real de la asignación de
  objetos
• Gráfico de secuencia en asignación de objetos
• Permite llegar a la línea de código implicada

71
Optimizeit Profiler CPU Usage Profiling

• CPU Profiler descubre cuellos de botella en el
  código
• Lista los puntos calientes por tiempo de
  ejecución
• Gráfico de secuencia de llamadas
• Permite llegar a la línea de código implicada

72
Remote profiling

• Establecer variables de entorno para CLR
• COR_ENABLE_PROFILING 1
• COR_PROFILER OIProfiler
• Ahora CLR usará OptimizeIt Profiler Audit System
• Le proceso Aspnet_wp.exe de IIS leerá estas
  variables al ejecutar aplicaciones ASP.NET.
• Variables para configurar el análisis
• DN_PAUSE, DN_PROFILER_PORT, DN_PROFILER_MODE,
  DN_OPEN_CONSOLE,

73
Integración de entornos Borland Janeva

• Daniel Pereiro
• Borland Ibérica
• www.borland.es

74
Enterprise Mixed EnvironmentsEnterprise
Application Interoperability
.NET
Web Services, CORBA, and Borland Janeva
Java
75
Borland Janeva

• Interoperabilidad entre Microsoft .NET y J2EE o
  CORBA
• Integra en el entorno de desarrollo .NET
• No requiere conocimientos de J2EE o CORBA
• No requiere cambios en la infraestructura de
  back-end

76
La solución Janeva
.NET Thin Clients
J2EE and CORBA Back Ends
.NET Thick Clients
77
Janeva - Java and Corba Interop
Develop
Deploy
78
(No Transcript)