acis desarrollar proyectos de software y evitar el fracaso ? por bernardo díaz arias...

ACISDesarrollar proyectos de software y “evitar” el fracaso ?

Por Bernardo Díaz Ariasberdiaz@yahoo.com

Arquitectura

Arquitectura

Antecedentes:

1. Demanda : Globalización

2. Basado en una analogía a la arquitectura de edificaciones.

3. Resultado de la experiencia de expertos en proyectos reales GoF.

Arquitectura

Realidad

Sistema Solar Atomos Cuerpo Humano Células Organigrama

Arquitectura

Sistemas Adaptativos

Entradas Proceso Salidas Monitoreo Control Influencias del Entorno Ciclico Recursivo

Arquitectura

Sistemas Adaptativos

Arquitectura

Sistemas Adaptativos

Arquitectura

Sistemas Adaptativos

Arquitectura

Arquitecturas de Información

Cliente

Vista = Asesor/Vendedor

Controlador = Coordinador de Area

Modelo = Operarios

Arquitectura

Arquitecturas de Información Recursividad Según Complejidad

Arquitectura

Arquitecturas de Información

Organigrama – Estructura Organizacional

Procesos de La Organización

Roles – Actividades / Área

Entidades de Negocio = Objetos de interés para una organización (pe. Formulario Predial para la SHD).

Arquitectura

Metapatrones de Diseño

Sistemas Adaptativos

Árboles de Información Puntos de Coordinación Centralizada Distribución de Responsabilidades Especialización Flujo de Información circular por nivel(eficiente)

Recursividad

ArquitecturaAntecedentes:

ArquitecturaAntecedentes:

ArquitecturaCaracterísticas

Principales:

1. Robustez

2. Escalabilidad.

3. Performance.

Rol:

1. Arquitecto2. Diseñador3. Implementador

ArquitecturaElementos Principales:

1. UML

2. Vistas UML (RUP)

3. Patrones de Diseño

4. Arquitecturas Por Tecnología (MDA: Implementation Model)

ArquitecturaGrupos de Modelos UML:

1. Static Use Case Package Class

2. Dynamic. Activity Sequence State Object Collaboration

3. Implementation. Component Deployment

Arquitectura

UML Diagramas Principales

ArquitecturaUML Diagramas de Apoyo (Opcionales):

ArquitecturaVistas UML:

ArquitecturaVistas UML 1:

1. Component View

Subsystem/Module

2. Deployment View Server/Subsystem/Module

3. Domain Model High Level (Business) Entities

4. Design View Package Classes

5. Use Cases View Use Cases / Module

6. Process View Activity / Use Case

ArquitecturaVistas UML 2:

1. Use Cases View

Use Cases / Module

2. Logical View Packages Classess

3. Process View Activities / Use Case

4. Deployment View Server/Subsystem/Module

5. Implementation View Layers/Components

6. Data View MER - Physical Model

ArquitecturaConceptos: 1. Arquitectura del Sistema:

a. D. Deployment (Subsistemas, módulos)b. D. Deployment (módulos, componentes)c. D. Packages (Por capas o subsistemas) d. D. de Clases

Control Entidad Datos interfaces entre componentes

e. D. Secuencias (Valida relaciones entre clases)

2. APIs y Frameworks según Plataforma de Implementación

3. Implementación de Referencia

Arquitectura

ArquitecturaCapas y Subcapas: Elementos 1. Data Tier

DBMS

2. Business Tier Persistence (Bidirectional-integration) Product Domain (Business Logic)*** Services (XML)

3. Presentation Tier FormManager (Bidirectional-integration) Form (JSP + JavaScript) Template (HTML) FrontController

4. Client Tier http data (Bidirectional-integration) Browser (HTML+JavaScript)

Arquitectura

Arquitectura

ArquitecturaFrameworks = 1 Spec + n-Impl

Son librerías de software (APIs) con un propósito definido en una especificación (Spec).

Los clientes del framework (desarrolladores y arquitectos) interactúan con el framework a través de la Spec. Esta se basa en roles (interfaces) con actividades y responsabilidades bien definidas (de forma similar a 1cargo – n-empleados en un área de la organización).

Entre más estándar/popular sea el framework existirán posibles implementaciones desde proveedores comerciales hasta open source.

Un framework se puede configurar para que la lógica la pueda realizar una implementación cualquiera de la Spec. Lo anterior, sin realizar cambios en código para el cliente del framework.

ArquitecturaFrameworks: Especificaciones del Java Community Process

JVM JSE 1.5.i J2EE 1.4.i

Administrativas (JNDI, JMX, JTA, Security Sandbox) Servlets (Presentación) JSP (Presentación) EJB (Negocio)

Session Entidad (Nunca recomendados por un arquitecto, sí por desarrolladores) Mensajería

JDO (persistencia) JSF (Presentación) Portal (Presentación) WSDP (XML y Web Services)

J2ME (Plataforma Móvil)

ArquitecturaEvaluación de Frameworks Opensource

Técnico1. Tiene Release de Producción / Estable ?2. Evaluar Documentación Técnica, de usuario y de

instalación3. Lea el FAQ4. Verifique instalación y Ejemplos5. Verifíquelo con sus demás herramientas en caso de

que se relacionen.

Administrativo1. Se basa en un estándar del JCP ?2. Cuantos de sus requerimientos cumple?3. Tiene soporte comercial ?

ArquitecturaCapas y Subcapas: Frameworks y

Herramientas (Maduras!!!) 1. Data Tier

DBMS

2. Business Tier Persistence (IBATIS) Product Domain = Business Logic Services (Spring ***)

3. Presentation Tier FormBeans – Forms (JSF)

Finalmente…

Muchas Gracias por su tiempo !!!