MGB 2003 Daniel Pereiro Borland Ibérica

Presentación del tema: "MGB 2003 Daniel Pereiro Borland Ibérica"— Transcripción de la presentación:

1 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Desarrollo de aplicaciones Solución Borland Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

2 Contenido Desarrollo de aplicaciones: Solución Borland
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 La alternativa: Caos Total
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
MGB 2003 Procesos de desarrollo Software Excellence Triangle Best-in-class TECHNOLOGY Skilled PEOPLE Effective PROCESSES © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

6 Procesos de desarrollo de Software
MGB 2003 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) … © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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 ?
MGB 2003 ¿ Usamos un proceso de desarrollo efectivo ? © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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 ALM Application Lifecycle Management
MGB 2003 Borland ALM Application Lifecycle Management Solución modular pero fuertemente integrada. Todo el equipo es coordinado por el SCM. DESIGN Together® Edition for .NET DEVELOP VS.NET C#Builder™ StarTeam® MANAGE Optimizeit™ For .NET DEFINE TEST CaliberRM™ DEPLOY Janeva™ InterBase® © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

14 LA VISIÓN DE BORLAND Buenas prácticas
MGB 2003 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. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

15 LA VISIÓN DE BORLAND Reengineering The Process
MGB 2003 LA VISIÓN DE BORLAND Reengineering The Process Configuration, Change, and Project Management Requirements Management Requirements Management CaliberRM Quality Assurance / Testing Analyze Design Develop Deploy Object-Oriented Analysis and Design Together Integrated Development Environment VS.NET, C#Builder Unit Testing OptimizeIT Configuration and Change Management StarTeam © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

16 Integración de herramientas MS Visual Studio .NET
Together CaliberRM StarTeam OptimizeIT Janeva

17 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Gestión de Requisitos Borland CaliberRM Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

18 Origen de errores en el Software
Requirements Errors (56%) Other Errors (10%) Coding Errors (7%) Design Errors (27%) Source: James Martin, An Information Systems Manifesto

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 MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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
MGB 2003 Información en CaliberRM Dentro del proyecto Hierarchy # ID # Atributos de usuario Atributos del sistema Proyecto Tipos de requisito Dentro de los tipos de requisito Requisitos Se definen por estos grupos de atributos (tabs) Detalles Otros.. Trazabilidad Referencias Discusión Historia Validación Responsables © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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
MGB 2003 CaliberRM - Integraciones Web Server: Microsoft IIS Netscape Server Apache CaliberRM Server Windows NT/2000/XP Java-enabled Browser Mod & Dev Tools Together JBuilder C#Builder Visual Studio .NET Rational Rose Embarca. Describe SELECT Enterprise Others via SDK SCM Tools StarTeam PVCS Microsoft VSS ClearCase CM Synergy Testing Tools Mer. TestDirector  PASS  FAIL Desktop & PM Tools Microsoft Office Microsoft Project SPC Estimate PRO MyProject 1 Task 1.1 Sub Task 1 1.2 SubTask 2 1.2.1 Sub Task 3 CaliberRM Integrations © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

25 En la práctica … Why? What? How? When? Where? MGB 2003
© 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

26 Integración con Together CC

27 Integración con Visual Studio .net

28 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Gestión de Configuración Borland StarTeam Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

29 La necesidad de un SCM Los errores corregidos suelen reaparecer
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

30 Trabajo Colaborativo Arquitectura interna … Workflow …
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

31 Trabajo Colaborativo Gestión de cambios e incidencias …
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

32 Trabajo Colaborativo Desarrollo colaborativo…
MGB 2003 Trabajo Colaborativo Desarrollo colaborativo… Acceso centralizado a “assets” del proyecto (ficheros, peticiones de cambio, tareas, requisitos,…), notificaciones y discusiones por ,… 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) © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

33 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: 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 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 STCMD Comandos Unix o Win JStar GUI via Java Apps Java, VB, C++,... Web Browser

35 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Diseño y Optimización de aplicaciones Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

36 Algunos datos Diseñar ¿Qué hacemos el 85% restante?
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

37 Necesidad de modelar El código es fácil de entender?
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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
MGB 2003 Diagramas UML Comportamiento del Sistema Estructura del Sistema Requisitos del Sistema Diagramas Casos de uso Diagrama Objetos Diagrama Componentes Diagrama Clases & Paquetes Diagrama Despliegue Diagrama Secuencia Diagrama Colaboración Diagrama Actividades Diagrama Estados Aspectos estáticos Aspectos dinámicos © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

40 UML y Vistas del sistema
Diagrama Estados Diagrama Componentes Diagrama Casos de uso Diagrama Objetos Diagrama Actividades Vistas Diagrama Clases Diagrama Secuencia Diagrama Secuencia Diagrama Colaboración

41 Patrones de Diseño Origen
MGB 2003 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. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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

43 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

44 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. …

45 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.

46 Patrones de GoF Casificació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ñ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

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.

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 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.

51 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.

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

53 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.

54 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Diseño de aplicaciones Borland Together For .NET Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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. Incremental Code Generator Together® Parsing Engine LiveSource™

57 Together for Visual Studio .NET
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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
CaliberRM

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 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Optimización de código Borland OptimizeIt For .NET Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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:

64 ¿Qué código tenemos que optimizar?
MGB 2003 ¿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. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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 -> oiprof.exe User interface -> OptimizeDotNet.exe Se comunican vía TCP por el puerto 1964 (por defecto).

67 Optimizeit Profiler for .net
MGB 2003 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. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

68 Optimizeit Profiler for .net
CLR Overview Memory Profiling CPU Profiling

69 Optimizeit Profiler – CLR Information
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

70 Optimizeit Profiler – Memory Profiling
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

71 Optimizeit Profiler – CPU Usage Profiling
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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 MGB 2003 Daniel Pereiro Borland Ibérica www.borland.es
Integración de entornos Borland Janeva Daniel Pereiro Borland Ibérica © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

74 Enterprise Mixed Environments Enterprise Application Interoperability
MGB 2003 Enterprise Mixed Environments Enterprise Application Interoperability Client Department Server Corporate Data Center .NET Web Services, CORBA®, and Borland Janeva Java © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

75 Borland Janeva Interoperabilidad entre Microsoft .NET y J2EE o CORBA
MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

76 La solución Janeva .NET Thin Clients J2EE and CORBA Back Ends
EJB BES AppServer BES VisiBroker WebSphere WebLogic InterBase Oracle Sybase MS-SQL Server “Bridge” Web Server Web Service “Bridge” .NET Server ASP Janeva No additional infrastructures needed No changes required to back end Seamless interoperability J2EE and CORBA infrastructures are leveraged, including Qualities-of- Service features High Performance .NET Thick Clients

77 Janeva - Java and Corba Interop
MGB 2003 Janeva - Java and Corba Interop .NET Janeva Run- Time Corba Proxy ASM .NET EXE J2EE .CS C# Source Code (or VB, Delphi,J#, etc) .NET IDE .EJB IIOP Compile Type IDL JAR Compiler Develop Deploy © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

78