En cada direccin IPv4, alguna porcin de los bits de orden superior representa la
direccin de red. Una red se define como un grupo de hosts con patrones de bits idnticos
en la porcin de direccin de red de sus direcciones.
Tipos de direccionamiento de una IPV4
Dentro del rango de direcciones de cada red IPv4, existen tres tipos de direcciones:
Direccin de red
: la direccin en la que se hace referencia a la red.
Direccin de broadcast
: una direccin especial utilizada para enviar datos a todos
los hosts de la red.
Direcciones host
: las direcciones asignadas a los dispositivos finales de la red.
Direccin de red
La direccin de red es una manera estndar de hacer referencia a una red. sta es una
manera mucho ms conveniente y descriptiva de referirse a la red que utilizando un
trmino como "la primera red". Todos los hosts de la red 10.0.0.0 tendrn los mismos bits
de red. Esta direccin tiene un 0 para cada bit de host en la porcin de host de la
direccin.
Direccin de broadcast
La direccin de broadcast IPv4 es una direccin especial para cada red que permite la
comunicacin a todos los host en esa red. Para enviar datos a todos los hosts de una red,
un host puede enviar un solo paquete dirigido a la direccin de broadcast de la red.
La direccin de broadcast utiliza la direccin ms alta en el rango de la red. sta es la
direccin en la cual los bits de la porcin de host son todos 1.
Unicast, Broadcast, multicast: tipos de comunicacin
En una red IPv4, los hosts pueden comunicarse de tres maneras diferentes:
Unicast:
el proceso por el cual se enva un paquete de un host a un host individual.
Broadcast
: el proceso por el cual se enva un paquete de un host a todos los hosts
de la red.
Multicast
: el proceso por el cual se enva un paquete de un host a un grupo
seleccionado de hosts.
Estos tres tipos de comunicacin se usan con diferentes objetivos en las redes de datos. En
los tres casos, se coloca la direccin IPv4 del host de origen en el encabezado del paquete
como la direccin de origen.
Trfico unicast
La comunicacin unicast se usa para una comunicacin normal de host a host, tanto en
una red de cliente/servidor como en una red punto a punto. Los paquetes unicast utilizan
la direccin host del dispositivo de destino como la direccin de destino y pueden
enrutarse a travs de una internetwork. Sin embargo, los paquetes broadcast y multicast
usan direcciones especiales como la direccin de destino. Al utilizar estas direcciones
especiales, los broadcasts estn generalmente restringidos a la red local.
Transmisin de broadcast
Dado que el trfico de broadcast se usa para enviar paquetes a todos los hosts de la red,
un paquete usa una direccin de broadcast especial. Cuando un host recibe un paquete
con la direccin de broadcast como destino, ste procesa el paquete como lo hara con un
paquete con direccin unicast.
Algunos ejemplos para utilizar una transmisin de broadcast son:
Broadcast dirigido: Se enva un broadcast dirigido a todos los hosts en una red especfica.
Este tipo de broadcast es til para enviar un broadcast a todos los hosts de una red local.
Broadcast limitado: El broadcast limitado se usa para la comunicacin que est limitada a
los hosts en la red local. Estos paquetes usan una direccin IPv4 de destino
255.255.255.255. Los routers no envan estos broadcasts. Los paquetes dirigidos a la
direccin de broadcast limitada slo aparecern en la red local.
Transmisin de multicast
La transmisin de multicast est diseada para conservar el ancho de banda de la red IPv4.
sta reduce el trfico al permitir que un host enve un nico paquete a un conjunto
seleccionado de hosts.
Algunos ejemplos de transmisin de multicast son:
Distribucin de audio y video
Intercambio de informacin de enrutamiento por medio de protocolos de enrutamiento
Distribucin de software
Suministro de noticias
Rangos de Direccin IPV4 reservadas
con el mismo formato decimal punteado que la direccin IPv4. La mscara de subred se
crea al colocar un 1 binario en cada posicin de bit que representa la porcin de red y un 0
binario en cada posicin de bit que representa la porcin de host.
El prefijo y la mscara de subred son diferentes formas de representar lo mismo, la
porcin de red de una direccin. La mscara de subred se configura en un host junto con
la direccin IPv4 para definir la porcin de red de esa direccin. Si la mscara de subred de
un octeto est representada por 255, entonces todos los bits equivalentes de ese octeto
de la direccin son bits de red.
Lgica AND
Dentro de los dispositivos de redes de datos, se aplica la lgica digital para interpretar las
direcciones. Cuando se crea o enva un paquete IPv4, la direccin de red de destino debe
obtenerse de la direccin de destino. Esto se hace por medio de una lgica llamada AND.
Se aplica la lgica AND a la direccin host IPv4 y a su mscara de subred para determinar
la direccin de red a la cual se asocia el host. Cuando se aplica esta lgica AND a la
direccin y a la mscara de subred, el resultado que se produce es la direccin de red.
Operacin AND
AND es una de las tres operaciones binarias bsicas utilizadas en la lgica digital. Las otras
dos son OR y NOT. Mientras que las tres se usan en redes de datos, AND se usa para
determinar la direccin de red. Por lo tanto, slo se tratar aqu la lgica AND.
Los routers usan AND para determinar una ruta aceptable para un paquete entrante. El
router verifica la direccin de destino e intenta asociarla con un salto siguiente. Cuando
llega un paquete a un router, ste realiza el procedimiento de aplicacin de AND en la
direccin IP de destino en el paquete entrante y con la mscara de subred de las rutas
posibles.
Principio de la Divisin de Subredes
La divisin en subredes permite crear mltiples redes lgicas de un solo bloque de
direcciones. Como usamos un router para conectar estas redes, cada interfaz en un router
debe tener un ID nico de red. Cada nodo en ese enlace est en la misma red.
Esto se hace ampliando la mscara para tomar prestado algunos de los bits de la porcin
de host de la direccin, a fin de crear bits de red adicionales. Cuantos ms bits de host se
usen, mayor ser la cantidad de subredes que puedan definirse. Para cada bit que se tom
prestado, se duplica la cantidad de subredes disponibles.
[
editar
] Desventajas
[
editar
] Asignacin de direcciones IP
Dependiendo de la implementacin concreta, el servidor DHCP tiene tres mtodos para
asignar las direcciones IP:
manualmente
, cuando el servidor tiene a su disposicin una tabla que empareja
direcciones MAC con direcciones IP, creada manualmente por el administrador de
la red. Slo clientes con una direccin MAC vlida recibirn una direccin IP del
servidor.
automticamente
, donde el servidor DHCP asigna permanentemente una
direccin IP libre, tomada de un rango prefijado por el administrador, a cualquier
cliente que solicite una.
dinmicamente
, el nico mtodo que permite la reutilizacin de direcciones IP. El
administrador de la red asigna un rango de direcciones IP para el DHCP y cada
ordenador cliente de la
LAN tiene su software de comunicacin
TCP/IP configurado
para solicitar una direccin IP del servidor DHCP cuando su
tarjeta de interfaz de
red se inicie. El proceso es transparente para el usuario y tiene un periodo de
validez limitado.
[
editar
] IP fija
Una
direccin IP fija es una direccin IP asignada por el usuario de manera manual (Que
en algunos casos el ISP o servidor de la red no lo permite), o por el servidor de la red (ISP
en el caso de internet, router o switch en caso de LAN) con base en la
Direccin MAC del
cliente. Mucha gente confunde
IP Fija
con
IP Pblica
e
IP Dinmica
con
IP Privada
.
Una IP puede ser Privada ya sea dinmica o fija como puede ser IP Pblica Dinmica o Fija.
Una IP Pblica se utiliza generalmente para montar servidores en internet y
necesariamente se desea que la IP no cambie por eso siempre la IP Pblica se la configura
de manera Fija y no Dinmica, aunque si se podra.
En el caso de la IP Privada generalmente es dinmica asignada por un servidor DHCP, pero
en algunos casos se configura IP Privada Fija para poder controlar el acceso a internet o a
la red local, otorgando ciertos privilegios dependiendo del nmero de IP que tenemos, si
esta cambiara (fuera dinmica) sera ms complicado controlar estos privilegios (pero no
imposible).
Las
IP Pblicas fijas actualmente en el mercado de acceso a Internet tienen un costo
adicional mensual. Estas IP son asignadas por el usuario despus de haber recibido la
informacin del proveedor o bien asignadas por el proveedor en el momento de la
primera conexin.
Esto permite al
usuario montar servidores web, correo, FTP, etc. y dirigir un nombre de
dominio a esta IP sin tener que mantener actualizado el servidor DNS cada vez que cambie
481.
Al pedir prestado 9 bits para la porcin de host se produce este clculo:
2^9 = 512
LAN de administradores
Para la LAN de administradores, necesitamos adaptar 23 hosts. Esta medida requerir del
uso de 6 bits del host utilizando el clculo: 2^6 - 2.
El siguiente bloque disponible de direcciones que puede adaptar estos hosts es el bloque
172.16.2.128 /26.
Direccin: 172.16.2.128
En nmeros binarios:
10101100.00010000.0000010.10000000
Mscara: 255.255.255.192
26 bits en nmeros binarios:
11111111.11111111.1111111.11000000
Interfaces LAN - Ethernet
La interfaz Ethernet se utiliza para conectar cables que terminan con dispositivos LAN,
como equipos y switches. La interfaz tambin puede utilizarse
conectar routers entre s.
E.Usodeherramientaparalaelaboracindeprototiposderedes.
ELABORACIN DE PROTOTIPOS COMO UNA ALTERNATIVA AL
CICLO DE VIDA DEL
DESARROLLO
DE SISTEMAS
Algunos analistas argumentan que la elaboracin de prototipos se debe considerar como
una alternativa para el ciclo de vida del desarrollo d sistemas (SDLC). Recuerde que el
SDLC, tratado en el capitulo 1, es un enfoque lgico y sistemtico que se sigue en el
desarrollo de
sistemas de informacin
.
Las quejas relativas al
proceso del SDLC se centran en dos preocupaciones
interaccionadas. La primera preocupacin es todo el tiempo que se requiere para pasar
por el ciclo de vida del desarrollo. Conforme aumenta la
inversin de tiempo del analista,
el costo del sistema entregado se incrementa proporcionalmente.
La segunda preocupacin sobre el uso del SDLC es que los requerimientos del usuario
cambian a travs del tiempo. Los requerimientos del usuario evolucionan durante el
considerable intervalo existente entre el
anlisis de los requerimientos del usuario y la
fecha en que se entrega el sistema final. Por lo tanto, debido al extenso ciclo del
desarrollo, el sistema resultante podra ser crtico por abordar deficientemente los
requerimientos de informacin del usuario actual.
Un corolario al problema de mantenerse al tanto de los requerimientos de informacin es
la
teora de que los usuarios realmente no saben lo que hacen o no lo desean sino hasta
que vean algo tangible .en el SDLC tradicional, una vez que se entrega un sistema, con
frecuencia es demasiado tarde para modificarlo.
Para resolver estos
problemas
, algunos analistas proponen la elaboracin de prototipos
como una alternativa al ciclo de vida del desarrollo de sistemas. Cuando la elaboracin de
prototipos se usa de esta forma, el analista reduce efectivamente el tiempo entre la
determinacin de los requerimientos de informacin y la entrega de un sistema funcional.
Adems, el uso de elaboracin de prototipos en lugar de SDLC tradicional podra resolver
algunos problemas como el de identificar con presicion los requerimientos de informacin
del usuario.
Ente las desventajas de sustituir el SDLC por la elaboracin de prototipos esta la de
configuracin prematura de un sistema antes de que el problema u oportunidad en
cuestin se entienda completamente. Tambin, el uso de la elaboracin de prototipos
como una Alternativa podra producir un sistema aceptado por
grupos especficos de
usuarios pero inadecuados para las necesidades globales del sistema.
El enfoque que apoyamos aqu es usar la elaboracin de prototipos como una parte del
SDLC tradicional. Desde esta perspectiva, la elaboracin de prototipos se considera como
un
mtodo
adicional y especializado para determinar los requerimientos de los usuarios.
Si los costos del tiempo de programadores y analistas y los del equipo que utilizaran estn
dentro del
presupuesto
, se puede proceder a la elaboracin del prototipo. La elaboracin
de prototipos es una excelente forma de facilitar la
integracin del sistema de informacin
con el sistema principal de la
organizacin
.
otros mdulos de sistemas. Las caractersticas del mdulo que se juzgan de menor
importancia se omiten intencionalmente en el prototipo inicial.
Construccin rpida del prototipo- La rapidez es esencial para la elaboracin exitosa del
prototipo de un
sistema de informacin
. Recuerde que unas de las quejas expresadas en
contra de el CDLC tradicionales es que el intervalo entre la
discriminacin de
requerimientos y la entrega de un sistema completo es demasiado largo para satisfacer
eficazmente las cambiantes necesidades del usuario.
Los analistas pueden usar la elaboracin de prototipos con el fin de reducir esta brecha
utilizando las
tcnicas tradicionales de recopilacin de informacin para determinar con
presin los requerimientos de infomacin que surjan sobre la marcha, y a continuacin
tomar rpidamente las decisiones que den lugar o un modelo funcional. De hecho, el
usuario de y utiliza el sistema muy temprano en el SDLC en lugar de esperar hasta que el
sistema se termine para practicar con l.
La preparacin de un prototipo operacional, con rapidez y en las etapas tempranas del
SDLC , permite al analista comprender mejor cmo desarrollar el resto del
proyecto
. Al
mostrar a los usuarios en las primeras etapas del proceso como se ejecutan en la realidad
algunas partes del sistema, la elaboracin rpida de prototipos evita que se dediquen
demasiados
recursos a un proyecto que a la larga podra ser imposible de concretar. Ms
adelante, cuando se explique el RAD, usted ver nuevamente la importancia de la
construccin rpida de sistemas.
Modificacin del prototipo. Un tercer lineamiento para desarrollar el prototipo es que su
construccin debe soportar modificaciones. Hacer un modificable el prototipo significa
crearlo en mdulos que no sean demasiado interdependientes. Si se observa este
alineamiento, se encontrar menos
resistencia cuando sea necesario realizar cambios al
prototipo. Generalmente, el prototipo se modifica varias veces al pasar por diversas
interacciones.
Los cambios en el prototipo deben propiciar que el sistema se acerque cada vez ms a lo
que los usuarios consideren importante. Cada modificacin necesita otra
evaluacin por
parte de los usuarios.
El prototipo no es un sistema terminado. Abordar la face de elaboracin de prototipos con
la idea de que el prototipo requerir modificaciones es una
actitud positiva que demuestra
a los usuarios cun necesaria es una retroalimentacin para mejorar el sistema.
Enfoques pioneros de Martn para el RAD En la figura 6.5 usted puede ver nuestra
conceptualizacion de la fases originales del RAD de James Martin; en la primera fase
Martin explica la
planeacin de requerimiento. Aqu los usuarios de alto nivel deciden qu
funciones
deben incluir la aplicacin.
En la segunda fase, llamada fase de diseo de usuarios, Martin caracteriza a los usuarios
como ocupados en discutir los aspectos no tcnicos del diseo del sistema, con la ayuda
de los analistas. La fase del taller del diseo del RAD incorpora la fase del usuario y la de
construccin es una, debido a que la
naturaleza muy interactiva y visual del proceso de
diseo y refinacin est ocurriendo de una forma interactiva y participativa.
En la fase de construccin se realizan muchas actividades diferentes. Cualquier diseo que
se cree en la fase anterior se mejora ms con la herramienta del RAD. Tan pronto como las
nuevas funciones estn disponibles, se muestran a los usuarios para la interaccin,
comentarios y revisin. Con las
herramientas del RAD, los analistas pueden hacer cambios
continuos en el diseo de las aplicaciones.
La cuarta y ltima fase de Martin, la fase de cierre, la aplicacin recientemente
desarrollada reemplazar a la anterior. Mientras est ejecutndose en paralelo con la
aplicacin anterior, la nueva prueba, los usuarios son entrenados y los
procedimientos de
la organizacin
se cambian antes de que ocurra el cierre.
Herramientas de
software para el RAD
Como usted poda esperar, por lo regular las
herramientas de software para el RAD son las mas nuevas, con frecuencias orientadas a
objetos. Algunos ejemplos son
programas muy conocidos como
Microsoft Acces,
Microsoft Basic, visual C++Microsoft. Net. (Vase el captulo 18 para una explicacin ms
detallada del enfoque orientado a objetos.)
Una forma en que las herramientas difieren entre s est en sus capacidades para dar
soporte a las aplicaciones
cliente
/
servidor (por ejemplo, MS
Access no da soporte,
Visual
Basic si lo da) as como tambin su facilidad de uso y el nivel de conocimientos de
programacin que se requieren. La mayora de las aplicaciones del RAD se usan para
aplicaciones pequeas basadas en PC, aunque su verdadero
poder podra radicar en las
aplicaciones cliente/ servidor que necesitan ejecutarse otra vez de mltiples plataformas.
Aunque hay identificadas casi tantas fases diferentes del RAD as como hay analistas, las
cuatros fases propuestas por Martin planeacin de requerimientos, diseo del usuario, la
construccin y cierre son tiles. Examinemos cada una con ms detalle, comparndolas y
contrastndolas con la elaboracin de las caractersticas de la elaboracin prototipos
clsica y el SDLC tradicional.
Figura 6.6
El taller de diseo del RAD en comparacin con el enfoque del SDLC
El flujo global de funcionamiento de la aplicacin. As, cuando los usuarios aprueban este
diseo, estn conviviendo en una representacin del modelo visual, no solo en un diseo
conceptual representado en papel, como tradicionalmente se hace.
La fase de implementacin del RAD es, en muchas formas, menos estresantes que otras
debido a que los usuarios han ayudado a disear los aspectos de
negocios del sistema y
saben perfectamente que cambios se harn. Ay pocas sorpresas, y el
cambio es algo a lo
que se le da la bienvenida. Con frecuencia, cuando se utiliza el SDLC y los analistas estn
separados de los usuarios, ay mucho tiempo entre el desarrollo y el diseo. Durante este
periodo, los requerimientos pueden cambiar y los usuarios se pueden sorprender si el
producto
final es diferente del que se anticipo durante muchos meses.
Cuando utilizar el RAD En su
funcin de analista, necesita aprender tantos enfoques y
herramientas como sea posible que lo ayuden a hacer mejor su trabajo. Ciertas
aplicaciones y trabajo de sistemas darn lugar a ciertas metodologas. Considere utilizar
RAD cuando:
1.
2.
haya razones de negocio urgentes para acelerar una parte del desarrollo de la
aplicacin; o
4. cuando est trabajando con una nueva aplicacin de
comercio electrnico y su
equipo de desarrollo crea que el negocio puede beneficiarse ampliamente sobre sus
competidores siendo innovador si esta aplicacin est entre la primera en aparecer
en la Web; o
5. cuando los usuarios sean maduros y estn altamente comprometidos con las metas
organizacionales.
3.
Desventajas del RAD Las dificultades con el RAD, como con otras clases de elaboracin de
prototipos, se originan debido a que los analistas de sistemas intentan apresurar
demasiado el proyecto. Suponga que se contratan dos carpinteros parra construir dos
cobertizos de
almacenamiento para dos vecinos. El primer carpintero sigue la
filosofa del
SDLC, mientras que el segundo la del RAD.
El primer carpintero es sistemtico, cataloga cada herramienta, cada podadora y cada uno
de los muebles del patio para determinar el tamao correcto del cobertizo, disea un
plano del cobertizo y anota las especificaciones para cada parte de
madera y
hardware
. El
carpintero construye el cobertizo con poca prdida y tiene la
documentacin precisa sobre
cmo fue construido el cobertizo por si cualquiera quisiera construir otro parecido,
repararlo o pintarlo del mismo
color
.
El segundo carpintero va directo al proyecto y calcula el tamao del cobertizo, consigue un
camin de madera y hardware, construye una
estructura y discute con el dueo de la
propiedad las modificaciones necesarias si no estn disponibles ciertos
materiales y hace
un viaje para devolver la madera que no se usa. El cobertizo se construye rpidamente,
pero si no se hace un plano nunca existe la documentacin.
PROGRAMACIN EXTREMA
La programacin extrema (XP) es un enfoque de desarrollo de software (tratando el
captulo 3) que adopta lo que generalmente designamos como prctica de desarrollo de
software aceptable y las lleva al extremo. Por ejemplo, la retroalimentacin es importante
para los programadores, analistas, diseadores, usuarios y
computadoras (como vern en
el captulo 14). As que la programacin extrema usa ciclo de retroalimentacin cada vez
ms rpido e intenso, que proporcionan ms informacin.
La
administracin de proyecto es importante ( como se vio en el capitulo 3), de tal manera
que la programacin extrema intenta definir rpidamente un
plan global del sistema,
Cuatro valores de XP Hay cuatro valores que crean un entorno en el cual se pueden servir
adecuadamente diseadores y negocios. Debido a que con frecuencia hay una tensin
entre lo que los diseadores hacen a corto plazo y lo que es comercialmente deseable a
largo plazo, es importante que est consciente de apoyar valores que formarn una base
para colaborar juntos en un proyecto de software. Como se
muestra la figura 6.7, los
cuatro valores son
comunicacin
, sencillez y retroalimentacin y valenta.
Empecemos con la comunicacin. Cada esfuerzo humano tiene la posibilidad de fallar en
la comunicacin
. Los
proyectos de los sistemas que requieren una actualizacin constante
y un diseo tcnico son especialmente propensos a dichos errores. Agregue a este
proyecto fechas lmite ajustadas, jerga especializada y el estereotipo de que los
programadores prefieren hablar con las
mquinas que con las personas, y usted tiene los
ingrediente para algunos problemas serios de comunicacin. Los proyectos pueden ser
retrasados; se puede resolver el problema equivocado; se castiga a los programadores
incluso por mencionar a los gerentes que hay problemas; las personas abandonan o se
unen al proyecto a la mitad sin estar al corriente; y as continua la letana.