SEMINARIO DE INGENIERÍA DE

SOFTWARE
1 MCC Sergio Fuenlabrada Velázquez
MSI Edna Martha Miranda Chávez
EL MODELADO

MSI. Edna Martha Miranda Chávez

 OBJETIVOS DEL SISTEMA

Un objetivo claro responde a todas estas preguntas:

¿Por qué?, ¿Para qué?, ¿Dónde? ¿Cuándo?, ¿Qué?,
¿Cómo?
Los ingenieros en sistemas
Deben contestan las preguntas
¿Por qué?, ¿Para qué?, ¿Dónde? Y
¿Qué?
No les corresponde contestar la Los ingenieros de software
pregunta ¿Cómo? Deben contestan las preguntas
¿Qué?, ¿Cómo?, ¿Cuándo?
Deben tener muy claro el
¿Por qué?, ¿Para qué? 3
 Control de
cambios

Administración Administración
del riesgo de la
planeación

Establecimiento Control
de la
Metodología Administración
Pertinencia, relevancia,
de proyectos
congruencia, vigencia, Diseño y
suficiencia, viabilidad desarrollo de Funcionalidad, fiabilidad,
viabilidad, eficiencia,
Establecimiento Ingeniería de software mantenibilidad, portabilidad
de funciones del
software
sistemas Ingeniería de
(vista del software
elemento)
Establecimiento
Estudio del de la estrategia
entorno Técnicas, métodos y de construcción
herramientas
(Vista global)
Estudio del
negocio Desarrollo del
software
(Vista de dominio)
(vista detallada) 4
DIAGRAMAS DE UML

Los diagramas se desarrollan conforme

se va profundizando en la información
y el conocimiento del sistema a
desarrollar

Su principal función es el detallar el

¿Qué?, ¿Cómo? y ¿Dónde?

5
MODELADO

El modelado o modelización, es una técnica

cognitiva que consiste en crear una representación
de “un algo”, a través del uso de un código (el cual
puede hacer uso de un lenguaje, imágenes,
símbolos, expresiones matemáticas, etc.).

Teniendo la característica de que el código empleado

es comprendido por todas las personas
relacionadas.

La representación es el resultado de una

abstracción.
6
MODELADO
 Proporciona detalles de forma consistente
con el nivel de abstracción, mostrando sólo
aquellos valores de atributos que sean
esenciales para su comprensión.

 No es tan minimalista que deje de

informar al lector sobre la semántica
importante.

7
 MODELADO
 Un modelo al ser una abstracción de “un
algo”, representa los detalles esenciales
(importantes) de ese “algo”.

 La abstracción tiene como resultado:

 Un refinamiento
 Establece los detalles esenciales
(importantes) de “ese algo”.
 Ignora las cosas que no son esenciales
(no importantes) de ese “algo”.
8
MODELADO
Su objetivo es:
 Facilitar el entendimiento entre las personas
 Unifican el lenguaje
 Facilitar la comprensión
 Facilitar la comunicación
 Ya que pueden hacer uso de imágenes, graficas,
formulas, etc., y esto permite la rápida
transmisión de datos e información
 Pueden ser usados para establecer
comportamientos futuros
 Establece el funcionamiento

9
MODELADO

Los modelos son la representación de

“algo” y ese algo puede ser:

• La realidad
• Ideas Procesos

• Cosas Rich-Picture

• Objetos
• Procesos
• Comportamientos
• Arte
• Economía Ejecutables
• Etc. Prototipos 10
EL CONTENIDO DE LOS
MODELOS
(DESDE EL PUNTO DE VISTA INFORMÁTICO)

Los modelos se pueden utilizar para representar información

referente a:
 Una elemento individual, o un conjunto de elementos
 Interrelaciones o interacción entre ellos.
 Características estáticas (no cambiantes en el tiempo) o
dinámicas (cambiantes en el tiempo).
 Conjunto de elementos interrelacionados o interactuando
entre si.
 Puntos de vista simples o complejos de un elemento.
 Implementaciones diferentes del mismo elemento.
11
CONFECCIÓN DE MODELOS

Los modelos pueden ser confeccionados

de diferentes formas:

 Sepuede hacer uso de un tipo de

modelado.

O Mezclar dos o más tipos de

modelados para la representación.

12
GENERACIÓN DE MODELOS
MÚLTIPLES
El objetivo de crear múltiples modelos estriba en que:

 El generar múltiples modelos para representar un elemento, permite

un mejor entendimiento y un mayor nivel de abstracción (nivel de
detalle).

 Cada modelo debe revelar alguna información que no revelan los

demás modelos. Un modelo puede mostrar algún detalle que otro
modelo no muestra o que es incapaz de mostrar

 El desarrollo de varios modelos de un mismo elemento, permite que en

conjunto se revele (muestre) progresivamente mayor detalle sobre ese
elemento, y por lo tanto incrementa la comprensión y en su caso
facilita la construcción.

Los múltiples modelos deben ser consistentes entre ellos. La terminología

utilizada debe ser consistente a través de todos ellos. Ejemplo: la
misma entidad debe tener el mismo nombre en todos los modelos.

13
 Comparativo entre
la orientación a la estructura y
la orientación a objetos

14
ORIENTACIÓN A LA ESTRUCTURA

• Los procesos interactúan para realizar un

trabajo, se basa en la teoría de control que
da origen a la jerarquía.

• De hecho, cuando un sistema estructurado

falla normalmente se debe a que no se
contemplan todos los procesos que debe
efectuar el sistema, o las excepciones o se
rompe la conexión entre los sub-niveles.
15
ORIENTACIÓN A OBJETOS

• Los objetos inactúan para realizar un

trabajo, se basa en el trabajo colaborativo,
la independencia de funciones y el rehúso
de código.

 De hecho, cuando un sistema orientado a

objetos, falla normalmente no suele ser por
un fallo en la lógica, sino porque se
rompen conexiones entre objetos o por un
estado no válido en objetos individuales. 16
 Informática y computación

LA ORIENTACIÓN ESTA RELACIONADA CON

EL LENGUAJE DE PROGRAMACIÓN
Lenguaje de programación

•Imperativo - Ensamblador
•Tradicional – 1era, 2da, 3era, y 4ta. Generación
Orientación a •Funcional – Acceso a BD
la estructura •Lógico - Inteligencia artificial - tiende a ser
estructurado
•Visual – Visual Basic 4 - Puede ser estructurado

Orientació • Visual – Visual Basic 7 – Puede utilizar

n a objetos objetos
• Orientado a Eventos – Utiliza objetos 17
• Orientado a objetos - Java
 VENTAJAS Y DEBILIDADES DE LA
ORIENTACIÓN ESTRUCTURADA

Ventajas:
• Es fácil de desarrollar e implementar cuando se cuenta con un
ambiente estable.
• Útil en desarrollo de software sencillos

Desventajas:
• No existe la reutilización de código
• El programado debe llevar en control conforme navega en los
diferentes niveles del sistema
• No es fácil la comunicación entre sistemas (envió y recepción de
información)
• Los lenguajes de programación que utilizan esta orientación tienden
al desuso (y por lo tanto, tienden a ser obsoletos, con excepción de los
18
lenguajes Ensamblado y C ).
 VENTAJAS DE LA
ORIENTACIÓN A OBJETOS

 Es una tendencia tecnológica

 Reduce la “brecha semántica” entre la realidad y los
modelos
 Hace que el sistema sea más fácil de entender

 Permite modificaciones locales de los modelos

 Permite modificaciones locales en el software

 Permite el manejo del cambio

 Promueve la reutilización

 Asegura la continuidad de la representación

19
DEBILIDADES DE LA
ORIENTACIÓN A OBJETOS

 La reutilización a gran escala aún es pobre.

 Existen pocas bibliotecas reutilizables.
 La administración de las bibliotecas reutilizables es un
problema debido a la falta de estandarización.
 Se requiere un entrenamiento del personal antes de
que se pueda implantar.

20
MODELADO
Informática y computación

Diferencias entre modelado

orientado a la estructura y
orientado a objetos

21
 Diferencias entre modelado
estructurado y orientado a objetos

Estructurado Orientado a Objetos

Enfoque:
• Jerárquico
- Muestra las relaciones
entre los niveles
- Conforme se
profundiza en los
niveles existe mayor
refinamiento
• Desarrollo descendente y
modular
• Desarrollo en etapas o
fases
Enfoque:
• Objetos = instancia =
Atributos + Operaciones
(método)
• Los objetos tienen
características de:
– Identidad
– Independencia
– Abstracción
– Encapsulamiento
– Herencia
– Polimorfismo
– Persistencia y concurrencia
22
• Se ocultan los detalles
 Ejemplo de diferentes diagramas de la orientación
estructurada y la de objetos
Estructurado Orientado a Objetos
Diagramas de Modelado de Datos -- Modelado estructural - Estático
Data Model Diagrams (DMD)- o • Clases
Diagramas de procesos • Objetos
• Diagrama conceptual del sistema • Componentes
• Diagrama de flujo de datos • Nodos / Despliegue
• Diagrama de Contexto • Paquetes
• Diagrama de bloque (Top-Down,
bloques) Modelado de Comportamiento - Dinámico
• Diagrama de Warnier – Orr • Casos de Uso (general y detallado)
Diagramas de Estructura de Datos -- • Secuencia
Data Structured Diagrams (DSD)- • Tiempo
• Diccionario de Datos • Comunicación / colaboración
• Diagrama de Entidad – Relación • Estados
Diagrama Lógico de Estructuras de • Actividad
Datos (Logical Data Structure
Diagrams –(LSD)
• Diagrama BD
• Diagrama de flujo de datos y su
23
relación con la BD
 Modelado
Orientado a la
Estructura

24
 Diagramas de la orientación estructurada que se
siguen utilizando
Estructurado Orientado a Objetos
Diagramas de Modelado de Datos -- Modelado estructural - Estático
Data Model Diagrams (DMD)- o Clases
Diagramas de procesos Objetos
• Diagrama conceptual del sistema Componentes
• Diagrama de flujo de datos Nodos /Despliegue
• Diagrama de Contexto Paquetes
• Diagrama de bloque (Top-Down,
bloques) Modelado de Comportamiento -
• Diagrama de Warnier – Orr Dinámico
Diagramas de Estructura de Datos -- Casos de Uso (general y detallado)
Data Structured Diagrams (DSD)- Secuencia
• Diccionario de Datos Tiempo
• Diagrama de Entidad – Relación Comunicación / colaboración
Diagrama Lógico de Estructuras de Estados
Datos (Logical Data Structure Actividad
Diagrams –(LSD)
• Diagrama BD
• Diagrama de flujo de datos y la
25
relación a BD
Diagramas de flujo de datos

 Describe los flujos de datos y los procesos que

cambian o transforman esos datos.

 Muestra las interfaces, componentes y fuentes

externas.

 Establece las bases de los diagramas: de contexto,

conceptual del producto, de procesos y detallados del
producto.

 Presenta secuencia, orden, procesos y manipulación

de datos.
26
SIMBOLOGÍA
CHRIS GANE Y THISH SARSON
Proceso
Se identifica con
una sola palabra,
frase u oración
sencilla.

Flujo de datos
Movimiento de
información

Archivo/Deposito
de información

27
SIMBOLOGÍA
YOUDON Y DE MARCO

Proceso Flujo de
datos

Entidad
Archivo Externa

28
Reglas
De la diagramación de flujos de datos
(DFD)
 El modelando es parte de la documentación del
sistema.

 Hay que identificar aquellas instancias que son

necesarias y suficientes para visualizar,
especificar, el problema y construir la solución.

 Hay que mostrar los valores que pueden tomar los

atributos necesarios y suficientes para modelar el
problema.

 Hay que representar las instancias y sus

relaciones 29
 Reglas
De la diagramación de flujos de datos
(DFD)
 Al los elementos hay que asígnales un nombre que comunique
su propósito.
 Hay que distribuir los elementos para minimizar los cruces de
líneas
 Hay que organizar los elementos espacialmente, de modo que
los que estén cercanos semánticamente y operacionalmente
también lo estén físicamente
 Hay que usar todo aquello que ayude a clarificar su
comprensión, desarrollo e implantación, como son: notas,
colores, señales visuales, etc.
 Hay que incluir todas las relaciones y comunicación entre los
elementos
 El diagrama debe contribuir a establecer y expresar el propósito
del sistema
30
DIAGRAMAS DE TRANSICIÓN DE ESTADO

Estado
Estado en el que se puede encontrar el
producto. Conjunto de circunstancias o atributos
que caracterizan a un momento dado.
Ejemplo: Reposo, Esperando una respuesta,
Procesando, etcétera

Cambio de estado
Muestra la secuencia entre los estados, Cambio
de un estado a otro estado

Acción que Condiciones y acciones

provoca el Condiciones que provocan un cambio de
cambio de estado, y acciones que el producto ejecuta
estado
cuando se da el cambio de estado.
31
DIAGRAMAS HVE
HISTORIA DE VIDA DE ENTIDADES

• Describen como se crean, modifican y eliminan las entidades en un

producto (a lo largo de la vida de este).
• Se utilizan para detallar aun más el proceso o para identificar datos
que nunca se modifican, se utilizan o consultan, para que estos se
puedan eliminar.

Proceso,
Dato o Actividad ó
Transacción Decisión

Borrar Dato o
Proceso o Transacción
Actividad
32
 DIAGRAMAS DE CAJAS

Representa el diseño procedimental

• Secuencia - Conecta dos cajas seguidas.
• Condición - Divide una caja siendo una parte el Then (sí) y la otra
parte el Else (no)
• Repetición - Encierra el proceso que ha de repetirse.
• Selección - Caja que tiene varias partes del proceso (partes que
intervienen)

Condición del Bucle Caso de condición

Primera Condición
F T 
Tarea Valor Valor
Parte
Segunda Repeat- Parte
Parte Parte 
Tarea Parte Parte until del
Do- del
Else Then While caso caso
Siguiente
Tarea +1 Condición del Bucle
33
Secuencia Condición Repetición Selección
Evolución del diagrama de flujo de datos --- Rich Picture

Representación
de relaciones 34
 Rich Picture Representación de procesos y secuencia

3. Solicita la
generación o
2. Solicita la actualización del
Jefatura de Carrera generación o programa de
Academias
de Ciencias de la actualización estudio
Academias Grupo de
Informática del programa
Academias Profesores
de estudio
de Computación
1. Establece las estrategias
académicas con base en el 4. Generan el
mapa curricular programa de
8. Entrega a la 7. Verifica que este estudio
Jefatura correcto el programa utilizando Word
9. Recibe el programa de estudio, de estudio 6. Entrega a la
lo revisa y si está de acuerdo con academia
5. Verifica que
las estrategias académicas, es 13. Distribuye a esté correcto
actual, esta completo, etc., lo profesores
aprueba.

10. Lleva a cabo el proceso para la 12. Distribuye a las

autorización del programa de academias y a
estudio por parte de la escuela material didáctico 14. Vende programas de
de nivel superior y después de la estudio a los alumnos
DEP
Alumnos
11. Una vez autorizado el programa Material
de estudio distribuye a las
Didáctico
academias y a material didáctico
35

Proceso de generación de programas de estudio

Rich Picture - Representación de secuencia de procesos

36
Rich Picture - Representación de ideas (análisis)

37
Rich Picture - Representación de infraestructura

38
 Modelado
Orientado a Objeto

39
 Proceso de Desarrollo de Software Orientado a Objetos

Rational Unified Process (RUP)

FASES E HITOS (MILESTONES)

Inicio Elaboració Construcción Transición

n
Inception Elaboration Construction Transition

Objetivos Arquitectura Capacidad Release

(Visión) Operacional del Producto
Inicial

Tiempo
40
 Ejemplo de diferentes diagramas de la orientación
estructurada y la de objetos
Estructurado Orientado a Objetos
Diagramas de Modelado de Datos -- Modelado estructural - Estático
Data Model Diagrams (DMD)- o • Clases
Diagramas de procesos • Objetos
• Diagrama conceptual del sistema
• Diagrama de flujo de datos • Componentes
• Diagrama de Contexto • Nodos / Despliegue
• Diagrama de bloque (Top-Down, • Paquetes
bloques)
• Diagrama de Warnier – Orr Modelado de Comportamiento -
Diagramas de Estructura de Datos -- Dinámico
Data Structured Diagrams (DSD)- • Casos de Uso (general y detallado)
• Diccionario de Datos • Secuencia
• Diagrama de Entidad – Relación
Diagrama Lógico de Estructuras de • Tiempo
Datos (Logical Data Structure • Comunicación / colaboración
Diagrams –(LSD) • Estados
• Diagrama BD
• Diagrama de flujo de datos y su • Actividad
41
relación con la BD
 DIAGRAMAS DE UML
Los diagramas expresan gráficamente partes del sistema

Use Case Use Case State

Use Case Use Case
Diagrama State
Diagrama Diagramas
Diagrama de Diagrama
Diagramas
Diagramas
Diagrama de Casos de Uso Diagrama de State
State
Secuencia Clases Diagrama
Diagramas
Diagrama de
Objetos

Escenario
Escenario
Diagrama
Diagramas
Diagrama de State
Colaboración State
Diagrama
Diagramas
Diagrams de
Componentes
Modelo
Escenario
Escenario
Diagrama
Diagramas
Diagrama de State
nodos State
Diagrama
Diagramas
Diagrama de
Escenario Paquetes
Escenario
Diagrama
Diagramas
Diagrama de Component
Estados Component
Diagrama
Diagramas de Diagramas
Diagrama de
Actividad Tiempo
42
 Diagramas de orientación a objetos
Orientado a Objetos
Modelado estructural – Estático - Representa
Clases - Los datos que entran al sistema, su almacenamiento y la emisión, interfaces
y colaboraciones
Objetos - Objetos
Componentes – Componentes de los objetos, estructura compuesta – estructura interna
Nodos - Muestra el hardware que esta instalado e interactúa con el sistema
Paquetes – Muestra la interrelación entre los paquetes del sistema
Modelado de Comportamiento - Dinámico
Casos de Uso – Muestra los servicios o funciones que ofrece al entorno. Muestra el
comportamiento del sistema -- Como se establecerá el dialogo entre el usuario y
el sistema
Secuencia Describe las operaciones y datos que procesa, almacena o generan los objetos.
Así como la secuencia de ejecución de los objetos (envió de mensajes).
Tiempo – Los objetos se ejecutan a todo lo largo del sistema, en este se muestra el tiempo
que pasa para que se ejecute el objeto y el tiempo que dura su ejecución
(interacción del usuario con el sistema).
Comunicación/colaboración – Representan el envío y recepción de mensajes entre los
objetos
Estados – Estados de los objetos, cambio del sistema cuando ocurre un evento
43
Actividad - Flujo de actividades en el sistema
 Recordatorio

DIAGRAMAS DE UML

Los diagramas se desarrollan

conforme se va profundizando en
la información y el conocimiento
del sistema a desarrollar

Su principal función es el detallar

el ¿Qué?, ¿Cómo? y ¿Dónde?
44
 FASES VS. DESARROLLO DE MODELOS
Definición de
requerimientos
Modelo de casos de uso
Casos de uso
D
e
Diagrama de clases
s (primera versión)
c Clases Casos de uso
Análisis (+ descripciones)
u
b Diagrama de clases
r (+ paquetes)
i Clases
m Diagrama de secuencias
i Secuencia de las
e Diseño Diagrama de estado operaciones
n Estados de las
Diagrama operaciones
t
o de clases
Clases
Definición de la interfaz 1 Atributos
Asociaciones 45
Definición de la interfaz
2
Complejidad de proyectos

CONSTRUCCIÓN
Proceso simple
DE UNA CASA
PARA “FIDO” Bajo Impacto, bajo riesgo

Puede hacerlo una sola

persona

Requiere:
Modelado mínimo
Herramientas simples

46
Complejidad de proyectos

Proceso complejo
CONSTRUCCIÓN Requiere un proceso bien definido
DE UNA CASA
Impacto medio, riesgo medio

Personal razonable, un equipo

Requiere:
Modelado
Herramientas más sofisticadas
Construcción eficientemente y en
un tiempo
47
 Complejidad de proyectos

Proceso muy complejo CONSTRUCCIÓN

Requiere un proceso bien definido DE UN
Alto Impacto, Altos riesgos RASCACIELOS

Personal varios equipos de trabajo

Requiere:
Modelado exhaustivo
Herramientas muy sofisticadas
Control de la construcción para
asegurar robustez, eficiencia, diseño,
eficacia en el uso de recursos
(materiales, tiempo, etc.), etc. 48
 Complejidad de proyectos

¿Y LA CONSTRUCCIÓN DE UN ¿Y la construcción
PUENTE? de un presa?

49
 I. Introducción: Modelado de SW

MV PARA MANEJAR LA COMPLEJIDAD

50
DIAGRAMAS DE UML

La siguiente descripción se establece

haciendo uso de imágenes escaneadas del
Libro UML, de los Autores Grady Booch,
James Rumbaugh, Ivan Jacobson (creadores
de RUP e UML) editorial Prentice
Hall/Adisson Wesley
Los diagramas se describen por la relación
que hay entre ellos, no en el orden lógico que
se tendrían que desarrollar.
51
 UML

“Con UML se construyen modelos a partir de bloques

de construcción básicos, tales como clases, interfases,
colaboraciones componentes, nodos, dependencias,
generalizaciones y asociaciones.

Como ningún sistema complejo puede ser

comprendido completamente desde una única
perspectiva, UML define varios diagramas que
permiten centrarse en diferentes aspectos del sistema
independientemente”

G. Booch, J Rumbaugh, I Jacobson

52
 UML
“Aunque no hay nada que impida que se coloquen
elementos de modelado de categorías totalmente
dispares en el mismo diagrama, lo mas normal es que
casi todos los elementos de modelado de un diagrama
sean de los mismos tipos. De hecho, los diagramas
definidos en UML se denominan según el elemento que
aparece en ellos la mayoría de las veces.

En un mismo diagrama se pueden representar cualquier

combinación de elementos de UML, por ejemplo se
pueden mostrar clases y objetos (algo frecuente) o incluso
se pueden mostrar clases y componentes en el mismo
diagrama (algo legal, pero menos frecuente)”

G. Booch, J Rumbaugh, I Jacobson

53
Simbología - Taxonómia
Los modelos utilizan simbología para describir características y
comportamiento del sistema.
UML identifica a esta simbología como clasificadores

54
Simbología - Taxonómia Base de datos

55
Simbología - Taxonómia

Esto permite describir al sistema desde una perspectiva sencilla hasta el

nivel más detallado (avanzado)

56
ESTEREOTIPOS

“Un estereotipo se extiende el vocabulario de UML, permitiendo

crear nuevos tipos de bloques de construcción que derivan de
los existentes pero que son específicos a un problema y los
lenguaje de programación”

G. Booch, J Rumbaugh, I Jacobson

Envía
Arranca
Lanza
Alumnos:
Nombre
“exception” Calificación
Alumnos – cambio Alta ()
escuela Baja ( )
Cambio ( )

include,
extend
57
Artefactos
Es una palabra que hace referencia a “algo” en el desarrollo del
sistema.
Información utilizada o producida en el desarrollo del sistema.
Los artefactos pueden ser diagramas, modelos, elementos, software,
etc.

58
Representación de asociaciones,
enlaces y conectores

59
Conectores
Los componentes
representan al software.
Un componente
representa un fragmento
del software, por lo tanto
se puede descomponer un
objeto en componentes.

Un conector establece las

interfaces de comunicación
entre el software.
Quien envía información y
quien recibe dicha información
(puertos)

60
COMENTARIOS - NOTAS
Su función es la dar mayor claridad al diagrama,
pueden contener: descripciones más detalladas,
clarificaciones, observaciones, o cualquier
comentario que ayude a dar claridad al diagrama.

Se pueden colocar en cualquier diagrama y lugar

61
EXTENSIBILIDAD DE LA SEMÁNTICA
“Extiende la semántica de UML … permitiendo
añadir nuevas reglas o modificar las existentes,
para la construcción de un modelo …. esto para que
permita indicar específicamente la operación ”

G. Booch, J Rumbaugh, I Jacobson

Autor: Juan
Alumnos:
Versión: 3.2
Nombre
Calificación
“exception”
Alumnos – cambio
escuela Alta ()
{ordered}
Baja ( )
Cambio ( )

62
 Combinación de diagramas

DIAGRAMA DE ESTADO / ACTIVIDAD

63
 Combinación de diagramas

DIAGRAMA DE ESTADOS / CLASE / NOTAS

alta baja

número_préstamos = 0
sin préstamos

Socio
número : int
nombre : char[50]
número_prestamos : int = 0
prestar devolver[ número_préstamos = 1 ]
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date) número_préstamos > 0

con préstamos

prestar

devolver[ número_préstamos > 1 ]

64
DIAGRAMA DE ACTIVIDAD

65
 Representación del funcionamiento de un sistema

REPRESENTACIÓN DE UN ALGORITMO

DFD
Diagrama de actividad
66
DIAGRAMA DE ACTIVIDAD
Es una evolución del diagrama de flujo (similar al DFD)

Sí se utiliza en la primera fase de desarrollo del

software ayuda a describir los procesos actuales del
sistema (análisis del problema).

Sí se utiliza en las últimas fases de desarrollo del

software, muestra el flujo de operación que lleva un
procedimiento interno (método).
Es complemento al diagrama de estados, detalla las
transacciones que provocan los cambios de estado, las
validaciones de datos, recuperación ante errores, etc.

67
 Se reemplaza Reservación

DIAGRAMA DE ACTIVIDAD
Aplicación
Pasajero Vendedor Web Airline

Solicitar pasaje
Verificar
existencia vuelo

Dar detalles vuelo

Informar alternativas
y precios
Seleccionar vuelo

Solicitar pago Reservar plazas

Confirmar
Pagar pasaje
plaza reservada

Emitir boleto Emitir reserva

68
69
 Maquina de preparación
de café

DIAGRAMA DE ACTIVIDAD /ESTADOS

70
DIAGRAMA DE CASOS DE USO

71
 Actores
DIAGRAMA DE CASO DE USO • Primarios
• Secundario

Representa las transacciones que efectuará el sistema, y los

actores que intervienen

BD

72
DIAGRAMA DE CASOS DE USO
Aerolínea

73
SENTENCIA INCLUDE Y EXTEND

74
DIAGRAMA DE
CASOS DE USO
DETALLADO

75
DIAGRAMA DE CASOS DE USO DETALLADO

76
DIAGRAMA DE SECUENCIA / INTERACCIÓN

77
Diagrama de Secuencia /
Interacción
Representa la parte dinámica del sistema
Representa los elementos del sistema y su comportamiento

78
Diagrama de Secuencia /
Interacción
Representa la parte dinámica del sistema
Representa los elementos del sistema y su comportamiento

79
 DIAGRAMA DE SECUENCIA
alta:Inventario

Ventana de
entrada menuPedido: altaPedido:
de pedidos
prepara( )
*[para cada línea
de pedido] prepara( )
Hay existencia:=revisa( ) Condición

Objeto
Mensaje [hay existencia]
Necesita Reorden:
descuenta( )
=necesita Reordenar ( )
No hay
producto Autodelegación

Pedido
registrado

80
 Mercado Libre

REALIZA
ACTUALIZA
MENU PEDIDO
CONTABILIDAD

81
DIAGRAMA GENERAL DEL SISTEMA

Figura 3. Diagrama general de secuencia del sistema ……

 El diagrama general del sistema debe mostrar todos los procesos

del sistema
 Observa que hasta el final se encuentra la base de datos.
DIAGRAMA GENERAL DEL SISTEMA

Figura 3. Diagrama general de secuencia del sistema ……

DIAGRAMA DE TIEMPO / SECUENCIA

84
Diagrama de Tiempo

Representa el tiempo que tarda un objeto en cambiar de

estado

85
Diagrama de tiempo / secuencia

86
Diagrama de secuencia y
comunicación (entre objetos)

87
 ¿Por qué esta mal este diagrama
de secuencia?

 Los procesos deben

iniciar con verbo por lo
que los nombres titulo,
ejemplar no queda claro
que actividad realizan
(se despliega, se
Observa entrega) ?
 Observe: Una vez que
llega a la línea de vida
del proceso ahí se
queda. ¿y luego que
pasa?

 Observa tiene las acciones de encontrar, crear. Pero ¿en donde crea, en donde encuentra?.
Es importante que al final se encuentre la base de datos o archivos, etc.
DIAGRAMA DE CLASES

89
Diagrama de Clase - Elementos

Dominio

90
DIAGRAMA DE CLASE

El diagrama de
clase se convertirá
en el diagrama de
estructura de la
Base de datos

91
DIAGRAMA DE CLASE

Diagrama de Clases

92
Diagrama Base de Datos
 Object.Java
DIAGRAMA DE CLASES

Atributos

Metodos
Funciones Relaciones

93
DIAGRAMA DE ENTIDAD – RELACIÓN
(BASE DE DATOS)

94
SIMBOLOGÍA DE RELACIONES EN BD

95
SIMBOLOGÍA DE RELACIONES EN BD

96
 DIAGRAMA DE BASE DE DATOS
Observa:

Atributos Que en la Base de Datos sólo

se muestran los objetos de
datos (las clases de datos)
Relaciones Relaciones
No aparecen los objetos de
código

97
 DIAGRAMA DE BASE DE DATOS

Atributos

Funciones o
Métodos

Relaciones

98
EJEMPLO DE DIAGRAMACIÓN DEL
PROYECTO

Diagrama de
Diagrama de Base de Datos
clases

99
 DIAGRAMA DE CLASES
(REPRESENTACIÓN DE LA GENERALIZACIÓN Y AGREGACIÓN)

Lámpara
1 1 1 1

Base Cubierta Switch Cableado

LámparaFluorescente LámparaIncandescente

1 1 1
1

1 1 1 1

Balastra MonturaDeRosca Arrancador Sócket

100
DIAGRAMA DE OBJETOS

101
OBJETOS

Los objetos prestan servicios,

Están conformados de método
y clase (atributos).
Se activan por medio de
mensajes
Por lo tanto un objeto puede
tener varios estados:
En espera, activo, etc.

102
Diagrama de vida de un objeto

Objeto
- Creación
- Proceso
- Muerte

103
Diagrama de estructura de objetos

Representa a
los objetos
que
intervienen
en el logro de
un objetivo.

104
Diagrama de flujo de control de objetos

105
DIAGRAMA DE ESTADOS

106
Eventos

Para que un objeto cambie de estado se requiere un

evento, este genera una transición de estados de un
objeto.

107
DIAGRAMA DE TRANSICIÓN DE
ESTADOS

Muestra la transición de los estados de un objeto. Eventos que

provocan en cambio de estado del objeto. Permite visualizar el
comportamiento de los objetos.

108
Diagrama de estados

109
Diagrama de estados

110
EJEMPLO DE DIAGRAMACIÓN DEL
PROYECTO

111
ALTA DE DATOS EN UNA APLICACIÓN

112
 Diagrama de comunicación

Representa la
comunicación
entre los
objetos para
el logro de un
objetivo.

113
DIAGRAMA DE COMUNICACIÓN Y
COLABORACIÓN

114
 Diagrama de comunicación

Representa la
comunicación
entre los objetos
para el logro de
un objetivo.

Comunicación:
• Síncrona
• Asíncrona

115
DIAGRAMA DE COLABORACIÓN

116
DIAGRAMA DE COLABORACIÓN

117
DIAGRAMA DE COLABORACIÓN

118
Diagrama de
colaboración
e iteración

Colaboración
para el logro
del objetivo e
interacción
(repetición)
de un proceso.

119
Diagrama de Paquetes

120
 Nombre de
paquete

PAQUETES
 Representación la agrupación de subsistemas (modelos o sub-
modelos)

 Una clase puede aparecer en otro paquete por la importación o

envió de atributos

 Un paquete encapsula elementos, por lo tanto pueden o no ser

visibles esos elementos (objetos, clases, etc.).

 Un paquete puede contener otros paquetes, sin límite de

anidamiento pero cada elemento pertenece a un sólo paquete

121
DIAGRAMA DE PAQUETES
Su objetivo es la representación generalizada de un grupo de elementos

122
DIAGRAMA DE COMPONENTES

123
 Recordatorio

DIAGRAMA COMPONENTES
Muestra la dependencia de distintos fragmentos del software, puede
ser a nivel objeto

Control y Análisis
Interfaz de Terminal
Comment
Comment

Gestión de Cuentas Acceso a BD

Rutinas de Coneccion
Comment Comment Comment

124
Comunicación entre Componentes

125
 Diagrama de Componentes

Puede hacerse la
representación a
nivel muy general o
muy detallado

126
 Diagrama de componentes

Puede hacerse la
representación a
nivel muy general
o muy detallado

127
Diagrama de componente Singular

Puede hacerse la
representación a
nivel muy general
o muy detallado

128
Diagrama de Nodos / despliegue

129
Diagrama de nodos / despliegue

Un nodo es hardware, normalmente se utiliza para la

representación del funcionamiento del sistema cuando este se
ejecuta en una red de computadoras, y su función es mostrar que
elementos de software se encuentran instalado y se ejecutan en que
nodo.

130
Diagrama de nodos / conexiones
Representa la conexión física entre los nodo (hardware) y el
software que se encuentran instalado y se ejecutan en cada nodo.

131
 DIAGRAMA DE NODOS / DESPLIEGUE
Representa la configuración del hardware y el software en
el momento de la ejecución
Servidor Central Control y Anál isi s

Acceso a BD Comment

Comment

Rutinas de Coneccion

Puede hacerse la Comment

representación a
nivel muy
general o muy T ermi nal de Consulta

detallado
Interfaz de T erminal
Rutinas de Coneccion
Comment Comment

Punto de Venta
Rutinas de Coneccion
Comment

Gestión de Cuentas Interfaz de T erminal

Comment Comment

132
Diagrama de Desarrollo
Representa los artefactos a generar en el desarrollo del sistema

Puede hacerse la
representación a
nivel muy
general o muy
detallado

133
 DISEÑO DE SOFTWARE
134 Errores clásico
 Errores clásicos

 Bajo control de calidad: error accidental

Encuentre y corrija los defectos cuando aparezcan por vez primera

y sean fáciles de controlar

Bajo control de calidad 135

 Errores clásicos

 En promedio, los requerimientos cambian

mensualmente entre el 1% y 4%
 La velocidad del cambio de requerimientos
se controla de 3 formas
 Seleccione los requerimientos “reales” Ya,
parale
 Limite el número de cambios
 Diseñe e implemente cada cambio

Requerimientos progresivos
136
 Errores clásicos

 Problemas:
 Encuentran fascinante la nueva tecnología
 Quieren probar nuevas formas (aunque
dudosas) de crear programas
 Improvisan sobre la marcha
 No diseñan ni documentan sus técnicas

Síndrome del “puede-lo-todo”

137
 Errores clásicos

 Perdida de tiempo al no tener

definidos las entradas y salidas del
sistema
 El líder aprueba los retrasos de
desarrollo (consecuencia de una
mala planeación)
 Cuando sucede los anterior se
vuelve a repetir el mismo error

“Estira-y-afloja” en la etapa de definición

138
 ERRORES CLÁSICOS

 Unaplaneación Hay, mamita

optimista
 en promedio se retrasa
el 220%
 No considera los
tiempos de coordinación
ni de corrección
 genera presión en el
personal al estar
desarrollando
No me interesa que los expertos digan que el
proyecto no puede ser realizado en menos de 6
meses.
¡Lo necesito en 4!

Planeación excesivamente optimista y no realista

139
 Errores clásicos

 Crear una lista de <<malos hábitos>>

 Iniciar con la lista que aparece en seguida

 Incrementar la lista según la terminación de

proyectos
 Aprender de los errores cometidos por el
equipo de trabajo
 Intercambiar experiencias con colegas

 Exhibir la lista en un lugar visible

A continuación el
Resumen de errores
clásicos 140
Errores relacionados con Errores relacionados con Errores relacionados con Errores relacionados con
personas el proceso el producto la tecnología
1. Motivación débil 14. Planificación 28. Exceso de 33. Síndrome del
2. Personal mediocre excesivamente requerimientos “puedelo-todo”
3. Empleados optimista 29. Cambio de 34. Sobrestimación de
problemáticos 15. Gestión de riesgos requerimientos las ventajas del
incontrolables insuficiente 30. Desarrolladores empleo de nuevas
4. Hazañas 16. Fallos de los meticulosos herramientas o
5. Sumar más personal a contratados 31. “Estira-y-afloja” en métodos
un proyecto 17. Planificación la negociación 35. Cambiar de
retrasado insuficiente 32. Desarrollo herramientas a
6. Oficinas repletas y 18. Abandono de la orientado a la mitad del proyecto
ruidosas planificación bajo investigación 36. Falta de control
7. Fricciones entre los presión automático del
clientes y los 19. Perdida de tiempo código fuente
desarrolladores en la etapa de
8. Expectativas poco definición
realistas 20. Escatimar en las
9. Falta de un promotor actividades iniciales
efectivo del proyecto 21. Diseño inadecuado
10. Falta de participación 22. Escatimar en el
de los implicados control de calidad
11. Falta de participación 23. Control insuficiente
del usuario de la directiva
12. Políticas antes que 24. Convergencia
desarrollo prematura o
13. Ilusiones excesivamente
frecuente
25. Omitir tareas
necesarias en la
estimación
26. Planificar ponerse al Resumen de errores clásicos
día más adelante 141
27. Programación a
destajo
 Errores clásicos

Reflexión
Mucho ojo

Para que el proyecto falle

142