FUNDAMENTOS DE INGENIERIA DE SOFTWARE

UNIDAD 5

ING. NELLY ROSINA IZAGUIRRE CARDENAS

CRUZ MEDINA PEDRO
DE LEON MARTINEZ PABLO
FUENTES MARTINEZ JORGE
GOMEZ REYES CARLOS FRANCISCO
RUIZ RAMIREZ LUIS VALENTIN
VELARDE ORTEGA DANIEL IVAN

FECHA DE ENTREGA //2013

INDICE
UNIDAD 5
INTRODUCCION..3
5 MODELO DE IMPLEMENTACIN OO. 4
5.1. DIAGRAMAS DE COMPONENTES.. 4
SUBSISTEMAS... 7
5.2. DIAGRAMAS DE DESPLIEGUE.....7
NODOS..7
DISPOSITIVOS....8
ARTEFACTOS..8
5.3 MODELOS DE PRUEBAS..9
MODELOS DE REQUISITOS...9
MODELOS DE COMPORTAMIENTO...
..9
MODELOS DE DATOS DE PRUEBAS...9
MODELOS DE INTERFAZ ABSTRACTA...9
MODELO DE INTERACCIN.
10
MODELO DE INTERAZ CONCRETA Y MODELO DE ACCIONES....10
CONCLUSION..11
BIBLIOGRAFIA.... 12

INTRODUCCION
En el siguiente trabajo de investigacin, se desarrollaran los temas de la unidad 5modelo de
implementacin antes que nada es necesario saber que el modelo de implementacin toma
el resultado del modelo de diseo para generar el cdigo final. Tambin es interesante saber
que con un buen diseo la tarea de implementacin es mucho ms fluida.
Otros temas a desarrollar son los diagramas de componentes los cuales describen los
elementos fsicos del sistema y sus relaciones. Muestran las opciones de realizacin
incluyendo cdigo fuente, binario y ejecutable.
En el desarrollo de dicha investigacin tambin se mencionaran los diagramas de despliegue
estos diagramas muestran los relaciones fsicas del hardware y software en el sistema final.
Por ltimo se mencionara el modelo de prueba el cual describe simplemente el estado de
resultados de la prueba.

UNIDAD 5. MODELO DE IMPLEMENTACIN.

5. Modelo de implementacin.
Describe como los elementos del modelo de diseo (como las clases) se implementan en
trminos de componentes, como ficheros de cdigo fuente, ejecutables, etc.
Describe cmo se organizan los componentes de acuerdo con los mecanismos de
estructuracin y modularizacin disponibles en el entorno de implementacin y en el lenguaje
o lenguajes de programacin utilizados, y cmo dependen los componentes unos de otros.
Se representa con un sistema de implementacin que denota el subsistema de nivel superior
del modelo. El utilizar otros subsistemas es una forma de organizar el modelo de
implementacin en trozos ms manejables. Define una Jerarqua de subsistemas de
implementacin que contiene componentes e interfaces
5.1. Diagrama de componentes.
Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones.
Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable. Los
componentes representan todos los tipos de elementos software que entran en la fabricacin
de aplicaciones informticas, pueden ser simples archivos, paquetes, bibliotecas cargadas
dinmicamente, etc.

UML define cinco estereotipos estndar que se aplican a los componentes:

4

* Ejecutable: especifica un componente que se puede ejecutar en un nodo.

* Biblioteca: especifica una biblioteca de objetos esttica o dinmica.
* Tabla: especifica un componente que representa una tabla de una base de datos.
* Expediente: especifica un componente que representa un documento que contiene cdigo
fuente o datos.
* Documento: especifica un componente que representa un documento.
Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar
que un componente se refiere a los servicios ofrecidos por otro componente.
Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos,
etc. que conformarn un sistema. Un diagrama de Componentes tiene un nivel ms alto de
abstraccin que un diagrama de clase usualmente un componente se implementa por una
o ms clases (u objetos) en tiempo de ejecucin. Estos son bloques de construccin, como
eventualmente un componente puede comprender una gran porcin de un sistema. Estos
Diagramas contienen:

Componentes

Interfaces

Relaciones de dependencia, generalizacin, asociacin y realizacin

Paq

uete
s

subsistemas

Los componentes se pueden agrupar en paquetes as como los objetos en clases, adems
pueden haber entre ellos relaciones de dependencia como:

Generalizacin

Asociacin

Agregacin

Realizacin

El diagrama de abajo muestra algunos componentes y sus relaciones internas. Los

conectores Ensamble vinculan las interfaces proporcionadas suministrada por el Producto y
el Cliente a las interfaces requeridas especificadas por orden. Una relacin de dependencia
traza los detalles de la cuenta asociada del cliente a la interfaz requerida, pago, indicada por
orden.

Los componentes son similares en prctica a los diagramas de paquete como los lmites
definidos y se usan para agrupar elementos en estructuras lgicas. La diferencia entre
Diagramas de Paquete y Diagramas de Componente es que los diagramas de componente
ofrecen un mecanismo de agrupamiento ms rico semnticamente. Con los Diagramas de
Componente todos los elementos del modelo son privados mientras que los diagramas de
Paquete solo muestran tems pblicos.
Subsistemas.
Los distintos componentes pueden agruparse en paquetes segn un criterio lgico y con
vistas a simplificar la implementacin, son paquetes estereotipados en <<subsistemas>>.
Los subsistemas poseen las siguientes caractersticas:
* Los subsistemas organizan la vista de realizacin de un sistema.
* Cada subsistema puede contener componentes y otros subsistemas.
* La descomposicin en subsistemas no es necesariamente una descomposicin funcional.
* La relacin entre paquetes y clases en el nivel lgico es el que existe entre subsistemas y
componentes en el nivel fsico.
* Paquetes (Categoras) y clases en el nivel lgico. Paquetes (Subsistemas) y componentes
en el nivel fsico.
5.2. Diagramas de Despliegue.
Un diagrama de despliegue muestra las relaciones fsicas entre los componentes hardware y
software en el sistema final, la configuracin de los elementos de procesamiento en tiempo
de ejecucin y los componentes software (procesos y objetos que se ejecutan).
Caractersticas:
Describe la arquitectura fsica del sistema durante la ejecucin , en trminos de:
Procesadores.
7

 Dispositivos.
Componentes de software.

Describen la topologa del sistema: la estructura de los elementos de hardware y el

software que ejecuta cada uno de ellos

Nodos: Son objetos fsicos que existen en tiempo de ejecucin, y que representan algn tipo
de recurso computacional (capacidad de memoria y procesamiento).
Computadores.
Otros dispositivos:
Impresoras.
Dispositivos de comunicacin.
Dispositivos
Los dispositivos del sistema tambin se representan como nodos.
Generalmente se usan estereotipos para identificar el tipo de dispositivo.
Los nodos se conectan mediante asociaciones de comunicacin.
Las asociaciones indican:
Algn tipo de ruta de comunicacin entre los nodos.
Los nodos intercambian los objetos o envan mensajes a travs de esta ruta.
El tipo de comunicacin se identifica con un estereotipo que indica el protocolo de
comunicacin o la red.
Artefactos: Es un producto del proceso de desarrollo de software, que pude incluir los
modelos del proceso.
Ventajas:
8

 La mayora de las veces el modelado de la vista de despliegue implica modelar

la topologa del hardware sobre el que se ejecuta el sistema.

Desventajas:
Estos sistemas contienen a menudo varias versiones de componentes
software, alguno de los cuales pueden incluso pueden incluso migrar de un
nodo a otro..
El diseo de tales sistemas requiere tomar decisiones que permitan un cambio
continuo de la topologa del sistema.

5.3. Modelos de pruebas.

El modelo de prueba es el ltimo modelo a construir. Describe simplemente el estado de
resultados de la prueba. El modelo de requerimientos de nuevo representa una herramienta
potente de prueba, al probar cada caso de uso, se verifica que los objetos se comuniquen
correctamente en dicho caso de uso. De manera simular se verifica la interface de usuario,
descrita en el modelo de requerimientos, con todo lo anterior, el modelo de requerimientos es
la base de verificado para el modelo de prueba.
Modelos de requisitos
Los nicos modelos de requisitos necesarios son los casos de uso y los requisitos de
almacenamiento, aunque otros modelos, como por ejemplo modelos de interfaces [3] o
modelos de navegacin [5] pueden enriquecer el proceso de prueba.
Modelo de comportamiento

El objetivo del modelo de comportamiento es expresar la misma informacin contenida en

una plantilla de caso de uso de una forma fcilmente manipulable. Las propuestas
estudiadas utilizan como modelos de comportamiento diagramas UML de estados,
diagramas UML de secuencia o diagramas UML de actividades
Modelo de datos de prueba
Los objetivos del modelo de datos de prueba son dos. En primer lugar, el modelo de
datos de prueba expresa todas las variables del caso de uso [1], su estructura si son tipos
complejos (como clientes o compras), las restricciones que puedan existir entre ellos y las
particiones de sus respectivos dominios
En segundo lugar el modelo de datos de prueba expresa los valores de prueba del
sistema y los resultados esperados del mismo. Esto se modela mediante un diagrama de
objetos, instanciando las clases identificadas en el modelo de clases anterior.
Modelos de interfaz abstracta
Los modelos anteriores nos indican lo que una prueba debe hacer (ejecutar un escenario
posible de un caso de uso), qu informacin hay que suministrarle y qu informacin nos
va a devolver. Sin embargo estos modelos an son demasiado abstractos y no se pueden
convertir en modelos dependientes de la plataforma ni en pruebas ejecutables de manera
directa. Por este motivo, a partir de los modelos anteriores, se obtienen los modelos de
interfaz abstracta y de interaccin.
El objetivo del modelo de interfaz abstracta es definir las interfaces que el sistema
ofrecer para poder realizar la funcionalidad expresada en el modelo de casos de uso y
en el modelo de comportamiento. Para lograr la independencia de la plataforma esta
modelo se construye a partir de un metamodelo de componentes que abstraen las
caractersticas de los componentes especficos. Este metamodelo puede adaptarse y
ampliarse fcilmente.
Modelo de interaccin
El objetivo del modelo de interaccin es definir cmo realiza las pruebas sus acciones y
definir los rbitros. En el contexto de las pruebas, un rbitro es elemento encargado de
comprobar si la prueba fue superada o no.
Modelo de interfaz concreta y modelo de acciones
Estos modelos permiten traducir las pruebas abstractas a pruebas ejecutables sobre el
sistema. Par ello es necesario conocer las interfaces definitivas, incluir los detalles de
10

dichos interfaces y completar las pruebas abstractas. El objetivo del modelo de interfaz
concreta es expresar los elementos de la interfaz abstracta en funcin de los
componentes concretos del sistema a prueba. A partir de este modelo, ya se pueden
expresar las pruebas a nivel de implementacin. El objetivo del modelo de accin es
expresar los elementos del modelo de interaccin mediante un lenguaje de una
herramienta de prueba concreta.

CONCLUSION
Al realizar el trabajo de investigacin de la unidad 5 se comprendi que el modelo de
implementacin que este describe cmo se organizan los componentes de acuerdo con los
mecanismos de estructuracin y popularizacin disponibles en el entorno de implementacin
y en el lenguaje o lenguajes de programacin utilizados, y cmo dependen los componentes
unos de otros. Este modelo de implementacin comprende de 3 diagramas el primero es el
diagrama de componentes Los componentes representan todos los tipos de elementos
software que entran en la fabricacin de aplicaciones informticas, pueden ser simples
archivos, paquetes, bibliotecas cargadas dinmicamente, etc. Tambin se comprendi que
dentro de los diagramas de componentes existen los subsistemas estos

Los distintos

componentes pueden agruparse en paquetes segn un criterio lgico y con vistas a

simplificar la implementacin, son paquetes estereotipados en subsistemas.
11

Otro tipo de diagrama que se investig es el de despliegue este muestra las relaciones
fsicas entre los componentes hardware y software en el sistema final, la configuracin de los
elementos de procesamiento en tiempo de ejecucin y los componentes software. Dentro de
los diagramas de despliegue podemos encontrar lo que son los nodos, los dispositivos y los
artefactos.
Por ltimo se estudi lo que son los modelo de pruebas el modelo de prueba es el ltimo
modelo a construir. Describe simplemente el estado de resultados de la prueba dentro del
modelo de pruebas existen los modelos de requisitos, los modelos de comportamiento, los
modelos de datos de pruebas, los modelos de interfaz abstracta, los modelos de interaccin,
y el Modelo de interfaz concreta y modelo de acciones.

BIBLIOGRAFA
http://ingenieriasoftwaredos.wikispaces.com/Diagrama+de+componentes+y+objetos
http://www.dsi.uclm.es/asignaturas/42530/pdf/M2tema12.pdf

12