Desarrollo de aplicaciones
Solución Borland
Daniel Pereiro
Borland Ibérica
www.borland.es
Contenido
Desarrollo de aplicaciones:
Proceso de desarrollo de Software.
Calidad en el desarrollo de aplicaciones.
Mejorar el rendimiento de las aplicaciones.
Solución Borland
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
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
Procesos de desarrollo
Software Excellence Triangle
Best-in-class
TECHNOLOGY
Skilled Effective
PEOPLE PROCESSES
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)
…
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
¿ Usamos un proceso de
desarrollo efectivo ?
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.
Proceso iterativo
Test/Deploy Analysis
tiempo
Construct Design
Borland ALM
Application Lifecycle Management
Solución modular pero fuertemente integrada.
Todo el equipo es coordinado por el SCM.
Together®
DESIGN DEVELOP Edition for VS.NET
.NET C#Builder
™
StarTeam®
MANAGE
DEFINE TEST CaliberRM™ Optimizeit™
For .NET
DEPLOY Janeva™
InterBase®
LA VISIÓN DE BORLAND
Buenas 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.
LA VISIÓN DE BORLAND
Reengineering The Process
Requirements Management
Requirements Management
CaliberRM
Object-Oriented Analysis and Design Integrated Development Environment
Analyze Design
Together Deploy
Develop C#Builder
VS.NET,
Unit Testing
Quality Assurance / Testing
OptimizeIT
Configuration and Change Management
Configuration, Change, and Project Management
StarTeam
Integración de herramientas
MS Visual Studio .NET
Janeva
OptimizeIT
Together
CaliberRM StarTeam
Gestión de Requisitos
Borland CaliberRM
Daniel Pereiro
Borland Ibérica
www.borland.es
Origen de errores en el Software
Requirements Design Errors (27%)
Errors
(56%)
Other Errors (10%) Coding Errors (7%)
Source: James Martin, An Information Systems Manifesto
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”...
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
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)
Información en CaliberRM
Proyecto
Dentro del proyecto
Tipos de requisito
Dentro de los tipos de requisito
Hierarchy #
ID #
Requisitos
Se definen por estos grupos de atributos (tabs)
Detalles Trazabilidad Referencias Discusión Historia Responsables Validación Otros..
Atributos
Atributos del sistema
de usuario
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.
CaliberRM - Integraciones
CaliberRM Server
Windows NT/2000/XP
Java-enabled Browser
Web Server:
Microsoft IIS
Netscape Server
Apache
CaliberRM Integrations
MyProject
1 Task PASS
1.1 Sub Task 1
1.2 SubTask 2
1.2.1 Sub Task 3
FAIL
Desktop & Mod & Dev Tools SCM Tools Testing Tools
PM Tools Together StarTeam Mer. TestDirector
Microsoft Office JBuilder PVCS Others via SDK
Microsoft Project C#Builder Microsoft VSS
SPC Estimate PRO Visual Studio .NET ClearCase
Rational Rose CM Synergy
Embarca. Describe Others via SDK
SELECT Enterprise
Others via SDK
En la práctica …
Why? What? How? When? Where?
Integración con Together CC
Integración con Visual Studio .net
Gestión de Configuración
Borland StarTeam
Daniel Pereiro
Borland Ibérica
www.borland.es
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
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
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
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)
Borland StarTeam
El 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:
Proceso de gestión de versiones: - Seleccionar un cambio aprobado como
- Add, checkin y checkout parte del proceso de check-in
- Vistas, revisiones y etiquetas - Enlazar versiones de ficheros con
StarTeam
- Discusiones y notificaciones por e-mail versiones de propuestas de cambio
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
Arquitectura StarTeam
StarTeam Server
SGBD-ODBC
PVCS
Cliente StarTeam VSS
IDE – Soporte SCC
StarGate SDK
StarDisk STCMD JStar Apps
Integración con Explorer Comandos Unix o Win Web Browser GUI via Java Java, VB, C++,...
Diseño y Optimización
de aplicaciones
Daniel Pereiro
Borland Ibérica
www.borland.es
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
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
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.
Diagramas UML
Comportamiento del Sistema Estructura del Sistema
Requisitos del Diagramas Diagrama Diagrama
Sistema Casos de uso Objetos Componentes
Diagrama Diagrama
Diagrama Diagrama Clases & Despliegue
Secuencia Colaboración Paquetes
Diagrama Diagrama
Actividades Estados Aspectos estáticos
Aspectos dinámicos
UML y Vistas del sistema
Diagrama
Estados
Diagrama Diagrama
Componentes Casos de uso
Diagrama Diagrama
Objetos Vistas Actividades
Diagrama Diagrama
Clases Secuencia
Diagrama Diagrama
Secuencia Colaboración
Patrones de Diseño
Origen
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.
Patrones de Diseño
DEFINICIÓ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.
Patrones de Diseño
DEFINICIÓ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
Patrones de Diseño
Elementos 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.
…
Patrones de GoF
Casificació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.
Patrones de GoF
Casificación Por Proposito
Creational patterns Behavioral patterns
Abstract Factory Pattern Chain of Responsibility
Builder Pattern Pattern
Factory Method Pattern Command Pattern
Prototype Pattern Interpreter Pattern
Singleton Pattern Iterator Pattern
Mediator Pattern
Memento Pattern
Structural patterns
Observer Pattern
Adapter Pattern
State Pattern
Bridge Pattern
Strategy Pattern
Composite Method Pattern
Template Method Pattern
Decorator Pattern
Visitor Pattern
Facade Pattern
Flyweight Pattern
Proxy Pattern
Patrones de Diseño
Otras 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
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
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.
Web Presentation Patterns
Observer
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.
Web Presentation Patterns
Page 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.
Web Presentation Patterns
Front 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.
Web Presentation Patterns
Front 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.
Diseño de aplicaciones
Borland Together For .NET
Daniel Pereiro
Borland Ibérica
www.borland.es
Sincronización modelo & código
The hard way
Manage conflicts?
Forward engineer source file
Replace lost data?
Version X
Manage conflicts? Reverse engineer
Replace lost data? Model file
Version Y
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.
Incremental
Code
Generator
LiveSource™
Together®
Parsing
Engine
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
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
Together for Visual Studio .NET
Together
CaliberRM
Together Design Pattern Support
Reutilizar soluciones probadas
Gang of Four (GoF) patterns
Nuestros propios patrones!
Generación automática de
documentación
Muestra cada dato introducido
Siempre esta actualizada
Incluye todos nuestros diagramas
Es navegable
Optimización de código
Borland OptimizeIt For .NET
Daniel Pereiro
Borland Ibérica
www.borland.es
¿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
¿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.
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.
Optimizeit Profiler for .net
OptimizeIt esta formado por dos aplicaciones:
Audit System -> oiprof.exe
User interface -> OptimizeDotNet.exe
Se comunican vía TCP por el puerto 1964 (por
defecto).
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.
Optimizeit Profiler for .net
CLR Overview
Memory Profiling
CPU Profiling
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
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
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
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,…
Integración de entornos
Borland Janeva
Daniel Pereiro
Borland Ibérica
www.borland.es
Enterprise Mixed Environments
Enterprise Application Interoperability
Department Corporate
Client Server Data Center
.NET
Java
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
La solución Janeva
.NET Thin Clients J2EE and CORBA Back Ends
BES VisiBroker
InterBase
.NET Server Web Server
Web Web Web
ASP ASP ASP Service Service Service BES AppServer
Janeva Janeva Web Web Web
“Bridge”
“Bridge”
Service Service Service
EJB EJB EJB
Oracle
Janeva
Web Web Web
Service Service Service
Web Web Web WebLogic
Janeva Service Service Service
EJB EJB EJB
- No additional infrastructures needed
Sybase
Janeva
- No changes required to back end
- Seamless interoperability WebSphere
EJB EJB EJB
Janeva - J2EE and CORBA infrastructures are
leveraged, including Qualities-of-
MS-SQL
Service features
.NET Thick Server
Clients - High Performance
Janeva - Java and Corba Interop
.NET IDE
IDL
C# Source Code Proxy JAR
(or VB, Delphi,J#, etc) .CS
.NET
Develop Type Janeva
Compiler
Compile
Corba
.NET EXE Proxy Janeva
.NET Run- J2EE
.NET ASM Time IIOP
Deploy Type .EJB
.NET