|
Tutorial de Xavier Ferré Grau (Univ. Politécnica de Madrid - España) y María Isabel Sánchez Segura (Univ. Carlos III de Madrid - España) - 24 de Octubre de 2005
|
| UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. |
| Cap 5 |
Diagrama de Casos de Uso
|
| |
" Diagrama de Casos de Uso
Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema |
| Cap 6 |
Modelado Dinamico
|
| |
Centraremos en los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así como las tareas concurrentes |
| Cap 2 |
Elementos Comunes a Todos los Diagramas
|
| |
" Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama . Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Una nota |
|
|
|
Tutorial de Juan Manuel - 02 de Diciembre de 2009
|
| En los últimos años parece que las metodologías ágiles convencen más a los desarrolladores que las complejas metodologías pesadas. Entre todas ellas, la eXtremme Programming es la que se lleva la palma, y una de... |
| Cap 14 |
Baterías de pruebas anidadas
|
| |
Fijarnos bien en la jerarquía de clases de CPPUnit , veremos que tenemos distintos objetos que podríamos retornar desde el método suite. Vamos a ver algunas de las clases que aparecen en el diagrama y cómo podemos utilizarlas de formas alternativas para modificar la estructura de las pruebas |
| Cap 12 |
La excepción es la que confirma la regla
|
| |
);
// si pasa por aquí, entonces error
assertMessage(false, "Error en setDato(NULL): no se ha generado la excepción. ");
}
catch(... ) {
}
} Como podéis ver, si se produce alguna excepción dentro de la función "setDato", el flujo de ejecución saltará dentro del “catch |
| Cap 6 |
Desarrollo guiado por puebas
|
| |
. De este modo, como dicen en mi pueblo, hemos matado dos pájaros de un tiro: hemos obtenido el análisis de casos de uso (incluso podríamos representarlo con un diagrama UML de Casos de Uso), y hemos confeccionado una lista de tareas a completar para dar por finalizada la unidad. ~1) Codificar |
|
|
|
Tutorial de Patrick Reijnen - 22 de Diciembre de 2006
|
| Lo que sigue es una guía detallada de configuración del programa de comunicaciones term en Linux. |
| Cap 5 |
Clientes TERM
|
| |
A trsh, tmon, tupload, tdownload, trdate y trdated. El resto tiene su propia sección cada uno. No funcionará ningún cliente de term hasta que se haya establecido un enlace term. tmon es una utilidad simple para monitorizar las estadísticas del enlace. Imprime un diagrama de tiempo |
| Cap 4 |
Poniendo a punto las cosas
|
| |
Posible. Esto puede implicar cambiar la forma en que accedes a tu sistema, por ejemplo, si el servidor usa rlogin , tendrás que usarlo poniendo el parámetro -8 para hacerlo transparente. Especialmente vigila el control de flujo por xon/xoff. No lo necesitas. Intenta habilitar el control |
|
|
|
Tutorial de Charles L. Hedrick - 20 de Febrero de 2006
|
| Este trabajo trata fundamentalmente sobre los aspectos "lógicos" de la arquitectura de red. Lo que puede o no puede hacer una red está generalmente determinado por los protocolos que dicha red soporta y la calidad... |
| Cap 3 |
Asignación de direcciones y enrutamiento
|
| |
De que nos quedemos sin direcciones. Sin embargo, tales "interfaces anónimas" pueden dificultar bastante el manejo de la red. Puesto que no tienen dirección, el ##software## de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible obtener información sobre el flujo y los errores |
| Cap 8 |
Configurando el enrutamiento de cada ordenador (II)
|
| |
A en diagrama siguiente), que va a enviar un datagrama al ##host## 128. 6.5.194 (el ordenador C) que se encuentra en una Ethernet distinta (subred 128.6.4). Hay un ##gateway## que conecta ambas subredes, de direcciones 128. 6.5.1 (##gateway## R) ## red 1 red 2 128.6.5 |
| Cap 9 |
Puentes y gateways (I)
|
| |
----- red 6 ## Las redes 1, 2 y 3 están en un edificio. Las redes 4 y 5 están en edificios distintos del campus. La red 6 puede estar en una localización más distante. El diagrama anterior nos muestra que las redes 1, 2 y 3 están conectadas directamente |
|
|
|
Tutorial de Charles L. Hedrick - 27 de Febrero de 2006
|
| Este trabajo trata fundamentalmente sobre los aspectos ''lógicos'' de la arquitectura de red. Lo que puede o no puede hacer una red está generalmente determinado por los protocolos que dicha red soporta y la calidad... |
| Cap 2 |
Asignación de direcciones y enrutamiento
|
| |
El manejo de la red. Puesto que no tienen dirección, el software de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible obtener información sobre el flujo y los errores de la interface |
| Cap 7 |
Configurando el enrutamiento de cada ordenador (II)
|
| |
Los datagramas y, al enviar "peticiones ARP" por ellas, nadie nos responderá. Los proxy ARP se basan en la idea de que los conceptos actúen como proxyes de hosts lejanos. Supongamos que tenemos un host en la red 128.6.5, con direcciones (es el ordenador A en diagrama siguiente), que va a enviar |
| Cap 8 |
Puentes y gateways (I)
|
| |
En edificios distintos del campus. La red 6 puede estar en una localización más distante. El diagrama anterior nos muestra que las redes 1, 2 y 3 están conectadas directamente, y los mecanismos que manejan las conexiones se marcan con "x". El edificio A está conectado a otros edificios en el mismo campus |
|
|
|
Tutorial de Peter Breuer - 03 de Enero de 2007
|
| Configuración de un sistema en el que coexista un cortafuegos con bridging entre interfaces de red. |
| Cap 2 |
¿Qué y por qué (y cómo)?
|
| |
Que el código del puente está justo encima del código de la capa física y que el código del cortafuegos está una capa más arriba, así que el puente y el cortafuegos actúan como si estuvieran ejecutando juntos, «secuencialmente» y no «en paralelo» ( ¡Vaya!). diagrama : -> Entrada-puente -> Entrada |
| Cap 4 |
Cortafuegos
|
| |
Es necesario esto para para ftp (es el servidor el que establece el flujo de datos al final) pero no sé por qué telnet también lo necesita. ipfwadm -I -i accept -P tcp -S 192. 168.2.0/255. 255.255.128 ftp telnet \ -D 0. 0.0.0/0. 0.0.0 Hay un problema específico con algunos demonios |
|
|
