Unidades 5 y 6

Vista previa del material en texto

Análisis de sistemas. 
Enfoques y 
herramientas
 HISTORIA DE UML
El lenguaje de modelado OO aparecieron entre
mediado de los 70 y fines de los 80
Entre los años 1989-1994 se incrementaron
entre 10 y 50 ningún método cubría sus
necesidades completamente entonces se inició
lo que se llamó las guerras de métodos.
Surgieron nuevas generaciones de métodos de
Booch, Ingeniería de software OO de Jacobsoon
(OOSE) y Técnicas de Modelado de Objeto
(OMT) Rumbaugh .
Otras fusiones fueron Coad-Yourdon.
En la primera mitad de los 90 se reconocieron
los métodos de OO de Grady Booch (Rational
Software Corporation) ,Ivar Jacobson(Objectory) 
y James Rumbaugh (General Electric) como 
los principales a nivel mundial.
Se inició el proceso de Modelado Unificado.
Muchas Organizaciones participaron de la 
definición de UML como Digital, HP, IBM, 
Rational, Texas Instruments,Unisys
,Microsoft,Oracle,etc. Se ofreció para su 
estandarización al Object Management 
Group (OMG) y para un Lenguaje estándar de 
modelado. Lográndolo en Noviembre de 1997.
 Ejemplo Caso de Estudio: Préstamo de 
libros en Biblioteca
 Modelo de Casos de Uso
El UP (Proceso Unificado) define el Modelo de Caso de Uso en la Disciplina 
Requisitos.
Artefactos:
1. Textos del Casos de Uso
2. Diagrama de Casos de Uso
3. Diagrama de Secuencia
4. Contratos 
Es recomendable definir en este momento la Frontera del sistema y los actores principales
Actor: Es algo con comportamiento, es un sistema informático, persona, departamento u organización, 
externo a nuestro sistema de estudio. Por ej. Un empleado.
1. Casos de Uso
› Definición
Mecanismo para ayudar a mantener simple y entendible el sistema para todo el personal involucrado.
Los casos de uso son requisitos funcionales que indican que hará el sistema, definen una 
promesa o contrato de la manera en la que se comportará un sistema.
Los casos de uso son documentos de textos, no son diagramas . 
› Formas de Escritura
▪ Breve : Resumen conciso de un párrafo, normalmente del escenario principal de éxito.
▪ Informal : Formato de párrafo en un estilo informal. Múltiples párrafos que comprenden varios escenarios. 
Ej.: Gestionar Devoluciones. (a dos columnas)
▪ Completo: el más elaborado. Se escriben con detalle todos los pasos y variaciones y hay secciones de 
apoyo como precondiciones y garantías de éxitos.
› Ejemplo de Casos de uso en formato Breve
Procesar Venta: Un Cliente llega a una caja con artículos para comprar. El cajero utiliza el sistema 
PDV para registrar cada artículo comprado. El sistema presenta una suma parcial y detalles de cada 
línea de venta. El cliente introduce los datos de pago, que el sistema valida y registra. El sistema 
actualiza el inventario. El cliente recibe un ticket del sistema y luego se va con los artículos.
 A 2 columnas: destaca la interacción entre actores y el 
sistema.
Actor principal:
Escenario principal de éxito:
Acción del actor (o intención) Responsabilidad del sistema
1. ___________________________
2. ___________________________
3. ___________________________ 4_____________________
5. ___________________________
6. ___________________________ 7_____________________
Extensiones
3 _____________________________
6 _____________________________
 A 2 columnas: destaca la interacción entre actores y el 
sistema.
Caso de Uso: Préstamo de libros
Actor principal: Bibliotecario
Descripción: este caso de uso comienza cuando un socio se presenta en la biblioteca
para solicitar al bibliotecario el préstamo de uno o varios libros. Luego de hacer el control
del socio y del libro, se concreta el préstamo.
Escenario principal de éxito:
Acción del actor (o intención) Responsabilidad del sistema
1. El socio solicita un libro 3. El sistema controla estado
2. El bibliotecario ingresa N° del socio
de socio
4. El bibliotecario ingresa nombre 5. El sistema verifica existencia y estado
del libro o código.
6. El bibliotecario ingresa fecha 7. El sistema calcula fecha de vencimiento y
del préstamo registra el préstamo.
El Bibliotecario repite por única vez los
pasos 4 y 6
Extensiones
2 Error: Socio inexistente o Datos incorrectos
3 .Socio inhabilitado
4. Error: Datos incorrectos
5. Libro inexistente o Libro prestado
6. Error: Datos incorrectos
 Formato Completo:
› Nombre: del Caso de Uso
› Actor principal:
› Personas involucradas: (Actores Secundarios)
› Precondiciones: (estado del sistema antes de empezar)
› Postcondiciones: (estado del sistema al finalizar)
› Escenario Principal: (Flujo Básico)
› Extensiones: (Flujos Alternativos)
› Requisitos especiales:
› Tecnologías y lista de Variaciones de Datos:
› Frecuencia:
› Cuestiones abiertas:
 A 2 columnas: destaca la interacción entre actores y el 
sistema.
Caso de Uso: Préstamo de libros
Actor principal: Bibliotecario
Personas involucradas: Socio.
Precondiciones: que existan libros y socios cargados
Postcondiciones: Préstamo generado, libro y socio actualizados
Escenario principal de éxito:
Acción del actor (o intención) Responsabilidad del sistema
1. El socio solicita un libro 3. El sistema controla estado
2. El bibliotecario ingresa N° del socio
de socio
4. El bibliotecario ingresa nombre 5. El sistema verifica existencia y estado
del libro o código.
6. El bibliotecario ingresa fecha 7. El sistema calcula fecha de vencimiento y
del préstamo registra el préstamo.
El Bibliotecario repite por única vez los
pasos 4 y 6
Extensiones
2 Error: Socio inexistente o Datos incorrectos
3 .Socio inhabilitado
4. Error: Datos incorrectos
5. Libro inexistente o Libro prestado
6. Error: Datos incorrectos
Requisitos especiales:
Tecnologías: 2 pc con equipamiento standart
Frecuencia: diario (varias veces al día)
Cuestiones abiertas: 
 Diagrama de Casos de Uso
Tiene la finalidad de ilustrar los Casos de Uso, los Actores y la 
relación entre ellos.
Caso de 
Uso 1
Caso de 
Uso 2
Caso de 
Uso N
Frontera
Actor 1
Actor M
Actor 2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
 Diagrama de Secuencia
› Definición: es un dibujo que muestra para un escenario 
específico de un caso de uso, los eventos que generan 
los actores externos, el orden y los eventos entre los 
sistemas. Todos los sistemas se tratan como cajas negras; 
los DSS destacan los eventos que cruzan los límites del 
sistema desde los actores a los sistemas.
: Actor :Sistema
Agente 
Externo
La caja puede 
encerrar un área 
de iteración Mensaje 
con 
parámetro 
Mensaje 
sin 
parámetros
Crear nueva venta ()
Introducir Artículo (ID_Artículo, cantidad)
Fin Nueva venta()
Diagrama de Secuencia
 Definición : Es una representación visual 
de las Clases conceptuales del mundo 
real, no de componentes software.
Modelo de Dominio
 Estrategias para identificar Clases Conceptuales (ideas, 
conceptos)
› Frases Nominales
› Lista de Categoría:
 Objetos
 Especificaciones de las cosas
 Lugares
 Operaciones o transacciones
 Líneas de la transacción
 Documentos
 Roles
 Reglas y Políticas
 Dependencias u oficinas 
 Sistemas informáticos EXTERNOS
 Etc.
Excepción: NO PUEDEN SER CLASES CONCEPTUALES LOS OBJETOS SOFTWARE
 Como armar un Modelo de Dominio
1. Identificar las Clases Conceptuales
2. Definir los Atributos (información que se desea recordar)
3. Establecer las asociaciones (vínculos o relaciones)
4. Incluir la cardinalidad.
 Ejemplo Caso de Estudio: Préstamo de 
libros en Biblioteca
Fuentes: UML y Patrones de Craig Larman, 
2da Edición
 Plan de desarrollo: es un artefacto de la Disciplina 
Gestión del Proyecto en el que se establece una 
clasificación de los requisitos. Ej:
Rango Requisito, Caso de Uso o 
característica
comentario
Alto Requisito N° 1: El sistema deberá solicitar 
ingreso de usuario y contraseña
Caso de Uso: Préstamo de libros
……………
Afecta la seguridad del 
sistema
Se realizan búsquedas de 
socios y libros y se procesa la 
transacción
…………..
Medio Mantenimientode cuentas de usuario
………….
Afecta la seguridad del 
sistema…….
Bajo ……. …….
 Marco de Desarrollo:
Es un artefacto de la Disciplina Entorno en el que se enumeran todos los artefactos 
seleccionados para un proyecto en particular. Ej.:
Disciplina Artefacto Inicio Elaboración
E1……En
Const.
C1……..Cn
Transición
T1……..Tn
Modelado de 
negocios
Modelo de 
Dominio
C
Requisitos Modelo de Casos 
de Uso.
Visión.
Glosario
C
C
C
R
R
R
Diseño Modelo de diseño
Modelo de Datos
C
C
R
R
Implementación Modelo de 
Implementación
C R R
Gestión del 
Proyecto
Plan de Desarrollo C R R R
Pruebas Pruebas C R
Entorno Marco de 
Desarrollo
C R