Está en la página 1de 14

Planeación y Especificación

del Sistemas (02).

Docente: Ing. Rosa Almaraz


Contenido.

5.- Casos de Uso


6.- Arquitectura del Sistema
Orientación para la Practica

Docente: Ing. Rosa Almaraz


5.- Definir Casos de Uso.

Introducción.

Los sistemas, no se encuentra aislados, ellos, interactúa con personas u objetos mecánicos con algún
objetivo y que esperan que el sistema funcione de una forma determinada.
Es por ello, que es importante identificar las fronteras de un sistema, y con quienes se interactúa,
además de conocer cuáles serían los procesos que se toman en cuenta para esta interacción.

Conceptos Básicos.

Qué es el modelo de casos de uso.


• El Modelo de Casos de usos proporciona la funcionalidad del sistema.
• Ilustra:
• Funciones del Sistema.
• Su entorno (Actores).
• Relaciones entre los casos de uso y actores. (Diagrama de Casos de Uso).

Importancia del Modelo de Casos de Uso.


• A través de él se comunican los Usuarios y los Desarrolladores.
• Decidir y describir los requerimientos funcionales del sistema.
• Dar una descripción concisa y consistente de lo que el sistema debe hacer.
• Proporciona las bases para las pruebas del sistema.
• Proporciona la habilidad de trazar los requerimientos funcionales en clases y operaciones
del sistema.
• Nos ayuda a comprender mejor los requisitos que debe tener un sistema, las necesidades
del usuario.

En qué momento se realizan.


▪ El modelo de casos de uso, comienza en la fase de inicio.
▪ (identificación de actores y casos de usos).
▪ Madura en la fase de Elaboración (se detallan más, se añaden más en la medida que se
necesiten).

Docente: Ing. Rosa Almaraz


Que representa
▪ Representa la Vista del Modelo de Casos de Usos.
▪ Que afecta las otras Vistas del Sistema.
▪ Las Funciones Especificadas en esta vista son implementadas en las otras Vistas.
▪ No sólo es utilizado para capturar requerimientos nuevos, sino también para desarrollar
nuevas generaciones de sistemas, añadiéndole nuevas funcionalidades a las ya existentes.

Que incluye:
 Diagramas de Casos de Uso.
 Descripción de los Casos de Uso.

Frontera del Sistema

 Como parte del modelaje se identifican las fronteras del Sistema.


 Aspectos a tener en cuenta para realizar la definición:
 Es difícil establecer la frontera.
 No se conoce que deberá ser automatizado y que no.
 Lo mejor es tomar la funcionalidad básica.
 Se debe obtener un catálogo de conceptos centrales, este no es un modelo del dominio,
sino un intento de describir la terminología del sistema.
 El sistema puede ser descrito como una caja, el nombre aparece arriba o dentro de la caja.

Actores

1. No son parte del Sistema.


2. Representan algo o alguien que debe interactuar con el Sistema.
3. El actor puede:
a) Solamente introducir datos.
b) Solamente recibir datos del sistema.
c) Introducir o recibir información desde / hacia el sistema.
4. Se comunican con el sistema enviando o recibiendo mensajes.
5. Un caso de uso es iniciado siempre por un actor, a menudo llamado estímulo.
6. El caso de uso es realizado para enviar mensajes a uno o más actores.
7. Un actor es una clase, no una instancia.
8. El actor representa un rol no un usuario individual del sistema.
9. Un actor tiene un nombre que representa el rol que realiza.

Docente: Ing. Rosa Almaraz


• Pueden tener rango:
• Actor primario: utilizan las funciones principales del sistema.
• Actor secundario: utilizan las funciones secundarias(mantenimiento del sistema,
respaldo, comunicación, etc).
• No tiene que ser un usuario directo.
• No tiene que ser humano siempre.
• Notación para actor:

▪ Identificación de Actores:
• Son encontrados en conversación con los clientes y los expertos del
dominio.
• Preguntas para encontrarlos:
• ¿Quién usará la funcionalidad Principal del Sistema?
• ¿Quién está interesado en cierto requerimiento?
• ¿Dónde en la organización será utilizado el Sistema?
• ¿Quién se beneficiará con el uso del Sistema?
• ¿Quién administrará, soportará y mantendrá al Sistema?
▪ Pueden tener relaciones pues son clases.
▪ Se muestran estas a través de generalización / especialización.
▪ Los actores especializados heredan el comportamiento de su superclase.

Docente: Ing. Rosa Almaraz


▪ Documentación de los actores
• Para cada actor se realizará una descripción.
• Esta descripción será el rol que juega.
• Ejemplo:
• Un cliente es aquella persona que adquiere un producto de
la compañía.
▪ Ejemplo:
• EL Caso de uso: Procesamiento de préstamos.
• Involucra necesariamente a los actores: cliente, responsable de
préstamos.

Docente: Ing. Rosa Almaraz


Casos de Uso

Que son?
 Modelan un diálogo entre una actor y el sistema.
 Representan la funcionalidad mostrada por el sistema.
 La colección de casos de usos representan todas las formas definidas en que un sistema será
utilizado.
 Representa una funcionalidad completa, tal y como será percibida por un autor.
 Caso de uso: es una secuencia de acciones, realizadas por el sistema que proporciona un
resultado observable de valor para un actor en particular.
 Notación:

• Un caso de uso especifica el comportamiento de un sistema o de una parte del mismo.


• Se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener
que especificar como se implementa ese comportamiento.
• Proporcionan un medio para que los desarrolladores los usuarios finales del sistema y los
expertos del dominio lleguen a una comprensión común del sistema.
• Puede tener varias variantes, se pueden tener casos de uso que son versiones especializadas
de otros casos de uso, casos de uso incluidos como parte de otros y casos de usos que se
extienden el comportamiento de otros casos de uso básicos.
1. Es siempre iniciado por un actor.
2. Proporciona valor a un actor.
3. Es completo.
4. Es una clase, no una instancia.
5. Un caso de uso puede tener instancias: Ejemplo de instanciación.
6. Caso de uso: Firmando Póliza de Seguro
7. Juan conecta el sistema por teléfono y firma una póliza de seguro para el tollota que
acaba de comprar.

Docente: Ing. Rosa Almaraz


8. Identificación de actores
• A partir de los Actores.
• ¿Cuáles son las tareas que necesita hacer?
• ¿Qué funciones requiere el actor del sistema?
• ¿necesitará el actor informar de algo al sistema?
• ¿Necesitará el actor ser informado de lago?
• Otras preguntas que no involucran a los Actores.
• ¿Qué casos de uso soportará y mantendrá el sistema?
• ¿Qué casos de uso creará, mantendrá o requerirá el
sistema?
• ¿Qué entrada, salidas recibirá/generará el sistema y
hacia7desde dónde?
1. Es una Vista Gráfica de algunos o todos los actores, casos de usos, interacciones del sistema.
2. Diagramas de Casos de Usos:
3. Diagrama de CU Principal: Es la imagen de la frontera (actores principales) y la
funcionalidades principales del Sistema.
4. Un diagrama que muestre todos los CU para un actor determinado.
5. Un Diag. De CU que muestre todos los CU implementados en una iteración.
6. Un diag. Que muestre un caso de uso y sus relaciones.

Ejemplo:

Docente: Ing. Rosa Almaraz


Como se describen los casos de Usos.
 Existen varias formas de hacer esto:
 Casos de uso de alto nivel. (En esta fase o etapa se describen en formato de alto
nivel) y es el que vamos a ver en este apartado.
 Formato Expandido.

Docente: Ing. Rosa Almaraz


Casos de uso de Alto Nivel.
a) Son más generales.
b) Son independientes del diseño.
c) Se deben especificar:
d) Nombre
e) Tipo
f) Actores
g) Descripción breve de lo que hace el caso de uso.
h) Pueden ser:
i) Primario (muy importante u ocurre con mayor frecuencia),
j) Secundario (menos importante),
k) Opcional (puede realizarse o no).

Formato a utilizar:

Nombre:

Tipo:

Actores:

Descripción:

Por Ejemplo:

Nombre: Comprar productos en el Supermercado

Tipo: Principal

Actores: Cajero, Cliente

Descripción: Cuando un cliente llega a la caja a pagar los productos que


se quiere llevar, el cajero va introduciendo cada código del
producto, cuando finaliza, el cajero indica le dice el total
que ha de pagar al cliente, el cliente paga y se va con los
productos comprados.

Docente: Ing. Rosa Almaraz


6.- Definir la Arquitectura del Sistema.

La Arquitectura del Sistema es una representación a alto nivel de los módulos que forman el
sistema, sus interfaces, conexiones, e interacciones.

La Arquitectura se representa mediante paquetes. Que gráficamente se pueden representar de la


siguiente forma.

Un paquete puede mostrar un grupo de subsistemas. Se denotan por carpetas. Es cualquier tipo de
elementos de UML. (clases, diagramas de casos de usos). Pueden tener otros paquetes subordinados
en si interior.

Docente: Ing. Rosa Almaraz


Arquitectura de tres niveles

La Arquitectura de tres niveles, divide el sistema en tres partes.


Presentación: La forma en que se presentan los datos.
Lógica del dominio: La comunicación entre la presentación y los datos
Almacenamiento: Gestión de las bases de Datos.

A continuación, se muestra un diagrama de la arquitectura del sistema, de tres niveles.

Docente: Ing. Rosa Almaraz


Arquitectura multinivel

La arquitectura multinivel, consiste en dividir en varios subniveles, un nivel.

Ventajas:
Reusabilidad: Un modulo bien construido se puede reutilizar en otros sistemas
Flexibilidad: Se pueden asignar distintos niveles a distintos equipos de desarrollo
Concurrencia: Distintos procesos pueden estar asignados a distintos procesos que se ejecuten en
varias máquinas.
Desventajas:
Aumento de la complejidad
Cada uno de los subniveles, puede a su vez tener varias particiones.

A continuación, se muestra un diagrama de la arquitectura del sistema multinivel.

Docente: Ing. Rosa Almaraz


Identificación de paquetes:

Se deben agrupar en un paquete los elementos que se refieren a un servicio en común, con un alto
nivel de colaboración y acoplamientos.
El paquete debe ser altamente cohesivo, incluir solamente aquellos elementos que se refieren a un
servicio con responsabilidades relacionadas
Entre los elementos de los paquetes, debe haber poco acoplamiento para evitar llamadas de unos
elementos a otros.

Orientación Tarea.

En esta parte, presentará un trabajo práctico, que deberá defender.

• Realice para su trabajo practico, todas las partes y la documentación que se genera en
esta fase.

Docente: Ing. Rosa Almaraz

También podría gustarte