Resumen AdS - Segundo Parcial PDF
Resumen AdS - Segundo Parcial PDF
Resumen AdS - Segundo Parcial PDF
Una demora indica un depósito de datos, el cual permite la adición y acceso de los datos,
es información que tiene diferencia de tiempos entre su generación y su utilización. Su
identificador se compone de la letra D seguida por un número. A continuación, lleva un
nombre que representa la información que contiene. Los nombres no pueden coincidir con
ningún otro elemento del diagrama.
También aparecen en este nivel los flujos de datos que vinculan procesos. Todos los
procesos en el nivel 1 deben estar vinculados a través de demoras. Por tal motivo la
cantidad de flujos de datos del nivel 1 siempre va a ser mayor a la cantidad de flujos de
datos del nivel 0. Con respecto a los procesos, se identificarán con un número, comenzando
por 1 ya que el 0 está reservado para el Diagrama de Contexto, y el nombre que será el
mismo de la Tabla de Eventos. Debe indicarse cómo se activa cada uno de ellos. El flujo
de datos estímulo o activador debe ser marcado de forma tal de diferenciarlo del resto
(Por ejemplo, doble flecha).
La disposición del dibujo debe ser de manera tal que en el centro se dibujen los procesos y
demoras del sistema y por fuera quedan las entidades externas. Debo poderse delimitar
con línea punteada el contexto del sistema.
Las demoras pertenecen al Sistema, y cada proceso demorará los datos hasta el momento
en que los necesite. Los flujos de salida que van hacia entidades externas nunca se
demoran ya que si la entidad externa los necesita demorar es ella la que tendrá que
hacerlo en su Sistema.
La manera correcta de vincular procesos es que uno genere información para la demora y
el otro la utilice, no es necesario que todos los procesos se vinculan entre sí, pero si
levanto imaginariamente un proceso el resto deben estar enganchados a ese a través de
demoras.
Otros Niveles
Cada proceso del Diagrama de Sistemas puede a su vez ser explotado para crear
un diagrama más detallado. No es necesario explotar todos los procesos, solo se
realizará esta acción en aquellos cuyo nivel de complejidad así lo ameriten. En el nivel 2, la
vinculación entre los procesos se realiza a través de un Flujo de Datos que va directo de
proceso a proceso. Los procesos que aparecen en el Nivel 2 son numerados usando el
número del proceso que se había utilizado en el Diagrama de Sistema y se le agrega un
punto decimal y un número único para cada proceso.
Diccionario de Datos (DD)
El diccionario de datos es un listado organizado de todos los datos que pertenecen a un
sistema. El objetivo de un diccionario de datos es dar precisión sobre los datos que se
manejan en un sistema, evitando así malas interpretaciones o ambigüedades. El DD
recopila y coordina términos de datos específicos y confirma lo que cada término significa
para las diferentes personas de la organización. Los elementos que definimos en un DD
son: Demoras y Flujos de Datos (Distinguiendo los que pasan por una demora y los que
no).
Definición de Procesos
La definición de procesos, es una herramienta de modelado de sistemas, que permite
definir qué sucede en los procesos o funciones de un sistema. El objetivo es definir qué
debe hacerse para transformar ciertas entradas en ciertas salidas. No hay una única forma
de realizar la definición de procesos; existen múltiples herramientas que facilitan esta tarea.
Algunas herramientas utilizadas para generar definiciones de procesos son:
● Lenguaje estructurado: Se emplea un lenguaje natural limitado en palabras y
construcciones, dándole más precisión y claridad, evitando ambigüedades. Definen
un algoritmo.
● Tablas de Decisiones.
● Lenguaje narrativo.
● Diagramas de flujos.
Diagrama Entidad-Relación
Este diagrama permite modelar la información que utiliza el sistema y la relación que
existe entre la misma. Esta herramienta se utiliza en el modelo de datos conceptual, es el
primer paso en el proceso de desarrollo de la base de datos.
Componentes de un DER
Entidades
Es una cosa significativa acerca de la cual se necesita conocer y mantener información.
Se representan con un rectángulo. El nombre es un sustantivo en singular y debe ser único.
Atributos
Son una pieza específica de información de la cual se necesita tener conocimiento. Los
atributos describen a las entidades. Son las características de las entidades.
Clave
Uno o más atributos que permiten identificar una y sola una ocurrencia en una entidad.
La clave debe ser única y mínima. Se indica con una línea debajo del atributo o atributos
que forman parte de la clave.
Relaciones
Es una asociación bidireccional entre dos entidades. Cada dirección de la relación tiene
un verbo que describe cómo es la relación de la entidad con respecto a la otra y un
identificador. Existen 2 tipos de relaciones:
● Asociación: Cuando el atributo heredado de la relación no forma parte del
identificador en la entidad destino.
● Dependencia: Cuando el atributo heredado de la relación forma parte del
identificador en la entidad destino.
Las características de una relación son:
● Cardinalidad: Indica el número máximo de instancias o elementos de una entidad
que pueden asociarse a un elemento de la otra entidad. Puede ser:
○ 1a1
○ 1 a Muchos
○ Muchos a Muchos
● Modalidad: Indica el número mínimo de elementos que participan en una relación.
Cada dirección de la relación tiene una modalidad. Esta puede ser:
○ Opcional: Se marca con un 0 y significa que puede no haber ninguna
ocurrencia en una entidad para un elemento de la otra.
○ Obligatoria: Se marca con L y significa que debe haber por lo menos 1
ocurrencia en una entidad para un elemento de la otra.
Existe una relación especial de especialización llamada Relación Tipo/Subtipo: La entidad
se relaciona consigo misma. Cada subtipo hereda los atributos de la entidad tipo pero posee
propios. La clave es la misma.
Casos de Uso
Actores
Un actor representa un conjunto de roles que los usuarios de los casos de uso juegan al
interactuar con ellos. Este rol o roles es llevado a cabo por una persona, un dispositivo de
hardware u otro sistema. La misma persona física puede interpretar varios papeles como
actores distintos. El nombre del actor describe el papel desempeñado. Los actores son
externos al sistema. Es por ello, que al identificar a los actores se está delimitando el
sistema.
Casos de Uso
Son una descripción de un conjunto de secuencias de acciones (interacciones con
elementos externos al sistema), que ejecuta un sistema para obtener un resultado que
agregue valor. Un caso de uso es iniciado por un único elemento externo al sistema
(Actor). A partir de ese momento, el sistema intercambia datos con el entorno. El nombre
siempre está expresado desde el punto de vista del usuario y no desde el punto de vista
del sistema. Se documentan con texto informal. Describen tanto lo que hace el usuario
como lo que hace el sistema cuando interactúa con él.
Relación de Extensión
Una relación de extensión (extend) entre casos de uso, significa que uno de ellos
incorpora implícitamente el comportamiento del otro caso de uso. Se utiliza cuando se
desea indicar que mientras se está ejecutando un caso de uso, se puede utilizar
opcionalmente otro caso de uso, en algún punto de la ejecución del primero. Las
características de las extensiones son:
● Representan una parte de la funcionalidad del caso que no siempre ocurre.
● Son un caso de uso en sí mismas.
● No necesariamente provienen de un error o excepción.
Relación de Inclusión
Una relación de inclusión (include), entre casos de uso, significa que un caso de uso
incorpora siempre el comportamiento de otro caso de uso. La relación de inclusión se
usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el
comportamiento común en un caso de uso aparte (que será incluido por un caso de uso
base). También se utiliza cuando se descompone un caso de uso largo (o complejo) en
subunidades para mejorar la comprensión. Las características de las inclusiones son:
● Aparecen como funcionalidad común, luego de haber especificado varios casos de
uso.
● Los casos usados son casos de uso en sí mismos.
● El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la
diferencia con las extensiones, que son opcionales.
La principal diferencia que existe entre las relaciones Include y Extend, es que la relación
extend cuenta con una condición a ser evaluada. En cambio, la relación include se define
como la inclusión de un Caso de Uso en otro, pero no precisa de una condición.
Flujo de Eventos
Un caso de uso está compuesto por un flujo principal y uno o más flujos alternativos:
● Flujo Principal: Es la ejecución del curso normal del caso de uso.
● Flujo Alternativo: Durante la ejecución de un caso de uso, suelen aparecer errores
o excepciones al curso principal. Esas desviaciones del curso normal del caso de
uso se llaman alternativas y representan un error o excepción en el curso normal del
caso de uso.
Precondiciones y Postcondiciones
Precondiciones
Las precondiciones, reflejan el estado en el que debe estar el sistema y su entorno para
que pueda comenzar la ejecución del caso de uso. Las precondiciones establecen lo que
debe cumplirse antes de comenzar un caso de uso. Estas no se prueban en el caso de
uso, sino que se asumen como verdaderas, generalmente, implica que un caso de uso
anterior se haya completado exitosamente. Las precondiciones indican suposiciones
importantes que deben cumplirse.
Postcondiciones
Las postcondiciones, reflejan el estado en el que queda el sistema y su entorno luego
de la ejecución del caso de uso. Establecen qué debe cumplirse cuando el caso de uso
se completa con éxito.
Escenario de un Caso de Uso
Un escenario es una instancia de un caso de uso, es decir, un camino concreto que puede
tomar un caso de uso. Los escenarios no contienen condiciones, ya que describen una de
las posibles instancias del caso de uso. Todos los escenarios de un caso de uso comienzan
igual, pero pueden terminar de muchas maneras diferentes. No se deben mostrar sólo
instancias (escenarios) exitosas del caso de uso, también se deben mostrar algunas en las
que falla. Cada uno de los escenarios definidos, van a servir como casos de prueba a la
hora de realizar testing (test funcional) del sistema. El desarrollo de un caso de uso es un
conjunto de todos los escenarios posibles que puede presentar el caso de uso.
Requerimientos Funcionales
Definición
Un requerimiento (o requisito) es una necesidad o solicitud cuyo objetivo es resolver un
problema. Los requisitos son condiciones, características o capacidades que debe tener un
sistema (Requerimientos del Sistema) para satisfacer las necesidades del usuario
(Requerimientos del Usuario).
Requerimientos en la Metodología
Teniendo en cuenta los pasos de la metodología de sistemas, definimos que:
● En la etapa de RELEVAMIENTO se relevan, capturan, escuchan, observan,
detectan y documentan las necesidades del usuario (requerimientos del usuario).
● En la etapa de ANÁLISIS DE REQUISITOS se definirán los Requerimientos
(requerimientos del sistema) que deberá tener el sistema para cumplir con todas
esas necesidades (requerimientos del usuario).
Tipos de Requerimientos
Funcionales
Los Requerimientos Funcionales describen las funcionalidades del sistema, es decir lo
que el sistema debe hacer, su comportamiento específico. Describen las transformaciones
que el sistema realiza sobre las entradas para producir salidas. Deben estar redactados
de tal forma que sean comprensibles para usuarios sin conocimientos técnicos avanzados.
Definen qué debe hacer un sistema.
No Funcionales
Los Requerimientos No Funcionales son los atributos o características que definen el
cómo el sistema realizará el trabajo. Pueden considerarse como las restricciones
planteadas al sistema respecto a cómo los requerimientos funcionales son implementados.
Definen cómo debe ser un sistema. Se clasifican en:
● De Producto o Calidad: Limites o restricciones sobre el comportamiento del
sistema.
○ Mantenibilidad: Significa que puede cambiar sin generar un gran impacto.
○ Usabilidad: Amigable para el usuario, respecto a la navegabilidad de las
pantallas.
○ Performance: Eficiencia esperada, es decir buen desempeño del frente a la
demanda esperada.
○ Disponibilidad: La disponibilidad del sistema debe ser continua con un nivel
de servicio para los usuarios de 7 días X 24 horas.
○ Seguridad: La solución debe reflejar patrones de seguridad teniendo en
cuenta la alta sensibilidad de la información que maneja de acuerdo a las
especificaciones funcionales dadas y a las políticas, normas y estándares de
seguridad requeridas
● Organizacionales: Se derivan de las políticas y procedimientos de la organización
como por ejemplo estándares de procesos o requerimientos de implementación:
○ De entorno u organizacionales: Procedimientos operativos que describen
cómo será usado el sistema dentro del contexto de la organización.
○ De diseño, desarrollo e implementación: Lenguaje de programación a usar,
estándares de codificación, patrones (y antipatrones) de diseño y
programación, herramientas para gestionar el desarrollo de software, entorno
de desarrollo de software (ambiente de desarrollo), entorno de pruebas de
software (ambiente de pruebas), entre otros aspectos.
● Externos:
○ Regulatorios: Leyes y reglamentos que establecen que debe hacer el sistema
y cómo debe hacerlo para cumplirlas
○ Éticos: Requerimientos que aseguran que el sistema será aceptable para el
usuario, público en general y se adapta a las costumbres de la sociedad en la
que se desenvuelve o a la que presta servicios.
○ Legislativos: Características que debe cumplir el sistema para cumplir con la
ley, por ejemplo en el área de contabilidad (normas contables y estándares
financieros), requerimientos de seguridad industrial (para sistemas críticos),
entre otros aspectos.