Modelo de Implementación
El Modelo de
Implementación es comprendido por un conjunto de componentes y subsistemas que
constituyen la composición física de la implementación del sistema. Entre los
componentes podemos encontrar datos, archivos, ejecutables, código fuente y los
directorios. Fundamentalmente, se describe la relación que existe desde los
paquetes y clases del modelo de diseño a subsistemas y componentes físicos.
Este artefacto describe
cómo se implementan los componentes, congregándolos en subsistemas organizados
en capas y jerarquías, y señala las dependencias entre éstos.
Para representar los
diagramas del Modelo de Implementación se puede emplear el diagrama de UML de
Componentes.
5.1 DIAGRAMAS DE COMPONENTES
Es una unidad autónoma
que forma parte del sistema y proporciona la implementación de un conjunto de
interfaces.
Un componente es
fácilmente reemplazable
Es físico
Reemplazable
Parte del sistema
Proporciona un conjunto de interfaces
TIPOS DE COMPONENTES
COMPONENTES
DE DESPLIEGUE: Son para formar un sistema
ejecutable.
COMPONENTES
DE PRODUCTO DE TRABAJO:
Estos son generados en el proceso de desarrollo.
COMPONENTES
DE EJECUCION: Consecuencia de la ejecución del
sistema.
ELEMENTOS
REQUISITOS: Ayudan a documentar el comportamiento funcional de los elementos del
software.
RESTRICCIONES: Son aquellos que indican el entorno en donde operan.
ESCENARIOS:
Describe las acciones de los
objetos a lo largo del tiempo y describe la forma en la cual un componente
trabaja, además se pueden crear múltiples escenarios para describir tanto el
camino básico como las excepciones errores y otras condiciones.
TRANZABILIDAD:
Un componente puede implementar
otro elemento del modelo (por ejemplo en un caso de uso) o puede ser
implementado por otro elemento.
UTILIZACIÓN
Los diagramas de componentes son
utilizados para:
Modelar l vista (lógica) de
implementación estática en un sistema
Modelar código fuente
Modelar base de datos
Modelos sistemas adaptables
ESTEREOTIPOS EN LOS COMPONENTES
EJECUTABLES: Especifica un
componente que se puede ejecutar en un nodo.
LIBRARY: Especifica una
biblioteca de objetos estáticos o dinámicos.
TABLE: Especifica un
componente que representa una tabla de una base de datos.
FILE: Especifica un
componente que representa un documento que contiene código fuente o datos.
DOCUMENTO: Especifica un componente que
representa un documento.
5.2 DIAGRAMA DE DESPLIEGUE
Es la etapa del
desarrollo que describe la configuración del sistema para su ejecución en un
ambiente del mundo real. Para el despliegue se deben tomar decisiones sobre los
parámetros de la configuración funcionamiento, asignación de recursos
distribución y concurrencia.
Un diagrama de
despliegue muestra la configuración de nodos que participan en la ejecución y
de los componentes que residen en ellos.
RELACIONES FISICAS
Muestran las relaciones entre los
componentes del hardware y software en el sistema final así como su
configuración.
Formados por instancias de componentes
software que son los que representan manifestaciones de código el tiempo de
ejecución
REPRESENTACION
Grafos de nodos
unidos para conexiones de comunicación
Diagramas de clase que se encarga de
modelar los nodos del sistema
USOS
SISTEMAS
EMPOTRADOS: Colección de hardware con gran cantidad de
software que controla los dispositivos.
SISTEMA CLIENTE
– SERVIDOR: Conectividad de los clientes sobre los
servidores y distribución física de los nodos.
SISTEMAS DISTRIBUIDOS: Incluyen varios
niveles de servidores cambios continuos de topologías.
NODO: Es un objetos físico en tiempo de
ejecución que representa un recurso computacional generalmente tiene memoria y
capacidad de procesamiento. Los nodos pueden contener objetos, instancias,
instancias del componente a de representar típicamente un procesador o un
dispositivo sobre el que se pueden desplegar los componentes.
RELACIONES
Las relaciones entre los nodos permiten modelar:
Un canal de
comunicación entre existentes entre nodos y el tipo.
La cardinalidad de la relación.
ARTEFACTOS: Son aquellos
que representan las especificaciones de un elemento de implementación concreto
y real.
5.3 MODELOS DE PRUEBA
OBJETIVOS DE LAS PRUEBAS
Encontrar defectos en el software
Una prueba tiene éxito si descubre un defecto
Una prueba fracasa si hay defectos pero no los
descubre
PRUEBAS DE VERIFICACION
Ver si cumple las especificaciones de diseño
PRUEBAS DE VALIDACION
Ver si cumple los
requisitos del análisis
El proceso de
pruebas del software tiene dos objetivos
1. Demostrar
al desarrollador y al cliente que el software satisface sus requerimientos.
2. Descubrir
defectos en el software que su comportamiento es incorrecto, no deseable o no
cumple su especificación.
PRUEBAS DE CAJA BLANCA
Pruebas en que se
conoce el código a probar caja blanca (clear box: clara o transparente). Se
procura ejercitar cada elemento del código.
CLASES DE PRUEBAS
Pruebas de cubrimiento
Pruebas de condiciones
Pruebas de bucles
PRUEBAS DE CAJA NEGRA
Pruebas en que se
conoce solo la interfaz caja negra (black box: caja opaca). Se procura
ejercitar cada elemento de la interfaz.
CLASES DE PRUEBA
Cubrimiento: Invocar
todas las funciones (100%)
Clases de equivalencia de datos
Pruebas
de valores limite
PRUEBAS DE VALORES
Complemento a las particiones de equivalencia
Varios casos de prueba por cada partición
Valores típicos, intermedios
Valores primero y segundo del rango
Valores penúltimo y último
Valores
vecinos fuera del rango (en otra partición)
ESTARTEGIAS DE PRUEBA DE SOFTWARE
PRUEBAS DE
UNIDADES: Se
concentra en el esfuerzo de la verificación de la unidad más pequeña del diseño
del software, el componente o modulo del software. Las pruebas de unidad se
concentran en la lógica del procesamiento interno.
PRUEBAS DE
INTEGRACION:
Es una técnica sistemática para construir la arquitectura del software,
mientras al mismo tiempo se aplican las pruebas para descubrir errores
asociados con la interfaz.
PRUEBAS DE REGRESION: Repetir las pruebas tras cada modificación
REPETIR SOLO PRUEBAS DE VERIFICACION
PRUEBAS DE UNIDADES
PRUEBAS DE INTEGRACION
Conservar y actualizar los programas de prueba
usar herramientas de ejecución automática de las pruebas.
PRUEBAS DE
VALIDACION:
Esto empieza tras la culminación de la prueba de integración, cuando se han
ejercitado los componentes individuales. Se ha terminado de ensamblar el
software como paquete y se han descubierto y corregido los errores de interfaz
No hay comentarios:
Publicar un comentario