s03-modelo de analisis 2014
DESCRIPTION
Ads IITRANSCRIPT
27/10/2014
1
MODELO DE ANALISISContenidos
Pasos previos - Introducción
El análisis en el ciclo de vida
Artefactos
Flujo de Trabajo
1
II APORTE
MODELO DE ANALISISContenidos
Pasos previos - Introducción
El análisis en el ciclo de vida
Artefactos
Flujo de Trabajo
2
PASOS PREVIOS - INTRODUCCIÓN
3
27/10/2014
2
4
WORK FLOW DE REQUISITOS
Descripción en tres
pasos:
•Artefactos a
desarrollar
•Trabajadores que
participan y
•El flujo de trabajo
Pieza de
información
producida por un
proceso del RUP
Secuencia de
actividades a
Realizar
Personal
especializado
5
ARTEFACTOS
Analista de Sistemas
Arquitecto
Especificador CU
Diseñador de Interfaz de usuario
Modelo de Negocio
Modelo de Dominio
Glosario
Caso de Uso
Prototipo de Interfaz de
Usuario
Descripción de la
Arquitectura
TRABAJADORES
n
6
27/10/2014
3
EJEMPLOSCaso Práctico: Documento de Requisitos7
Requisitos, Antecedentes, Objetivos y Alcance
Los requisitos iniciales se han obtenido directamente del cliente y usuario final.
Se desea desarrollar una aplicación para dar soporte a la matriculación de los alumnos de unauniversidad.
La aplicación debe dar soporte a las siguientes funcionalidades:
- Un alumno puede matricularse de curso completo o de asignaturas sueltas.
- Cada alumno se matricula para una asignatura en concreto en un grupo en concreto, durante unperiodo académico concreto.
- Un profesor imparte una asignatura en un grupo
- La aplicación debe incorporar la gestión de profesores, es decir, añadir un nuevo profesor, borrarloo modificar sus datos.
- La aplicación debe permitir al administrador inscribir alumnos en la universidad.
- Entendemos por inscripción crear su expediente, es decir, un alumno puede tener expediente perono estar matriculado.
- Si el alumno se matricula de curso completo elegirá grupo y cursará todas las asignaturas en esemismo grupo.
- También debe ser posible modificar el expediente de un alumno y en casos especiales borrarlo.
- Todas las operaciones de borrado se realizan únicamente a nivel lógico.
- La aplicación debe permitir al administrador crear nuevos grupos y también borrarlos.
- La aplicación también debe dar soporte a la gestión de asignaturas, es decir, añadir, borrar ymodificar.
- El administrador también debe poder asignar un profesor a un grupo para una asignaturaconcreta.
- La aplicación funcionará en pc’s con windows 95 y pocos recursos.
- La aplicación debe funcionar con un esquema cliente servidor, central.
- El sistema desarrollado debe ser lo más estándard posible.
- Los alumnos se validarán para usar el sistema introduciendo su login y password en formulario.
8
Página –
9–
CASO PRÁCTICO: CASOS DE USO (VISTA PARCIAL)
27/10/2014
4
CASO PRÁCTICO: DESCRIPCIÓN DE UN CASO
DE USO
Descripción de Casos de Uso
Número: 001
Nombre de Caso de Uso: “Matricular Asignaturas Sueltas”
Actor(es): Alumno
Descripción
Proceso que sigue un alumno a la hora de matricular una o varias asignaturas sueltas.
Flujo de Eventos
- Entrada en el sistema
- Selección de las asignaturas que desea
- Realizar matrícula
Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso.
Pre-Condiciones: Haber realizado un login exitoso en la aplicación. 10
Página –
11–
CASO PRÁCTICO: DESCRIPCIÓN DE UN CASO
DE USO
Descripción de Casos de Uso
Número: 002
Nombre de Caso de Uso: “Logín”
Actor(es): Alumno
Descripción
Proceso que sigue un alumno para entrar en el sistema.
Flujo de Eventos
- Introducir el nombre de usuario
- Introducir la password
- Realizar Login
Requerimientos Especiales: El actor no puede ser un alumno de nuevo ingreso.
Pre-Condiciones: N/A.
P
á
g
i
n
a
–
1
2
–
CASO PRÁCTICO: PROTOTIPO DE LA INTERFAZ DE
USUARIO
Caso de Uso Hacer
Matrícula
27/10/2014
5
P
á
g
i
n
a
–
1
3
–
CASO PRÁCTICO: PROTOTIPO DE LA INTERFAZ DE
USUARIO
Actividad: Login
MODELO DE ANALISIS14
15
27/10/2014
6
ANÁLISIS
Descripción
de la
arquitectura
Realización
caso de uso
-Análisis
Clase
del
análisis
Arquitecto
Modelo
de
análisis
Paquete
del
análisis
Ingeniero de
componentesIngeniero de
casos de uso
16
ANÁLISIS - ARTEFACTOS
Modelo de análisis
Modelo de análisis Sistema de
análisis
1 *
*
Realización caso
de uso -Análisis
Clase del
análisis
Paquete del
análisis
* * *
*
17
ACTIVIDADES
Las actividades que se realizan para elaborar el
modelo de análisis son los siguientes:
1. Análisis de la Arquitectura
2. Análisis de Casos de Uso
3. Análisis de Clases
4. Análisis de Paquetes.
18
27/10/2014
7
1. ANÁLISIS DE LA ARQUITECTURA
El Análisis de la Arquitectura se realiza como
sigue:
Identificación de los paquetes de análisis
Definición de las dependencias entre los paquetes de
análisis
Identificación de clases de entidad obvias por cada
paquete de análisis
Identificación de mecanismos de análisis
Identificación de las características fundamentales de
un requisito especial.
19
20
21
27/10/2014
8
Página 22
MODELO DE ANÁLISIS A PARTIR DE CASOS DE USO
Crece incrementalmente
Se especifican a través de diagramas de clases yde colaboración
Al principio se examinan unos pocos casos de usoy se crean sus realizaciones
Cada clasificador puede participar en variasrealizaciones distintas con distintos roles
Clases estereotipadas de análisis (entorno(interfaz), control y entidad)
EJEMPLO – CASO CAJERO
AUTOMATICO
23
Págin
a –
24–
Sacar dinero
Modelo de
casos de uso
Modelo de
análisis
«trace»Sacar dinero
CuentaRetirada
efectivo
Interfaz
cajero
Salida
Realización de un caso de uso (Modelo de análisis):
27/10/2014
9
Página - 25
Cliente del
banco
Sacar dinero
Ingresar dinero
Transferencia
Modelo de
casos de uso
Modelo de
análisis
Retirada
efectivo
Salida
Cliente del
banco
Cuenta
Págin
a –
26–
:Retirada
efectivo
:Salida
:Cliente
del banco
:Interfaz
cajero
:Cuenta
1:Identificación
5: entrega dinero
2: solicitar retirada
4: autorizar entrega
3: validar y retirar
Diagrama de colaboración para describir una realización:
Página - 27
Cliente del
banco
Sacar dinero
Ingresar dinero
Transferencia
Modelo de
casos de uso
Modelo de
análisis
Retirada
efectivo
Salida
Cliente del
banco
Transferencia
IngresoReceptor
dinero
CuentaInterfaz
cajero
27/10/2014
10
PAQUETES DE ANALISIS28
IDENTIFICACIÓN DE PAQUETES DE
ANÁLISIS
Entre las asignaciones adecuadas de casos de uso
a un paquete en concreto se tiene los siguientes
criterios:
1. Los casos de uso requeridos para dar soporte a un
determinado proceso de negocio.
2. Los casos de uso requeridos para dar soporte a un
determinado actor del sistema.
29
Para identificar los paquetes se basa en lo
siguiente:
1. Tener un diagrama de casos de uso con los roles
bien definidos.
2. Los casos de uso que estén bajo la
responsabilidad de un actor deben tener
contenidos estrechamente relacionados.
3. Los casos de uso que están relacionados mediante
relaciones de generalización deben pertenecer al
mismo paquete
Casos de Uso con
relación de
generalización.
30
27/10/2014
11
4. Los casos de uso relacionados mediante relaciones de
extensión y que solo se extienden a partir de un caso de uso
base deben pertenecer al mismo paquete del caso de uso base.
5. Los casos de uso incluidos tienden a generar su propio
paquete la mayor parte de veces. Si los casos de uso base que
incluyen al caso de uso son funcionalidades con distintos
contenidos, entonces, se debe crear un paquete para el caso de
uso incluido.
Casos de Uso
con relación
extend.
31
DEFINICIÓN DE DEPENDENCIAS ENTRE
PAQUETES DE ANÁLISIS
El objetivo es conseguir paquetes que sean relativamenteindependientes y débilmente acoplados, pero que poseanuna cohesión interna alta.
Es inteligente intentar reducir el número de relaciones entreclases en paquetes diferentes, debido a que ello reduce lasdependencias entre paquetes.
32
EJEMPLO: PAQUETES GENERADOS PARA
UN LOCAL COMERCIAL EN GENERAL
33
Un empleado de recepción en el
Paquete Recepción necesita
hablar con la orden de compra del
paquete Compra para validar los
productos que ingresan antes de
colocar los productos en
inventario
27/10/2014
12
a) Capa Específica: Aquí se ubican los paquetes
correspondientes al proceso del negocio (core) de la
empresa identificados (Nivel Superior).
b) Capa General: Aquí se ubican los paquetes de
maestros de información, paquetes de servicio,
seguridad y casos de apoyo del sistema (Nivel
Inferior).
34
CARACTERISTICAS
Permiten dividir un modelo para agrupar y
encapsular sus elementos en unidades lógicas
individuales
En general, pueden tener una interfaz (métodos
de clases e interfaces exportadas) y una
realización de éstas interfaces (clases internas
que implementan dichas interfaces)
Los paquetes pueden estar anidados unos dentro
de otros, y unos paquetes pueden depender de
otros paquetes.
Plantean la arquitectura del sistema a nivel
Macro. 35
36
27/10/2014
13
Fuente: Universidad de los Andes Venezuela
37
También se pueden mostrar algunas clases dentro de los paquetes, así
como las relaciones de dependencia de estas clases con otras clases o
paquetes.
38
CASO PRACTICO:
SISTEMA DE CONTROL DE PRODUCCIÓN DE
EMPRESAS EMBOTELLADORAS
39
27/10/2014
14
CASO: Sistema de Control del proceso productivo de una
empresa embotelladora:
CMateria Prima
CProducto
contienen
CCaja
CLineaProduccion
CProduccion
perteneceproduce
pertenece
CEmpleado
manejan
CDptoProduccion
pertenece
CEmpresa
tiene
es parte
40
Administrar Usuarios
Administrar Elementos
Administrar Departamentos Administrar Informacion
Empresaria
Imprimir Reporte
Mostrar Ayuda
Configurar Sistemas Administrador
Administrar Produccion
Usuario
Generar Reportes
<<extend>>
Visualizar Informacion
<<include>>
Operador
CASO: Sistema de Control del proceso productivo de una empresa
embotelladora:
41
Produccion
Configuracion
Visualizar Informacion
Ayuda
Configurar Sistemas
(from Use Case View)
Administrar Produccion
(from Use Case View)
Administrar Departamentos
(from Use Case View)
<<extend>>
Administrar Elementos
(from Use Case View)
<<extend>> Administrar Informacion
Empresaria(from Use Case View)
<<extend>>
42
27/10/2014
15
Administrador del Sistema
Administrador de produccion
Administrar Reportes y Ayuda
Administrar Produccion
(from Use Case View)
Configurar Sistemas
(from Use Case View)
Mostrar Ayuda
(from Use Case View)
Administrar Visores
Visualizar Informacion
(from Use Case View)
Generar Reportes
(from Use Case View)
<<include>>
43
CAPA ESPECIFICA
CAPA GENERAL
Administrador de
produccion
Administrador del
Sistema
Administrar Reportes y
Ayuda
44
45
27/10/2014
16
46
EJEMPLOIDENTIFICA LOS PAQUETES PARA EL
SIGUIENTE DIAGRAMA
47
48
27/10/2014
17
IDENTIFICACIÓN DE CLASES DE ENTIDAD
OBVIAS - ENTIDAD
Solo se debe concentrar en identificar las clases
del tipo entity por cada caso de uso. La mayoría
de las clases se identificarán al crear las
realizaciones de caso de uso.
49
CLASES ENTIDAD
Empleado
Empresa
Producto
Caja
CEmpleadoCEmpresa
CProducto CCaja
CLineaProduccionCMateria Prima
50
ANÁLISIS DE CASOS DE USO
El rol responsable de esta tarea es el Diseñador.
Esta tarea describe cómo desarrollar las
Realizaciones de los Casos de Uso del nivel de
análisis de un caso de uso particular. Tiene los
siguientes propósitos:
Identificar las clases que llevan a cabo el flujo de
eventos de un caso de uso.
Distribuir el comportamiento de casos de uso a las
clases identificadas, usando realizaciones de casos de
uso a nivel de análisis.
Identificar atributos, responsabilidades y relaciones
entre las clases.
Observar los mecanismos arquitectónicos.51
27/10/2014
18
52
TAREA SGTE. SESION:
Investigar acerca de
los pasos para el
Análisis de casos de
uso y traer un ejemplo
53