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


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



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


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


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


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


Definicóndel

problema

Definicóndel

problema

Integración de solucionesIntegración de soluciones

Desarrollotécnico

Desarrollotécnico


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


Desarrollotécnico

DesarrollotécnicoEdo.

actual

Edo. actual

Definicóndel

problema

Definicóndel

problema



Desarrollotécnico

Desarrollotécnico

Edo. actual

Edo. actual

Definicóndel

problema

Definicóndel

problema



Desarrollotécnico


actual

Edo. actual

Definicóndel

problema

Definicóndel

problema



Desarrollotécnico

Desarrollotécnico

Edo. actual

Edo. actual

Definicóndel

problema

Definicóndel

problema



Desarrollotécnico


actual

Edo. actual

Definicóndel

problema

Definicóndel

problema



Desarrollotécnico

Desarrollotécnico

Enero 2006 10


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


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 datos


Generación de

aplicaciones

Pruebasy

volumen


Modelado de datos


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


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


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


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?



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


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


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.


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



¿Cómo pueden combinarse métodos estructurados y OO?



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


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


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


Comment


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



¿Qué aspectos de producto le parece que hacen diferente a una aplicación Web?



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



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



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


Enero 2006 90

clase 2 2006 ing del sw procesos y paradigmas · puntos de sqa conjunto de tareas actividades del...

Documents