UML

1Necesidad modeladoDiagramas de claseDiagramas de secuenciaCasos de usoUML2Necesidad modeladoUse casesDiagramas de claseDiagramas de secuenciaUML3Objetivos al desarrollar softwareSatisfacer las necesidades de los usuarios.Entregar el software en tiempo y con un costo predecible.Comprender mejor el sistema que se est construyendo.

4Acciones para alcanzar los objetivosRealizar una buena elicitacin de requerimientos.

Desarrollar un modelo del sistema.5Que es un modelo?Simplificacin de la realidad.Incluir los elementos que son importantes y omitir los elementos que no son relevantes para ese nivel de abstraccin.6Diferentes modelosModelos estructuralesModelos de comportamientoQue es un modelo?7Construccin de una casa para fido

Puede hacerlo una sola personaRequiere:Modelado mnimoProceso simpleHerramientas simples7Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).8Construccin de una casa

Construida eficientemente y en un tiempo razonable por un equipoRequiere:ModeladoProceso bien definidoHerramientas ms sofisticadas8Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).

9Claves en Desarrollo de SIHerramientasProcesoNotacin9Figura Triangle for Success adaptada desde Visual Modeling with Rational Rose and UML de Terry Quatrani

10Sistema ComputacionalProceso de Negocios

OrdenItemenvoEl modelado captura laspartes esenciales del sistema Abstraccin - Modelado Visual (MV) 1011Mltiples SistemasMV promueve la reutilizacin

Componentes Reutilizados1112

Interfaz de Usuario(Visual Basic,Java, ..)Lgica del Negocio(C++, Java, ..)Servidor de BDs(C++ & SQL, ..)Modelar el sistema independientemente del lenguaje de implementacinMV para definir la Arquitectura del SW1213Qu es lo que va a construir?

Cmo lo va a construir?

Qu tecnologa usar?

Cmo lo documentar?

Etapas en la construccin de un proceso de software14Etapas en la construccin de un proceso de softwareAnlisisDiseoRefinamiento del diseoImplementacinDocumentacinRequerimientos FuncionalesLos requerimientos/requisitos de un sistema describen los servicios que ha de ofrecer el sistema y las restricciones asociadas a su funcionamiento.Requerimientos:Propiedades o restricciones determinadas de forma precisa que deben satisfacerse.15Requerimientos funcionales:Expresan la naturaleza del funcionamiento del sistema (cmo interacciona el sistema con su entorno y cules van a ser su estado y funcionamiento).

Importante: A veces, tambin es conveniente indicar lo que no har el sistema.16Requerimientos no funcionales:Restricciones sobre el espacio de posibles soluciones.

Rendimiento del sistema: Fiabilidad, tiempo de respuesta, disponibilidadInterfaces: Dispositivos de E/S, usabilidad, interoperabilidadProceso de desarrollo: Estndares, herramientas, plazo de entrega17Requerimientos Funcionales y Requerimientos No FuncionalesLos requisitos funcionales definenqu debe hacer un sistema.

Los requisitos no funcionales definen cmo debe ser el sistema.18Requerimientos No FuncionalesA los requisitos no funcionales se les suele llamar coloquialmente cualidades del sistema [-ilities en ingls] y pueden dividirse en dos categoras: Cualidades de ejecucin, como la seguridad o la usabilidad, observables en tiempo de ejecucin.Cualidades de evolucin,como la testabilidad, mantenibilidad, extensibilidad o escalabilidad, determinadas por la estructura esttica del software.19Como especificar los RequerimientosLos requerimientosse suelen especificar en lenguaje natural,se expresan de forma individual(p.ej. esquemticamente),se organizan de forma jerrquica(a distintos niveles de detalle),a menudo, se numeran (para facilitar su gestin),2020Los requerimientos han de serclaros y concretos(evitando imprecisiones y ambigedades) p.ej. Uso de puntos suspensivos, etctera concisos(sin rodeos ni figuras retricas), completos y consistentes,21Los requerimientos han de indicarlo que se espera que haga el sistema (qu?), su justificacin(por qu ha de ser as? quin lo propuso?) y, en su caso, los criterios de aceptacin que sean aplicables (cmo se verifica su cumplimiento?).22Los requerimientos funcionales

deben estar redactados de tal forma que sean comprensibles para usuarios sin conocimientos tcnicos avanzados (de Informtica, se entiende),deben especificar el comportamiento externo del sistema y evitar, en la medida de lo posible, establecercaractersticas de su diseo,deben priorizarse (al menos, se ha de distinguir entre requisitos obligatorios y requisitos deseables).23Los requerimientos no funcionaleshan de especificarse cuantitativamente, siempre que sea posible (para que se pueda verificar su cumplimiento).24Ejemplos:MALPara facilitar el uso del editor grfico, se podr activar y desactivar una rejilla que permitir alinear las figuras del diagrama. Cuando se ajuste la figura al tamao de la pantalla, se reducir el nmero de lneas de la rejilla para que no se dificulte la visualizacin del diagrama.

Por qu?Amalgama de varios requisitos.25Ejemplos:BIENEl editor permitir el uso de una rejilla de lneas horizontales y verticales que aparecern dibujadas tras el diagrama.

Justificacin: La rejilla facilita la creacin de diagramas cuidados en los que las figuras se puedan alinear con facilidad (Manual Prctico de Usabilidad, seccin 15.3).

Por qu?Preciso, conciso y justificado correctamente.26Ejemplos:MAL

El sistema ser lo ms fcil de utilizar posible.El sistema proporcionar una respuesta rpida al usuario.El sistema se recuperar automticamente tras producirse un fallo.

Por qu?Objetivos generales, vagos y abiertos a distintas interpretaciones.27Ejemplos:BIEN

Un usuario experimentado debe ser capaz de utilizar todas las funciones del sistema tras un entrenamiento de 2 horas, tras el cual no cometer ms de 3 errores diarios en media.

Cuando haya hasta 100 usuarios accediendo simultneamente al sistema, su tiempo de respuesta no ser en ningn momento superior a 2 segundos.28Ejemplos:BIEN

Ante un fallo en el software del sistema, no se tardar ms de 5 minutos en restaurar los datos del sistema (en un estado vlido) y volver a poner en marcha el sistema.

Por qu?Requisitos verificables.29Qu problemas se pueden Presentar: En la elaboracin de Requerimientos?La existencia de un requerimiento ha de estar debidamente justificada (debemos saber por qu es un requisito del sistema).

Un requerimiento es, a veces, difcil de verificar (especialmente, si es un requisito no funcional). Adems, si somos incapaces de especificarlo, cmo sabemos que realmente es un requisito?30EJEMPLO: REQUERIMIENTOS FUNCIONALESMatriculacin

La matrcula ser realizada de forma interactiva. Se le preguntar al alumno cul es el plan de estudios en que desea matricularse (pueden ser varios).

Se podr generar una copia impresa de la matrcula (sin valor oficial) en el ordenador desde donde se realice el proceso de matriculacin.

Se podr generar el impreso de pago debidamente cumplimentado.

Para la matriculacin se consultarn los datos del expediente y se realizarn las validaciones necesarias, descritas a continuacin31EJEMPLO: REQUERIMIENTOS FUNCIONALESPago de matrcula:

La aplicacin generar un impreso para que el alumno realice el pago correspondiente a la matrcula en 1 2 plazos (segn las fechas establecidas).

Si el alumno tiene matrculas de honor de cursos anteriores o disfruta de algn tipo de beca, la aplicacin deber calcular automticamente los descuentos correspondientes32Organizados jerrquicamentey desglosados en requisitos individualesEJEMPLO: REQUERIMIENTOS NO FUNCIONALESInterfaces

Hardware: El sistema se debe implementar sobre la infraestructura existente en las aulas de prcticas de la Materia de Analisis de Sistemas.Software:No existe posibilidad de adquirir licencias de software.

La aplicacin deber funcionar sobre Oracle.33Requisitos Claros, Concretos, Concisos y verificables34Nombre Requerimiento: Ingreso Usuarios ID Requerimiento: RF-001 Entradas: Usuario y Contrasea Salidas: El usuario Ingresa al sistema El usuario recibe mensaje de Error Prerrequisito: No aplica Opciones: Ingresar , Cancelar Restricciones: Los dos campos son obligatorios El usuario debe estar creado en el sistema Descripcin del proceso El usuario ingresa al sistema mediante autenticacin, usuario y contrasea, el sistema valida si los datos estn correctos, si estn errados presenta en la pantalla un mensaje de error, si son vlidos ingresa a la aplicacin y se activan las formas y opciones asignadas segn el perfil. Tabal de Requerimientos (Ficha)35UMLEs una notacin grfica para modelar.Es un lenguaje de modelado.

36UML aglutina enfoques OOUMLRumbaughJacobsonMeyerHarelWirfs-BrockFusionEmblyGamma et. al.Shlaer-MellorOdellBoochPre- and Post-conditionsState ChartsResponsabilitiesOperation descriptions, message numberingSingleton classesFrameworks, patterns, notesObject life cycles3637... Diagramas de UMLUse CaseDiagramsUse CaseDiagramsDiagramas de Casos de UsoScenarioDiagramsScenarioDiagramsDiagramas deColaboracinStateDiagramsStateDiagramsDiagramas deComponentesComponentDiagramsComponentDiagramsDiagramas deDistribucinStateDiagramsStateDiagramsDiagramas de ObjetosScenarioDiagramsScenarioDiagramsDiagramas deEstadosUse CaseDiagramsUse CaseDiagramsDiagramas deSecuenciaStateDiagramsStateDiagramsDiagramas deClasesDiagramas deActividadModeloII. Breve Tour por UMLLos diagramas expresan grficamente partes de un modelo3738... Diagramas seleccionadosDiagramas deSecuenciaDiagramas deClasesDiagramas de Casos de Uso39Modelos y DiagramasUn modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle.

3940Diagrama: una representacin grfica de una coleccin de elementos de modelado.

Modelos y Diagramas41Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters

El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos ...

... Modelos y Diagramas4142Necesidad modeladoCasos de usoDiagramas de claseDiagramas de secuenciaUML43Casos de Uso

Un caso de uso es una interaccin entre el usuario y el sistema para lograr cierto objetivo.Objetivo de los mismos.Son de tamao variable.Se debe especificar todos los cursos alternativos.44 Casos de UsoActores:

Roles de los usuarios

Otros sistemas: sistemas con los que el sistema interacta (el otro sistema necesita algo del sistema que se desarrolla)

4445EjemplosSupervisorVerificar Situacin del ClienteAdministrativoPreparar CatlogoSistema Inventario45En los D. de Casos de Uso no existe el concepto de explosin tal como se tiene en los DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un caso de uso es atmica (aunque en Rational Rose 98 a un caso de uso se le puede asociar un nuevo D. de Casos de Uso!!). En UML el concepto de paquete permite organizar de manera jerrquica un modelo, y en este caso, un paquete puede tener asociado un nuevo diagrama.46 Casos de UsoEjemplo:Actor ACaso de Uso AActor BCaso de Uso BIII. El Paradigma OO: Diagrama de Casos de Uso4647Identificacin de casos de usosEventos ante los cuales se debe reaccionarActores que intervienen Casos de Uso48Representacin de escenarios alternativos Casos de Uso49 EjemplosVenta NormalVenta en RebajasVenta en OfertasVendedorVentas4950Casos de UsoLos Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario

Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno

Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin

50Algunas similitudes y diferencias entre DFDs y D. de Casos de Uso:Un caso de uso es una funcin (servicio o transaccin) atmica ofrecida por el sistema al entorno (actores), mientras que un proceso de un DFD puede ser detallado en un DFD hijo. As, el concepto de explosin de proceso slo se aplica a los DFDs. Aunque en cierta forma con relaciones de inclusin entre casos de uso (que se explican ms adelante) puede mostrarse la factorizacin de un caso de uso, esto no llega a ser equivalente a explosin de proceso.Aunque un caso de uso y un proceso modelan una pieza de funcionalidad del sistema su especificacin es diferente. En un caso de uso interesa expresar la funcionalidad mediante la interaccin (pasos de comunicacin) actor(es) sistema. En un proceso la funcionalidad se expresa mediante la transformacin que se hace de los flujos de entrada para producir flujos de salida.Un caso de uso en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visin externa del sistema. La excepcin a lo anterior podra producirse al factorizar funcionalmente un caso de uso para establecer una relacin de inclusin (que se explica ms adelante). Un DFD, segn sea el nivel de detalle, puede mostrar descomposicin funcional interna del sistema.La diferencia entre Captura de Requisitos y Anlisis radica esencialmente en el grado de detalle que se obtiene respecto del particionamiento del problema (funcional y de datos). La Captura de Requisitos ofrece un particionamiento en el contexto del usuario y adecuado para su comprensin. El Anlisis provee un particionamiento que pueda ser utilizado como entrada para el Diseo del Sistema. As, se puede afirmar que los D. de Casos de Uso son una herramienta exclusivamente de Captura de Requisitos mientras que los DFD podran utilizarse en ambas actividades. En captura de requisitos para un DFD una entidad externa equivale a un actor, un almacn nico y global evita entrar en anlisis de datos y los procesos establecidos slo hasta el nivel de transacciones externas se corresponderan con casos de uso.Las relaciones de extensin y de generalizacin entre casos de uso no tienen correspondencias en los DFDs....51 Casos de UsoLos Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario

Un escenario es una instancia de un caso de uso

Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso

51Una caracterstica resaltada respecto de un proceso de desarrollo de software asociado a UML es su naturaleza use case driven, es decir, el proceso es dirigido por los casos de uso. Esto significa que en puntos determinado del desarrollo se valida y verifica el correspondiente modelo respecto del modelo de casos de uso. En s la especificaciones de casos de uso (con los respectivos diagramas de interaccin) constituyen una especificacin de casos de prueba para el sistema (pruebas funcionales).52Casos de Uso: RelacionesUML define tres tipos de relacin en los Diagramas de Casos de Uso:

ComunicacinActorCaso de Uso5253 Casos de Uso: RelacionesInclusin(uses) : una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino

reemplaz al denominado Caso de Uso OrigenCaso de Uso Destino

III. El Paradigma OO: Diagrama de Casos de Uso53Para la explicacin de las relaciones entre casos de uso se han identificado como caso de uso origen y caso de uso destino slo para indicar el sentido del smbolo (flecha de generalizacin).

54 Casos de Uso: RelacionesExtensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destinoCaso de Uso OrigenCaso de Uso Destino

54Las relaciones y corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interaccin de otro caso de uso. Sin embargo, la intensin es diferente; la relacin pretende evitar duplicacin de interacciones en distintos casos de uso, la relacin pretende describir una variacin del comportamiento normal de un caso de uso, sobre todo cuando dicha variacin pudiera complicar la legibilidad del caso de uso.55 Casos de Uso: RelacionesEjemplo:IdentificacinTransferencia en InternetClienteTransferencia

55Podra en este ejemplo haberse modelado el caso de uso Transferencia por Internet con una relacin de generalizacin hacia el caso de uso Transferencia?. Si la idea de extensin (vista como especializacin) forma parte esencial del concepto de generalizacin/especializacin, para qu tener dos tipos de relaciones? ... estos son algunos de lo muchos aspectos de UML que estn en discusin.56Casos de Uso: ConstruccinUn caso de uso debe ser simple, inteligible, claro y concisoGeneralmente hay pocos actores asociados a cada Caso de Uso5657Preguntas clave:cules son las tareas del actor?qu informacin crea, guarda, modifica, destruye o lee el actor?debe el actor notificar al sistema los cambios externos?debe el sistema informar al actor de los cambios internos?

Casos de Uso: Construccin58 Casos de Uso: ConstruccinLa descripcin del Caso de Uso comprende:el inicio: cundo y qu actor lo produce?el fin: cundo se produce y qu valor devuelve?la interaccin actor-caso de uso: qu mensajes intercambian ambos?5859objetivo del caso de uso: qu lleva a cabo o intenta?cronologa y origen de las interaccionesrepeticiones de comportamiento: qu operaciones son iteradas?situaciones opcionales: qu escenarios alternativos se presentan en el caso de uso?

Casos de Uso: ConstruccinEjemplo PlantillaImagen6061Necesidad modeladoCasos de usoDiagramas de claseDiagramas de secuenciaUML62ImplementacinClases: abstracciones del mundo real. Perspectiva ms usada63ClasificacinEl mundo real puede ser visto desde abstracciones diferentes (subjetividad)

Mecanismos de abstraccin:

Clasificacin / InstanciacinComposicin / DescomposicinAgrupacin / IndividualizacinEspecializacin / Generalizacin6364Clases: Notacin GrficaCada clase se representa en un rectngulo con tres compartimientos:

nombre de la claseatributos de la claseoperaciones de la clasecuentatitularsaldodepositarextraertransferir64- Un atributo es semnticamente equivalente a una composicin (composite aggreation). La sintaxis por defecto para los atributos es:

visibilidad nombre [multiplicidad] : tipo = valor-inicial {propiedades}

- tipo es una especificacin dependiente del lenguaje de implementacin- Para indicar que un atributo es constante se puede poner la propiedad frozen- Ejemplos usando multiplicidad:colores [3]: Colorpuntos [2..*]: Puntonombre [0..1]: String

- Un atributo de clase (del mbito de clase y no de objeto) se indica subrayndolo

65Clases: Notacin GrficaOtros ejemplos:

listaprimeroultimoaadirquitarcardinalidadconjuntointersecarunircardinalidad65- Una operacin es un servicio que una instancia de la clase puede realizar. La sintaxis por defecto es:

visibilidad nombre (parmetros) : tipo-devuelto {propiedades}

Una operacin que no modifica el estado del objeto es especificada con la propiedad query. La propiedad abstract se usa para indicar que el mtodo de la operacin es implementado en una subclase. Una operacin de clase (del mbito de clase y no de objeto) puede indicarse subrayando dicha operacin - Los parmetros se especifican usando la siguiente sintaxis:

io nombre : tipo = valor_por_defecto

donde io puede ser in, out o inout

66Diagrama de ClasesEl Diagrama de Clases es el diagrama principal para el anlisis y diseo

Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia

La definicin de clase incluye definiciones para atributos y operaciones

II. Breve Tour por UML6667El modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operaciones

Diagrama de Clases68 Ejemplos (Generalizacin)II. Breve Tour por UMLTrabajadorDirectivoAdministrativoObrero{ disjunta, completa }6869 Ejemplos (Clase Asociacin)II. Breve Tour por UMLEmpresaEmpleado1..**1..**trabajadoresempleadorCargonombresueldo0..11..*superiorsubordinado1..*0..16970Ejemplos (Clase y Visibilidad)Alumno

DNI : char[10]

nmero_exp : int

nombre : char[50]

alta()

poner_nota(asignatura : char , ao : int, nota : float)

matricular(cursos : asignatura, ao : int)

listar_expediente()7071 Ejemplos (Asociacin)ProfesorDepartamento10..1director1dirige0..17172Necesidad modeladoCasos de usoDiagramas de claseDiagramas de secuenciaUMLDiagrama de SecuenciaEste diagrama (tambin llamado diagrama de interaccin) muestra las interacciones entre un conjunto de objetos (clases, actores), ordenadas segn el tiempo en que tienen lugar. Es decir, muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama la secuencia de todas las llamadas posibles del sistema, es por ello que se escoge un punto de partida. El diagrama se compone con los objetos que forman parte de la secuencia, estos se sitan en la parte superior de la pantalla, normalmente a la izquierda se sita el que inicia la accin. De estos objetos sale una lnea que indica su vida en el sistema. Esta lnea simple se convierte en una lnea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando l esta activo.

73Diagrama de SecuenciaEl objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin.En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino. El diagrama de secuencia puede ser obtenido de dos partes, desde el Diagrama Esttico de Clases o desde el de Casos de Usos.

74Elementos Diagrama de Secuencia75Lnea de vida

Un objeto (o actor) se representa como una lnea vertical punteada con un rectngulo de encabezado y con rectngulos a travs de la lnea principal que denotan la ejecucin de mtodos (activacin). El rectngulo de encabezado contiene el nombre del objeto y el de su clase.Elementos Diagrama de SecuenciaActivacinMuestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de sus atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto.

76Elementos Diagrama de SecuenciaEl envo de mensajes entre objetos se denota mediante una lnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. Representa la llamada de un mtodo (operacin) de un objeto en particular.77Mensajes

Elementos Diagrama de Secuencia78

Tambin es posible visualizar llamadas a mtodos desde el mismo objeto en estudio. Ejemplo79

80

81

82

83

84

85

86

87

88

89

90Diagrama de SecuenciaMuestra la secuencia de mensajes entre objetos durante un escenario concreto.

Cada objeto viene dado por una barra vertical. Se llama lnea de vida.

El tiempo transcurre de arriba abajo.

9091Cada mensaje se representa mediante una flecha entre las lneas de vida.Cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicua.Cada mensaje se etiqueta con el nombre del mensaje y pueden incluirse los argumentosDiagrama de Secuencia9192Los rectngulos en las lneas de vida indican el tiempo en el cual un mtodo est activo.Diagrama de Secuencia93Diagrama de Secuencia : Encargado:WInPrstamos:Socio:Video:Prstamoprestar(video, socio)verificar situacin socioverificar situacin videoregistrar prstamoentregar recibo93Los Diagramas de Secuencia y de Colaboracin son usados para describir grficamente un caso de uso o un escenario

Un Diagrama de Secuencia muestra los objetos de un escenario mediante lneas verticales y los mensajes entre objetos como flechas conectando objetos

Los mensajes son dibujados cronolgicamente desde arriba hacia abajoLos rectngulos en las lneas verticales representan los periodos de actividad de los objetos.

94Diagrama de SecuenciaVentana de entrada de pedidosUn Pedidouna Lneade pedidoun artculode inventarioprepara( )*[para cada lneade pedido] prepara( )hayExistencia:=revisa( )[hayExistencia] descuenta( )ObjetoMensajeCondicinnecesitaReorden:=necesitaReordenar ( )Autodelegacin94Los Diagramas de Secuencia y de Colaboracin son usados para describir grficamente un caso de uso o un escenario

Un Diagrama de Secuencia muestra los objetos de un escenario mediante lneas verticales y los mensajes entre objetos como flechas conectando objetos

Los mensajes son dibujados cronolgicamente desde arriba hacia abajoLos rectngulos en las lneas verticales representan los periodos de actividad de los objetos.

95 Diagrama de Secuencia

9596

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

127Modelado de SI: Algunas ReflexionesModelar para la comprensin del sistema y/o para el mantenimiento y la documentacin.

Pragmatismo, los modelos deben ser tiles.

Sencillez y Elegancia.

Distintos nivel de abstraccin, diferentes modelos.

Seguimiento de transformaciones durante el proceso (Traceability).127128Sincronizacin de modelos.

Dificultades para la introduccin de tcnicas y herramientas de modelado.Modelado de SI: Algunas Reflexiones129ResumenUML define una notacin que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos

El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady Booch129