miércoles, 2 de agosto de 2017

Diagrama de Interaccion:

Los diagramas de interacción son modelos que describen como grupos de objetos colaboran para conseguir algún fin,  estos diagramas muestran objetos, así como los mensajes que se pasan entre ellos dentro del caso de uso.
  Los diagramas de interacción capturan el comportamiento de un caso de uso, también  se expresan de dos maneras:
  •   Diagramas de secuencia:                                 Un diagrama de secuencias muestra las interacciones expresadas en función del tiempo.En concreto muestra los objetos participantes y los mensajes que intercambian entre ellos a lo largo del tiempo.
 Los diagramas de secuencias son más apropiados para especificar restricciones de interacción en tiempo real.
 Un diagrama de secuencias tiene dos dimensiones, que son:
• La vertical que representa el tiempo
 • La horizontal que representa los distintos objetos.
El tiempo avanza desde el comienzo hasta el final de la página, aunque se puede tomar el sentido contrario.
La exactitud temporal solo toma importancia en las aplicaciones de tiempo real, por lo que los ejes de tiempo suelen tener marcas temporales.
El orden horizontal de aparición de los objetos no tiene ninguna importancia.
 La notación está tomada, en gran parte, del diagrama de secuencias de mensajes entre objetos de Buschmann (POSA diagrams).
Existen dos tipos de formatos para los diagramas de secuencia  las cuales son:
ü  En forma genérica: que describirá todas las posibles secuencias.
ü  En forma instancia: que describe una secuencia en concreto pero de forma consistente a lo especificado en la forma genérica
 Ejemplo de diagrama de secuencia:

El diagrama de secuencia usa una notación la cual puede ser:
La Line de Vida (lifeline): La línea vertical representa la existencia de un objeto a lo largo de un determinado tiempo y recibe el nombre de línea de vida del objeto.
 Si el objeto es creado o destruido, entonces su lifeline debe de comenzar y acabar en la línea de tiempo: 
 El mensaje que lo crea apuntará al objeto creado.
 Si el objeto fuera destruido durante el diagrama, se marcaría este evento con una gran “X”.
 En caso contrario la línea irá de la parte inferior a la superior del diagrama.
 Una línea de vida se puede ramificar en varias para representar
Activación :La cual muestra el periodo durante el cual un objeto realiza una acción
  Una activación se representa como un rectángulo alineado con los momentos en que se inicia y en que finaliza.  

 La acción que realiza aparece de manera opcional descrita en una etiqueta próxima al símbolo de activación o en el margen izquierdo.
Esta la Activación Concurrente: En objetos concurrentes, la activación muestra el intervalo en el que un objeto está realizando una operación.
Y la Activación Procedual: En código procedural (o concurrente sincrónizado) la activación muestra el intervalo de tiempo durante el cual un procedimiento o un procedimiento subordinado está activo. 


Diagrama de Clases

Un diagrama de clases es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.

Para especificar la visibilidad de un miembro de la clase (es decir, cualquier atributo o método), se coloca uno de los siguientes signos delante de ese miembro:
+ Público
- Privado
# Protegido
/ Derivado (se puede combinar con otro)
~ Paquete

-Los miembros clasificadores se denotan comúnmente como “estáticos” en muchos lenguajes de programación. Su ámbito es la propia clase.
-Los valores de los atributos son los mismos en todas las instancias
-La invocación de métodos no afecta al estado de las instancias
-Los miembros instancias tienen como ámbito una instancia específica.
-Los valores de los atributos pueden variar entre instancias
-La invocación de métodos puede afectar al estado de las instancias(es decir, cambiar el valor de sus atributos)
-Para indicar que un miembro posee un ámbito de clasificador, hay que subrayar su nombre. De lo contrario, se asume por defecto que tendrá ámbito de instancia.

Por otra parte, una relación es un término general que abarca los tipos específicos de conexiones lógicas que se pueden encontrar en los diagramas de clases y objetos:

-Enlace: Un enlace es la relación más básica entre objetos.

-Asociación: Una asociación representa a una familia de enlaces. Una asociación binaria (entre dos clases) normalmente se representa con una línea continua. Una misma asociación puede relacionar cualquier número de clases. Una asociación que relacione tres clases se llama asociación ternaria.
A una asociación se le puede asignar un nombre, y en sus extremos se puede hacer indicaciones, como el rol que desempeña la asociación, los nombres de las clases relacionadas, su multiplicidad, su visibilidad, y otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional, agregación (en la que se incluye la composición) y reflexiva. Las asociaciones unidireccional y bidireccional son las más comunes.

-Agregación: La agregación es una variante de la relación de asociación “tiene un”: la agregación es más específica que la asociación. Se trata de una asociación que representa una relación de tipo parte-todo o parte-de.
Una agregación se puede dar cuando una clase es una colección o un contenedor de otras clases, pero a su vez, el tiempo de vida de las clases contenidas no tienen una dependencia fuerte del tiempo de vida de la clase contenedora (de el todo). Es decir, el contenido de la clase contenedora no se destruye automáticamente cuando desaparece dicha clase.

martes, 1 de agosto de 2017

Gestión De Requisitos

Es el proceso encargado de la identificación, asignación y seguimiento de los requisitos para la creación de un proyecto, incluyendo el interfaz, verificación, modificación y control a todo lo largo del ciclo de vida. Es el conjunto de actividades que lleva el aseguramiento de las especificaciones, por ejemplo, los requisitos que son reunidos para la satisfacción del cliente. Es el proceso que inicia con la concepción de un proyecto y continúa hasta el resultado final del producto.

Clasificación de requisitos:

  • Funcionales: indican características y restricciones sobre la funcionalidad del software, además son la condición necesaria de un atributo para que cumpla una función determinada.
  1. Requisitos sobre la actualización de datos: son características sobre las funciones que cambian la información del sistema. Debe estudiarse de qué forma y bajo que restricciones el usuario desea que se introduzcan nuevos datos, se cambien los que ya existen o se eliminen.
  2. Requisitos sobre la estructura de información: son características de los datos que el software maneja.
  • No funcionales: son propiedades o cualidades que el producto debe tener. Los Requisitos no funcionales deben establecer restricciones en el producto que está siendo desarrollado, en el proceso de desarrollo y en restricciones específicas que el producto pueda tener. Pueden clasificarse en:
  1. Requisitos de rendimiento: son límites al rendimiento (para aquellas aplicaciones donde existan) y volúmenes de información que el software debe tratar.
  2. Requisitos de seguridad: son características de control de acceso al software y copias de seguridad, entre otros relacionados con la seguridad del sistema y la información.
  3. Requisitos de frecuencia de tratamiento: son características sobre la frecuencia con que se ejecutan las diferentes funciones del software.
Características de una BUENA especificación de requisitos:

1.    No debe ser ambigua.
2.     Debe ser Completa.
3.    Debe ser Fácil de verificar.
4.    Debe ser Fácil de verificar.
5.    Debe ser Consistente (coherente).
6.    Estar Clasificada por importancia o estabilidad.
7.    Debe ser Fácil de modificar.
8.    Ser de Fácil identificación del origen y de las consecuencias de cada requisito.
9.    De fácil utilización durante la fase de explotación y de mantenimiento.


Los requisitos para sistemas software son siempre cambiantes

v  A veces el problema no puede definirse completamente
v  Durante el proceso de desarrollo, evoluciona la comprensión del problema
v   Una vez que el sistema se ha instalado surgen nuevo requisitos