INGENIERÍA DE

SOFTWARE POR OBJETOS

Docente:
Luis Emilio Velásquez Restrepo
Tecnológico de Antioquia
 CONTENIDO
• Modelado con UML
• Comunicación de proyectos
• Obtención de requerimientos
• Análisis
• Diseño: de Sistema y de Objetos
• Administración de la Fundamentación
• Pruebas
• Administración de la configuración y del
proyecto
 UML
UML = Lenguaje Unificado de Modelado.

Es un lenguaje que sirve para analizar y

diseñar con el enfoque orientado a
objetos. Ofrece varios diagramas para
representar los aspectos asociados al
proyecto y al sistema. Entre ellos están:
el diagrama de Casos de uso, el de
Clases, el de Estado y el de secuencia.
 DIAGRAMA DE CASOS DE USO
Muestra los usos que cada Actor le puede
dar al sistema con unos roles bien definidos.

Uso 1

Uso 2

Actor 2
Actor 1
Uso 3

Sistema
 Son usos que agrupados
<< incluir >> conforman el otro uso
Ejemplo:
Retirar: Verifica cuenta
Consulta saldo
Hace el retiro

Se aumenta el detalle
<< Extiende >> Ejemplo:
Forma de pago: Efectivo
Cheque
Tarjeta
 Solicitar Bienes
o servicios

Iniciador Confirmar Pago Iniciador

Iniciador
Enviar Factura
Iniciador al comprador
Comprador Vendedor

Pagar Factura
<<Extiende >> Iniciador
Realizar Pagar Recargo por
Transacción saldo deudor

Sistema de
Cuentas bancarias

comprador

Casos de uso para un sistema de Pagos y Facturación que soporta el caso de uso del negocio
Ventas: Del Pedido a la Entrega. El papel de iniciador, contacto a las asociaciones, indica qué
el actor comienza el caso de uso.
 Diagrama de Clases
Representa las clases con sus atributos y métodos
asociados. También muestra las relaciones entre las
clases.

Nombre de la clase + publico

Atributos - Privado
# Protegido

Métodos
 Multiplicidad: obligatoria
PEDIDO CLIENTE
fechaRecibo 1 Nombre
prepagado * dirección
cantidad: String
precio: Dinero
Despachar () ClasificacionCredito(): String
Asociación
cierra ()
Generalización
Restricción 1
[ si Pedido cliente.clasificacion es “Pobre”,
entonces Pedido.prepagado debe ser
verdadero] Cliente Corporativo Cliente
Nombre NombreContrato Personal
del papel CalificacionCredito
limiteCredito NroTarCredito

Multiplicidad Atributos
Artículos Recuerda ()
Varios valores FactuMes (Entero)
de línea * Métodos [ callificacionCredito ( ) ==
Línea de Pedido * “Pobre”]
Representante
Cantidad: Integer Ventas
precio: Dinero 0..1
Satisfecho: Boolean Empleado
* 1 Multiplicidad
Producto opcional
 Clase

Nombre de Papel de B
la Clase Clase A Clase B
Papel de A
Nombre de la Clase

articuloTipo =: Valor Inicial

Multiplicidades
Metodo1(argumentos): Tipo de retorno
1 Estrictamente
Clase uno

Generalización * Muchos
Clase (cero o más)
Subtipo

discriminador 0..1 Opcional

Clase (cero o uno)

m..n Especificado
Subtipo 1 Subtipo 2 Clase Numéricamente
 Restricción Agregación
Clase
(Descripción de la condición)
Composición
Clase
Estereotipo
Generalización
Clase
(< nombre del Estereotipo >)
Asociación
Clase
Nota
Asociación Calificada
Comentario
Clase calificador

Navegabilidad
Objeto
Nombre del Papel
Origen Destino
Nombre objeto: Nombre Clase

Dependencia
Clase A Clase B
 Diagrama de Estado
Describe los estados por los que pasa el
sistema y el evento que hace pasar de un
estado a otro.
Inicio del estado
Estado
Fin del estado
Características Estado 1
Transición
Actividades

Estado 2
[ No se reciben todos
Los artículos / Obtiene [ Todos los artículos comprobados &&
Siguiente Artículo ] todos los Artículos disponibles ]
Comprobación Despachado
Hace / revisa Hace / inicia
Artículo s Entrega
d os lo
[ Todos los artículos o
d os, t
comprobados && algunos bi ]
reci ibles
artículos no inventariados ] s
t íc ulo ispon
[ Ar ulos d
c
[ Artículos recibidos ] artí Cancelado

Espera

Cancelado
Cancelado Entregado

Diagrama de Estados sin súper estados

 Diagrama de Secuencia
Describe los pasos o subestados por los
que pasa el sistema para obtener un
resultado o para pasar de un estado a otro,
ayuda a identificar el proceso.

En un diagrama de secuencia, un objeto se

muestra como caja en la parte superior de
una línea vertical punteada.
 DIAGRAMA DE SECUENCIA
Una Ventana Un pedido Una Línea de Un Articulo
de entrada a pedido de Inventario
pedidos
Preparar () [para cada línea de
Condición
pedido] Preparar ()
Hay Existencia =
objeto

Mensaje Iteración Revisar ()

[Hay Existencia]
Despachar () Necesita Reorden =
necesitaReorden ()
Autodelegación

[necesitaReorden]
Nuevo
regreso Un Articulo
de Reorden
[Hay Existencia]
Nuevo
Un Articulo
para entregar
creación
DIAGRAMA DE PAQUETES DIAGRAMA DE CASO DE USO
Nombre del
paquete
<< usa >>

Case 1 << extiende >>

Nombre del Case 3
proyecto Case 2

DIAGRAMA DE SECUENCIA DIAGRAMA DE EMPLAZAMIENTO

Un Objeto

crea nodo
Nuevo Objeto

Mensaje Componente 1
Autodelégacion

Regreso
Componente 2

Borra
x
 Comunicación de Proyectos
• Conocimientos de expertos en: Dominios,
Analistas, diseñadores, programadores,
Administrativos, escritores, diseñadores
gráficos, entre otros. Es muy importante
que todos se comuniquen.
• Modo de comunicación: por fechas, por
eventos.
• Mecanismos de comunicación (Canal):
Sincrónico, asincrónico.
• Revisión de los asuntos de transición
 Comunicación de Proyectos
• Definición del problema:
– Alcance
– Requerimientos: funcionales y no funcionales
– Criterios de Adaptación
• Revisión del cliente
• Inspecciones y pruebas de recorrido
• Revisiones de estado
• Lluvia de ideas
 Comunicación de Proyectos
• Lanzamiento: Poner en conocimiento
• Revisión Post Mortem: Posventa o
después de la entrega
• Peticiones de aclaraciones.
• Petición de cambio.
• Resolución de problemas.
• Discusión.
 Mecanismos de Comunicación
• Conversaciones de pasillo
• Cuestionarios y entrevistas estructuradas
• Reuniones
• Revisiones
• Groupwere en distintos lugares y al tiempo
• Correo electrónico
• Grupos de Noticias.
 Actividades de Comunicación del
Proyecto
• Identificación de las necesidades de
comunicación
• Instalación de una infraestructura
• Organización de las revisiones del cliente
y del proyecto
• Organización de reuniones de equipo
semanales
 Obtención de Requerimientos
Requerimiento: Es una característica que
debe tener el sistema o una restricción que
debe satisfacer para que sea aceptado por
el cliente.

Para obtener los requerimientos se

comunican los desarrolladores, clientes y
usuarios con el fin de determinar un nuevo
sistema.
 Obtención de Requerimientos
Especificación del sistema: Consiste en
identificar el área problema y delimitar el
alcance del proyecto; la descripción del
sistema se hace en un lenguaje natural.
Lenguaje Natural: Es el empleado para
comunicarse las personas sin usar términos
técnicos; con el fin de que pueda ser
entendido por los integrantes de un grupo
heterogéneo.
 Actividades de la Obtención de
Requerimientos
• Identificación de Actores
• Identificación de Escenarios
• Identificación de Casos de Uso
• Identificación de Relaciones entre los
casos de uso
• Identificación de requerimientos no
funcionales.
 Fuentes de Información
• Manuales
• Archivos históricos
• Documentos técnicos
• Observación
• Cuestionarios
• Conceptos de clientes o usuarios
• Informes
 Métodos de obtención de Información

•Diseño conjunto de Aplicaciones (JAD): Es

un consenso entre desarrolladores, clientes
y usuarios sobre las especificaciones del
sistema.
•Conocimiento del Análisis de Tareas (KAT):
Obtiene información observando a los
usuarios.
•Prueba de utilidad: P. de escenario, P. de
prototipo, P. de producto.
 Conceptos de la Obtención de
Requerimientos
• Requerimientos funcionales
• Requerimientos no funcionales,
pseudorequisitos y pseudorequerimientos
(suministrados por el cliente).
• Niveles de descripción
• Corrección, suficiencia, consistencia,
claridad y realismo.
• Verificabilidad y rastreabilidad
• Ingeniería a partir de cero.
 Documentación de la Obtención de
Requerimientos

Abrir incidente

<< Inicio >>

Oficial Despachador

Asignar Recursos
 Heurísticos para la Identificación
de los Objetos de Análisis
• Términos que los desarrolladores o usuarios
necesitan para comprender un caso de uso.
• Nombres recurrentes en casos de uso.
• Entidades del mundo real de las que el sistema
toma términos.
• Procesos del mundo real
• Casos de uso
• Origen o Destino de los Datos
• Interfaz
• Términos del Dominio de aplicación
 ANALISIS
• Objetos de entidad, Frontera y
Control
• Revisión de la Multiplicidad de las
asociaciones (1..1, 1..*, *..*)
• Asociaciones calificadas
• Generalización
• Diagrama de secuencia
 Actividades de Análisis
Desde Casos de uso hasta los Objetos
• Identificación de:
– Objetos de Entidad
– Objetos de Frontera
– Objetos de Control
– Asociaciones entre los Objetos
• Modelado de interacciones entre los
objetos
• Documentación del Análisis
 Actividades de Análisis
Desde Casos de uso hasta los Objetos
• Asignación de Responsables
• Comunicación acerca del Sistema
• Documentación del Análisis

INTEGRACIÓN POR EL ANÁLISIS (MODELO)

• Lluvia de ideas, satisfacción, madurez
• Aprobación del cliente
 DISEÑO
Comprende o Incluye:
• La definición de los objetos de diseño
• La descomposición del sistema en
subsistemas
• La selección de componentes hechos y
heredados
• La correspondencia entre los subsistemas
y el hardware.
 DISEÑO
• La selección de la infraestructura de
Administración de los datos persistentes.
• La selección de una política de control de
Acceso.
• La selección de un mecanismo de flujo de
control Global.
• El manejo de condiciones de frontera
Consideraciones del Diseño del Sistema

• Correspondencia entre el Hardware y el

Software.
• Coherencia
• Administración de los Datos.
• Flujo de control
• Consideraciones de Frontera
• Capas: Se divide un sistema complejo en
partes, donde cada parte es una capa.
Nivel de Abstracción en el Modelo
OSI (siete capas)
Aplicación

Presentación Formato
CORBA
OBJETO
Sesión Conexión

Transporte Mensaje

Red Paquete TCP / IP SUCKET

Vinculo marco

Físico Bit ETHERNET ALAMBRE

ENFOQUE CLIENTE / SERVIDOR

Cliente
Proyecto Clase

Datos

Main Métodos

Servidor
Cliente Servidor

Tubo = Asociación de sistemas

Filtro = Subsistema
DIAGRAMA DE DESPLIEGUE UML

Nestcape Serv Web

Servidor Web

Petición
URL
HTML

Archivo Consulta

Base de Datos
Explorer
Componente
 ADMINISTRACION DE LA
FUNDAMENTACION

• Un panorama de la fundamentación
• Conceptos de fundamentación
• Actividades de la fundamentación de
los problemas a las decisiones.
• Administración de la fundamentación.
 UN PANORAMA DE LA
FUNDAMENTACIÓN
• La fundamentación es la motivación que hay
detrás de una decisión. incluye: Problemas,
Alternativas, Criterios, Argumentación,
Decisiones.
• Niveles de captura de la fundamentación:
– Captura de fundamentación no explícita
– Reconstrucción de la fundamentación
– Captura de fundamentación
– Integración de la fundamentación
 Captura de fundamentación no
explícita.
Los recursos se gastan sólo en el
desarrollo. La documentación se enfoca
sólo en los modelos del sistema. La
información de la fundamentación está
presente únicamente en la memoria de los
desarrolladores y en los registros de
comunicación, como los mensajes de correo
electrónico, memorandos y faxes.
 Reconstrucción de la
fundamentación
Se gastan recursos en la recuperación de la
fundamentación del diseño durante el
esfuerzo de documentación. El criterio de
diseño y la motivación que está detrás de
las decisiones arquitectónicas principales se
integra con los modelos del sistema
correspondientes. Las alternativas y
argumentaciones descartadas no se
capturan en forma explícita.
 Captura de fundamentación
Se hace un gran esfuerzo en la captura de la
fundamentación conforme se toman las
decisiones, se documenta como un modelo
separado y con referencias cruzadas hacia los
demás documentos. Por ejemplo, la
motivación para el modelo de análisis de
requerimientos se captura en el Documento de
fundamentación del análisis de requerimientos
(RARD, por sus siglas en inglés),
complementando al Documento de análisis de
requerimientos (RAD, por sus siglas en
inglés).
 Captura de fundamentación

En forma similar, la motivación para el diseño

del sistema se captura en el Documento de
fundamentación del diseño del sistema
(SDRD, por sus siglas en inglés).
 Integración de la fundamentación

El modelo de fundamentación llega a ser el

modelo central que usan los desarrolladores. La
fundamentación producida durante diferentes
fases se integra en una base de información viva y
consultable. Los cambios al sistema de
información suceden primero en la base de
información como una discusión seguida por una o
más decisiones: Los modelos del sistema
representan la suma de las decisiones capturadas
en la base de información.
CONCEPTOS DE LA FUNDAMENTACIÓN
• Control de tráfico centralizado (CTC):
• Definición de la cuestión: problemas
• Exploración del espacio de solución: propuestas
• Evaluación del espacio de solución: criterios y
argumentos
• Descomposición del espacio de solución:
resoluciones
• Implementación de resoluciones: conceptos de
acción
• Ejemplos de modelos y sistemas basados en
problemas
ACTIVIDADES DE LA FUNDAMENTACIÓN:
De los Problemas a las Decisiones
• Diseño del sistema CTC (Control de Trafico
Centralizado).
• Captura de la fundamentación en las reuniones
• Captura asíncrona de la fundamentación
• Captura de la fundamentación cuando se tratan
los cambios
• Reconstrucción de las fundamentaciones
 Diseño del sistema CTC
• Disponibilidad. El sistema debe fallar menos
de una vez al mes y recobrarse por completo en
diez minutos después de una falla.
• Seguridad. Ninguna entidad que esté fuera, del
cuarto de control debe poder tener acceso al
estado de las vías controladas o manipular
ninguno de sus dispositivos.
• Usabilidad. Una vez que esté entrenado, un
despachador no debe dar más de dos
comandos erróneos al día.
 Captura de la fundamentación en las
reuniones
Las reuniones permiten que los desarrolladores
presenten, negocien y resuelvan problemas frente a
frente. La presencia física de los desarrolladores
respectivos involucrados en la discusión es
importante al añadir los beneficios de la comunicación
no verbal: permite que las personas valoren las
posiciones relativas de cada cual y los compromisos
que están dispuestos a aceptar. En forma alterna, es
difícil la negociación y toma de decisiones mediante
correo electrónico, por ejemplo, ya que pueden
suceder tergiversaciones. Por tanto, las reuniones
frente a frente son un punto de inicio natural para la
captura de la fundamentación.
Las reuniones deben ser planeadas y se documentan
en una Acta o minuta.
 Captura asíncrona de la fundamentación
Las discusiones de las reuniones se apoyan en
información del contexto. Cuando se inicia la
reunión, la mayoría de los participantes ya tienen
una cantidad considerable de información acerca del
sistema, su propósito pretendido y su diseño. El
moderador de la reunión se enfoca, por lo general,
en un pequeño conjunto de problemas que
necesitan resolverse. La minuta de esta reunión sólo
registra los problemas que están a discusión y, por
tanto, no contiene mucha o ninguna información
antecedente. Por desgracia, esta información se
pierde con el tiempo y las minutas de reunión se
hacen obsoletas con rapidez.
Reconstrucción de las fundamentaciones
Se reconstruyen en forma sistemática a partir del
modelo del sistema, el registro de comunicaciones
y la memoria de los desarrolladores. Se invierten
menos recursos durante las primeras fases del
proceso; llegando más rápido a una solución.
Además, la separación de la actividad de diseño
con respecto a la captura de la fundamentación
permite que los desarrolladores regresen y
critiquen sus diseños en forma más objetiva.

La reconstrucción de las fundamentaciones se

enfoca en la solución seleccionada y no captura las
alternativas descartadas y su discusión.
 Administración de la
Fundamentación

• Documentación de la fundamentación
• Asignación de responsabilidades
• Heurística para la comunicación acerca de
la fundamentación
• Modelado y negociación de problemas
• Estrategias para la resolución de
conflictos
1. Introducción
1.1 Propósito del documento Documentación
1.2 Objetivos del diseño de la
1.3 Definiciones, siglas y abreviaturas fundamentación
1.4 Referencias
1.5 Panorama
2. Fundamentación para la arquitectura de software actual
3. Fundamentación para la arquitectura de software
propuesta
3.1 Panorama
3.2 Fundamentación para la descomposición en subsistemas
3.3 Fundamentación para la correspondencia entre hardware
y software . 3.4 Fundamentación para la administración de
datos persistentes
3.5 Fundarnentación para el control del acceso y la seguridad
3.6 Fundarnentación para el control del software global
3.7 Fundamentación para las condiciones de frontera
Glosario
 Asignación de responsabilidades
• Secretario de actas registra la fundamentación
en las reuniones
• Editor de fundamentación recolecta y organiza
la información relacionada con la
fundamentación
• Revisor examina las fundamentaciones
capturadas por el editor de fundamentación e
identifica brechas que necesiten reconstruirse.

Si el proyecto es muy grande puede requerir grupos

de trabajo donde cada grupo puede tener su propio
secretario, editor y revisor.
 Heurística para la comunicación
acerca de la fundamentación
• Nombre los problemas en forma consistente
• Centralice los problemas
• Haga referencias cruzadas de problemas y
elementos del sistema.
• Administre el cambio (Gestión del Cambio).
La captura y estructuración de la fundamentación no
sólo mejora la comunicación acerca de la
fundamentación, sino que también facilita la
comunicación acerca de los modelos del sistema. La
integración de la fundamentación y la información del
sistema permite que los desarrolladores mantengan
en mejor forma ambos tipos de información.
Modelado y negociación de problemas
El método de negociación Harvard [Fischer et al.,
1991] aborda los puntos retirando el foco de las
posiciones. A continuación presentamos varios
puntos importantes del método Harvard redactados
desde el punto de vista del modelado de problemas:

• Separe a los desarrolladores de las propuestas

• Enfóquese en los criterios y no en las propuestas
• Tome en cuenta todos los criterios en vez de
maximizar uno solo.
Modelado y negociación de problemas
La visión del desarrollo como una negociación
responde a los aspectos sociales del desarrollo. Los
desarrolladores son personas que, además de sus
opiniones técnicas, pueden tener una perspectiva
emocional sobre soluciones diferentes. Esto puede
influir en sus relaciones con los demás
desarrolladores (y a veces interferir con ellas)
conforme se presentan los conflictos. El uso del
modelado de problemas para capturar la
fundamentación y dirigir las decisiones puede
integrar y mejorar los aspectos técnicos y sociales
del desarrollo.
 Estrategias para la resolución de
conflictos
Son posibles muchas estrategias diferentes
para la resolución de conflictos. Por ejemplo,
considere las cinco estrategias siguientes:

• La mayoría gana.
• El propietario tiene la última palabra.
• La gerencia siempre está en lo correcto.
• Los expertos siempre tienen la razón.
• El tiempo decide.
 Estrategias para la resolución de
conflictos
Las estrategias La mayoría gana y El
propietario tiene la última palabra no funcionan
bien. Ambas producen resultados
inconsistentes (multiplicidad de tomadores de
decisiones) y decisiones que no están bien
apoyadas por el resto de los participantes. Las
estrategias La gerencia siempre está en lo
correcto y Los expertos siempre tienen la
razón conducen a mejores decisiones técnicas
y a mejor consenso cuando el gerente y el
experto tienen suficiente conocimiento.
 Estrategias para la resolución de
conflictos

La estrategia El tiempo decide es una retirada,

que puede dar como resultado una costosa
repetición del trabajo.

En la práctica, primero tratamos de llegar a un

consenso, y en el caso de la falta de consenso,
recurrimos a una estrategia de experto o
gerente. Si falla la estrategia del experto o
gerente dejamos que el tiempo decida o lo
resolvemos por voto obligatorio de la mayoría.