1 modelado de proyectos de software proyecto de solución de problemas con programación

11

Modelado de Proyectos Modelado de Proyectos de Softwarede Software

Proyecto de Solución de Problemas con Programación

ModeladoModelado

• Es la primera fase creativa del desarrollo de proyectos. Se compone de lo qué es análisis y diseño.

• El modelado parte de lo que es la Ingeniería de Requerimientos y devuelve un modelo que puede ser construido (implantable a través de lenguajes de programación).

Principios de AnálisisPrincipios de Análisis

• En general durante la etapa de análisis se deben especificar procesos, datos y control.

• Etimológicamente análisis significa “descomponer”, debe de responder a la pregunta ¿Qué? del desarrollo de software


• En análisis estructurado se utiliza la técnica de Diagrama de Flujo de Datos para especificar procesos, Diagrama Entidad-Relación para especificar datos y diagramas de transición de estados para control.

• Para el modelado de datos se recomienda definir todos los objetos (entidades) y definir sus atributos.


• El diccionario de datos (DD) es otra forma de especificar los requerimientos de un sistema.

• En general un DD son metadatos que contienen alias, donde se usa/como se usa, descripción e información adicional de los diccionarios de datos.


• Ejemplo:

• Datos de Factura, • Datos del Cliente, • Facturación(Entradas),

• Datos de Factura = NombreCliente + Domicilio + RFC+ Tel

Análisis Orientado a ObjetosAnálisis Orientado a Objetos

• Para construir un modelo de Análisis Orientado a Objetos, se usan cinco principios básicos:

• Se modela el dominio de la información• Se describe la función.• Se representa el comportamiento del

modelo.


• Los modelos de datos funcional y de comportamiento se dividen para mostrar más detalles.

• Los modelos iniciales representan la esencia del problema mientras que los últimos aportan detalles de la implementación.


• Se deben encontrar todos los objetos.

• Se debe especificar una jerarquía de clases.

• Representan las relaciones objeto a objeto

• Modelar el comportamiento del objeto.

Herramientas CASEHerramientas CASE

• Las herramientas CASE (Ingeniería de Software Asistida por Computadora) permiten ayudar a las personas en el proceso de desarrollo de software en áreas tales como: análisis de requerimiento, depuración y pruebas.


• Existen muchas clasificaciones de las herramientas CASE, a continuación se describirán las más importantes.

• U-CASE (Upper-CASE) es una herramienta que sirve de front-end durante las primeras fases del ciclo de vida: análisis y diseño.


• L-CASE (Lower-CASE) sirve de back-end durantes las últimas fases del ciclo de vida: implementación y pruebas.

• I-CASE (Integrated-CASE) también llamadas workbench CASE son herramientas que ayudan en todas las fases del ciclo de vida.

• Los toolkits son herramientas que solo auxilian durante una fase del ciclo de vida.

Herramientas CASEHerramientas CASE• Tampoco se debe confundir CASE con las

herramientas de gestión de proyectos que en general ayudan a la planificación y seguimiento de actividades.

• Existen otras herramientas como: entornos de programación, herramientas de diseño de interfaces, herramientas de documentación, herramientas de reestructuración, ingeniería inversa, etc.


• Los componentes básicos de un sistema CASE son: los repositorio (bases de datos con algunas características del proyecto); las herramientas de diagramación y modelado, herramientas de prototipado, generación de código, generador de documentación y en la mayoría de los casos un módulo de gestión del proyecto.

Diseño de SoftwareDiseño de Software

• El diseño es la primera parte del desarrollo de cualquier proyecto.

• Etimológicamente significa componer, por lo que se obtiene la solución que habrá de implantarse.

• Todas las cosas siempre tienen primero una creación mental.


• El diseño en proyectos informáticos presenta cuatro apartados: datos, arquitectura, interfaz y procedimientos.

• El diseño de datos se encarga de transformar el modelo de información obtenido en el proceso de análisis en estructuras de datos. Se pueden utilizar diagramas entidad-relación pero especificados a mayor detalle.


• El diseño arquitectónico tiene la finalidad de comprobar las relaciones con los diferentes módulos o macrorequisitos del sistema (subsistemas).

• El diseño de interfaz define como se comunica el software consigo mismo y hacia el exterior.


• El diseño procedimental o basado en componentes consiste en la traducción de cada uno de los elementos obtenidos en la especificación de procesos, datos y transición hacia elementos implantables a través de computadoras.

Proceso del DiseñoProceso del Diseño

• El proceso de diseño sirve de base para la codificación del sistema. Se deben seguir algunas recomendaciones para su mejor desarrollo como las siguientes:

• Se deben especificar todos los elementos explícitos e implícitos del modelo de análisis.

Procesos del DiseñoProcesos del Diseño

• El diseño deber servir de guía para que cual integrante del proyecto pueda construir y entender el software.

• El diseño debe de dar una completa idea de lo que es el software.

• El diseño debe presentar uniformidad e integración. Se deben definir reglas y estilos que deben seguir los miembros del equipo.

Procesos del DiseñoProcesos del Diseño

• El diseño debe estar estructurado, de tal forma que permita cambios.

• El diseño no es escribir código, ni codificar es diseñar.

• Al diseñar se deben tomar en cuenta Factores de Calidad Externos (velocidad, Fiabilidad, utilidad) y Factores de Calidad Interno (abstracción, refinamiento, modularidad).

Fundamentos del DiseñoFundamentos del Diseño

• A continuación se muestra el glosario básico del diseño de proyectos de software:

• Abstracción: son los niveles de resolución de problema, los cuales pueden ser alto si se especifica en lenguaje natural o bajo nivel de abstracción si tiene una implantación directa.

• La abstracción puede ser de datos, procedimientos y control.


• Refinamiento: es la base del diseño. Es un proceso de elaboración que comienza con un nivel de abstracción alto y van descendiendo sucesivamente de nivel de abstracción hasta llegar a un nivel bajo.

• Durante el proceso de refinamiento se van obteniendo detalles tanto de procedimientos como de datos obteniendo mejores soluciones más fáciles de implementar.


• La modularidad es el atributo de software que permite un programa sea manejable intelectualmente.

• El software monolítico es muy difícil de manejar. Se debe aplicar el principio de “divide y vencerás”


• Los módulos son los componentes básicos de todo sistema y tienden a satisfacer a uno o más requerimientos.

• Se han definido cinco métricas para evaluar el diseño modular: capacidad de descomposición, reutilización, capacidad de comprensión, continuidad modular y protección modular.


• La arquitectura del software hace referencia a la estructura global del sistema, dicha estructura es jerárquica en forma de módulos.

• La arquitectura de software debe ayudar a definir como interactúan los componentes de software entre sí y las estructuras de los datos.


• La jerarquía de control representa dos características: visibilidad y conectividad.

• La visibilidad es el conjunto de componentes de un programa que pueden ser invocados o utilizados sus datos por un componente aun de manera directa.

• La conectividad indica el conjunto de componentes que son accedidos de manera directa por otros componentes.


• La partición estructural de una arquitectura de software puede ser horizontal: datos, procesos y control; o bien vertical definiendo una jerarquía de módulos.

• Los módulos deben programarse de tal forma que los datos no estén accesibles por otros módulos.

Diseño Modular EfectivoDiseño Modular Efectivo

• El diseño modular ayuda a reducir la complejidad, facilita los cambios y ayuda a producir soluciones más sencillas.

• Los tres tipos de módulos existentes son: secuencial, incremental y paralelo.

• La independencia funcional se adquiere cuando se desarrollan los conceptos de modularidad, abstracción y ocultamiento de información.


• La independencia funcional se mide en base a dos criterios: cohesión y acoplamiento.

• Cohesión: es una extensión del principio de ocultamiento de información, es deseable tener una alta cohesión. Esta se obtiene cuando un módulo realiza una tarea sencilla sin depender de otros módulos


• El acoplamiento es una medida de interconexión de los módulos. Es necesario tener un bajo acoplamiento. El acoplamiento se mide en las relaciones que guardan los módulos con sus interfaces de entrada y salida.

• Hay tres tipos de acoplamiento: común, de datos y control.

Diseño de DatosDiseño de Datos• Algunas recomendaciones para el diseño

de datos son:

• Definir todas las posibles operaciones a realizar sobre los datos.

• Se deben refinar las estructuras de datos hasta tener representaciones de bajo nivel.

Diseño de DatosDiseño de Datos• Se deben desarrollar bibliotecas útiles para

la manipulación de datos.

• El lenguaje de implementación debe soportar tipos de datos abstractos.

• Se debe tener cuidado a la hora de diseñar diccionarios de datos, para que no se tengan “basureros de datos” en lugar de almacenes de datos.

Diseño ArquitectónicoDiseño Arquitectónico

• El concepto de Arquitectura de Software tiene mucho tiempo de antigüedad, pero no fue hasta la década de los 1990s que comenzó a utilizarse de manera formal.

• Analizando los sistemas se puede observar que existen patrones que se repiten conformando lo que se conoce como estilos arquitectónicos.


• Un estilo arquitectónico define un conjunto de familias de patrones de software con una determinada estructura y restricciones.

• Generalmente los patrones de diseño y arquitectura definen soluciones para medios repetitivos.

• La arquitectura de software es una abstracción del sistema que nos permite ver su estructura y su relaciones.


• Para el desarrollo del Diseño Arquitectónico se recomiendan seguir los siguientes pasos:

• Estructuración del sistema• Modelado de control• Descomposición modular

Diseño ArquitectónicoDiseño Arquitectónico• La Arquitectura de Flujo de Datos parte del

DFD para obtener una arquitectura del sistema:

• Se establece el tipo de flujo de información

• Se indican los límites del flujo• Se convierte el DFD en una estructura del

programa


• Se define la jerarquía de control mediante particionamiento.

• Se refina la estructura resultante utilizando heurísticas de diseño.

• La Arquitectura Centrada en Datos tiene como componente principal un repositorio, del cual surgen los demás componentes.


• Las Arquitecturas Estratificadas son de las más utilizadas en la actualidad, dado que dividen las actividades y responsabilidades de sistemas por capas.

• El software más elaborado como los sistemas operativos, software de base, sistemas distribuidos y otros maneja variantes de esta arquitectura.


• El diseño se debe refinar realizando cada uno de los siguientes pasos:

• Desarrollar una descripción del procedimiento para cada módulo.

• Desarrollar una descripción de la interfaz para cada módulo.


• Se definen las estructuras de datos generales y globales.

• Se anotan todas las limitaciones/restricciones del sistema.

• Se debe refinar el diseño hasta que esté completo. Se recomienda completar la arquitectura con el Diseño de Interfaces.

Diseño de Interfaz de UsuarioDiseño de Interfaz de Usuario

• El diseño de interfaces se refiere al estudio de las relaciones entre los usuarios y las computadoras para que un sistema se pueda ejecutar.

• El diseño de una interfaz puede definir el éxito de cualquier proyecto, ya que la utilización de cualquier interfaz de usuario depende de factores humanos.

Diseño de Interfaces de UsuarioDiseño de Interfaces de Usuario

• Existen algunas reglas de oro para el buen diseño de Interfaces de Usuario:

• Dar el control al usuario

• Reducir la carga de memoria del usuario

• Construir una interfaz consecuente


• Existen cuatro modelos diferentes para el desarrollo de interfaces:

• Modelo de diseño: que consiste en representar el software de acuerdo a los datos, arquitectura, interfaz y procedimiento.

• Modelo de Usuario: Representa el perfil del usuario (edad, cultura, etnia, educación, etc.)


• Existen tres tipos de usuario: Principiantes, Esporádicos y Frecuentes.

• La percepción del sistema (modelo de usuario): es la idea que tienen los usuarios sobre la posible interfaz del sistema.

• La imagen del sistema es un modelo que intenta mezclar lo que es la estructura del sistema con analogías de la vida real.


• Las fases del proceso del desarrollo de interfaces de usuario son:

• Análisis de usuarios, tareas y entornos• Diseño de la interfaz• Implementación de la interfaz• Validación de la interfaz


• Se deben seguir las siguientes recomendaciones:

• Establecer los objetivos e intenciones de cada tarea.

• Hacer correspondencia entre cada objetivo con una secuencia de interacción.

• Especificar la secuencia de acciones de tareas y subtareas.


• Se debe indicar el estado del sistema• Se deben definir mecanismos de control

• Se debe mostrar la forma en como los mecanismos de control afectan el estado del sistema.

• Se debe indicar la forma en que el usuario interpreta el estado del sistema a partir de la información presente en la interfaz.


• Los principales problemas que se presentan al diseñar una interfaz de usuario son:

• El tiempo de respuesta del sistema• Los servicios de ayuda al usuario• La manipulación de información de errores• El etiquetado de órdenes

Diseño ProcedimentalDiseño Procedimental

• También llamado de Componentes, se debe de desarrollar cuando se haya terminado el diseño de datos, interfaz y arquitectura.

• El objetivo de este diseño es tener un modelo de solución que sea fácil de implementar en lenguajes de programación.

• El diseño de procedimientos se hace de manera estructurada pero bien podría hacerse con otro paradigma.


• Se pueden utilizar mecanismos como los diagramas de flujo, los diagramas de caja (NS-Chapin), Lenguaje de Diseño de Programación (Pseudocódigo).

• El diseño procedimental debe de ser:

• Simple (leer, usar y entender)• Modular• Fácil de editar


• Legible para la computadora• Representar los datos del problema

• El diseño procedimental es la etapa más importante del diseño para la fase de construcción del proyecto dado que el modelo que aquí se genere debe de estar libres de errores.

Documentación del DiseñoDocumentación del Diseño

• Existen varias formas de documentación de la etapa del diseño, a continuación se muestra la que se utilizará en el curso:

• Ámbito• Diseño de Datos• Diseño Arquitectónico• Diseño de Interfaz• Diseño Procedimental


• Referencias cruzadas de requisitos• Recursos de prueba• Notas especiales

• Ámbito:– Objetivos– Principales requisitos de Software– Restricciones de Diseño y Limitaciones


• Diseño de Datos: – Objetos de Datos– Estructuras de archivos y base de datos

(estructura lógica, métodos de acceso, datos)

• Diseño arquitectónico:– Revisión de datos y flujos de control– Estructura del Programa

Documentación del DiseñoDocumentación del Diseño• Diseño de Interfaz:

– Especificación HMI– Normas de diseño de la HMI– Diseño de la interfaz externa (con datos y

sistemas externos)– Normas de diseño de la interfaz interna.

• Diseño procedimental:– Los pasos siguientes se deben hacer para cada

módulo.

Documentación del DiseñoDocumentación del Diseño– Descripción del proceso– Descripción de la interfaz– Descripción del lenguaje de diseño– Módulos usados– Estructuras de datos internas

• Referencias cruzadas de requisitos: esta sección es opcional, sirve para llevar el control de donde se están satisfaciendo los requerimientos del modelo de análisis.


• Recursos de prueba:– Directrices para las pruebas– Estrategias de integración– Consideraciones especiales

• Notas especiales:– Apéndices

Heurísticas del DiseñoHeurísticas del Diseño

• A continuación se muestra un conjunto de heurísticas a seguir para obtener mejores resultados:

• Evaluar la primer iteración de la estructura de programa para reducir el acoplamiento y mejorar la cohesión.– Explosión– Implosión


• Intentar minimizar las estructuras con un alto grado de salida; esforzarse por la entrada a medida que aumenta la profundidad.

• Mantener el ámbito del efecto de un módulo dentro del ámbito de control de ese módulo.

• Evaluar las interfaces de los módulos para reducir la complejidad, la redundancia, y la consistencia.


• Definir módulos cuya función pueda predecir, pero evitar módulos que sean demasiado restrictivos.

• Intentar conseguir módulos de entrada controlada evitando conexiones patológicas.

Optimización del DiseñoOptimización del Diseño

• Se recomienda las siguientes acciones para tener un diseño óptimo:

• Desarrollar y refinar la estructura del programa sin preocuparse de la optimización.

• Usar herramientas CASE que simulen el rendimiento en tiempo de ejecución para aislar áreas de ineficiencia.


• Durante iteraciones posteriores del diseño, seleccionar los módulos sospechosos de “devorar tiempo” y desarrollar cuidadosamente procedimientos que mejoren la eficiencia en el empleo de tiempo.

• Codificar en un lenguaje de programación apropiado.


• Instrumentar el software para aislar módulos que consuman mucho tiempo de procesador.

• Si es necesario, rediseñar o recodificar en lenguaje máquina para mejorar la eficiencia.

Diseño Orientados a ObjetosDiseño Orientados a Objetos

• Consiste en representar un modelo de datos que pueda ser fácilmente implantable con algún lenguaje de programación orientado a objetos.

• Los objetos son componentes potencialmente reutilizables, lo que hace que el software sea más fácil de mantener.

Diseño Orientado a ObjetoDiseño Orientado a Objeto

• El proceso general para el diseño orientado a objetos tiene varias etapas:

1.Comprender y definir el contexto y los modos de utilización del sistema.

2.Diseñar la arquitectura del sistema.3.Identificar los objetos principales en el

sistema.

Diseño Orientado a ObjetosDiseño Orientado a Objetos

4. Desarrollar los modelos de diseño.

5. Especificar las interfaces de los objetos.

• No es un proceso sistematizado al 100%, por lo que necesita refinarse con varias iteraciones.


• El primer paso consiste en identificar los tipos de relaciones definidos en el sistema, los cuales pueden ser internos y externos. Estas relaciones pueden ser dos:

• El contexto del sistema: es un modelo estático que describe a los otros sistemas en ese entorno.


• El modelo que el sistema utiliza: es un modelo dinámico que describe cómo interactúa el sistema con su entorno.

• Con el diseño de contexto se puede crear fácilmente el diseño arquitectónico de la aplicación.

• Existen diversas técnicas para identificar objetos:


• Utilizar un análisis gramatical de la descripción en lenguaje natural de un sistema.

• Utilizar entidades tangibles (cosas).

• Utilizar un enfoque de comportamiento.

• Utilizar un análisis basado en escenarios.


• Existen dos tipos de modelos de diseño para describir un diseño orientado a objetos:

• Modelos Estáticos.

• Modelos Dinámicos.

• Ejemplos de algunos modelos:

Diseño Orientado a ObjetosDiseño Orientado a Objetos• Los modelos de subsistemas

• Los modelos de secuencia

• Los modelos de máquinas de estado

• La encapsulación de las clases hace que los sistemas evolucionen de forma rápida y sencilla.

Métodos Orientado a ObjetosMétodos Orientado a Objetos

• Existen diversas metodologías para la realización de análisis y diseño orientado a objetos como:

• Método de Booch: abarca un microproceso de desarrollo y un macroproceso de desarrollo.

• Método OMT (Rumbaugh)

Métodos Orientado a ObejtosMétodos Orientado a Obejtos

• Objectory (Jacobson)

• Método de Coad-Yourdon

• Método UML:

Diagramas de actividadesDiagramas de actividades

• Es la versión UML de un diagrama de flujo.

• Se usan para analizar los procesos y realizar la ingeniería de los mismos.

• Es una excelente herramienta para analizar problemas.


• Son diagramas que representan las carácterísticas de los procesos.

• Estos diagramas deben facilitar la implementación del sistema.

• Van enfocados a los expertos del dominio (programadores y analistas).

Diagrama de actividadesDiagrama de actividades

• Pueden modelar procesos lineales y paralelos.

• Los diagramas deben ser más simples que detallados.

• Los elementos principales son: nodo inicial, flujo, actividades, conectores.


• Se pueden utilizar clavijas para conectar dos nodos de acción.

• Los nodos de decisión son importantes para bifurcar el flujo de actividades.

• Los nombres y los verbos nos sirven para determinar las clases y los métodos.


• Los casos de uso son candidatos a desarrollar diagramas de actividades.

• Las condiciones previas y posteriores se manejan con el uso de guardianes.

• Los nodos de decisión también sirven para fusionar diversos flujos en uno solo.


• Los carriles sirven para delimitar quien es el responsable de una serie de actividades.

• Los carriles formalmente se llaman partición de actividades y puede haber varios siempre y cuando no se encimen.

• Se puede modelar el tiempo a través de señales.

Diagramas de ActividadesDiagramas de Actividades

Diagramas de clasesDiagramas de clases

• Se usan para mostrar las clases de un sistema y las relaciones entre ellas.

• Muestran la vista estática del sistema; no describen los comportamientos ni la forma en como interactuan las clases del sistema.


• Los elementos del lenguaje son unos rectángulos denominados clases y los conectores representan las relaciones.

• Las clases pueden tener comportamientos y atributos. Lo difícil no es encontrar las clases sino definir sus relaciones


• Un diagrama de objetos es similar a un diagrama de clases pero representa un comportamiento dinámico.

• Los objetos se distinguen al subrayar el nombre de la clase.

• Las interfaces son clases abstractas puras.


• Las interfaces se usan cuando las partes de las cosas tienen facetas semánticamente similares pero no tienen genealogía relacionada.

• Se utiliza el estereotipo interface. Los tipos de datos pueden variar dependiendo de la implementación.


• El símbolo + se usa para describir datos públicos. El símbolo - para datos privados y # un dato no es ni público ni privado (protegido).

• Para acceder a datos privados y/o protegidos se deben utilizar métodos get/set


• Los atributos funcionan como asociación. La multiplicidad de las relaciones es importante.

• Si los valores superiores e inferiores de las relaciones son iguales (1..1) se pone un solo número (1).


• Es común hablar de elementos opcionales, obligatorios, de un solo valor y valores múltiples.

• El 80% de los diagramas de clase utilizan relaciones simples.

• Si existe una flecha en la asociación se dice que ésta es dirigida o direccional.

Diagramas de claseDiagramas de clase

• La agregación se representa con un diamante hueco; mientras que la composición es un diamante relleno.

• La generalización o herencia se refiere a una relación del tipo es un.

• En una relación de herencia la clase hijo hereda las carácterísticas de la clase padre.


• Las relaciones de realización se utilizan en interfaces para definir que la clase hija implementará esa interfaz. Se utiliza una línea punteada con un diamante parecido a la herencia.

• Las relaciones de dependencia se dan entre dos clases denominadas cliente y proveedor. Se representa con una línea punteada con flecha sencilla.


• Los paquetes tienen la apariencia de una carpeta de archivos. Se usa para representar un nivel más avanzado de abstracción. Se utilizan para organizar las clases, generalmente representan un espacio de nombres.

• Los espacios de nombres solucionan el problema de tener clases diferentes con el mismo nombre.

Diagramas de claseDiagramas de clase• Algunas herramientas soportan la

documentación del modelo, pero no forma parte del estándar.

• UML tiene datos primitivos: Integer, Boolean, String y UnlimitedNatural, pero se pueden utilizar otros tipos de datos definidos por el estereotipo primitivo, solo hay que definir sus componentes y sus operadores.


• Los espacios de nombre se anteponen al de la clases con el operador de alcance: ::

• Existen dos modalidades para el desarrollo de software orientado a objetos: consumo (Visual Basic) y Producción (Visual C++).

• La técnica de nombres son clases, verbos son métodos sólo funciona en el 20% de los casos.

Diagramas de clasesDiagramas de clases• Se recomienda realizar un análisis de

dominio ya que nos ayuda a encontrar clases frontera, de control y entidad.

• Las clases frontera interconenctan elementos del exterior con elementos del interior. Las clases de entidad representan datos (generalmente persistentes). Las clases de control representan interacciones entre el sistema.


• La refactorización y los patrones de diseño ayudan a mejorar los diagramas de clases.

• La herencia múltiple se puede modelar en UML pero no es recomendable hacerlo. Es mejor usar la composición o herencia de interfaces.

• “El mal se encuentra en los detalles”.

Diagramas de ClasesDiagramas de Clases

Diagramas de secuenciaDiagramas de secuencia

• Muestran la parte dinámica del sistema.

• Muestran los mensajes que se envían las clases con respecto al tiempo.

• Los diagramas de secuencia muestran un orden a través del tiempo.

• Un diagrama de secuencia es más fácil de leer que uno de colaboración.


• Existen muchos diagramas en UML que resultan redundantes, ya que dicen exactamente lo mismo pero en diferente forma.

• Los elementos esenciales son las líneas de vida y los mensajes.

• La línea de vida representa un ejemplo de clase


• Las líneas de vida pueden ser actores u objetos.

• La activación de una línea de vida se hace a través de un rectangulo sobre la línea de vida. Un objeto puede crearse y destruirse varias veces dentro de la ejecución de un sistema.


• Los mensajes forman una parte importante de este diagrama. Si se tiene una flecha triangular representa un mensaje síncrono, si se tiene una flecha abierta se representa un mensaje asíncrono, los mensajes de retorno se representan con flechas punteadas, mientras que un mensaje anidado inicia y termina en la misma línea de vida.


• Los marcos de interacción o fragmentos combinados son nuevos en UML 2.

• Son regiones rectangulares que se usan para organizar los diagramas de interacción.

• Los marcos de interacción más comunes son: alt, bucle, neg, opt, par, ref, regio rod


• En un futuro no tan lejano, los diseños deberán ser tan detallados como los circuitos eléctricos.

• En algunos casos es mejor usar diagramas de colaboración, debido a la sencillez de su diseño.

Diagramas de SecuenciaDiagramas de Secuencia

Diagramas de interacciDiagramas de interacciónón

• También muestran la parte dinámica del sistema.

• Organizan las clases y los mensajes en forma espacial. Como no lleva ordenación del tiempo los mensajes se enumeran.

• Los diagramas de secuencia e interacción son complementarios y en algunos casos no es aconsejable utilizar ambos.

Diagramas de colaboraciDiagramas de colaboraciónón

• También se les llama diagrama de comunicación en UML 2.

• Los elementos son un rectángulo llamado papel clasificador que representa los objetos, conectores y una secuencia que indica los mensajes. En UML la secuencia se numera como 1, 1.1, 1.2, … en lugar de 1, 2, 3

Diagramas de colaboraciDiagramas de colaboraciónón

• Un diagrama de interacción se puede pasar a código. Los objetos son instancias de clases y los mensajes son métodos, los cuales se codifican en la clase del receptor no del llamador.

• En diagramas donde existen muchos mensajes se necesitan de más notas para poder explicar el diagrama.

Diagramas de colaboraciónDiagramas de colaboración

Diagramas de estadoDiagramas de estado

• Muestra el estado cambiante de un objeto.

• UML es un lenguaje relativamente sencillo ya que utilizando poco vocabulario se puede realizar la mayoría del modelado de un sistema.


• Sirven para representar máquinas de estados (e.g. autómatas).

• Son ideales para representar procesos de red y de tiempo real.

• La creación de diagramas de interfaces gráficas de usuarios no es parte del estándar UML.


• Los diagramas de estado y actividades comparten mucha de la simbología por lo que se les suele confundir con frecuencia.

• Los estados son activos cuando se ejecutan su actividad de entrada. Se vuelven inactivos después de ejecutar su actividad de salida


• Las actividades comunes son algo que sucede de manera instantánea; mientras que una actividad inicia con el prefijo “hacer/” es una actividad de hacer.

• Un estado simple no está dividido en regiones. En un estado compuesto cada región representa una subactividad.


• Las transacciones son líneas dirigidas que conectan estados. Pueden ocurrir en base a algún mecanismo de disparo.

• Las máquinas de estado de protocolo se utilizan para describir interfaces.

Diagramas de componentesDiagramas de componentes

• Muestra los subsistemas del producto final.

• No es un diagrama ampliamente utilizado en UML.

• Existen dos métodos para el diseño basado en componentes: diseño componentes-interfaz (arriba abajo) y a partir de clases.

Diagramas de componentesDiagramas de componentes

• El símbolo de componente cambió en UML 2 a un diagrama más simple.

• Se utiliza generalmente para modelar sistemas muy grandes.

• Sistemas basados en red y distribuidos pueden modelarse bien con este diagrama.

Diagrama de despliegueDiagrama de despliegue

• Se utiliza para modelar la forma en como lucirá el sistema cuando se ponga en uso.

• Los nodos representan componentes físicos que pueden ser computadoras, sistemas operativos, entornos, servidores, etc.

• Ayudan al proceso de instalación de un sistema

Diagrama de despliegueDiagrama de despliegue

• Los artefactos son las cosas que se están desplegando. Usan el estereotipo artefacto y pueden ser achivos exe, dll, HTML, .jar, scripts, etc.

• Dentro de cada nodo se suele describir algunas carácterísticas propias.

111188

¿Preguntas, dudas y ¿Preguntas, dudas y comentarios?comentarios?

1 modelado de proyectos de software proyecto de solución de problemas con programación

Documents