Desarrollo de Software

Trabajo de Campo: Gua Terica

Prof. Andrs Flores

aflores@uncoma.edu.ar
Departamento de Ciencias de la Computacin
Facultad de Economa y Administracin
Universidad Nacional del Comahue
Neuqun - Argentina
Trabajo de Campo: Gua Terica

Contenidos

Proceso Unificado con UML

Anlisis de Sistemas

Diseo de Sistemas

1
 Bibliografa
Ghezzi, et al. Fundamentals of Software Engineering. PrenticeHall, 1991
Davis Alan. Software Requirements: Objects, Functions & States. Prentice-
Hall, 1993
Roger S. Pressman. Ingeniera de Software, un enfoque prctico. Mc Graw-
Hill, 1992.
Wirfs-Brock, et al. Object-Oriented Design, Addison-Wesley, 1990
Rumbaugh, Jacobson, Booch. The Unified Modelling Language Reference
Manual. Addison-Wesley, 1999
Fowler & Scott. UML Gota a Gota. Addison-Wesley, 1997
Erikson, Penker. UML Toolkit. Wiley & Sons Inc. 1998
Gamma, Helm, Johnson, Vlissides. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, 1995
Larman. Applying UML and Patterns. Prentice-Hall PTR, 1998
Buschmann,et al.Pattern-Oriented Software Architect.: A System of
Patterns.Wiley,1996
2
 Proceso Unificado con UML

El Proceso Unificado es
Iterativo e incremental
Contempla al desarrollo como sucesivas iteraciones a partir de un
refinamiento sucesivo
La construccin es incremental, tomando como base el ciclo de
vida incremental
Manejado por Casos de Uso
La construccin comienza a partir de los casos de uso, que son los
que determinan los requerimientos que debe cumplir el sistema
Arquitectura Centrica
Los diagramas que representan distintos aspectos del sistema
confluyen en un modelo de sistema

3
 Casos de Uso

Manejan las iteraciones

Manejan el nmero de actividades de desarrollo

Creacin y validacin de la arquitectura del sistema
Definicin de los casos de test y procedimientos
Planificacin de iteraciones
Creacin de la documentacin del usuario
Despliegue del sistema

Sincronizan el contenido de los diferentes modelos

4
 Funcin vs. Forma

Casos de uso Arquitectura

Los casos de uso especifican funcin;

Arquitectura especifica forma

Los casos de uso y la arquitectura deben estar balanceados

5
Workflow de Requerimientos

Listar los requerimientos candidatos (Estado, Costo,

Prioridad, Riesgos)

Entender el contexto del sistema (Modelo de Negocios,

Modelo de Dominio)

Capturar los requerimientos funcionales (Casos de Uso)

Capturar los requerimientos no-funcionales

(Propiedades del Sistema)

6
 Contexto del Sistema: Modelo de Dominio

Un Modelo de Dominio captura los tipos ms importantes en

el contexto del sistema. Representa las cosas que existen o
eventos que ocurren en el entorno donde el sistema trabaja.

Tipos de Clases de Dominio:

Objetos de Negocios que representan cosas que son manipuladas
en un negocio (ordenes, cuentas, contratos)
Objetos y Conceptos del Mundo Real que el sistema necesita
tener en cuenta (enemigos de aviones, misiles, trayectoria)
Eventos que ocurriran o han ocurrido (llegada/salida de avin,
lunch break)

Se describe mediante Diagramas de Clases

7
 Modelo de Dominio: Ejemplo

El sistema usar Internet para enviar ordenes, facturas, pagos

entre compradores y vendedores. El sistema ayuda a los
compradores a preparar sus ordenes, el vendedor evalua las
ordenes y envia los recibos, y el comprador valida los recibos y
efecta el pago desde la cuenta del comprador a la del vendedor.
Una orden indica un nmero de items. Cada item ocupa una
lnea en la orden. Una orden tiene atributos como fecha y
direccin del comprador.
Una factura tiene atributos como cantidad, fecha de emisin y
ultima fecha de pago. Puede ser el documento para el pago de
multiples ordenes.
Una factura se paga por trasferencia bancaria. La cuenta tiene
atributos como saldo y dueo.
8
 Modelo de Dominio: Ejemplo - Diagrama

Orden Item
1..*
fecha emisin descripcin
direccin costo
1..*

paga

comprador
Factura Cuenta
1
cantidad vendedor saldo
fecha emisin 1 dueo
ultima fecha pago

9
 Contexto del Sistema: Modelo de Negocios

Un Modelo de Negocios describe el proceso de negocios de la

compaa en trminos de casos de uso y actores de negocio que
corresponden respectivamente a procesos de negocios y clientes.
Presenta un sistema (el negocio) desde la perspectiva de uso y
muestra cmo provee valores a los usuarios (clientes y partners)

Proceso de desarrollo:
1. Preparar un modelo de casos de uso de negocio que identifica
los actores del negocio y los casos de uso usados por ellos.
2. Desarrollar un modelo de objetos de dominio consistente de
empleados, entidades de negocio, y unidades de trabajo que
juntas realizan los casos de uso de negocio. Con estos objetos
se asocian reglas de negocio y otras regulaciones.
10
 Modelo de Negocios: Ejemplo - Diagrama

Comprador Manejador Vendedor

de Pago

factura_a_pagar
comprador
vendedor

Cuenta Factura

11
 Modelo de Casos de Uso
El Modelo de Casos de Uso describe al sistema como un
conjunto de actores y casos de uso y las relaciones entre ellos.
Describe lo que el sistema hace para cada tipo de usuario
(actores).

Actores:
Cada sistema externo con el que se interacta se representa por uno
o ms actorres. stos colaboran con el sistema.
Una vez identificados los actores externos, hemos identificado el
entorno externo del sistema.
Actores son trabajadores de un negocio. Cada rol (de un trabajador)
define qu hace el trabajador en un proceso particular.
Los roles permiten derivar los roles que el actor del sistema jugar.
12
 Modelo de Casos de Uso

Un Caso de Uso especifica una secuencia de acciones, incluyendo

alternativas de la secuencia, que el sistema puede realizar,
interactuando con los actores del sistema. Especifca el
comportamiento de las cosas dinamicas que ocurren en el
sistema.
Secuencia tipo:
1. Se inicia la instancia del caso de uso y pasa al estado de
comienzo
2. Es invocada por un mensaje externo de un actor
3. Pasa a otro estado al realizar un secuencia de acciones. Ej:
clculos internos, seleccin de camino, envo mensaje a actor.
4. Espera (en nuevo estado) otro mensaje de un actor.
5. Se repite desde 2.
13
 Modelo Casos de Uso: Ejemplo - Diagrama

Solicitar Bienes
o Servicios

iniciador Confirmar
Orden
iniciador

Comprador Vendedor
Facturar iniciador
iniciador al Comprador

Pagar
Factura
Sistema de
Cuentas
14
 Modelo de Casos de Uso - Desarrollo
Pasos de Construccin
Encontrar los Actores
Encontrar los Casos de Uso
Describir brevemente casa Caso de Uso
Describir el modelo de casos de uso como un todo (incluye
preparar un glosario de trminos)
Encontrar Actores y Casos de Uso para:
Delimitar el sistema de su entorno
Mostrar quin y qu (actores) interacta con el sistema, y qu
funcionalidad (casos de uso) es esperada del sistema.
Capturar y definir en un glosario los trminos comunes lo que es
esencial para crear descripciones detalladas de la funcionalidad del
sistema.
15
 Modelo de Casos de Uso - Actores

Encontrar Actores
Identificar al menos un usuario que se tome como actor
candidato. Nos ayuda a encontrar slo actores relevantes y evitar
aquellos que hemos creado en nuestra mente.
Debera haber el mnimo de superposicin entre roles de
diferentes instancias de los actores. No queremos dos o ms
actores con el mismo rol.
Si es as tratar de combinar los roles en un conjunto simple
para un actor; tratar de encontrar un actor genrico que tiene
asignado los roles comunes. Ej. Comprador y Vendedor pueden
ser especializaciones de un actor Cliente_de_Banco.
Asignar nombres relevantes a los actores.
16
 Modelo de Casos de Uso Casos de Uso
Encontrar Casos de Uso
Un caso de uso es sugerido por cada rol de cada trabajador que
participa en la realizacin de un caso de uso de negocios y quin
usar la informacin del sistema.
Se analiza por cada actor qu casos de uso necesita para soportar
su trabajo. Para crear, cambiar, mantener, eliminar, o estudiar
objetos de negocios.
Algunos casos de uso candidatos pueden ser partes de otros casos
de uso. Intentamos crear casos de uso que sean fciles de modificar,
revisar, testear, y manejar como una unidad.
Elegimos un nombre que nos haga pensar acerca de esa particular
secuencia de acciones que aportan significado a un actor.
Nombre: Verbo + Sustantivo
17
 Modelo Casos de Uso: Ejemplo - Descripcin

Descripcin Inicial del Caso de Uso: Pagar Factura

Breve Descripcin
El caso de uso Pagar Factura es usado por un Comprador para planear los pagos de
facturas. Luego el caso de uso efecta el pago en la fecha establecida.
Descripcin Inicial Paso-a-Paso
Antes que este caso de uso sea iniciado, el Comprador ya ha recibido una factura
(enviada por otro caso de uso: Facturar Comprador) y ha recibido los bienes o
servicios solicitados:

1. El Comprador estudia la factura a pagar y chequea que sea consistente

con la orden original.
2. El Comprador planea el pago de la factura por medio del banco.
3. En la fecha de pago, el sistema chequea el saldo de la cuenta del
Comprador. Si es suficiente, se realiza la transaccin.
18
 Modelos de Casos de Uso - Formalizacin

Adems de Diagramas de Casos de Uso se puede especificar ms

detalle de los casos de uso mediante otros diagramas UML.

Diagramas de Transicin de Estados, se pueden usar para

describir los estados del caso de uso y las transiciones entre
esos estados.
Diagramas de Actividad, para describir las transiciones
entre los estados en mayor detalle como secuencia de
acciones.
Diagramas de Interaccin, para describir cmo una
instancia de un caso de uso interacta con una instancia de
un actor.
19
 Diagrama de Transicin de Estados

Diagrama de
Transicin de
Estados para el Verificacin
Caso de Uso:
Pagar Factura planificar
rechazar

Planificacin
de Facturas

pagar en fecha

Factura Factura
Pagada Cancelada

20
 Mtodo de Diseo OO
Ciclo de vida Orientado a Objetos
Mayor duracin de la etapa de diseo (foco en reuso)
Menor duracin global

El diseo genera:
un sistema compuesto por objetos que cumple con los requerimientos,
una descripcin del comportamiento de los objetos,
y los patrones de comunicacin entre objetos.

El diseo orientado a objetos es el proceso por el cual los

requerimientos se traducen a una especificacin detallada de objetos.
Esta especificacin incluye una descripcin de roles y
responsabilidades de cada objeto y su forma de comunicacin.
21
 Mtodo de DOO (cont.)

El proceso consiste en:

Encontrar las clases
Determinar las operaciones y estructura de cada clase
Determinar la forma de colaboracin entre objetos

El diseo produce:
(1) una lista de clases de la aplicacin
(2) una descripcin de la estructura y de las operaciones
que son responsabilidad de una clase, y
(3) una descripcin de la colaboracin entre clases

Dependiendo de la complejidad, una

aplicacin puede dividirse en subsistemas.

22
 Mtodo DOO - Responsabilidades
Las responsabilidades incluyen: el conocimiento que mantiene un
objeto, y las acciones que debe hacer el objeto.

Identificar Especificacin de requerimientos

responsabilidades: Clases candidatas

Relaciones is-kind-of
Examinar relaciones Relaciones is-analogous-to
entre clases: Relaciones is-part-of

Dificultades Clases faltantes

comunes: Asignacin arbitraria

23
 Mtodo DOO - Colaboraciones
Colaboracin: interaccin en la que un objeto requiere un servicio
de otro objeto.

Encontrar colaboraciones
Para cada responsabilidad de cada clase:
Puede esa clase cumplir con su responsabilidad
por s misma?
Si no, qu necesita?
De qu otras clases puede adquirir lo que necesita?
Para cada clase:
Qu hace o registra esa clase?
Qu otras clases necesitan el resultado o informacin?
Si una clase no tiene interacciones con otras,
debera ser descartada.

24
 Mtodo DOO - Colaboraciones y Contratos
Examinar relaciones
relacin is-part-of

relacin has-knowledge-of

relacin depends-upon

Contrato: lista de requerimientos que un cliente puede solicitar a

un servidor.
requerimiento

cliente servidor
contrato

25
 Mtodo DOO - Jerarquas
Construir Jerarquas
Modele la jerarqua clase-de
Factorice responsabilidades comunes lo ms alto posible
Verifique que las clases abstractas no hereden de clases
concretas
Elimine clases que no agreguen funcionalidad

Las clases abstractas pueden disearse:

suministrando una implementacin funcional
completa del comportamiento que capturan,
suministrando un marco (template) para el
comportamiento que ser definido por las subclases.
Las clases concretas heredan el comportamiento desde sus superclases
abstractas y pueden agregar habilidades propias (extienden la interface).

26
 Mtodo DOO - Jerarquas (cont.)
Identificar contratos
Agrupar responsabilidades relacionadas
Cada responsabilidad ser parte de un contrato,
pero no todas las responsabilidades sern
asignadas
Responsabilidades privadas y pblicas
Cohesin de responsabilidades
Guas
Agrupar responsabilidades usadas por
los mismos clientes
Maximizar la cohesin de una clase
Minimizar la cantidad de contratos

27
 Mtodo DOO Tipos de Clases
La construccin del diseo del sistema debe basarse en una
clasificacin de las entidades participantes:
Interface de Bases de Datos: Efectuar registros y consultas.
Interface de Usuario: Presentar y Solicitar informacin al user.
Dispositivos: Manejar los dispositivos de interaccin con el user.
Transacciones: Poseen la lgica de la aplicacin especfica.
System: Transaccin especial. Inicia las transacciones del sistema.
El control dentro de la
Dispositivos aplicacin es asignado a
las entidades de transaccn.
I.U. Las I.U no poseen
inteligencia para acceder
System Transacciones datos de la BD.
El usuario es solo un actor,
I.B.D. no posee el control.
28
 Mtodo DOO Arquitectura
Visin vertical de la clasificacin de entidades: Arquitectura de tres
niveles (consideramos solamente las mas importantes).

El usuario se comunica con las funciones

de la aplicacin a travs la I.U.
Las I.U. claramente no pueden acceder
al nivel de I.B.D. (no se aplica compresin).

I.U. Correspondencia:

Transacciones
I.U Presentacin
Transacciones Dominio de la
I.B.D. Aplicacin
I.B.D Dominio de Negocios
BD

29
 Diagramas UML - Vista Esttica - Clases
Etapa de Anlisis: se utilizan los diagramas de Casos de Uso, Clases, Secuencias,
Transicin de Estados, etc..
El diagrama de Clases es usado para describir las Dominio de Negocios.
Etapa de Diseo: se refina este diagrama y se agregan las clases de Presentacin y
Aplicacin. El resto de los diagramas ayudan a describir el nivel de Aplicacin.

Diagrama de Clases: Describe los tipos de objetos que hay en el sistema y las diversas
clases de relaciones estticas que existen entre ellos. Tambin muestra el estado (atributos)
y operaciones (comportamiento) de una clase y las restricciones a que se ven sujetos, segn
la forma en que se conecten los objetos.

Restriccion: Cliente Pers.

(si Pedido.cliente.calificacionCredito Pedido Cliente #tarjeta
es pobre, entonces Pedido.prepagado fechaRecibido * 1 nombre
debe ser verdadero) prepagado direccion
1
Despacha() CalificacionCredito()
articulos
Cierra() Cliente Corp.
de linea *
nombreContacto
LineaPedido calificacionCredito
0..1 *
cantidad: Integer * 1 Empleado FacturacionMes()
Producto representante
precio: Dinero
satisfecho: Boolean ventas

30
 UML Diagrama de Clases (cont.)
Dos tipos principales de relaciones estticas:
Asociacin: relacin entre instancias de clases (ej. Una persona trabaja para una
empresa; una empresa tiene cierta cantidad de oficinas).
Herencia: relacin de generalizacin (hacia arriba) o especializacin (hacia abajo).
(ej. Cliente: clase general. Cliente Corporativo y Cliente Personal: clases especficas
Subclases).

Dos relaciones estticas ms (casos especiales de la asociacin):

Agregacin: relacin que clasifica elementos.
Genero Persona
(ej. Gnero: Masculino, Femenino. Las personas
estn clasificadas por el gnero). Las partes pueden
sobrevivir a quien agrega.
Composicin: relacin Todo-Partes. Las partes Rueda
Genero
conforman el Todo y sin las partes el Todo desaparece. Motor
El ciclo de vida de las partes depende del Todo.
(ej. Auto: compuesto por ruedas, chasis, ventanas, motor, etc.)
31
 UML - Vista de Interaccin
Los objetos interactan para implementar un comportamiento. La vista de Interaccin
provee una visin holstica del comportamiento de los objetos.

Colaboracin: Es una descripcin de una coleccin de objetos que interactan para

implementar algn comportamiento. Describe una sociedad de objetos cooperativos
ensamblados para desarrollar algn propsito. Contiene slots (huecos) que son
llenados por objetos y enlaces en tiempo de ejecucin. Los slots son identificados
como roles porque describen el propsito de un objeto o enlace dentro de una
colaboracin. Roles de Clases Roles de Asociacin.
La Vista Esttica describe las propiedades inherentes de una clase.
Ej. Un Vehculo tiene un Dueo.
Una colaboracin describe las propiedades que una instancia de una clase tiene porque
juega un rol particular en una colaboracin. Ej. Un vehiculo_Alquiler en una
colaboracin AlquilarAuto tiene un conductor_Alquiler, algo que no es relevante al
Vehiculo en general pero es una parte esencial de la colaboracin.

Interaccin: Es un conjunto de mensajes dentro de una colaboracin que son

intercambiados por los roles clasificadores a travs de los roles de asociacin.
32
 UML - Vista de Interaccin - Secuencias
Interaccin como un diagrama en dos dimensiones. La dimensin vertical es el tiempo
y la dimensin horizontal muestra los roles que identifican objetos individuales.

33
 UML - Vista de Interaccin - Colaboraciones
Un diagrama de colaboraciones es un diagrama de clases que contiene roles (de clases
y asociaciones). Estos describen la configuracin de objetos y los enlaces que pueden
establecerse cuando se ejecuta una instancia de la colaboracin.

Los enlaces pueden estar marcados para indicar que son temporarios (parameter,
local) o que llaman al mismo objeto (self).

34
 Vista de Interaccin - Colaboraciones (cont.)
Es til clasificar los objetos en cuatro grupos: (1) los que existen durante toda la
interaccin; (2) aquellos creados durante la interaccin ([new]); (3) aquellos eliminados
durante la interaccin ({destroyed}); y (4) aquellos creados y eliminados durante la
interaccin ({transient}).
Cada mensaje tiene un
nmero de secuencia, una
lista de mensajes
predecesores (opcional), una
condicin de ejecucin
(opcional), un nombre y una
lista de argumentos y el
nombre de un valor de
retorno (opcional).

El nmero de secuencia incluye el nombre de la ejecucin (opcional). Todos los

mensajes en la misma ejecucin se ordenan secuencialmente. Los mensajes en distintas
ejecuciones son concurrentes si no se indican otras dependencias.
35
 Vista de Interaccin - Colaboraciones (cont.)
En general, un diagrama tiene un smbolo para cada objeto durante la ejecucin. Sin
embargo, un objeto puede tener distintos estados que deben ser explcitos. Por ej., un
objeto puede cambiar sus ubicaciones o asociaciones en el tiempo.
Los smbolos de objeto que representan al mismo objeto pueden conectarse usando
flujos de conversin (become) que representan transiciones de un estado al otro o
una migracin de un lugar a otro.
Menos comn es el estereotipo copy que muestra el valor de un objeto producido
copiando el valor de otro objeto.

36
 Vista de Interaccin - Colaboraciones (cont.)
Los diagramas de interaccin y los diagramas de colaboraciones enfatizan aspectos
diferentes: los primeros muestran en forma clara las secuencias de tiempo mientras
que los diagramas de colaboracin muestran las relaciones entre objetos y las
secuencias se obtienen de los nmeros.

37