ACIS Desarrollar proyectos de software y evitar el fracaso ? Por Bernardo Díaz Arias...
-
Upload
rodrigo-munguia -
Category
Documents
-
view
14 -
download
3
Transcript of 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 [email protected]
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
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 !!!