Clase 2 2006 Ing del Sw Procesos y Paradigmas · Puntos de SQA Conjunto de tareas Actividades del...
Transcript of Clase 2 2006 Ing del Sw Procesos y Paradigmas · Puntos de SQA Conjunto de tareas Actividades del...
Enero 2006 2
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera grupal y en 10 minutos, LEA ELCASO DE ESTUDIO y ESCRIBA la respuesta de lo siguiente:
• ¿Identifique y clasifique las causas de fracaso en: tecnológicas y organizacionales? ¿Cuáles eran las disciplinas que se necesitaba dominar para evitar este fracaso?
2. A nivel grupal, COMPARTA lo que escribió en el paso anterior.
Duración 15 minutos
Enero 2006 3
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera grupal y en 10 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
• Dadas las siguientes palabras: proceso de desarrollo, modelo, método, herramienta, instrumento, CASE, metodología, grafico. Elabore un gráfico que represente las relaciones entre ellas
2. A nivel grupal, COMPARTA lo que escribió en el paso anterior.
Duración 15 minutos
Enero 2006 4
Contenido de la sesión
Proceso de desarrolloModelos de procesoParadigmas de desarrollo
Enero 2006 5
Proceso de desarrollo
Marco de trabajo de las tareas que se requieren para construir software de calidad
Tareas
Hitos, Entregas
Puntos de SQA
Conjunto de tareasActividades del marco de trabajo
Actividades de protección
Marco de trabajo común del proceso
Enero 2006 6
Proceso de desarrollo
Modelo de capacidad de madurez
Nivel 1: Inicial
Nivel 1: Inicial
Nivel 2: RepetibleNivel 2: Repetible
Nivel 3:DefinidoNivel 3:Definido
Nivel 4:Gestionado
Nivel 4:Gestionado
Nivel 5:Optimizado
Nivel 5:Optimizado
Ad hoc, caótico, Heróico, individual
Gestión del proyectoAnalogía
DocumentadoEstandarizado
Integrado
Mediciones yControl del
Proc./producto
Retroalimentación Cuantitativa
Mejora
Enero 2006 7
Proceso de desarrollo
CMM - Nivel 5: Tener cada proceso definido rigurosamente y seguirlo al pie de la letraÁreas clave del proceso
ObjetivosCompromisos CapacidadesActividadesMétodos para supervisar la implementaciónMétodos para verificar la implementación
Enero 2006 8
Proceso de desarrollo
Nivel 2 de madurez del procesoGestión de la configuración del swGarantía de calidad del sw.Gestión de subcontratación del sw.Seg. y superv. Del proyecto de sw.Planificación del proyecto de sw.
Nivel 3 de madurez del procesoRevisiones periódicasCoord. Entre gruposIng. de prod. de sw.Gest. de integrac. del sw.Programa de formaciónDef. del proceso de la organizac.Enfoque del proc de la org.
Nivel 4 de madurez del procesoGestión de calidad del sw.Gestión cuantitativa del sw.
Nivel 5 de madurez del procesoGestión de cambios del procesoGestión de cambios de tecnologíaPrevención de defectos
Enero 2006 9
Modelos de desarrollo
Modelo de desarrollo: estrategia de desarrollo que acompaña al proceso, métodos y capas de herramientas
Edo. actualEdo. actual
Edo. actualEdo. actual
Definicóndel
problema
Definicóndel
problema
Integración de solucionesIntegración de soluciones
Desarrollotécnico
Desarrollotécnico
Edo. actualEdo. actual
Definicóndel
problema
Definicóndel
problema
Integración de solucionesIntegración de soluciones
Desarrollotécnico
Desarrollotécnico
Edo. actual
Edo. actual
Definicóndel
problema
Definicóndel
problema
Integración de soluciones
Integración de soluciones
Desarrollotécnico
DesarrollotécnicoEdo.
actual
Edo. actual
Definicóndel
problema
Definicóndel
problema
Integración de soluciones
Integración de soluciones
Desarrollotécnico
Desarrollotécnico
Edo. actual
Edo. actual
Definicóndel
problema
Definicóndel
problema
Integración de soluciones
Integración de soluciones
Desarrollotécnico
DesarrollotécnicoEdo.
actual
Edo. actual
Definicóndel
problema
Definicóndel
problema
Integración de soluciones
Integración de soluciones
Desarrollotécnico
Desarrollotécnico
Edo. actual
Edo. actual
Definicóndel
problema
Definicóndel
problema
Integración de soluciones
Integración de soluciones
Desarrollotécnico
DesarrollotécnicoEdo.
actual
Edo. actual
Definicóndel
problema
Definicóndel
problema
Integración de soluciones
Integración de soluciones
Desarrollotécnico
Desarrollotécnico
Enero 2006 10
Modelos de desarrollo
Modelo lineal secuencial
Los proyectos reales raras veces siguen el modelo secuencialEs difícil que el cliente exponga explícitamente todos sus requisitosEl cliente debe tener paciencia
Análisis
Diseño
Codifica-ción
Prueba
Manteni-miento
Ingeniería de sistemas/información
Enero 2006 11
Modelos de desarollo
Modelo de construcción de prototipos
El cliente ve lo que parece ser una versión de trabajo del softwareEl desarrollador hace compromisos de implementación para hacer que el prototipo funcione
Enero 2006 12
Modelos de desarrollo
Modelo DRASe logra a través de la construcción basada en componentesPara proyectos grandes requiere de RRHH suficientesClientes y desarrolladores comprometidos con un activ. RápidasProyectos que se pueden modularizarNo adecuado si los riesgos técn. Son altos (TI nueva, interop.)
Modelado de Gestión
Modelado de datos
Modelado de procesos
Generación de
aplicaciones
Pruebasy
volumen
De 60 a 90 días
Modelado de Gestión
Modelado de datos
Modelado de procesos
Generación de
aplicaciones
Pruebasy
volumen
Modelado de Gestión
Modelado de datos
Modelado de procesos
Generación de
aplicaciones
Pruebasy
volumen
Equipo No.1
Equipo No.2Equipo No.3
Enero 2006 13
Modelos de desarrolloModelo incremental
Modelo lineal secuencial (repetidos) + prototipo. Producto operacional con cada incrementoEl primer incremento es a menudo un producto esencial. Plan para el incremento siguiente
Incremento1
Análisis Diseño Código Prueba Entrega de 1 er. incremento
Análisis Diseño Código Prueba Entrega de 2do. incremento
Incremento2
Análisis Diseño Código Prueba Entrega de 3 er. incremento
Incremento3
Enero 2006 14
Modelos de desarrollo
Modelo en espiralVersiones incrementalesPrimeras versiones: modelo en papel o prototipoRegiones de tareas: conjunto de tareasPrototipo en cualquier momento
Enero 2006 15
Modelos de desarrolloModelo en espiral winwin
Identificación del sistema o subsistema clave de los directivosDeterminación de las condiciones de victoria de los directivosNegociación de las condiciones: victoria-victoriaPuntos de fijación: Objetivos del ciclo de vidaArquit. del ciclo de vidaCapacidad operativa inicial
Enero 2006 16
Modelos de desarrolloModelo de desarrollo concurrente
Una serie de actividades técnicas importantes, tareas y estados asociados a ellasAplicable a todo tipo de proyectoEstado actual
Enero 2006 17
Modelos de desarrolloDesarrollo basado en componentes
Evolutivo por naturaleza, iterativoA partir de componentes preparados de softwareReutilización-70% tiempo, -84% costos, 26.2 productividad
Enero 2006 18
Modelos de desarrollo
Modelo de métodos formalesUn conjunto de actividades que conducen a la especificación matemática del software de computadoraNotación rigurosa y matemáticaClaridad, completitud y consistenciaCostoso en tiempo y dineroPocos desarrolladores preparadosDifícil comunicaciónConjuntos, sucesiones, operadores lógicos...
Enero 2006 19
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 5 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
¿Qué criterio utilizaría para la selección del proceso de desarrollo adecuado?
2. A nivel grupal, COMPARTA lo que escribió en el paso anterior.
Duración 10 minutos
Enero 2006 20
Dimensiones del desarrollo de SICuando la entidad que se va a construir es software, nuestro modelo debe ser capaz de modelar la información que transforma el software, las funciones (y sub-funciones) que permiten que ocurran las transformaciones y el comportamiento del sistema cuando ocurren estas transformaciones
Comportamiento
Datos
Funciones
¿Cuándo?¿Cuándo?
¿Cómo?¿Cómo?
¿Qué?¿Qué?
Enero 2006 21
El Modelado de Sistemas
Al desarrollar un sistema es necesario saber qué hace el sistema, cómo debe hacerlo o cómo será utilizado (automatizado, manual, en línea, etc.) y cómo deberá ser construido cada uno de sus componentes para utilizar ventajosamente el hardware y el software.
Un Modelo es una representación de la realidad. Representa una realidad compleja en términos simples, así como las características esenciales del sistema y ayuda a plantear interrogantes cuyas respuestas orientarán al diseñador y al constructor de sistemas.
Enero 2006 22
¿Por qué los modelos?. En los proyectos de ingeniería es común desarrollar modelos antes de dar inicio a la construcción, ya que ello brinda múltiples ventajas:
el modelo permite discutir con el cliente las necesidades a ser cubiertas,sirve de base para definir la apariencia y el diseño del producto final,permite representar y evaluar conceptos,sirve como especificación para el constructor y,una vez finalizada la construcción, servirá de criterio de aceptación del producto, pues éste no será aceptado a menos que se haya construido de acuerdo con las especificaciones que el modelo representa.
El Modelado de Sistemas
Enero 2006 23
Desarrollo bajo el enfoque estructurado
Breve historia:
Es un método de modelado clásico.
Aparece a finales de los 60’s y principios de los 70’s. Aparece primero el diseño (Yourdon) y luego el análisis estructurado (De Marco). Sólo posteriormente se introdujo una notación útil para sistemas de tiempo real (Ward y Mellor).
En la actualidad, se está intentando desarrollar una notación consistente y se están publicando tratamientos modernos que permitan acomodar el uso de herramientas CASE.
Enero 2006 24
Desarrollo bajo el enfoque estructurado
Todos los sistemas basados en computadora pueden modelarse como una transformación empleando la arquitectura Entrada (E) – Proceso (P) – Salida (S).
Mediante la representación de E-P-S, tratamiento de la interfaz de usuario, y la auto-comprobación, un ingeniero de sistemas puede crear un modelo de componentes del sistema que establezca el fundamento para el análisis de requisitos posteriores y etapas de diseño en cada una de las disciplinas de ingeniería.
Enero 2006 25
Dimensiones de un sistema bajo el enfoque estructurado
Comportamiento
Datos
Funciones
Diagrama deTransiciónde Estados
DFD
Diagrama E/R
Diccionario de Datos
Enero 2006 26
Dimensiones de un sistema bajo el enfoque estructurado
Modelos funcionales: se concentra en funciones específicas del problema. Va de un modelo sencillo de contexto a más y más detalles funcionales, a través de iteraciones. De lo general a lo particular.Modelos de comportamiento: muestran los estímulos y las respuestas. Parten de listas de eventosModelos de Datos: muestra los objetos de datos queentran y salen del sistemas, y los atributos de esos objetosA menudo los problemas son demasiado grandes o complejos para entenderlos globalmente. Por ese motivo tenemos que hacer una partición (división) de estos problemas en partes que puedan entenderse fácilmente y establecer las interacciones entre las partes de manera que pueda conseguirse la función global
Enero 2006 27
Elementos del Análisis estructurado
El modelado de Análisis estructurado debe lograr tres objetivos primarios:
Describir lo que requiere el clienteEstablecer una base para el diseño de softwareDefinir el conjunto de requisitos que se puedan validar una vez que se construya el software
Diccionariode Datos
Diagra
ma ER Diagrama FD
Diagrama TE
Especificación de procesos
Especificación de control
Desc.
de ob
jetos
de da
tos
Enero 2006 28
Modelado de DatosObjetos de datos Atributos Relaciones
NombreDirecciónEdadLicencia de conducirNúmero
FabricanteModeloNúmero de bastidorTipo de carroceríaColor
posee
Enero 2006 29
Modelado de Datos
Libro Librería
PideMuestraAlmacenaVendeDevuelve
Fabricante
Distribuidor
Coche
Transportista
autoriza
Contrata
almacena
transporta
construye
I<
I<
o< >o
I<
I<
>o
IIII
Enero 2006 30
Modelado funcional y Flujo de información
Obtener elformato de
la carta
Extraer datosde la orden
Componerorden
Obtenerdirección
Formatosde cartas
Solicitudesautorizadas
Direcciones
Cliente
Formato
Formatode carta
Ordencompleta
Dirección
Cantidadsolicitada
Destinatario
Tipo decarta
Dirección
Orden desolicitud
de compra
Enero 2006 31
Modelado funcional y Flujo de informaciónDiagrama de Contexto
SE1 E2
E3
3
3.3
1 2
4
3.1 3.2
3.4
Nivel 1
Nivel 2 para P3
Enero 2006 32
Modelado del Comportamiento
E1
E2
E3
E4
E5
Leyendo órdenes
Leyendo órdenes
Realizandocopias
Realizandocopias
Recargandopapel
Recargandopapel
Llena y comienzoInvocar gestión de copiado
InactivaInvocar leer_op_ent
LlenaInvocar leer_op_ent
Copias hechasInvocar leer_op_ent
VacíaInvocar recarga papel
Enero 2006 33
Diccionario de datos
NOTACIÓN:= Esta compuesto de+ y() Optativo (puede estar presente o ausente){} Iteración[ ] Seleccionar una de varias alternativas** Comentario@ identificador (campo clave) para un almacén! Separa opciones alternativas en la construcción
Enero 2006 34
Diccionario de datos
Ejemplo 1:nombre = titulo de cortesía+nombre+(segundo nombre)+apellidotitulo de cortesía = [Sr!Srita!Sra!dr!Prof]nombre = {carácter legal}apellido = {carácter legal}carácter legal = [A-Z!a-z!0-9!’!-! !]
Ejemplo 2:Detalles de artículos = número de artículo + descripción del artículo + costo del
artículo +número de artículosMonto de la factura = {Número de artículo} + costo de envío + (impuesto de
ventas)Datos de estudiante = nombre + dirección + ciudad + estado + código postal +
número telefónico + [matricula! número de seguro social] + {clave del curso nombre del curso + créditos + departamento + horario + día + profesor} + periodo lectivo + año + asesor
nombre = nombre + (apellido paterno) + apellido materno
Enero 2006 35
Especificación de proceso
LENGUAJE ESTRUCTURADO:Verbos orientados a la acción:
Conseguir (Aceptar/Leer)Poner (Mostrar/Describir)Encontrar (Buscar/Localizar)Sumar, restar, multiplicar, dividir, calcular, borrar, validar, mover, reemplazar, fijar, ordenar.
Combinación de frases programación estructurada
Enero 2006 36
Especificación de proceso
Ejemplo:SI condición1
frase 1SI condición2
frase 2frase 3
SINOfrase 4frase 5
FIN-SIfrase 6
SINOfrase 7SI condición3
frase 8FIN-SIfrase 9
FIN-SI
Enero 2006 37
Especificación de control
CONDICIONES 7 8 11 12 13 141. Monto Pequeño S S N N N N2. Monto Mediano N N S S N N3. Monto Grande N N N N S S4. Cliente Frecuente S N S N S N
ACCIONES 1. Descuento 0%
X
2. Descuento 5% X X 3. Descuento 10% X X X
Enero 2006 38
Conversión del análisis al diseño estructurado
Diccionario de Datos
Diagra
ma ER Diagrama FD
Diagrama TE
Especificación de procesos
Especificación de control
Desc.
de ob
jetos
de da
tos
DiseñoProcedi-mental
Diseño de interfaz
Diseño de interfaz
Diseño ArquitectónicoDiseño Arquitectónico
Diseño de DatosDiseño de Datos
Enero 2006 39
Actividad Práctica
PIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 5 minutos, PIENSEy ESCRIBA la respuesta de lo siguiente:
¿Cuáles son algunas ventajas y desventajas del paradigma estructurado?
2. A nivel grupal y en máximo 10 minutos, COMPARTA lo que escribió en el paso anterior.
Duración 15 minutos
Enero 2006 40
Paradigma de la Orientación a ObjetosBreve Historia:
La Orientación a Objetos (O.O.) surge en Noruega en un lenguaje llamado Simula 67, en el centro de cálculo noruego. Introdujo por primera vez los conceptos de clases, co-rutinas y subclases (conceptos muy similares a los lenguajes Orientados a Objetos de hoy en día). Científicos del centro de investigación en Palo Alto Xerox (Xerox park) inventaron el lenguaje Small talk. Fue el primer lenguaje Orientado a Objetos puro, es decir, únicamente utiliza clases y objetos .D. Parnas propuso la disciplina de ocultar la información. Su idea era encapsular cada una de las variables globales de la aplicación en un solo módulo junto con sus operaciones asociadas, sólo mediante las cuales se podía tener acceso a esas variables. AT&T Labs., amplió el lenguaje C para crear C++ que soporta la programación Orientada a Objetos.
1967
1970
1980
Enero 2006 41
Paradigma de la Orientación a ObjetosSe desarrollaron otros lenguajes Orientados a Objetos como Objective C, Common Lisp Object System (CIOS), object Pascal, Ada y otros. Posteriores mejoras en herramientas y lanzamientos comerciales de C++ por distintos fabricantes, justificaron la mayor atención hacia la programación Orientada a Objetos en la comunidad de desarrollo de software. El desarrollo técnico del hardware y su disminución del costo fue el detonante final. Con más computadoras al alcance de más personas más programadores, más problemas y más algoritmos surgieron. Se consolida la Orientación a Objetos como una de las mejores maneras para resolver problemas. Aumenta la necesidad de generar prototipos más rápidamente (concepto RAD Rapid Aplication Developments). Sin esperar a que los requerimientos iniciales estén totalmente precisos.
1980
Enero 2006 42
Paradigma de la Orientación a ObjetosSurge JAVA (extensión de C++). Su filosofía es aprovechar el software existente. Facilitar la adaptación del mismo a otros usos diferentes a los originales sin necesidad de modificar el código ya existente. Se desarrollan herramientas ‘CASE’ orientadas a objetos (como el diseño asistido por computadora). Del 98 a la fecha se desarrolla la arquitectura de objetos distribuidos RMI, Corba, COM, DCOM.
1996
1997
1998
Enero 2006 43
Paradigma de la Orientación a ObjetosEs una “nueva” manera de ver y expresar el mundo, de pensar acerca de los problemas para encontrar una representación adecuada a nivel de software.
El software es organizado como una colección de unidades atómicas (los OBJETOS) constituidas por datos y funciones, que interactúan entre sí.
Los CONCEPTOS inherentes al dominio de la aplicación son identificados, organizados y comprendidos antes de que los detalles sobre las estructuras de datos y las funciones puedan ser considerados efectivamente.
Es un proceso conceptual INDEPENDIENTE del lenguaje de programación hasta que se encuentra en sus etapas finales.
Consiste en la construcción y paulatino refinamiento del MODELO DEL DOMINIO DE LA APLICACIÓN para, finalmente, agregarle los detalles de implementación.
Enero 2006 44
Paradigma de la Orientación a Objeto
Los SI son organizados como una colección de unidades atómicas (los objetos) constituidas por datos y funciones, que interactúan entre sí.
Casa
Persona
Carro
Árbol
vive en
tiene u
n
Enero 2006 45
Potenciales Beneficios de la Tecnología OOPromueve la reusabilidad.Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios).Riqueza semántica.Disminuye la brecha semántica entre la visión interna y la visión externa del sistema.Facilita la construcción de prototipos.
Enero 2006 46
Algunos Métodos OODiseño Basado en Responsabilidades (Wirfs-Brock y Otros - 1990)Análisis y Diseño Orientado a Objeto (Coad y Yourdon - 1991)Diseño Orientado a Objeto (Grady Booch - 1991)Técnica de Modelado de Objetos: OMT (Rumbaugh - 1991)Ingeniería de Software Orientada a Objeto: OOSE (Jacobson - 1992)Fusión (Coleman - 1994)Lenguaje de Modelación Unificado: UML (RationalCorporation - 1996)
Enero 2006 47
El modelo de proceso OO
Identificar clases
candidatas
BuscarClases enBiblioteca
ExtraerNuevasClases
Si existen
DesarrollarLas clases
Si no existen
Añadir las Nuevas clasesA la Biblioteca
Construir n-ésimaIteración
del sistema
Análisis deRiesgo
Planificación
ComunicaciónCon el cliente
EvaluaciónDel cliente
Ingeniería,Construcción yTerminación
Enero 2006 48
persona
María Juan Pedro : Objetos
Encapsulación AtributosMétodos
•Estado•Comportamiento•Identidad
Propiedades :1. Relación de agregación
hijohombre mujer
familia
Conceptos OO …
instancia de
Persona
: Clase
Enero 2006 49
2. Relación de Uso Impresora OperadorEs activada por
3. Asociación Factura Item1 n
4. Herencia Persona
Profesor Estudiante
ReservarSala ReservarSala
Superclase(abstracta)
Subclase(concreta)
Polimorfismo
Repasemos …
Enero 2006 50
Dimensiones de un sistema bajo el enfoque OO
Comportamiento
Datos
Funciones
Modelo Dinámico• Diagrama de Transición de Estados• Diagramas de Interacción/Traza de Eventos• Diagramas de actividad
Modelo Funcional• Caso de UsoModelo de Objetos
• Modelo de Análisis• Modelo de Diseño
Modelo CRC
Enero 2006 51
Análisis y Diseño Orientado a Objeto
ConstruirModelos
ConstruirModelos
Detalles de Implementación
Entrevistas a UsuariosConocimiento del Dominio
Experiencia
Especificación deRequerimientos
Análisis
Diseño
ModeloFuncional
ModeloDinámico
ModeloObjeto
GenerarRequerimientos
GenerarRequerimientos
Enero 2006 52
Componentes genéricos del AOOVista estática de clases semánticas, se imponen los requisitos y se extraen las clases como parte del modelo de análisisVista estática de los atributos, toda clase se describe explícitamenteVista estática de las relaciones, los objetos están conectados unos a otros de varias formasVista dinámica de la comunicación, los objetos deben comunicarse unos con otros a través de mensajes que provocan transiciones de estadoVista dinámica del control y manejo del tiempo, se describe la naturaleza y duración de los sucesos que provocan transiciones de estado
Casos deUsoMod
elo de
Tar
jetas
CRC
Modelo de
Objetos
Modelo de Comportamiento
Atributo
s, op
erac
iones
, colaboradores
Enero 2006 53
Modelo Funcional
Enero 2006 54
Modelo Dinámico
CURSO NORMAL
1. El MC abre la pantalla de Pago de Idease introduce en el sistema la fecha paracalcular el pago por ideas.
2. El MC presiona el Botón Imprimir
El sistema de información:
2.2. Calcu la pago por par t ic ipante,correspondiente a las ideas que para lafecha dada, no han sido pagadas y queesten aprobadas o con más de 30 diasimplantadas.
2.3. Emite los comprobantes de pago(formato F2, original y copia).
3. Cuando todos los comprobantes depago correspondientes a la fecha han sidoemitidos, se imprime la lista de pago(formato F3, original y copia)
4. Se entregan el listado (F3) original y loscomprobantes (F2) al Departamento deAdministración Planta para que esteefectue el pago.
5. Se publica en cartelera la copia de lal i s t a d e p a g o p a r a i n f o r m a r a l o strabajadores. El caso de uso termina.
CURSO ALTERNO
S i n o h a y i d e a s q u e c u m p l a n l a scondiciones, se muestra por pantalla unmensaje indicándolo.
clicSobreBoton()
CalcularPago()
ImprimirListaPago()
: Participante
Abre
: Pantalla dePago
: BotónImprimir
Miembro delComité
ImprimirComprobantePago()
BuscarMontoEstatus()
BuscarNoPagada()
: Mensajede Error
Muestra
: Mensajede Error
El MC entregaF 3 y F 2 a lDpto Admon.
El MC publicacopia de F3
Enero 2006 55
Modelo Dinámico
p:ParticipantePagoPendiente =
NO
mc:Miembro del Comité
1. Calcular Pago
3. Cambiar
e:Estatus
p:ParticipantePagoPendiente =
SI
1.1. Buscar Monto
2. ImprimirComprobante
Revisada
Implantada
Directa
Aprobada
Implantada
Indirecta
No Procede
VerificarIdeasSimilares
VerificarIdeasSimilares
VerificarFuncionamiento
VerificarFuncionamiento
EjecuciónTrabajos
Enero 2006 56
Modelo Dinámico
Click en "Agregar"
Personal Académico - Administrativo
Validar Usuario
Reintento de ingreso al sistema
Introducir información
Click en "Agregar"
Verificar campos en blancos
[ * Por cada campo de
información ]
Se muestra mensaje de error
[ Se encontraron campos en
blanco ]
Materia almacenada
[ No se encontraron campos en blanco ]
[ Datos introducidos ]
[ Usuario no valido ]
[ Usuario valido ]
Enero 2006 57
Modelo Clases-Responsabilidades-Colaboraciones
Nombre de la clase:Tipo de clase: (dispositivo, propiedad, rol, evento..)Características de la clase:Responsabilidades: Colaboradores:
Nombre de la clase:Tipo de clase: (dispositivo, propiedad, rol, evento..)Características de la clase:Responsabilidades: Colaboradores:
Enero 2006 58
Modelo de Objetos
Area Palabra C laveM ejora
Participante
Idea
D escriptores
Trabajador
M iembro de C omité
Estatus
Incentivo
Enero 2006 59
Casos deUsoMod
elo de
Tar
jetas
CRC
Modelo de
Objetos
Modelo de Comportamiento
Atributo
s, op
erac
iones
, colaboradoresConversión del análisis al diseño OO
Diseño de responsa-bilidades
Diseño de mensajesDiseño de mensajes
Diseño de clasesDiseño de clases
Diseño de subsistemasDiseño de subsistemas
Enero 2006 60
Ventajas de la Orientación a ObjetosReutilizaciónEl diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivelConfiabilidadUn diseño más rápidoIntegridadMantenimiento más sencillo. Modifica-ciones locales.Ciclo vital dinámico.Modelado más realista.Modelos empresariales inteligentes.Independencia del diseño.Computación Cliente-Servidor.Computación paralela.Eficacia de la máquina.Bibliotecas de clases para las empresas.
EstabilidadSe construyen clases cada vez más complejas.Nuevos mercados para el software.Diseño de mayor calidad.Programación mas sencilla.Especificaciones declarativas y diseño.Interacción.Computación de distribución masiva.Mayor nivel de automatización de las bases de datos.Migración.Bibliotecas de clases para las industrias.La comprensión del sistema es más fácil porque la semántica entre el sistema y la realidad son similares.
Enero 2006 61
La Calidad en los Sistemas OOReusabilidadExtensibilidad-MantenibilidadCompatibilidad-InteroperabilidadVerificabilidadIntegridadEntendibilidadFacilidad de usoPortabilidadCorrectitudEficienciaConfiabilidadRobustez
Enero 2006 62
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 5 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
¿Cómo pueden combinarse métodos estructurados y OO?
2. A nivel grupal, COMPARTA lo que escribió en el paso anterior.
Duración 15 minutos
Enero 2006 63
Métodos Tradicionales Vs. Métodos OO
Modelo de AnálisisEstructurado en el
Espacio del Problema
Modelo de DiseñoEstructurado en elEspacio Solución
Implementación enun Lenguaje deProgramación
Modelo de Objetosen el
Espacio del Problema
Modelo de Objetosen el
Espacio Solución
Implementación enun Lenguaje de
Programación OO
ANÁLISIS
DISEÑO
IMPLEMENTACIÓN
Métodos basados enDescomposición Funcional
Métodos basados enOrientación a Objeto
Enero 2006 64
Ingeniería del Software Basada en Componentes
Breve Historia:En el contexto de la Ingeniería del Software, la reutilización se puede considerar una idea nueva y antigua.Los programadores han reutilizado ideas, abstracciones y procesos desde el principio de la era de los computadores, pero el primer enfoque de reutilización era muy concreto.Hoy en día, los sistemas complejos y de alta calidad basados en computadora se deben construir en períodos de tiempo muy corto.Esto se mitiga con un enfoque de reutilización más organizado.
Enero 2006 65
Ingeniería del Software Basada en Componentes
La Ingeniería del Software Basada en Componentes (ISBC) es un proceso que se centra en el diseño y construcción de sistemas basados en computadora que utilizan “componentes” de software reutilizables
Enero 2006 66
Ingeniería del Software Basada en Componentes
Componente:Unidad de composición con interfaces especificadas contractualmente y dependencias contextuales explícitas. Donde, según Szyperski (2003) :
Una interfaz es un conjunto de operaciones con nombre que pueden ser invocadas por los clientes.Las dependencias contextuales son especificaciones de lo que el entorno en el que se usa el componente deberá proporcionar, de modo que los componentespuedan funcionar.
Unidad funcional de un sistema; puede ir desde una función de bajo nivel hasta una de alto nivel; puede ser atómica o compuesta; es reutilizable o compartible. El modelo de componentes difiere del de objetos; éste no contiene todos los elementos necesarios para describir los componentes y su ensamble (Bronsard, 1997).
Enero 2006 67
ComponenteEs una parte de una arquitectura de software:
Claramente identificable.Independiente a la aplicación en la que se utiliza.Independiente de otros componentes (partes), lo cual implica un bajo acoplamiento.Describe y realiza funciones específicas y claras dentro del contexto de la arquitectura.Puede ser modificado a tiempo de diseño.Posee una documentación clara que permite conocer sus características, atributos y comportamiento.Reutilizable.Su interoperabilidad con otros componentes (partes) no reduce el nivel de eficiencia de la arquitectura.
Enero 2006 68
Diferencias entre objetos y componentesObjetos Componentes
Un objeto es creado desde cero para desarrollar un nuevo sistema.
El componente es reutilizado no solo para desarrollar un nuevo sistema, sino también para construir un nuevo componente.
Es una unidad de instanciación, con una identidad única.
Es una unidad de despliegue independiente: está bien delimitado en un ambiente, y con respecto a otros componentes. Todos los elementos que lo constituyen están encapsulados. No se tiene acceso a su implementación.
Encapsula su estado y comportamiento. No presenta un estado externo. No es posible distinguir entre dos copias del mismo componente. Como consecuencia de esta característica, no deberían existir dos copias del componente en un mismo contexto de ejecución.
No es independiente de su contexto. Debe ser independiente de su contexto y de otros componentes.
Implementa entidades. Implementa servicios.
Las interfaces de los objetos presentan menos detalles
Las interfaces de los componentes presentan más detalles
Tiene un único identificador. Puede tener varios identificadores.
Las operaciones de un objeto son específicas de una clase.
Un componente trabaja con modelos y relaciones de diferentes interfaces.
El principal mecanismo de comunicación es el pase de mensajes.
Utilizan un conjunto mayor de mecanismos de comunicación.
Enero 2006 69
Elementos de un componenteEl componente objeto.
Una vez instalado en una infraestructura, el componente puede ser ejecutado una o más veces.
Public class Pedido{private int
PrecioSugerido;...public int
ObtenerNumPedido;...public void Create() {}...
}
Enero 2006 70
Modelo de proceso de soporte a la ISBCAnálisis
delDominio
Desarrollode la
Arquitecturade Software
Desarrollode
Componentesreutilizables
Modelo dedominio
Modeloestructural
Artefactos/Componentesreutilizablesde la reserva
Análisis DiseñoArquitectónico
Cualificación del componente
Adaptación del componente
Composición del componente
Ingeniería decomponentes Comprobación
Actualización de componente
Softwarede
aplicaciones
Ingeniería de dominio
Desarrollo basadoen componentes
Enero 2006 71
Dimensiones de un sistema bajo el enfoque ISBC
Comportamiento
Datos
Funciones
Modelo Dinámico• Diagramas de Interacción de componentes
Modelo estructural• Diagrama de Componentes• Infraestructura de despliegue
Enero 2006 72
Modelo estructural
Trabajador
OrganigramaEstatus
Descriptor IdeaMiembro del
Comité
Enero 2006 73
Modelo estructural
Punto de Venta
Gestión de Cuentas
Comment
Rutinas de Conexión
Comment
Interfaz de Terminal
Comment
Servidor Central
Acceso a BD
Comment
Control y Análisis
Comment
Rutinas de Conexión
Comment
Rutinas de Conexión
Comment
Interfaz de Terminal
Comment
Terminal de Consulta
Enero 2006 74
Características que presenta un componente de software
IdentificableAuto-contenidoRastreableReemplazableEs accesible sólo a través de su interfazSus servicios son inmutablesEstá documentadoEs mantenidoEs genéricoLa reutilización de sus servicios no está restringida por la implementación físicaEstá encapsuladoSu implementación física está ocultaPuede ser reutilizado dinámicamenteEstá certificado
Enero 2006 75
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 5 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
¿Qué aspectos de producto le parece que hacen diferente a una aplicación Web?
2. A nivel grupal, COMPARTA lo que escribió en el paso anterior.
Duración 15 minutos
Enero 2006 76
Atributos de una aplicación Web
Intensivas de redControladas por el contenidoEvolución continuaInmediatezSeguridadEstética
Enero 2006 77
Ingeniería Web (IWeb)
Gracias al desarrollo de nuevas herramientas y tecnologías, las Aplicaciones Web son cada vez más populares. La facilidad de su desarrollo provoca, a veces, la ausencia de un análisis y diseño correctos; sin embargo, están consiguiendo reemplazar a las aplicaciones software tradicionales.
Enero 2006 78
Ingeniería WebUna aplicación Web no es más que una especialización de un proceso cliente/servidor, por lo que se puede aprovechar el modelado de dichas aplicaciones. En particular, los casos de uso son una herramienta fundamental en la captura de requisitos.
sitio Web dinámicoo
Aplicación Web
sitio Web tradicional
Enero 2006 79
Modelo de Ingeniería Web
Planificación
Formulación
Evaluacióndel cliente
Análisis
Ingeniería
Generaciónde páginasy pruebas
Diseño delcontenido
Producción
Diseño arquitectónico
Diseño deNavegación
Diseño de lainterfaz
Enero 2006 80
Dimensiones de un sistema bajo el enfoque IWeb
Comportamiento
Datos
Funciones
Modelo Dinámico• Diagramas de Interacción
Modelo de contenido• Diagrama de Clases
• Casos de Uso
Enero 2006 81
Análisis de sistemas basados en WebAnálisis del contenido: identificación del espectro completo que se va a proporcionarAnálisis de la interacción: descripción detallada entre el usuario y la aplicación:Análisis funcional: descripción detallada de todas las operaciones y funciones.Análisis de la configuración: descripción detallada del entorno y la infraestructura donde reside la aplicación.
Casos deUso
Config
uració
n Modelo de
Contenido
Modelo Dinámico
Formulación
Enero 2006 82
Estereotipos de Clase para WebServer Page
Client Page
Form
Frameset
Target
JavaScript Object
nombre
Enero 2006 83
Estereotipos de AsociaciónLinkDescripción:
Asociación o vínculo entre una «Client Page» y otra «Client Page», o una «Server Page»
SubmitDescripción:
Asociación entre «Form» y «Server Page»Indica qué páginas pueden procesar el «Form» y los Forms conocidos por una «Server Page»Los forms envían información al servidor web a través de «Server Page»'s para su procesamiento
Enero 2006 84
Estereotipos de Asociación
BuildsDescripción:
Asociación entre «Server Page» y «Client Page»Identifica la «Server Page» responsable de la creación de una «Client Page»
RedirectDescripción:
Asociación unidireccional entre páginas webDesde una «Server Page» a otra página:
El procesamiento de la solicitud de página puede continuar con la página destinoLa página destino puede o no participar en la construcción de una «Client Page»
Enero 2006 85
Asociaciones válidas entre estereotipos:To:
From:Client Page Server Page Frameset Target Form
Client Page
LinkTargeted LinkRedirect
LinkTargeted LinkRedirect
LinkTargeted LinkRedirect
Dependency Aggregation
Server Page
BuildRedirect
RedirectRedirectBuild
Frameset Frame ContentFrameContent
Frame Content
Target
Form Aggregated By Submit
Reglas de Modelos WAE
Enero 2006 86
AS P C o n te n id o A S P A d mF o rm A d m
< < S u b m it> >
f ( ){ }
J S P A d m
S u bS e cc i o n
f ( ){ }
J S V a lid a rL o g inH om e
< < L in k > >
M e n u
< < L in k > >
F o rm L o g in
In d e x
< < L in k > >
A S P L o g in
< < S u b m it> >
< < R e d ire c t> >
C o n tro l
< < R e d ire c t> >< < Q u e ry > >
(fro m E d i t)
< < S u b m it> >
f ( ){ }
J S D e ta lle A d m
< < Li n k> >f ( ){ }
J S F o rm a to C o n te n ido
E d it
< < Li nk > >
Usuario
Modelo de Contenido
Enero 2006 87
Conversión del análisis al diseño Web
Casos deUso
Config
uració
n Modelo de
Contenido
Modelo Dinámico
Formulación
Diseño Arquitect-
nico
Diseño de NavegaciónDiseño de
Navegación
Diseño de InterfazDiseño de Interfaz
Enero 2006 88
Atributos de calidad de una aplicación Web
Calidad de una aplicaciónWeb
Usabilidad
Fiabilidad
Mantenibilidad
Funcionalidad
Eficiencia
Capacidad de comprensión delSitio globalServicios de ayuda y realimentación en líneaCapacidades estéticas y de interfazServicios especiales
Capacidad de recuperación y de búsquedaServicios de búsqueda y navegaciónServicios relacionados con el dominio de aplicación
Proceso correcto de enlaceRecuperación de erroresValidación y recuperación de la entrada del usuario
Rendimiento del tiempo de respuestaVelocidad de generación de páginasVelocidad de generación de gráficos
Facilidad de correcciónAdaptabilidadExtensibilidad
Enero 2006 89
Actividad PrácticaPIENSE – ESCRIBA – COMPARTA
1. De manera individual y en 15 minutos, PIENSE y ESCRIBA la respuesta de lo siguiente:
¿Cómo puede contribuir cada uno de los elementos de análisis y diseño estudiados (formulación,
contenido, interacción y configuración) al logro de los atributos de calidad?
2. A nivel grupal y en máximo 15 minutos, COMPARTAlo que escribió en el paso anterior.
Duración 30 minutos
Enero 2006 90