Clase7
Upcoming SlideShare
Loading in...5
×
 

Clase7

on

  • 351 views

 

Statistics

Views

Total Views
351
Views on SlideShare
351
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Clase7 Clase7 Presentation Transcript

    • Arquitectura de Softwareoctubre de 2007
    • Seis mejores Prácticas• Desarrollo Iterativo• Administrar Requerimientos• Usar Arquitecturas basadas en Componentes• Modelado Visual (UML)• Verificar Continuamente la Calidad• Administrar el Cambio
    • Centrado en la Arquitectura Proyección de la organización y estructura de un sistema enfocándose en aspectos particulares¿Qué es la Arquitectura de un Sistema? La descripción del Sistema a través de vistas utilizando diagramas y modelos¿Con qué notación?
    • Centrado en la Arquitectura¿Por qué es importante?• Permite una comunicación efectiva entre las personas involucradas (diseñador, desarrollador).• Promueve el reuso del software.• Permite la prueba individual e integración gradual de los componentes.• Permite crear sistemas flexibles y tolerantes a cambios.
    • Arquitectura : Vistas Proceso Unificado 1999• Vista de Modelo de Casos de Uso• Vista de Modelo de Análisis• Vista de Modelo de Diseño• Vista de Modelo de Despliegue• Vista de Modelo de Implementación
    • Arquitectura : Vistas (RUP) Krutchen 2000• Vista de los Casos de Uso• Vista Lógica• Vista de Procesos• Vista de Implementación• Vista de Entrega.
    • Arquitectura de Software: Modelo de las “4+1 Vistas” Vista Lógica Vista de Implementación Programadores Analistas/Diseñadores Usuario Final Administradores Estructura Funcionalidad de Software Vista de Casos de Uso Vista de Procesos Vista de Despliegue Integradores del Sistema Ingeniería del Sistema Rendimiento Topología del Sistema Escalabilidad Entrega, Instalación Throughput
    • Arquitectura: VistasPara modelar un sistema desde diferentesvistas se debe responder: ¿Qué vistas se requiere?Para cada vista: ¿Qué artefactos producir?
    • Arquitectura: Vistas• Vista de los Casos de Uso: Esta vista contiene los escenarios o casos de uso claves, para cada uno de los cuales se describen las secuencias de interacción entre objetos y procesos. Diagramas de Casos de Uso Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.
    • Review: Analysis and Design is Use-Case Driven • Los Casos de Uso definidos para un sistema son la base para el proceso entero de desarrollo. • Beneficio de los Casos de Uso: – Concisos, simples y comprensibles para la gran variedad de involucrados. – Ayudan a sincronizar el contenido de los diferentes modelos. Verificar Balance Cliente Depositar
    • Concepto: Realización de Casos de Uso Modelo de Casos de Uso Modelo de Diseño Caso de Uso Realización de Caso de Uso Diagramas de Diagramas de Secuencia Colaboración Caso de Uso Diagramas de Clase
    • Arquitectura: Vistas• Vista Lógica o de Diseño: Es una abstracción del modelo de diseño e identificación a gran escala del diseño de paquetes, subsistemas y clases Diagramas de Clases y Objetos Diagramas ER Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.
    • Arquitectura: Vista LógicaDiagramade Clases
    • Arquitectura: Vista Lógica
    • Arquitectura: Vistas• Vista de Procesos: • Toma en cuenta algunos requerimientos no-funcionales: Rendimiento, disponibilidad, integridad del sistema, tolerancia a fallas. • Captura aspectos de Sincronización y Concurrencia del diseño. • Control de los procesos concurrentes.
    • Arquitectura: Vista de Procesos
    • Arquitectura: Vistas• Vista de Implementación o Desarrollo: La vista de Implementación se enfoca en la organización de los módulos del software actual en el ambiente de desarrollo de software. Diagramas de Componentes Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.
    • Arquitectura: Vistas de Implementación• Diagrama de componentes
    • Arquitectura: Vistas• Vista Física o de Despliegue: • Describe mapping del SW al HW y refleja su aspecto distribuido. Diagramas de Despliegue Se complementa con vistas del Área Dinámica Diagramas de Actividad, Diagramas de Interacción, Diagramas de Estado.
    • Arquitectura: Vista de Despliegue• Diagrama de Despliegue
    • Arquitectura de Software– Es la organización o estructura de los componentes significativos dentro del sistema, lo cuales interactúan, a través de an interfaces. Los componentes pueden ser usados para formar componentes más grandes • ¿Cuáles son las partes principales? • ¿Cómo colaboran? • ¿Se tiene un marco en el cual el resto de los componentes puede ser agregado?.
    • Arquitectura de Software– La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución. IEEE Std 1471-2000
    • Arquitectura de Software¿Cómo diseñarla? A partir de los escenarios significativos del proyecto Considerando la plataforma sobre la cual se construirá el sistema: sistema operativo, Una secuencia manejador de bases de datos, específica de sistemas existentes, acciones que etc Una solución a ilustra los un problema comportamientos Utilizando la experiencia común en un arquitecturas previas contexto dado patrones de diseño.
    • Arquitectura de Software• ¿Cómo especificarla? – En dos etapas: • Nivel General: se especifican los aspectos generales del sistema a construir (middleware, sistemas existentes, etc.) • Nivel Específico: a través de diferentes vistas de los modelos: – casos de uso – clases y componentes – subsistemas – colaboraciones – interfaces – nodos
    • Arquitectura de Software de conjunto subsistemas que comparten el mismo gradoNivel general (arquitectura por niveles) de generalidad El sistema es descrito en términos de varios niveles, niveles donde los subsistemas pertenecientes a un nivel dado, sólo pueden referenciar a los componentes del nivel inmediatamente inferior Los subsistemas de los niveles superiores son construidos a partir de los subsistemas de los niveles inferiores.
    • Evolución de Arquitecturas• Aplicaciones Arquitectura Cliente- Monolíticas Servidor• Interfaces gráficas de usuario • Clientes pesados, no estándar (GUI). • Conexiones dedicadas a BD• Servicios de presentación, • Protocolos pesados negocios y persistencia en la • Ejecución remota de SQLs misma máquina.• No hay concurrencia de usuarios. • Alta administración• Alto acoplamiento entre tiers. • Bajo rendimiento • Alto tráfico de red • Baja accesibilidad
    • Evolución de Arquitecturas• Arquitectura C/S Arquitectura de 3 niveles Mejorada • Reutilización de lógica de negocio• Lógica de negocios en BD para diferentes clientes o sistemas.• Clientes pesados, no estándar. • Mejora la escalabilidad.• Conexiones dedicadas a la BD. • Mejora la flexibilidad.• Mejora en rendimiento • Independencia de la base de datos.• Alta administración• Baja escalabilidad• Baja flexibilidad• Baja portabilidad
    • Arquitecto de Software• Arquitecto es un rol en un proyecto dedesarrollo de software el cual esresponsable de: • Liderar el proceso de arquitectura. • Producir los artefactos necesarios: Documento de descripción de arquitectura • Modelos y prototipos de arquitectura.
    • • La Arquitectura de Software abarca las decisiones más significativas acerca de la organización de un sistema de software – La selección de los elementos estructurales que componen un sistema y sus interfaces – El comportamiento expresado en términos de colaboración entre estos elementos – La composición de estos elementos en subsistemas – El estilo arquitectónico que guía su organización, sus elementos e interfaces y su composición Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational Software (derived from Mary Shaw)
    • Arquitectura Vs. Diseño• La arquitectura y el diseño difieren en tres áreas: Arquitectura Diseño Nivel de Alto nivel Bajo nivel. Enfoque Abstracción específico en detalles Entregables Planear subsistemas, interfaces Diseño detallado con sistemas externos, componentes. servicios horizontales, frameworks, componentes Especificaciones de reutilizables, prototipo codificación arquitectónico Áreas de Selección de tecnologías, Requerimientos Enfoque Requerimientos no funcionales funcionales (QoS), Manejo de riesgos
    • Arquitectura Vs. Diseño• La arquitectura envuelve un conjunto de decisiones estratégicas de diseño, lineamientos, reglas y patrones que restringen el diseño y la implementación de un software. Las decisiones de arquitectura Código causan un alto Implementación impacto en los proyectos de IT Diseño Arquitectura
    • Definición de Arquitectura en RUPFase de Inicio• Con respecto a la arquitectura, en la fase de inicio de los proyectos se establece: – Requerimientos no- funcionales – Lista de riesgos y restricciones – Arquitectura inicial
    • Definición de Arquitectura en RUPFase de Elaboración• Con respecto a la arquitectura, en la fase de elaboración se establece: – Arquitectura línea base.• Entregables: – Documento de Definición de Arquitectura. – Prototipo evolutivo de arquitectura. – Guías y Estándares de Diseño.
    • RUP en 10 PasosRushton Prince. “Implementing RUP in 10steps” . (2005): Definir un Caso de Desarrollo para el proyecto. Identificar los casos de uso o funcionalidades para el proyecto. Clasificar los casos de uso según los niveles de riesgo. Clasificar los artefactos por disciplinas. Iterar a través de las disciplinas de RUP para crear los artefactos necesarios para recopilar la información necesaria para el desarrollo del proyecto.
    • RUP en 10 PasosRushton Prince. “Implementing RUP in 10steps” . (2005): Iterar a través de las disciplinas de RUP para detallar cada uno de estos artefactos. Cumplir el objetivo de la Fase de Inicio: Alcance del proyecto. Cumplir el objetivo de la Fase de Elaboración: Línea Base de la Arquitectura. Cumplir el objetivo de la Fase de Construcción: Primer release del Producto. Cumplir el objetivo de la Fase de Transición: Integrar el producto a la realidad del negocio.