P. 1
UML.pdf

UML.pdf

|Views: 16|Likes:
Publicado porIrving Lopez

More info:

Published by: Irving Lopez on Jun 21, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/19/2013

pdf

text

original

Modelado de Software Orientado a Objetos usando UML

Construcción de Algoritmo de Fibonacci

int fib(int val){ if ((val==1)||(val==2)) return 1; else return (fib(val-1)+fib(val-2)); }

Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples

I. Introducción: Modelado de SW

Construcción del software para un cajero automatico
Security sy stem Branch accounting sy stem Auto-teller sy stem Branch counter sy stem Maintenance sy stem Usage database Account da tabase

Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

Sistema de Radar de Aeropuerto Notación Herramientas Proceso .

como se modela un sistema con esta complejidad ? .Pero.

.) “Modelar el sistema independientemente del lenguaje de implementación” Componentes Reutilizados Promover la Reutilización ..Beneficios del Modelado Manejar la complejidad Interface de Usuario (Visual Basic. . Java... .) Lógica del Negocio (C++. Java.) Múltiples Sistemas Servidor de BDs (C++ & SQL.

omg.org)  Documento “OMG Unified Modeling Language Specification”  UML combina notaciones provenientes desde: – – – – Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows) . Impulsado por el Object Management Group (OMG.Qué es UML?  UML = Unified Modeling Language  Un lenguaje de propósito general para el modelado orientado a objetos. www.

UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.Qué es UML?   El UML modela sistema mediante el uso de objetos que forman parte de él así como. . las relaciones estáticas o dinámicas que existen entre ellos.

visualizar y documentar los objetos de un sistema programado. Rumbaugh (OMT: Object Modeling Technique) y Jacobson (OOSE: Object-Oriented Software Engineering). construir. Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch. .Qué es UML?   UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar.

especificar .UML  UML es un lenguaje de modelado que sirve para visualizar. Jacobson y Rumbaugh). Lenguaje de modelado: “Lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema” (Booch. construir y documentar un sistema software. .

UML para visualizar    Símbolos con semántica bien definida. UML transciende al lenguaje de programación. Modelo explícito. que facilita la comunicación. .

UML para especificar   Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. diseño e implementación de un sistema software. UML cubre la especificación del análisis. .

Datos. etc.).UML para construir  Es posible hacer Ingeniería Directa corresponder con los Modelo CÓDIGO lenguajes de UML programación Ingeniería Inversa (Java. . C#. B.

UML para documentar  UML cubre la documentación de un sistema: – – – – – – – – Requisitos Arquitectura Diseño Código fuente Planificación Pruebas Prototipos Versiones .

patterns. notes Embly Singleton classes Wirfs-Brock Fusion Responsabilities Operation descriptions. Frameworks.UML “aglutina” enfoques OO Rumbaugh Booch Odell Jacobson Meyer Pre.and Post-conditions Shlaer-Mellor Object life cycles UML State Charts Harel Gamma et. message numbering . al.

 Util en la definición de requerimientos. pero tambien en el diseño (y en las pruebas…).Factores importantes en UML  Definición del proceso de desarrollo usando UML.  No cubre todas las necesidades de especificación de un proyecto software. .  Notacion estándar y soportada por herramientas CASE  Estándar del OMG  Gran cantidad de Libros y cursos. UML no es una metodología o proceso.

3 UML 1.4 UML 1.2 Revisiones menores .Historia de UML 2001 2000 1999 1998 Nov ‘97 UML aprobado por el OMG UML 2.0 UML 1.

UML 2.4 incorpora ciertas modificaciones sobre el estándar en base a los comentarios recogidos de los usuarios finales y de los fabricantes de software compatible con UML. las cuales corrigen o mejoran la especificación base (UML 1. .0 promete la puesta a punto del estándar para poder integrarse con el desarrollo basado en componentes que demanda el mercado.3 es una versión madura de UML a la que se le han añadido una serie de pequeñas revisiones.2). UML 1.Actualizaciones de UML    UML 1.

Personalización: mejora de los mecanismos de extensibilidad y personalización.0     Arquitectura: refinamiento del núcleo del estándar para que esté en consonancia con el resto de estándares del mercado. . EJB. así como el intercambio de los metadatos del mismo con XMI (XML Metadad Interchange). Mecanismos generales: nuevos mecanimos para el control de las versiones dentro del modelo.UML 2. COM+). Componentes: mejor soporte para el desarrollo basado en componentes (CORBA.

.. Sin embargo. sin embargo. existen relaciones de trazabilidad entre los diferentes modelos   . Cada modelo es completo desde su punto de vista del sistema.Modelos y Diagramas  Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). se requieren otros modelos .

 .Modelos y Diagramas  Modelo: captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema. a menudo dibujada como un grafo con vértices conectados por arcos. Diagrama: representación gráfica de una colección de elementos de modelado. considerando un cierto propósito.

Organización de Modelos Vista de Diseño Vista de los Casos de Uso Vista de Implementación Vista de Procesos Vista de Despliegue .

Diagramas de UML
Use Case Use Case Diagramas de Diagrams Diagrams Casos de Uso State State Diagramas de Diagrams Diagrams Clases

Use Case Use Case Diagramas de Diagrams Diagrams Secuencia Scenario Scenario Diagramas de Diagrams Diagrams Colaboración

State State Diagramas de Diagrams Diagrams Objetos State State Diagramas de Diagrams Diagrams Componentes

Modelo

Scenario Scenario Diagramas de Diagrams Diagrams Estados

Diagramas de Actividad

Component Component Diagrams Diagramas Diagrams de

Distribución

Mecanismos comunes en UML
Especificaciones. Es más que un lenguaje gráfico (semántica detrás de la notación).  Adornos. Detalles sobre un clase, nivel de acceso de sus métodos, notas.  Divisiones Comunes: Clase/Objecto o Interfaz/Implementación.  Extensibilidad. Estereotipos, valores etiquetados o restricciones.

Mecanismos comunes en UML
{orderById}

«utility» Producto -Paginas : int +Insert() +Update() +Delete() #GetNumPaginas() : int IDataManaged

«utility» p1 : Producto Paginas : int

«utility» p2 : Producto Paginas : int

Definición de un producto gestionado desde base de datos

Casos de Uso .

Casos de Usos  Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones). Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.  .

Casos de Usos    Los casos de Uso Se representa en el diagrama por una elipse que denota un requerimiento solucionando por el sistema. Cada caso de uso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. . El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.

Casos de Usos .

Casos de Usos  Actor: Es un usuario del sistema. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual. un caso de uso puede tener varios actores. . que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso. recíprocamente.

Casos de Usos  También se puede encontrar tres tipos de relaciones. denota la participación del actor en el caso de uso determinado. como son: – Comunica (comunicates) Entre un actor y un caso de uso. .

Frecuentemente no hay actor asociado con el caso de uso común. .Casos de Usos  Usa (uses): Relación entre dos casos de uso. Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados. denota la inclusión del comportamiento de un escenario en otro.

denota cuando un caso de uso es una especialización de otro.Casos de Usos  Extiende (extends): Relación entre dos casos. . Se usa cuando se describe una variación sobre el normal comportamiento.

Casos de Usos  Técnicas comunes de modelado: – – – Modelado del contexto del sistema (utilidad similar a los DFD). Modelado de los requisitos de un sistema. Modelado del proceso de test y estrés del sistema. .

Diagrama de Clases .

Conceptos básicos orientación a objetos         Clase Objeto Herencia Interfaz Polimorfismo de clases Clases y atributos estáticos Clases y atributos finales Clases y métodos abstractos .

Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases. dada por sus relaciones con los demás en el modelo. junto con las relaciones existentes entre clases y objetos. .Diagrama de clases  Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema.

Modelado de un conjunto de clases de test. Modelado de colaboraciones simples. Modelado de un esquema lógico de base de datos.Diagrama de clases  Usos comunes del diagrama: – – – – Modelado del vocabulario del sistema. .

son los elementos fundamentales del diagrama.Diagrama de clases    Clase: representa un conjunto de entidades que tienen en común propiedades. relaciones y semántica. En UML la clase está representada por un rectángulo con tres divisiones internas. operaciones. . Una clase es un constructor que define la estructura y comportamiento de una colección de objeto denominados instancia de la clase.

– # protegido.Diagrama de clases    Atributo: Representa una propiedad de una entidad. Las sintaxis de una atributo es: – Visibilidad <nombre>: tipo = valor { propiedades} Donde visibilidad es uno de los siguientes: – + público.privado. – . Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado. .

Diagrama de clases   Operación: El conjunto de operaciones que describen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es: Visibilidad nombre (lista de parámetros): tipo que retorna { propiedades} .

Diagrama de clases Nombre de la clase Atributos Métodos .

– Mantener estructura del producto plantilla. Clase Producto: – Registrar el código de la publicación. .Diagrama de clases   Responsabilidades: Contrato u obligación de una clase. asignada en el momento del diseño.

Diagrama de clases  Técnicas de modelado: – Modelado del vocabulario de un sistema a partir de las descripciones funcionales. personas. etc). – Modelado de tipos primitivos. – Modelado de cosas que no son software (hardware. . – Modelado de la distribución de responsabilidades en un sistema.

Se caracteriza por tener una identidad única. multiplicidad. calificador): representan las relaciones entre instancias de clase. un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos.Diagrama de clases  Objeto: es una instancia de una clase. . Una asociación es una línea que une dos o más clases.  Asociación (rol.

Rol: Identificado como un nombre a los finales de la línea.Diagrama de clases   Nombre: Identifica la asociación entre los objetos. describe la semántica de la relación en el sentido indicado. caracterizándola. cada rol es una dirección en la asociación. Cada asociación tiene dos roles. . El rol puede estar representado en el nombre de la clase.

Diagrama de clases  Multiplicidad: Describe la cardinalidad de la relación. es decir. cuanto objetos de esa clase pueden participar en la relación dada. Tipos: .

lo que implica que cambiar el elemento independiente puede requerir cambios en los dependientes.Diagrama de clases  Dependencia: Es una relación donde existen entidades independientes y otras dependientes. indicando el sentido de la dependencia. Se representa con una línea punteada direccional. .

Diagrama de clases .

Asociación n-aria.Diagrama de clases  Los tipos de asociaciones entre clases presentes en un diagrama estático son: – – – – – Asociación binaria. . Generalización. Composición. Refinamiento.

Asociación n-aria: Es una asociación entre tres o más clases. no muy fuerte (es decir. Se representa como un diamante del cual salen líneas de asociación a las clases. . no se exige dependencia existencial ni encapsulamiento). Se indica como una línea sólida que une dos clases.Diagrama de clases   Asociación Binaria: Representa una relación sencilla entre dos clases.

Diagrama de clases .

.Diagrama de clases  Composición: Es una asociación fuerte que implica: – – Dependencia existencial. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene. El elemento dependiente desaparece al destruirse el que lo contiene y. si es de cardinalidad 1. Hay una pertenencia fuerte. es creado al mismo tiempo.

no hacen parte del estado de otro objeto. .Diagrama de clases – Los objetivos contenidos no son compartidos.  Se denota dibujando un rombo del lado de la clase que contiene a la otra en la relación. esto es.

Diagrama de clases .

Es también una relación de composición menos fuerte (no se exige dependencia existencial) y se denota por un rombo sin rellenar en un o de los extremos. .Diagrama de clases  Agregación: Relaciona una clase ya ensamblada con una clase componente.

Diagrama de clases .

.Diagrama de clases  Generalización: es un proceso de abstracción en el cual un conjunto de clases existentes. que tienen atributos y métodos comunes. La subclase hereda todos los atributos y mensajes descritos en la superclase. Se representa dibujando un triángulo sin rellenar en el lado de la superclase. La relación de generalización denota una relación de herencia entre clases. es referido por una clase genérica a un nivel mayor de abstracción.

Diagrama de clases .

Por ejemplo. una clase del diseño es un refinamiento de una clase de análisis. .Diagrama de clases  Refinamiento: Es una relación que representa la especificación completa de algo que ya ha sido especificado con cierto nivel de detalle.

Diagrama de clases .

– Modelado de relaciones estructurales (composiciones y agregaciones). – Modelado de herencia simple.Diagrama de clases  Técnicas de modelado: – Modelado de dependencias simples. – Modelado de comentarios. .

Diagrama de clases .

Diagrama de Interacción .

Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.Diagrama de interacción   Estos son modelos que describen como los grupos de objetos que colaboran en algunos ambientes. . un diagrama de interacción captura el comportamiento de un único caso de uso. Por lo general.

Esta descripción es importante porque puede dar detalle a los casos de uso. como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación. .Diagrama de interacción  Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo. aclarándolos al nivel de mensajes de los objetos existentes.

Diagrama de interacción  Elementos básicos interacción: – – – – del diagrama de Objetos o actores para cada entidad. Mensajes entre los objetos. Enlaces entre los objetos. . Procedimientos a invocar entre los objetos.

El rectángulo de encabezado contiene el nombre del objeto y el de su clase. . en un formato nombreObjeto: nombreClase. con un rectángulo de encabezado y con rectángulo a través de la línea principal que denotan la activación.Diagrama de interacción   Un objeto se representa como una línea vertical punteada (línea de vida). es decir. desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. El envío de mensajes entre objetos se denotan mediante una línea sólida dirigida. el período de tiempo en el cual el objeto se encuentra desarrollando alguna operación.

Diagrama de interacción .

Diagrama de interacción  Diagramas de Colaboración: – Es una forma de representar interacción entre los objetos. Muestra como varios objetos colaboran en un solo caso de uso. cuáles temporales. pueden mostrar el contexto de la operación (cuáles objetos son atributos. las relaciones entre ellos y la secuencia de los mensajes de las iteraciones que están indicadas por un número A diferencia de los diagramas de secuencia. etc) y ciclos en la ejecución. es decir. .

Diagrama de interacción .

– Modelado del flujo de control por organización (colaboración). – Implementación de un caso de uso en concreto para cada diagrama. – Modelado del flujo de control por ordenación temporal (secuencia).Diagrama de interacción  Técnicas de modelado: – Modelado dinámico del sistema. .

Diagrama de Estados .

Diagrama de estados  Diagrama de Estados: – Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro. Elemento. Esta representado principalmente por los siguientes elementos:    Estado. Transición. .

Diagrama de estados  Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación. . tiene cierto estado característico o puede recibir cierto tipo de estímulos.

Subestados.Diagrama de estados  Partes que componen un estado: – – – – – Nombre Acciones de entrada y de salida. Eventos diferidos. . Transiciones internas.

Diagrama de estados  Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. después de entrar al estado o de cierta hora y fecha particular. . Recepción de un mensaje. Recepción de una señal de otro objeto en el modelo. puede ser una: – – – – Condición que toma el de verdadero o falso. Esta. Paso de cierto período de tiempo.

Diagrama de estados

Transición: Es una relación entre estados de un
fuente a un destino. Partes que componen una transición:
– – – – –

Estado de origen. Evento de disparo. Condición de guarda. Acción. Estado de destino.

Diagrama de estados

Otros elementos:
– – –

Subestados. Secuenciales o no, resultan en una nueva máquina de estados. Estados de historia. Estados de historia. Permiten a un conjunto de estados o subestados de un objeto, recordar el estado que estaba activo en su última ejecución. Si no existe historia, se comenzaría por el estado inicial. Subestados concurrentes.

Diagrama de estados

. Este tipo de diagramas se asocian directamente a una clase.Diagrama de estados  Técnicas de modelado: – Modelado de la vida de un objeto.

Diagrama de Actividades .

Diagrama de Actividades   Un diagrama de actividades es un caso especial de un diagrama de estados en el cual casi todos los estados son estados de acción (identifican que acción se ejecuta al esta en él ) y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior. . un objeto o un mensaje en un objeto. Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso.

Diagrama de Actividades   Sirven para representar transiciones internas. Los elementos que conforman el diagrama son: – – – Acción Transición. Objetos . sin hacer mucho énfasis en transiciones o eventos externos.

– Permite modular un paso dentro del algoritmo.Diagrama de Actividades  Estado de Acción: representa un estado con acción interna. . Se representan por un rectángulo con bordes redondeados. con lo menos una transición que indica la culminación de la acción (por medio de un evento implícito).

en cuanto a la notación.Diagrama de Actividades  Estado de Actividad: Estado más general que permite su descomposición en otro diagrama de actividades interno. . es la misma que el de Acción. de nivel más bajo. – Su representación.

Representado con un rombo. Representa el punto de entrada del diagrama de actividades. Estado final. Su existencia depende de si el diagrama es cíclico. Ítem de decisión. permite tomar bifurcaciones condicionales. .Diagrama de Actividades  Casos especiales: – – – Estado inicial.

Diagrama de Actividades  Casos especiales: – – Carriles o “Swim Lanes”. módulos del sistema. etc). Flujos con objetos. Permiten acotar el área a las cuales las actividades están asociadas (departamentos. Hacer explícita la relación con una entidad en concreto. .

Diagrama de Actividades  Transición: Es la relación entre dos estados y se encuentran unidos por flechas. . indicando que un objeto que está en el primer estado realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas.

Diagrama de Actividades  Tipos de transiciones: – – Bifurcaciones condicionales. Permiten representar el paralelismo en la ejecución de actividades. División y unión. . Permiten tomar distintos caminos dentro del diagrama en función de una condición o “guarda”.

Diagrama de Actividades .

Uso intensivo de estados de actividad. . swim lanes y bifurcaciones condicionales. Uso intensivo de transiciones (simples o paralelas) y de estados de acción.Diagrama de interacción  Técnicas de modelado: – – Modelado de un flujo de trabajo o Workflow. Modelado de una operación concreta que resulta muy complicada.

Diagrama de Componentes .

Diagrama de componentes  Los diagramas de componentes describen los elementos físicos reemplazables del sistema y sus relaciones  Muestran las opciones de realización incluyendo código fuente. binario y ejecutable .

Diagrama de componentes  Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. librerías. etc. bibliotecas cargadas dinámicamente. Pueden ser simples archivos.  Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente .

Diagrama de componentes .

Modelado del código fuente. Planificación de versiones ejecutables para su implementación con Nant.Diagrama de componentes  Técnicas de modelado: – – – – – Modelado de ejecutables y bibliotecas. Modelado y diseño de un API. Modelado de tablas. . archivos y documentos.

Diagrama de Despliegue .

Diagrama de despliegue  Los diagramas de despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos .

Diagrama de despliegue  La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. .  Un nodo es un recurso de ejecución tal como – Dispositivos – Procesadores – Memoria  Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse.

Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos.Diagrama de despliegue   Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. .

Diagrama de despliegue .

Diagrama de despliegue .

Modelado de distribución de componentes.Diagrama de despliegue  Técnicas de modelado: – – Modelado de procesadores y dispositivos. .

Paquetes en UML  Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado  Se representan gráficamente como: Nombre de paquete .

sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete  Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes .… Paquetes en UML  Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema)  Un paquete puede contener otros paquetes.

… Paquetes en UML  Todos los elementos no son necesariamente visibles desde el exterior del paquete. un paquete encapsula a la vez que agrupa  El operador “::” permite designar una clase definida en un contexto distinto del actual . es decir.

.Los modelos se usan para describir al sistema de software  Modelo del sistema: Modelo de objetos + modelo funcional + modelo dinamico Modelo de objetos: Cual es la estructura del sistema? Cuales son los objetos y cual es su relacion? –  Notacion UML: Diagramas de clases  Modelo funcional: Cuales son las funciones del sistema? Como fluyen los datos en el sistema? – Notacion UML: Diagramas de casos de uso  Modelo dinamico: Como reaccciona el sistema a eventos externos (e internos) y cual es el flujo de eventos? – Notacion UML: Diagramas de secuencia. state charts y de actividad.

. o cuando los requerimientos cambian frecuentemente.Modos de utilización de UML     Ingenieria hacia adelante(Forward Engineering) – Se comienza con un modelo antes de producir codigo Ingenieria en reversa (Reverse Engineering) – Se crea un modelo a partir de algun codigo – Proyectos de interfaces o re-ingenieria Ingenieria ciclica (Roundtrip Engineering) – Se mueve constantemente entre ingenieria hacia adelante y en reversa. – Util en proyectos que utilizan el modelo de procesos evolutivo. pero en donde se ubica UML dentro del proceso de Diseño ?. Se asume que a partir de UML se puede producir codigo.

de Datos (Data Model) M. de Análisis (Analysis Model) M. de Despliegue (Deployment Model) M.Proceso de Desarrollo Unificado basado en UML Propuesta de Rational Unified Process (RUP)          M. de Objetos del Negocio (Business Object Model) M. de Diseño (Design Model) M. de Pruebas (Test Model) . de Casos de Uso del Negocio (Business Use-Case Model) M. de Implementación (Implementation Model) M. de Casos de Uso (Use-Case Model) M.

0 o XP .e.Claves en el Desarrollo de Software Notación UML Herramientas p. Rational Rose Poseidon Proceso p.e. Rational Unified Process Métrica 3.

Modelado de Software. Principio básico: “Sencillez y Elegancia” Gestión de modelos  Distintos nivel de abstracción. La importancia del Proceso de Desarrollo .  Comunicar ideas y estudiar alternativas  Tomar decisiones de análisis/diseño que dirijan la implementación  Generar parcial o totalmente una implementación a partir de los modelos  Pragmatismo. los modelos deben ser útiles.  ¿Cuál es el propósito de nuestros modelos?  “Documentar”. expresados en diferentes modelos    Seguimiento de transformaciones durante el proceso (Traceability) Sincronización de modelos  Dificultades para la introducción de notaciones y herramientas de modelado.

.Resumen  UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos  El modelo de proceso RUP utiliza UML para el modelado.

Bernd Bruegge & Allen H.martinfowler. Edition). and Java. Dutoit (3rd.Bibliografía Partes de este Curso esta basado en el siguiente material:  Curso de Desarrollo de Software Orientado a Objetos usando UML. del DSIC de la Universidad Politecnica de Valencia. autor de “UML Destilled” (“UML Gota a Gota”) http://www. Prentice Hall. 2009. UML – www.objectsbydesign. del Prof.  Transparencias del Libro: Object-Oriented Software Engineering: Using UML.org/uml/ – Martin Fowler. Patricio Letelier Torres.com/ Herramientas CASE – Rational Rose de IBM – Herramientas basadas en UML www.com/tools/umltools_byPrice.omg.html . Patterns.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->