DIAGRAMA DE DESPLIEGUE
DIAGRAMAS DE DESPLIEGUE
Un diagrama de despliegue es una forma de ilustrar el hardware y el
software de un sistema. Se utilizan para visualizar los procesadores/
nodos/dispositivos de hardware de un sistema, los enlaces de
comunicación entre ellos y la colocación de los archivos de software en
ese hardware.
El diagrama de despliegue es un tipo de diagrama del Lenguaje
Unificado de Modelado que se utiliza para modelar el hardware
utilizado en las implementaciones de sistemas y las relaciones entre sus
componentes.
Elementos
• Nodos
Se representa mediante un cubo, es una entidad física (recursos
computacionales) que ejecuta uno o más componentes, subsistemas o
ejecutables. Un nodo podría ser un elemento de hardware o software.
• Componente
Se describe como el bloque de unidades de implementación de un
sistema que muestra las partes independientes e intercambiables de
dicho sistema. Es un conjunto de clases que pueden clasificarse en
función de su tipo.
• Artefactos
Son representaciones mucho más concretas que hacen referencia a un
elemento específico. En el caso de los diagramas de despliegue, podría
tratarse de archivos ejecutables o archivos de configuración.
• Dependencia
Especifica el elemento del modelo que depende de otro elemento del
modelo. Si se introduce un cambio en el elemento de destino, el
elemento dependiente también sufre el cambio. Es comúnmente
representado por una línea discontinua con una punta de flecha.
• Conexión
Muestra la ruta de comunicación utilizada por el hardware. También
indica el método de comunicación.
UTILIDAD Y CARACTERÍSTICAS
Los diagramas de despliegue tienen como utilidad y características que:
1. Son utilizados en las etapas de diseño del proceso.
2. Se refinan a lo largo del proceso de desarrollo.
3. Son útiles en el proceso de instalación del sistema.
4. Representan la estructura del sistema solo en tiempo de ejecución
pero no en tiempo de desarrollo o compilación.
REQUERIMIENTO
En el mundo del desarrollo de software y aplicaciones, los
requerimientos son críticos. Son los que definen la funcionalidad y el
propósito de una pieza particular de software o aplicación. Sin estos
bien definidos, es difícil crear algo que satisfaga las necesidades y
expectativas del usuario.
En síntesis un requerimiento es una descripción de lo que un programa
de software en particular debe hacer. Actúan como pautas para que los
desarrolladores creen un producto funcional que satisfaga las
necesidades de los usuarios.
IMPORTANCIA DE LOS REQUERIMIENTOS
• Definir el alcance de un proyecto (Características del producto final)
• Identificar riesgos potenciales (Obj. Contradictorios y plazos irrealistas)
• Proporcionar una base para las pruebas (Pruebas base)
• Dar dirección a los desarrolladores (Hoja de ruta del desarrollo)
• Salvaguarda la experiencia del usuario final (Satisfacción del cliente)
• Fomenta la comunicación y la colaboración entre los miembros del
equipo
• Evita el costo de “retrabajar” y las sorpresas de última hora
REQUERIMIENTO FUNCIONAL
Un requisito funcional es una declaración de cómo debe comportarse
un sistema. Define lo que el sistema debe hacer para satisfacer las
necesidades o expectativas del usuario. Los requisitos funcionales se
pueden considerar como características que el usuario detecta.
Los requisitos funcionales se componen de dos partes: función y
comportamiento. La función es lo que hace el sistema (por ejemplo,
"calcular el impuesto sobre las ventas"). El comportamiento es cómo lo
hace el sistema (p. ej., "El sistema calculará el impuesto sobre las
ventas multiplicando el precio de compra por la tasa impositiva").
EJEMPLOS
Ejemplo 1
Un usuario podrá iniciar sesión en el sistema utilizando su nombre de
usuario y contraseña.
En este ejemplo, la función es "iniciar sesión" y el comportamiento es
"El sistema permitirá que un usuario inicie sesión con su nombre de
usuario y contraseña".
Ejemplo 2
El sistema calculará el impuesto a las ventas por la compra del
usuario.
En este ejemplo, la función es "calcular el impuesto sobre las ventas" y
el comportamiento es "El sistema calculará el impuesto sobre las
ventas multiplicando el precio de compra por la tasa impositiva".
Ejemplo # 3
El sistema enviará un correo electrónico de confirmación al usuario
después de que haya realizado un pedido con éxito.
En este ejemplo, la función es "enviar correo electrónico de
confirmación" y el comportamiento es "El sistema enviará un correo
electrónico de confirmación al usuario después de que haya realizado
un pedido con éxito".
Al crear requisitos funcionales, es importante tener en cuenta que
deben ser específicos, medibles, alcanzables, relevantes y limitados en
el tiempo (SMART). Al seguir estas pautas, puede estar seguro de que
sus requisitos funcionales son claros y ayudarán a su equipo de
desarrollo a crear el producto adecuado.
REQUERIMIENTO NO FUNCIONAL
Se trata de requisitos que no se refieren directamente a las funciones
específicas suministradas por el sistema (características de usuario),
sino a las propiedades del sistema: rendimiento, seguridad,
disponibilidad. En palabras más sencillas, no hablan de “lo que” hace el
sistema, sino de “cómo” lo hace.
Define como debe ser un sistema, describe restricciones que limitan las
elecciones para construir una solución, por ende, son atributos
relacionados con la calidad, como el rendimiento, la escalabilidad, la
viabilidad, la disponibilidad, el mantenimiento, la seguridad, etc.
Los requisitos no funcionales son tan importantes como los requisitos
funcionales. Si los requisitos funcionales especifican lo que debe hacer
un sistema, los requisitos no funcionales describen cómo lo hará. Por
ejemplo, la nueva aplicación nos proporcionará la lista final de todos los
usuarios conectados. Eso es parte de los requisitos funcionales.
Si el requisito dice que el sistema solo funcionaría en un sistema
Windows y Linux, eso sería parte de los requisitos no funcionales.
La única diferencia entre los dos es que el sistema no puede funcionar
sin satisfacer todos los requisitos funcionales. Por otro lado, el sistema
le dará el resultado deseado incluso cuando no satisfaga los requisitos
no funcionales.
EJEMPLOS
• Seguridad: El sistema debe estar protegido contra el acceso no
autorizado.
• Actuación: El sistema debe poder manejar el número requerido de
usuarios sin ninguna degradación en el rendimiento.
• Escalabilidad: El sistema debe ser capaz de escalar hacia arriba o
hacia abajo según sea necesario.
• Disponibilidad: El sistema debe estar disponible cuando sea
necesario.
• Mantenimiento: El sistema debe ser fácil de mantener y actualizar.
• Portabilidad: El sistema debe poder ejecutarse en diferentes
plataformas con cambios mínimos.
• Fiabilidad: El sistema debe ser confiable y cumplir con los requisitos
del usuario.
EJEMPLOS
• Usabilidad: El sistema debe ser fácil de usar y comprender.
• Compatibilidad: El sistema debe ser compatible con otros sistemas.
• Compliance: El sistema debe cumplir con todas las leyes y
reglamentos aplicables
Los requisitos no funcionales son esenciales para cualquier sistema.
Ayudan a garantizar que el sistema satisfaga las necesidades del
usuario y pueda funcionar según lo previsto. Es importante considerar
cuidadosamente todos los requisitos no funcionales antes de diseñar y
desarrollar un sistema.
DOCUMENTO DE REQUERIMIENTOS
El documento de requerimientos de software, es el lugar donde se da
descripción a las características y requisitos de un software, producto,
programa o conjunto de programas. Los requisitos se expresan en
lenguaje natural, sin consideraciones ni términos técnicos.
La especificación de requisitos de software es el resultado del
levantamiento de información con el usuario o cliente del producto.
Un documento de especificación de requisitos de software es una
descripción detallada de lo que hará un software, sistema o aplicación y
cómo debería funcionar.
CASOS DE USO
• Son cada uno de los requisitos funcionales del sistema.
• Puede incluir actores (elementos externos).
• Especificación del comportamiento de una funcionalidad, tanto el
comportamiento básico como el comportamiento excepcional
(manejo de errores).
• En resumen un caso de uso es una descripción funcional completa de
lo que se va a hacer con la interacción entre actores y el sistema
(formato textual).
ESPECIFICACIONES DE CASOS DE USO
ID
Caso de Uso
Actores
Propósito
Descripción
Precondición
Postcondición
Extensiones síncronas
[Identificador del caso de uso]
[Nombre]
[Listado de los actores que tienen participación en el caso de uso]
[Requerimientos o funcionalidades incluidas en este caso de uso.
Casos de uso relacionados.]
[Descripción del caso de uso]
[Condiciones sobre el estado del sistema que deben cumplirse
para iniciar el caso de uso]
[Efectos inmediatos que tienen la ejecución del caso de uso sobre
el estado del sistema]
[Alertas, Avisos]
ID
Caso de Uso
Actores
Propósito
2
Añadir monitor a una actividad
Administrador
Asignar un monitor a una actividad
Descripción
Precondición
1. El sistema mostrará todas las actividades.
2. El administrador seleccionará una actividad.
3. El sistema mostrará la información detallada de la actividad incluyendo si la
misma ya tiene un monitor asignado.
4. El sistema mostrará todos los monitores que pueden impartir dicha actividad
atendiendo las posibles restricciones horarias que puedan existir.
5. El administrador seleccionará el monitor que lo impartirá.
6. El sistema asignará el monitor a la actividad.
-
Postcondición
La asignación es creada y almacenada en el sistema
Extensiones
síncronas
Si en 4 no se encuentran monitores disponibles, el sistema mostrará un mensaje
de error y el caso de uso terminará.
DIAGRAMAS DE CASOS DE USO
El diagrama de caso de uso es un tipo de diagrama UML de
comportamiento y se usa frecuentemente para analizar varios sistemas.
Permiten visualizar los diferentes tipos de roles en un sistema y cómo
esos roles interactúan con el sistema.
El diagrama de casos de uso es bastante estático, ya que solo puede
emplearse para describir acciones y objetivos, pero no la secuencia
exacta de procesos y acciones.
Permite visualizar clara y fácilmente qué casos de uso deben tenerse en
cuenta durante el desarrollo para que los actores logren su objetivo, en
principio independientemente de la viabilidad técnica.
FINALIDADES DE LOS DIAGRAMAS DE CASOS
DE USO
• Representar los requisitos funcionales.
• Representar los actores que se comunican con el sistema.
Normalmente los actores son los usuarios y otros sistemas externos
que se relacionan con el sistema. En el caso de los usuarios hay que
entender el actor como un “perfil”, pudiendo existir varios usuarios
que actúan como el mismo actor.
• Representar las relaciones entre requisitos funcionales y actores.
• Guiar el desarrollo del sistema (Crea un punto de partida).
• Comunicarse
de
forma
precisa
entre
cliente
y
desarrollador. Simplifica la forma en que todos los participes del
desarrollo, incluyendo el cliente, perciben como el sistema funcionará
y ofrecerá una visión general común del mismo
ELEMENTOS Y ESTRUCTURA DEL DIAGRAMA
DE CASOS DE USO
Para garantizar que el diagrama de casos de uso sea comprensible para
todo el mundo de un vistazo, se utilizan elementos estandarizados para
elaborarlo. En primer lugar, hay tres elementos principales:
Actor: es algo o alguien externo que interactúa de forma directa con el
sistema, se representa con el dibujo de una figura humana esquemática.
Sistema: El sistema se utiliza para definir el alcance del caso de uso y se
dibuja como un rectángulo.
Caso de uso: Un caso de uso se utiliza para representar una de las
funcionalidades que realiza el sistema. Es una secuencia de acciones
que hace el sistema y que producen un resultado que puede percibir
un usuario. Se muestra como una elipse que suele incluir un texto
describiendo brevemente el proceso.
Relaciones: Las relaciones conectan los casos de uso con los actores o
los casos de uso entre sí.
Cuando conectan casos de uso entre sí se pueden diferenciar dos tipos
de relaciones: <<include>> y <<extends>>.
<<include>>: Se utiliza para representar que un caso de uso utiliza
siempre a otro caso de uso.
<<extend>>: Este tipo de relaciones se utilizan cuando un caso de uso
tiene un comportamiento opcional, reflejado en otro caso de uso.
En este ejemplo, los casos de uso emitir factura y enviar producto
ejecutarán ambos el caso de uso autenticación.
En este ejemplo, el caso de uso Hacer pedido puede dar lugar (o no) a
otros dos casos de uso: Enviar notificación SMS y Enviar notificación
email.
Según el número de casos de uso se puede usar un diagrama, o varios
según los módulos o funcionalidad.
DIAGRAMAS DE CLASE
Un diagrama de clase es un tipo de diagrama UML que describe un
sistema visualizando los diferentes tipos de objetos dentro de un
sistema y los tipos de relaciones estáticas que existen entre ellos.
El diagrama de clases es un diagrama puramente orientado al modelo
de programación orientado a objetos, ya que define las clases que se
utilizarán cuando se pase a la fase de construcción y la manera en que
se relacionan las mismas.
Cada tipo de clase es representada como un rectángulo con tres
compartimientos para el nombre de la clase, los atributos, y las
operaciones.
ELEMENTOS DE UN DIAGRAMA DE CLASES
CLASES
Son el elemento principal del diagrama y representa, como su nombre
indica, una clase dentro del paradigma de la orientación a objetos. Este
tipo de elementos normalmente se utilizan para representar conceptos
o entidades del «negocio».
Una clase está compuesta por tres elementos: nombre de la clase,
atributos, funciones.
La primera de las zonas se utiliza para el nombre de la clase. En caso de
que la clase sea abstracta se utilizará su nombre en cursiva.
La segunda de las zonas se utiliza para escribir los atributos de la clase,
uno por línea y utilizando el siguiente formato:
visibilidad nombre_atributo : tipo = valor-inicial { propiedades }
Aunque esta es la forma «oficial» de escribirlas, es común simplificando
únicamente poniendo el nombre y el tipo o únicamente el nombre.
La última de las zonas incluye cada una de las funciones que ofrece la
clase. De forma parecida a los atributos, sigue el siguiente formato:
visibilidad nombre_funcion { parámetros } : tipo-devuelto { propiedades }
De la misma manera que con los atributos, se suele simplificar indicando
únicamente el nombre de la función y, en ocasiones, el tipo devuelto.
Tanto los atributos como las funciones incluyen al
principio de su descripción la visibilidad que tendrá.
Esta visibilidad se identifica escribiendo un símbolo y
podrá ser:
• (+) Pública. Representa que se puede acceder al
atributo o función desde cualquier lugar de la
aplicación.
• (-) Privada. Representa que se puede acceder al
atributo o función únicamente desde la misma
clase.
• (#) Protegida. Representa que el atributo o función
puede ser accedida únicamente desde la misma
clase o desde las clases que hereden de ella (clases
derivadas).
RELACIONES
Una relación identifica una dependencia. Esta dependencia puede ser
entre dos o más clases o una clase hacía sí misma. Las relaciones se
representan con una línea que une las clases, esta línea variará
dependiendo del tipo de relación.
• Multiplicidad. Es decir, el número de elementos de una clase que
participan en una relación. Se puede indicar un número o un rango.
Se utiliza n o * para identificar un número cualquiera.
• Nombre de la asociación. En ocasiones se escriba una indicación de
la asociación que ayuda a entender la relación que tienen dos clases.
Suelen utilizarse verbos como por ejemplo.
TIPOS DE RELACIONES
• Asociación
Este tipo de relación es el más común y se utiliza para
representar dependencia semántica. Se representa con
una simple línea continua que une las clases que están
incluidas en la asociación.
• Agregación
Es una representación jerárquica que indica a un objeto
y las partes que componen ese objeto. Es decir,
representa relaciones en las que un objeto es parte de
otro, pero aun así debe tener existencia en sí mismo.
Se representa con una línea que tiene un rombo en la
parte de la clase que es una agregación de la otra clase.
• Composición
La composición es similar a la agregación,
representa una relación jerárquica entre un
objeto y las partes que lo componen, pero
de una forma más fuerte. Se representa
con una línea continua con un rombo
relleno en la clase que es compuesta.
• Dependencia
Se utiliza este tipo de relación
para representar que una clase requiere de
otra para ofrecer sus funcionalidades. Es
muy sencilla y se representa con una flecha
discontinua que va desde la clase que
necesita la utilidad de la otra flecha hasta
esta misma.
• Herencia
Es una relación muy común en el diagrama de clases. Este tipo de
relaciones permiten que una clase (clase hija o subclase) reciba los
atributos y métodos de otra clase (clase padre o superclase). Estos
atributos y métodos recibidos se suman a los que la clase tiene por sí
misma. Se representa con una flecha.
• INTERFACES
Una interfaz es una entidad que declara una serie de atributos,
funciones y obligaciones. Es una especie de contrato donde toda
instancia asociada a una interfaz debe de implementar los servicios que
indica aquella interfaz.
Dado que únicamente son declaraciones no pueden ser instanciadas.
Su representación es similar a las clases, pero indicando arriba la
palabra <<interface>>.