Modelado de Proyectos de Software

1
Modelado de Proyectos de Software

• M.C. Juan Carlos Olivares Rojas

2
Modelado

• 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).

3
Principios 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

4
Principios de Análisis

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

5
Principios de Análisis

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

6
Principios de Análisis

• Ejemplo
• Datos de Factura,
• Datos del Cliente,
• Facturación(Entradas),
• Datos de Factura NombreCliente Domicilio
  RFC Tel

7
Aná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.

8
Análisis Orientado a Objetos

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

9
Análisis Orientado a Objetos

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

10
Herramientas 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.

11
Herramientas CASE

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

12
Herramientas CASE

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

13
Herramientas 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.

14
Herramientas CASE

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

15
Diseñ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.

16
Diseño de Software

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

17
Diseño de Software

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

18
Diseño de Software

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

19
Proceso 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.

20
Procesos 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.

21
Procesos 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).

22
Fundamentos 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.

23
Fundamentos del Diseño

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

24
Fundamentos del Diseño

• 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

25
Fundamentos del Diseño

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

26
Fundamentos del Diseño

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

27
Fundamentos del Diseño

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

28
Fundamentos del Diseño

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

29
Diseñ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.

30
Diseño Modular Efectivo

• 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

31
Diseño Modular Efectivo

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

32
Diseñ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.

33
Diseñ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.

34
Diseñ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.

35
Diseño Arquitectónico

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

36
Diseño Arquitectónico

• Para el desarrollo del Diseño Arquitectónico se
  recomiendan seguir los siguientes pasos
• Estructuración del sistema
• Modelado de control
• Descomposición modular

37
Diseñ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

38
Diseño Arquitectónico

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

39
Diseño Arquitectónico

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

40
Diseño Arquitectónico

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

41
Diseño Arquitectónico

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

42
Diseñ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.

43
Diseñ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

44
Diseño de Interfaces de Usuario

• 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.)

45
Diseño de Interfaces de Usuario

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

46
Diseño de Interfaces de Usuario

• 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

47
Diseño de Interfaces de Usuario

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

48
Diseño de Interfaces de Usuario

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

49
Diseño de Interfaces de Usuario

• 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

50
Diseñ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.

51
Diseño Procedimental

• 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

52
Diseño Procedimental

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

53
Documentació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

54
Documentación del Diseño

• Referencias cruzadas de requisitos
• Recursos de prueba
• Notas especiales
• Ámbito
• Objetivos
• Principales requisitos de Software
• Restricciones de Diseño y Limitaciones

55
Documentación del Diseño

• 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

56
Documentació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.

57
Documentació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.

58
Documentación del Diseño

• Recursos de prueba
• Directrices para las pruebas
• Estrategias de integración
• Consideraciones especiales
• Notas especiales
• Apéndices

59
Heurí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

60
Heurísticas del Diseño

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

61
Heurísticas del Diseño

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

62
Optimizació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.

63
Optimización del Diseño

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

64
Optimización del Diseño

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

65
Diseñ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.

66
Diseño Orientado a Objeto

• El proceso general para el diseño orientado a
  objetos tiene varias etapas
• Comprender y definir el contexto y los modos de
  utilización del sistema.
• Diseñar la arquitectura del sistema.
• Identificar los objetos principales en el sistema.

67
Diseño Orientado a Objetos

• Desarrollar los modelos de diseño.
• Especificar las interfaces de los objetos.
• No es un proceso sistematizado al 100, por lo
  que necesita refinarse con varias iteraciones.

68
Diseño Orientado a Objetos

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

69
Diseño Orientado a Objetos

• 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

70
Diseño Orientado a 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.

71
Diseño Orientado a Objetos

• 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

72
Diseñ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.

73
Mé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)

74
Métodos Orientado a Obejtos

• Objectory (Jacobson)
• Método de Coad-Yourdon
• Método UML

75
Diagramas 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.

76
Diagramas de actividades

• 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).

77
Diagrama 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.

78
Diagramas de actividades

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

79
Diagramas de actividades

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

80
Diagramas de actividades

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

81
Diagramas de Actividades
82
Diagramas 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.

83
Diagramas de clases

• 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

84
Diagramas de clases

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

85
Diagramas de clases

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

86
Diagramas de clases

• 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

87
Diagramas de clases

• 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).

88
Diagramas de clases

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

89
Diagramas 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.

90
Diagramas de clase

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

91
Diagramas de clase

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

92
Diagramas 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.

93
Diagramas de clases

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

94
Diagramas 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.

95
Diagramas de clases

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

96
Diagramas de Clases
97
Diagramas 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.

98
Diagramas de secuencia

• 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

99
Diagramas de secuencia

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

100
Diagramas de secuencia

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

101
Diagramas de secuencia

• 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

102
Diagramas de secuencia

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

103
Diagramas de Secuencia
104
Diagramas de interacció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.

105
Diagramas de colaboració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

106
Diagramas de colaboració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.

107
Diagramas de colaboración
108
Diagramas 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.

109
Diagramas de estado

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

110
Diagramas de estado

• 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

111
Diagramas de estado

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

112
Diagramas de estado

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

113
Diagramas de estado
114
Diagramas 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.

115
Diagramas 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.

116
Diagrama 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

117
Diagrama 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.

118
Preguntas, dudas y comentarios?