1. Ing. Carlos Avalos Ruiz 1
Tema Nro.1:
Desarrollo de sistemas
de información
“Una guía para la automatización de las funciones de la
organización para la obtención de ventajas competitivas”

2. Ing. Carlos Avalos Ruiz 2
Introducción
• El desarrollo de los sistemas de información se
basan en ciclo de vida del desarrollo del software.
• La disciplina encargada de proveer los medios
necesarios para la construcción de una software es
la ingeniería de software.
• Por ende el desarrollo de los sistemas de
información están basado en procesos de desarrollo
de software que la ingeniería de software propone.
• Para ello existen dos enfoques paradigmáticos:
estructurado y orientado a objetos.

3. Ing. Carlos Avalos Ruiz 3
La Ingeniería de Software (IS)
• La IS es una disciplina que integra métodos, herramientas y
procedimientos para el desarrollo del software de
computadoras.
• Se han propuesto varios paradigmas, entre ellos podemos
mencionar: estructurado,orientado a objetos ,sala limpia,
cliente/servidor, reutilización del software, reingeniería del
software, software asistido por computa- doras, etc.
• El software se ha convertido en el elemento clave de la
evolución de los sistemas y productos informáticos.

4. Ing. Carlos Avalos Ruiz 4
Paradigma Orientado a Objetos
• Con frecuencia se alude a la Orientación a Objetos
como un nuevo paradigma (Paradigma de Objetos) y
al término Orientado a Objeto ( OO ) como la
aplicación de este paradigma al mundo de la
computación.
• El paradigma para los programadores, es la manera
como se maneja la complejidad.
• Desde este punto de vista el paradigma es el modelo
o la estructura dentro del software solución de un
problema.

5. Ing. Carlos Avalos Ruiz 5
• Superficialmente OO significa la organización del
software como una colección de Objetos discretos
que incorpora tanto la estructura de datos como su
comportamiento.
• Para cada entidad del dominio, hay un objeto que
representa ese concepto en el modelo.
• Finalmente, OO modela mirando en alguna parte
realidad o dominio que es de interés, y busca las
abstracciones claves y las relaciones entre esas
abstracciones claves.

6. Ing. Carlos Avalos Ruiz 6
• La Orientación a Objetos se aplica a otros disciplinas
dentro del mundo de la computación, tal como se
aprecia en la siguiente ilustración :

7. Ing. Carlos Avalos Ruiz 7
En resumen la Orientación a
Objetos:
Orientado
a
objetos
abstracción
de la realidad
Conceptos
Objetos
Clases
Estructuras -
jerárquicas
Métodos/ope-
raciones/servicios
Abstracción
Encapsulamiento
Herencia
Polimorfismo
Mensaje
Identidad
Asociación
en función
y que mediante
permite manejar
la complejidad

8. Ing. Carlos Avalos Ruiz 8
Tecnología Orientada a Objetos
• La Tecnología de Objetos (TO), una de las más
recientes técnicas de desarrollo de sistemas y se basa
en la OO; cuenta con cuatro bases fundamentales :
– Análisis Orientado a Objetos (AOO).
– Diseño Orientado a Objetos (DOO).
– Programación Orientada a Objetos (POO).
– Base de Datos Orientado a Objetos (BDOO).

9. Ing. Carlos Avalos Ruiz 9
Tecnología
orientada a
objetos
Nuevos
métodos de
programación.
Nuevos
métodos de
análisis
Nuevos
métodos de
diseño
Reutilizar
el código
Mas calidad
Mas productividad
Menos costo
Situación Actual en la TOO

10. Ing. Carlos Avalos Ruiz 10
Desarrollo de la Tecnología
Orientada a Objetos
• Con el universo de métodos, se ha formado un cos-
mo dinámico con el mundo de objeto en el que un
método evoluciona en una estrella nítida u otra cesa
para ser destacado y llega a ser un gigante rojo antes
de desaparecer enteramente.
• De aquí en adelante, una organización debería prime
ra comprender completamente qué significa para pen
sar desde el punto de vista de objetos.

11. Ing. Carlos Avalos Ruiz 11
Método, Metodología y Proceso en
el desarrollo de software
• Un método es la aplicación particular de una método
logia de desarrollo de software pero que no abarca el
ciclo de vida de desarrollo de software ni cuenta con
herramientas tecnológica de soporte.
• Una metodología es una marco general basado en un
paradigma que sirve de base para el desarrollo de
software y que abarca todo el ciclo de vida.
• Un proceso de desarrollo de software esta basado en
una metodología, abarca todo el ciclo de vida y provee
herramientas tecnológica de soporte.

12. Ing. Carlos Avalos Ruiz 12
¿Problemas en el desarrollo de software?
• Retrasos en los plazos
• Proyectos cancelados
• Rápido deterioro del sistema instalado
• Tasa de defectos o fallos
• Requisitos mal comprendidos
• Cambios frecuentes en el dominio del problema
• Muchas de las interesantes características del software no
proporcionan beneficios al cliente
• Buenos programadores se cansan y dejan el equipo

13. Ing. Carlos Avalos Ruiz 13
El Modelado
• El modelado es una tecnica de ingeniería probada y
bien aceptada.
• El modelado no solo es parte de la industria de la
construcción.
• Un modelo es una abstracción del sistema,
especificando el sistema desde un cierto punto de
vista y en un determinado nivel de abstracción.
• Un modelo es una simplificacion de la realidad.

14. Ing. Carlos Avalos Ruiz 14
¿Por qué las empresas no hacen
modelado?
• La mayor parte de las empresas software no realizan
ningún modelado.
• El modelado requiere:
– aplicar un proceso de desarrollo
– formación del equipo en la técnicas
– ¿tiempo?
• ¿Se obtienen beneficios con el modelado?

15. Ing. Carlos Avalos Ruiz 15
¿Por qué modelamos?
• Los modelos :
• Ayudan a visualizar como es o queremos que sea el
sistema.
• Especifican la estructura o comportamiento de un
sistema
• Proporcionan plantilla que nos guian en la
construccion de un sistema.
• Documentan las decisiones que hemos adoptado.
Construimos modelos para comprender mejor el sistema
que estamos desarrollando.

16. Ing. Carlos Avalos Ruiz 16
Principio de Modelado
• La elección de que modelos crear tiene una profunda
influencia sobre como se define un problema y como
se da forma a una solucion.
• Todo modelo puede ser expresado a diferentes nive
les de expresion.
• Los mejores modelos están ligados a la realidad.
• Un único modelo no es suficiente.
• El modelado no es sólo para los grandes sistemas.

17. Ing. Carlos Avalos Ruiz 17
Sistema de Computo
Procesos del Negocio
Order
Item
Ship via
“El modelado captura la
parte escencial de un sistema.”
Dr. James Rumbaugh
El Modelado Visual es un
modelamiento usando
notaciones graficas
estandares
Modelado Visual

18. Ing. Carlos Avalos Ruiz 18
Arquitectura del Software
• La visualización, especificación, construcción y
documentación de un sistema con gran cantidad de
software requiere que el sistema sea visto desde
varias perspectivas.
• La arquitectura de un sistema es quizás el artefacto
mas importante que puede emplearse para manejar
estos diferentes puntos de vista y controlar el
desarrollo iterativo e incremental.

19. Ing. Carlos Avalos Ruiz 19
• La arquitectura es un conjunto de decisiones significativas
sobre:
– La organización de un sistema software.
– La selección de elementos estructurales y sus
interfaces a través de los cuales se constituye el
sistema.
– Su comportamiento, como se especifica en la
colaboraciones entre esos elementos.
– La composición de esos elementos estructurales y de
comportamiento en subsistemas progresivamente
mas grandes.
– El estilo arquitectónico que guía esta organización:
los elementos.

20. Ing. Carlos Avalos Ruiz 20
• estáticos y dinámicos y sus interfases, sus
colaboraciones y su composición.
• La arquitectura del software no tiene que ver sola
mente con la estructura y el comportamiento, sino
también con el uso, la funcionalidad, el rendimiento,
la capacidad de adaptación, la reutilización, la
capacidad de ser comprendido, las restricciones
económicas y de tecnología y los compromisos entre
alternativas, así como de los aspectos estáticos.

21. Ing. Carlos Avalos Ruiz 21
Modelado de la arquitectura de
un sistema software
Vista de Diseño Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
vocabulario
funcionalidad
ensamblado
gestión conf.
topología
entrega
distribución
instalación
Funcionamiento
escalabilidad
rendimiento
comportamiento

22. Ing. Carlos Avalos Ruiz 22
• La vista de casos de uso de un sistema comprende
los casos de uso que describen el comportamiento
del sistema tal y como es percibido por los usuarios
finales, analistas, y encargados de las pruebas.
• La vista de diseño de un sistema comprende las
clases, interfaces y colaboraciones que forman el
vocabulario del problema y las solución.
• La vista de procesos de un sistema comprende los
hilos y procesos que forman los mecanismos de
sincronización y concurrencia del sistema.

23. Ing. Carlos Avalos Ruiz 23
• La vista de implementación de un sistema compren
de los componentes y archivos que se utilizan para
ensamblar y hacer disponible el sistema físico.
• La vista de despliegue de un sistema contiene los
nodos que forman la topología hardware sobre la
que se ejecuta el sistema.
Cada una de estas cinco vistas pueden existir por si
misma, de forma que diferentes usuarios pueden
centrarse en las cuestiones de la arquitectura del
sistema que mas le interese.

24. Ing. Carlos Avalos Ruiz 24
Por qué es necesaria la
arquitectura
• Un sistema software grande y complejo requiere una
arquitectura para que los desarrolladores puedan
progresa hasta tener una visión común.
• Se necesita una arquitectura para:
– Comprender el sistema.
– Organizar el desarrollo.
– Fomentar la reutilización.
– Hacer evolucionar el sistema.

25. Ing. Carlos Avalos Ruiz 25
Unified Modeling Language (UML)
• UML es un lenguaje estandar para la visualiza cion ,
especificacion, construccion, y documenta cion de
artefactos de un sistema.
• UML combina lo mejor de :
– Modelamiento conceptual de datos (Diagrama Entidad
Relacion)
– Modelamiento del flujo de actividades.
– Modelamiento de Objetos
– Modelamiento de Componentes

26. Ing. Carlos Avalos Ruiz 26
• UML Significa Lenguaje Unificado de Modelado.
Un lenguaje de modelado es lenguaje cuyo voca
bulario y reglas se centra en la representación
conceptual y física de un sis tema.
• UML consiste en Reglas de simbología que se
aplican a cualquier tipo de modelo hecho bajo
este lenguaje.
• UML es un Lenguaje estandar para escribir
planos o modelos de software.

27. Ing. Carlos Avalos Ruiz 27
• UML tiene una sintaxis y una semántica bien
definida. La parte mas visible de UML es su
notación gráfica.
• Puede utilizarse con todos los procesos y a lo
largo del ciclo de vida del desarrollo de softwa
re, y con diferentes tecnologias de implementa
cion.
• UML puede utilizarse para:
– Visualizar el límite de un sistema y sus fun
ciones importantes.

28. Ing. Carlos Avalos Ruiz 28
– Ilustrar realizaciones de un sistema.
– Representar la estructura estática de un siste
ma .
– Modelar el comportamiento de objetos.
– Conocer la arquitectura física de la implemen
tación.
– Extender su funcionalidad con estereotipos.
• El vocabulario y las reglas de un lenguaje como
UML indican como crear y leer modelos bien for
mados, pero no dicen “que” ni “cuando” estos mo
delos se deben crear.

29. Ing. Carlos Avalos Ruiz 29
• UML es sólo un lenguaje y por lo tanto estan
sólo una parte de un método de desarrollo de
Software. UML es independiente del proceso.
• Un proceso bien definido guiará a sus usuarios
al decidir qué artefactos producir, qué activida
des y qué personal emplear para crearlo y ges
tionarlo.
• Un artefacto es una pieza de información que es
utilizada o producida por un proceso de desarro
llo de software.

30. Ing. Carlos Avalos Ruiz 30
Antecedentes de UML
• Originalmente desarrollado por Rational, Grady
Booch y James Rumbaugh.
• Posteriormente se tiene la contribución de Ivar
Jacobson.
• Esta aceptada por OMG (Object Manage ment
Group)
• UML se ha publicado en las siguientes
versiones: 0.8, 0.9, 0.91, 1.0, 1.1,1.2,1.3.......

31. Ing. Carlos Avalos Ruiz 31
Los tres amigos (y otros)
• Ivar Jacobson -- Objectory and use cases.
• Jim Rumbaugh -- OMT and UML.
• Grady Booch -- Booch Method and UML.
• Hewlett-Packard, Texas Instruments, Oracle.
• Microsoft -- Repository, visual modeling.
• Platinum -- OPEN Modeling Language.
• IBM/ObjectTime -- OCL/ROOM.

32. Ing. Carlos Avalos Ruiz 32
Contribuciones
Meyer
Before and after
conditions
Harel
Statecharts
Gamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and
message numbering
Embley
Singleton classes and
high-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE

33. Ing. Carlos Avalos Ruiz 33
Historia de UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
public
feedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1
OMG Acceptance, Nov 1997
UML 1.3
UML 1.0UML partners

34. Ing. Carlos Avalos Ruiz 34
Donde puede utilizarse UML
• UML esta pensado principalmente para sistemas de
gran cantidad de software.
• UML es apropiado para modelar desde sistemas de
información en empresas hasta aplicaciones
distribuidas basadas en Web, e incluso para sistemas
empotrados de tiempo real muy exigentes.
• UML no esta limitado al modelado de software, es lo
sufientemente expresivo para modelar sistemas que
no son software.

35. Ing. Carlos Avalos Ruiz 35
Classes
application partitioning
Business Objects
Relationships
Business Process
Objects
Use Cases
large scale system
Scenarios
Components
Microsoft
ActiveX/COM
Microsoft
ORDBMS
Oracle
CORBA
OMG
UML: Soporte para el desarrollo
de cualquier tipo de aplicaciones

36. Ing. Carlos Avalos Ruiz 36
Utilidad de UML
• Permite especificar todas las decisiones de análisis,
diseño e implementación, construyéndose modelos
precisos, no ambiguos y completos.
• UML puede conectarse a lenguajes de programación:
– Ingeniería directa e inversa
• Permite documentar todos los artefactos de un
proceso de desarrollo (requisitos, arquitectura,
pruebas, versiones,..)

37. Ing. Carlos Avalos Ruiz 37
Metamodelo UML
• ¿Cómo se expresa la semántica del modelo?
– Informalmente
– Formalmente
• El metamodelo UML define la notación de un modo
riguroso, a través de diagramas de la propia
notación y con OCL.

38. Ing. Carlos Avalos Ruiz 38
Metamodelo UML: Ejemplo
Relación
AsociaciónGeneralización
Role de
asociación
1
2..*ordered

39. Ing. Carlos Avalos Ruiz 39
Modelo Conceptual de UML
• Para comprender UML, se necesita adquirir un
modelo conceptual del lenguaje, y esto requiere
aprender tres elementos principales:
– Los bloques de construcción.
– Las reglas que dictan como se pueden combinar
estos bloques básicos.
– Algunos mecanismos comunes que se pueden
aplicar.

40. Ing. Carlos Avalos Ruiz 40
UML
Elementos
Estructural
Use case
Clases
Clases Activas
Interfaces
Componentes
Colaboraciones
Nodos
Comportamiento Agrupación Anotación
Relaciones Diagramas
Especificaciones
Adornos
Divisiones
comunes
Mecanismos
de extensión
Interacción
Maquina de
Estado
Paquete
Modelo
Subsistema
Framework
Notas
Dependencia
Asociación
Generalización
Realización
Use case
Clases
Objetos
Secuencia
Colaboraciones
Estado
Actividad
Componentes
Despliegue
Estereotipos
Valores etiquetados
Restricciones
Bloques de Construcción Reglas
Nombres
Alcance
Visibilidad
Integridad
Mecanismos
Comunes

41. Ing. Carlos Avalos Ruiz 41
Elementos del modelo conceptual
de UML
• Elementos estructurales: modelan partes estáticas y
representan cosas conceptuales y materiales, son:
Clases, una interfaz, una colaboración, un use case,
componentes y nodos.
• Elementos de comportamiento: son las partes dinámi
cas de los modelos, representan comportamiento en
el tiempo y el espacio, son: una interacción y una
máquina de estados.

42. Ing. Carlos Avalos Ruiz 42
• Elementos de agrupación: son las partes organizati
vas, el elemento de agrupación principal son los pa
quetes.
• Elementos de anotación: son las partes explícitas, se
usan para describir, clarificar o hacer observaciones,
esta es una nota

43. Ing. Carlos Avalos Ruiz 43
Elementos Estructurales
Ventana
origen
tamaño
abrir()
cerrar()
mover()
dibujar()
clase
IAvisable
<<Interface>>
IAvisable
Interface
ValidarTransacción
caso de uso
Gestor Eventos
suspender()
vaciarCola()
clase activa
Gestión Pedidos
colaboración componente
Hola
Mundo.class
Servidor
nodo

44. Ing. Carlos Avalos Ruiz 44
Elementos de Comportamiento
Interacción
Conjunto de mensajes intercambiados entre un conjunto
de objetos con un propósito particular.
mensaje
dibujar
Máquina de estados
Secuencia de estados por las que pasa un objeto durante
su vida en respuesta a eventos.
estadoactivado

45. Ing. Carlos Avalos Ruiz 45
Elementos de Agrupamiento
Modelo del Negocio Paquete
Un paquete incluye un conjunto de elementos de cualquier
naturaleza.
Tiene una naturaleza conceptual.

46. Ing. Carlos Avalos Ruiz 46
Elementos de Notación
Son las partes explicativas de los modelos UML
NotaRetorna 0 si no
existe el valor

47. Ing. Carlos Avalos Ruiz 47
Relaciones del modelo concpetual
de UML
Dependencias
Asociaciones
patrón empleado
0..1 *
Generalizaciones
Realización

48. Ing. Carlos Avalos Ruiz 48
Diagrama
Use Case
Diagrama
de
ColaboracionColaboracion
Diagrama
de
Componentes
Diagrama
de
Despliegue
Diagrama
de
Objetos
Diagrama
de
Estado
Diagrama
de
Secuencia
Diagrama
de
Clases
Diagrama
de
Actividad
Un modelo es una
descripción completa de un
sistema desde una perspectiva particular
Modelos
Modelos y Diagramas de UML

49. Ing. Carlos Avalos Ruiz 49
atributos
operaciones
dependencia
Empresa
generalización
Oficina Principal
1
1..**
0..1
clase
**
miembro
rol
11..*
{subgrupo}
asociación
administrador
restricción
multiplicidad
agregación
nombre
1..*
sitio
Empleado
Nombre: María
IDEmpleado: 2568
Cargo: Gerente
obtenerFoto(f:Foto)
obtenerSonido()
obtenerContacto()
obtenerRegistroEmpleados()
Contacto
Dirección: Pizarro 254
RegistroEmpleados
IdImpuesto
Historialempleado
sueldo/salario
Departamento
Nombre: Ventas *
Oficina
Dirección : Sucre 360
Código: 2358
*
Diagrama de Clases
• Muestra un conjunto de clases, interfaces y colabora
ciones con sus relaciones.

50. Ing. Carlos Avalos Ruiz 50
e: Empresa
objeto anónimo
valor de atributo
enlace
objeto
d1: Departamento
Nombre: “Ventas”
d2: Departamento
Nombre: “RRHH”
d3: Departamento
Nombre: “Ventas a Crédito”
p: Personal
Nombre = “Eddi”
IDEmpleado = “4356”
Cargo = “Vendedor”
: Contacto
Dirección:“Pio265”
Diagrama de Objetos
• Muestra un conjunto de objetos y sus relaciones.

51. Ing. Carlos Avalos Ruiz 51
Red celular
Usuario
actor
Emitiendo
llamadas de
conferencia
Recepcionando
llamada
adicional
Usando horario
Recibiendo
llamada
Emitiendo
llamada
Relación extendida
<<extend>>
<<extend>>
use-case
límites del sistema
Telefonía Celularasociación
Diagrama de Use Case
• Muestra un conjunto de Casos de Uso (Use Case),
actores y sus relaciones, presenta una descripción de la
conducta de un sistema para un usuario en un punto
determinado.

52. Ing. Carlos Avalos Ruiz 52
h : hilo : herramientas
p : par
a1 : ejecutar(3)
ejecutar()
<<create>>
<<destroy>>
pideIdent()
rellamada()
objeto
etiqueta de
la secuencia
mensaje
línea de vida
creacion
llamada
recursión
retorno/rspta
destrucción
enfoque de control
interacción
Diagrama de Secuencia
• Es un diagrama de interacción que resalta el orden tem
poral de los mensajes, es decir, muestra el dinamismo
de la interacción entre objetos, en función al tiempo.

53. Ing. Carlos Avalos Ruiz 53
Diagrama de Colaboraciones
• Es un diagrama de interacción que resalta el orden tem
poral de los mensajes, es decir, muestra el dinamismo
de la interacción entre objetos, en función al tiempo.
c:Cliente
:Transacción p:ODBDProxy
1: <<create>>
2: grupoAcciones(a,d,o)
3: <<destroy>>
<<global>>
2.1: grupoValores(d,3.4)
2.2: grupoValores(a,”CO”)
objeto
mensaje
enlace
<<local>>
{transitorio}
Diagrama de Colaboración

54. Ing. Carlos Avalos Ruiz 54
estado inicial
conectado
conectando
Trabajando
listo(3) [señal OK]
Inactivo
encender
apagar/reconectar()
activado/revisar()
apagado
estado final
estado
evento
acción
transición
transición interna
guardar
estado anidado
Máquina de Estado
Diagrama de Estado
• Muestra una máquina de estados, que consta de: esta
dos, transiciones, eventos y actividades. Estos diagra
mas cubren la vista dinámica del sistema. Son importan
tes para modelar el comportamiento de una interfaz, cla
se o colaboración.

55. Ing. Carlos Avalos Ruiz 55
estado inicial
Seleccionar lugar
Comisionar a arquitectos
Desarrollar plan
Ofertar plan
Fin de construcción
Trabajar el plan Negociar el plan()
:Certificado de ocupación
[terminado]
ramas de secuencia
[no aceptado]
[else]
flujo de objeto
estado de actividad
con submáquina
estado final
bifurcación concurrente
unión concurrente
estado de
la acción
Diagrama de Actividades
• Es un tipo especial de
diagrama de estado
que muestra el flujo
de actividades dentro
de un sistema. Son
especialmente impor
tantes al mode lar el
funcionamiento de un
sistema pues resaltan
el flujo de control
entre objetos.

56. Ing. Carlos Avalos Ruiz 56
hallar.exe
índice.html
hallar.html
accesoBd.dll busca.dll
<<hiperenlace>>
ejecutable
página web
librería
componente
Diagrama de Componentes
• Muestra la orga
nización y las
dependencias
entre un conjun
to de componen
tes. Presentan la
vista estática de
implementación
del sistema.

57. Ing. Carlos Avalos Ruiz 57
<<processor>>
servidor
primario
<<processor>>
servidor
<<processor>>
servidor
<<processor>>
servidor
<<network>> red local
<<processor>>
servidor de
caché
<<processor>>
servidor de
caché nodo
conexión
internet Modem
nodo
Diagrama de Despliegue
• Muestra la
configuración
de nodos de
procesamiento
en tiempo de
ejecución y los
componentes
que residen en
ellos.

58. Ing. Carlos Avalos Ruiz 58
Mecanismos comunes del modelo
conceptual de UML
• Especificaciones
– Proporcionan una base semántica para cada
elemento
– Los diagramas son proyecciones de esa base
• Adornos
– La notación gráfica básica de cada elemento puede
incluir adornos textuales o gráficos para resaltar
algunas propiedades de la especificación.

59. Ing. Carlos Avalos Ruiz 59
• Divisiones Comunes
– Dicotomía clasificador
/instancia
Persona
nombre
dirección
teléfono
Elena :
Persona
: Persona
Elena
• Divisiones Comunes
– Dicotomía interfaz /
implementación
IOrtografía
asistente
Ortográfico.dll

60. Ing. Carlos Avalos Ruiz 60
Mecanismos de extension del
modelo conceptual de UML
• Mecanismos de extensibilidad
– Estereotipos
• Extienden el vocabulario de UML, permitiendo añadir
nuevos tipos de bloques de construcción.
– Valores etiquetados
• Extienden las propiedades de un bloque de
construcción, añadiendo nueva información.

61. Ing. Carlos Avalos Ruiz 61
– Restricciones
• Extiende la semántica de un bloque, añadiendo reglas
o modificando las existentes.
Overflow
<<Exception>>
ColaEventos {version 3.2; autor: jgm}
añadir()
quitar()
vaciar()
{ordenado}
estereotipo
valor etiquetado
restricción

62. Ing. Carlos Avalos Ruiz 62
Sistema, modelo, vista, diagrama
• Un sistema es aquello que se está desarrollando y
para lo que se crean modelos.
• Un subsistema es una parte de un sistema.
• Un modelo es una abstracción de un sistema que
ayuda a comprenderlo.
• Una vista es una proyección de la estructura y
organización de un modelo del sistema, centrada en
algún aspecto.
• Un diagrama es una representación de un conjunto
de elementos.

63. Ing. Carlos Avalos Ruiz 63
Vistas UML en términos de
Elementos
Vista de Diseño
Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
clases
interfaces
colaboraciones componentes
nodosclases activas
casos de uso

64. Ing. Carlos Avalos Ruiz 64
Vistas UML en términos de
Diagramas
Vista de Diseño
Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
Diagramas de clase
Diagramas de interacción
Diagramas de estado
Diagramas de componentes
Diagrama de interacción
Diagramas de estado
Diagramas de despliegue
Diagrama de interacción
Diagramas de estado
Diagramas de casos de uso
Diagramas de clase
Diagramas de interacción
Diagramas de estado

65. Ing. Carlos Avalos Ruiz 65
Ejemplo: Hola mundo!
import Java.awt.Graphics;
class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString (“¡Hola, Mundo!”,10,10);
}
}
HolaMundo
paint()
g.drawString
("Hola, mundo”)
Abstracción de clases para hola mundo

66. Ing. Carlos Avalos Ruiz 66
Applet
HolaMundo
paint () Graphics
Object
Compone
nt
Container
Panel
Applet
HolaMun
do
ImageObserver
Clase relacionadas
Con Holamundo
Jerarquía de la
Herencia de
Hola mundo

67. Ing. Carlos Avalos Ruiz 67
java
lang
awt
Applet
HolaMundo
Organización de paquetes de Holamundo

68. Ing. Carlos Avalos Ruiz 68
:Thread :Toolkit target:HolaMundo:ComponentPeer
run
run
handleExpose paint
callbackLoop
Mecanismo para dibujar de Holamundo

69. Ing. Carlos Avalos Ruiz 69
HolaMundo.class
hello.java
hello.html
Componentes de Holamundo

70. Ing. Carlos Avalos Ruiz 70
Equipo base de
desarrollo
Pero UML no es suficiente
Unified Modeling
Language
Development
process

71. Ing. Carlos Avalos Ruiz 71
Proceso de Desarrollo de Software
• Un proceso de desarrollo de software es un conjunto
de actividades necesarias para transformar los
requisitos de un usuario en un sistema software.
Proceso de desarrollo
de software
Requisitos del
usuario
Sistema
software

72. Ing. Carlos Avalos Ruiz 72
Un Proceso Iterativo e Incremental
• Un proceso de desarrollo de software debe tener
una secuencia de hitos claramente articulados para
ser eficaz, que proporcionen a los director y al resto
del equipo del proyecto los criterios que necesitan
para autorizar el paso de una fase a la siguiente
dentro del ciclo del producto.
• Un proceso iterativo es aquel que involucra la
gestión de un flujo de ejecutables del sistema.

73. Ing. Carlos Avalos Ruiz 73
• Un proceso incremental es aquel que involucra la
continua integración de la arquitectura del sistema
para producir esos ejecutables, donde cada nuevo
ejecutable incorpora mejoras incrementales sobre
los otros.
• En conjunto, un proceso iterativo e incremental esta
dirigido por el riesgo, lo que significa que cada nueva
versión se encarga de atacar y reducir los riesgos
mas significativos para el éxito del proyecto.

74. Ing. Carlos Avalos Ruiz 74
Lo que es una Iteración
• Una iteración es un miniproyecto (un recorrido mas o
menos completo a lo largo de todos los flujos de
trabajo fundamenta) que obtiene como resultado una
versión interna.
• El resultado de una iteración es un incremento ( un in
cremento es la diferencia entre la versión interna de
una iteración y la versión interna de la siguiente).
• Los modelos evolucionan con las iteraciones
( construyen los modelos incremento por incremento).

75. Ing. Carlos Avalos Ruiz 75
Las Iteraciones sobre el ciclo de
vida
• Las iteraciones se realizan en cuatro fases.
• Cada una de las cuatro fases termina con un hito
principal.
– Inicio: Objetivos del ciclo de vida.
– Elaboración: arquitectura del ciclo de vida.
– Construcción: Funcionalidad operativa inicial.
– Transición : versión del producto

76. Ing. Carlos Avalos Ruiz 76

77. Ing. Carlos Avalos Ruiz 77
¿Por qué un Desarrollo Iterativo e
Incremental?
• Para tomar la rienda de los riesgos críticos y
significativos desde el principio.
• Para poner en marcha una arquitectura que guíe el
desarrollo del software.
• Para proporcionar un marco de trabajo que gestione
de mejor forma los inevitables cambios en los
requisitos y en otros aspectos.

78. Ing. Carlos Avalos Ruiz 78
• Para construir el sistema a lo largo del tiempo en
lugar en lugar de hacerlo de una sola vez cerca del
final, cuando el cambiar algo se ha vuelto costoso.
• Para proporcionar un proceso de desarrollo a través
del cual el personal pueda trabajar de manera mas
eficaz.
En resumen: “para obtener un software mejor”

79. Ing. Carlos Avalos Ruiz 79
Fases del Ciclo de vida
time
Inicio Elaboración Construcción Transición
• Inicial: define el alcance del proyecto y el límite del
sistema.
• Elaboración: Plan del proyecto, características, y la línea
base de la arquitectura.
• Construcción: Se construye el producto
• Transición: entrega del producto al usuario

80. Ing. Carlos Avalos Ruiz 80
Fases e Iteraciones
Una fase es el intervalo de tiempo entre dos hitos importantes del
proceso.
Una iteración es una sucesión de actividades con un plan establecido
y criterio de evaluación, mientras se va produciendo las versiones del
sistema.
Arch
Iteration
... Dev
Iteration
Dev
Iteration
... Trans
Iteration
...
Release Release Release Release Release Release Release Release
Prelim
Iteration
...
Inception Elaboration Construction TransitionElaboration Construction Transition

81. Ing. Carlos Avalos Ruiz 81
Creando el Proceso Unificado
Functional testing
Performance testing
Requirements mgmt
Conf. and change mgmt
Business engineering
Data engineering
UI design
Rational Unified Process 5.0
1998
Rational Objectory Process 4.1
1996-1997
Objectory Process 1.0-3.8
1987-1995
The Ericsson Approach
The Rational Approach UML
Unified Process
Unified Software Development Process
Iconix Unified Process
Rationa Unified Process 5.5