Cliente – Servidor

El modelo cliente-servidor consiste en un sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma más adecuada.

El término Cliente/Servidor fue usado por primera vez en 1980 para referirse a PC’s en red. Este modelo Cliente/Servidor empezó a ser aceptado a finales de los 80’s. Su funcionamiento es sencillo: se tiene una máquina cliente, que requiere un servicio de una máquina servidor, y éste realiza la función para la que está programado (nótese que no tienen que tratarse de máquinas diferentes; es decir, una computadora por sí sola puede ser ambos cliente y servidor dependiendo del software de configuración).

El Modelo Cliente-Servidor

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma.

En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio).

En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son más adecuadas a sus características.

Si esto se aplica tanto a clientes como servidores se entiende que la forma más estándar de aplicación y uso de sistemas Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces gráficas de usuario; mientras que la administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto puede variar).

En otras palabras la arquitectura Cliente/Servidor es una extensión de programación modular en la que la base fundamental es separar una gran pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar su mantenimiento.

Esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.

Patrón arquitectónico para el desarrollo de sistemas distribuidos.

·         Distribuye una aplicación entre 2 o más componentes especializados cuya ejecución se distribuye entre 1 o más equipos.

·         Define dos tipos de entidades diferenciadas (asimétricas) que se responsabilizan de acciones diferentes: clientes y servidores. Especifica 2 tipos de procesos con roles diferenciados.

·         Define un modelo de interacción basado en el concepto de servicio implementado sobre un dialogo petición-respuesta. Cliente inicia el dialogo mediante el envío de peticiones. Servidor presta el servicio y responde las peticiones recibidas

·         Especifica el modo en que se sincronizan los procesos.

Cliente (parte activa)

·         Demanda servicios a los servidores.

·         Se asume que cada petición deberá obtener respuesta.

·         Diseñado para soportar la interacción con el usuario final.

Servidor (parte pasiva)

·         Espera las peticiones de los clientes.

·         Procesa esas peticiones y envía una respuesta.

·         Diseño orientado a maximizar la eficiencia.

Características de los servidores.

Componente del sistema que presta servicios a los clientes.

Gestiona y comparte sus recursos con los clientes a los que sirve.

Suele tener restricciones especiales respecto a rendimiento, fiabilidad, escalabilidad y seguridad:

·         Capacidad suficiente para atender múltiples clientes.

·         Fallos en el servidor son críticos e invalidan el sistema.

·         El número de clientes (peticiones) puede ser muy variable y aumentar si así se requiere.

·         Evitar comprometer la seguridad de los recursos o datos gestionados y de los clientes.

Características de los clientes.

Componente del sistema que interactúa con el usuario.

No comparte sus recursos con otros clientes (en general).

No suelen tener restricciones especiales respecto a rendimiento, fiabilidad y escalabilidad:

·         No suele requerir equipos de altas prestaciones.

·         Fallo en un cliente no afecta al resto del sistema.

Debe dar soporte a restricciones relativas a ergónoma  (facilidad de uso) y seguridad (evitar comprometer los demás componentes)

Categorías de Servidores

Ya se ha desarrollado una gran variedad de servidores. La siguiente lista ampliada se ha extraído de:

Servidores de archivos. Un servidor de archivos proporciona archivos para clientes. Estos servidores se utilizan todavía en algunas aplicaciones donde los clientes requieren un procesamiento complicado fuera del rango normal de procesamiento que se puede encontrar en bases de datos comerciales. 

Servidores de bases de datos. Los servidores de bases de datos son computadoras que almacenan grandes colecciones de datos estructurados. Por ejemplo, un banco utilizaría un servidor de bases de datos para almacenar registros de clientes que contienen datos del nombre de cuenta, nombre del titular de la cuenta, saldo actual de la cuenta y límite de descubierto de la cuenta. Una de las características de las bases de datos que invalidan la utilización de los servidores de archivos es que los archivos que se crean son enormes y ralentizan el tráfico si se transfirieran en bloque al cliente.

Servidores Web. Los documentos Web se almacenan como páginas en una computadora conocida como servidor Web. Cuando se utiliza un navegador(browser) para ver las páginas Web normalmente pincha sobre el enlace en un documento Web existente. Esto dará como resultado un mensaje que se enviará al servidor Web que contiene la página. Este servidor responderá entonces enviando una página a su computadora, donde el navegador pueda visualizarlo. De esta manera los servidores Web actúan como una forma de servidor de archivos, administrando archivos relativamente pequeños a usuarios, quienes entonces utilizan un navegador para examinar estas páginas.

Servidores de impresión. Los servidores de impresión dan servicio a las solicitudes de un cliente remoto. Estos servidores tienden a basarse en PCs bastante baratos, y llevan a cabo las funciones limitadas de poner en cola de espera las peticiones de impresión, ordenar a la impresora que lleve a cabo el proceso de impresión e informar a las computadoras cliente que ya ha finalizado una petición de impresión en particular.

Servidores de correo. Un servidor de correo gestiona el envío y recepción de correo de un grupo de usuarios. Para este servicio normalmente se utiliza un PC de rango medio. Existen varios protocolos para el correo electrónico. Un servidor de correo estará especializado en utilizar solo uno de ellos.

Software intermedio (middleware)

Hasta el momento probablemente ya tenga la impresión de que la comunicación entre cliente y servidor es directa. Desgraciadamente, esto no es verdad: normalmente existe por lo menos una capa de software entre ellos. Esta capa se llama software intermedio (middleware).

Arquitectura cliente – servidor

Clientes pesados / Servidores ligeros: La mayor parte de la funcionalidad  de la aplicación se implementa en el cliente. 

• Los servidores son mecanismo de acceso a recursos compartidos. 
• Mayor flexibilidad para aplicaciones que implementan nuevas funcionalidades.

„             Ejemplos: Servidores de bases de datos o servidores de ficheros.

Clientes ligeros / Servidores pesados: La mayor parte de la funcionalidad se implementa en los servidores.

• Incrementar la reusabilidad del código.
• Son más fáciles de desplegar y administrar.
• Se basan en servidores más abstractos que reducen el flujo por la red.
• En vez de proporcionar datos, exportan procedimientos.

„       Ejemplos: Servidores de transacciones y servidores web.

Ingeniería del software de sala limpia

Sala limpia es un método de ingeniería de software propuesto en los años 80 por Harlan Mills, es una técnica que puede dar lugar a un software de calidad extremadamente alta. Es un resultado de la combinación del modelo convencional de ingeniería de software, métodos formales, demostraciones de corrección y estadística de especificaciones para el aseguramiento de calidad (SQA).

Emplea la especificación de estructura de cajas para el modelado de análisis y diseño, haciendo hincapié en la verificación de la corrección, más que en la comprobación, como mecanismo fundamental para encontrar y eliminar errores. Se aplica una comprobación estadística de uso para desarrollar la información relativa a la tasa de fallos necesaria para certificar la fiabilidad del producto software. La filosofía de sala limpia es un enfoque riguroso de la ingeniería del software. Se trata de un modelo de proceso del software que hace hincapié en la verificación matemática de la corrección, y en la certificación de la fiabilidad del software. El resultado final es una tasa de fallo extremadamente baja, que sería difícil o imposible de conseguir  empleando métodos menos formales.

Importancia del método de sala limpia.

Los errores conllevan doble trabajo. Trabajar el doble lleva más tiempo y es más caro. ¿No sería maravilloso poder reducir dramáticamente la cantidad de errores (fallos informáticos) que se cometen en el diseño y construcción del software? Esto es lo que promete la ingeniería del software de sala limpia.

Cuando el software falla en el mundo real, suelen abundar los peligros a largo plazo así como los peligros inmediatos. Los peligros pueden estar relacionados con la seguridad humana, con pérdidas económicas o con el funcionamiento efectivo de una infraestructura social y de negocios. La ingeniería del software de sala limpia es un modelo de proceso que elimina los defectos antes de que puedan dar lugar a riesgos graves.

En la aplicación de este método de sala limpia se realizan las siguientes tareas:
Planificación de Incrementos. Permite calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras el desarrollo progresa. El acercamiento incremental evita los riesgos inherentes integración tardía en el ciclo de desarrollo.

 Recolección de requisitos. El propósito del proceso del análisis de requisitos es :

• Definir requisitos para el producto de software, incluyendo función, uso, ambiente, y funcionamiento. 
• Obtener un acuerdo con el cliente en los requisitos como la base para la función y especificación del uso.

 Especificación de la estructura de cajas. Tres tipos especiales de funciones matemáticas son importantes en el desarrollo a Sala limpia, debido a su correspondencia y correlación en el proceso de descomposición y verificación. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposición, además se puede incluir funcionabilidad y orientación a objeto.

 Diseño Formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Dan los objetivos, los participantes, los criterios de entrada, las tareas, la verificación, las medidas y los criterios comunes de la salida en los procesos, así como elementos de proceso común.

Verificación de Corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección aplicadas primero al diseño y después al código. El propósito del proceso de la verificación de la corrección, es verificar la corrección del incremento del software usando técnicas matemáticas.

Generación de Código, inspección y verificación. Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen la lengua de programación más adecuada. 

Planificación de la comprobación estadística, Comprobación estadística de utilización y Certificación. El propósito del proceso estadístico de prueba y de certificación es demostrar la aptitud del software para el uso en un experimento estadístico formal. La "aptitud para el uso" se define con respecto a los modelos de uso y a las metas de la certificación empleados en el proceso de prueba. Las metas de certificación, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en términos tales como índice de confiabilidad del software.

Cajas utilizadas en el modelo.

Caja negra

 Es una abstracción que describe la forma en que un sistema responde a unos estímulos. Las abstracciones de datos, las operaciones que manipulan estas abstracciones, se ven encapsuladas por la caja negra. Al igual que una jerarquía de clases, la especificación de caja negra puede mostrara las jerarquías de utilización en que las cajas de nivel inferior heredan las propiedades de las cajas de nivel inferior dentro de la estructura de árbol.

Caja de estado

Es una generalización sencilla de una máquina de estado. Un estado es algún modo observable de comportamiento del sistema. A medida que se produce el procesamiento, el sistema va respondiendo a sucesos (estímulos) efectuando una transición que parte del estado actual y llega a algún nuevo estado. A medida que se efectúa la transición, puede producirse una acción.

Utiliza una abstracción de datos para determinar la transición al estado siguiente, y la acción (respuesta) que se producirá como consecuencia de la transición.

La caja de estado contiene una caja negra.

Caja transparente
Está íntimamente relacionada con el diseño de procedimientos y con la programación estructurada. Es importante tener en cuenta que la especificación de procedimientos descrita en la jerarquía de caja transparente se puede demostrar a efectos de corrección. 

Refinamiento de la estructura de cajas

No ha alcanzado la mayor simpatía quizás por tres razones:

• La creencia de que es muy teórica y radical para aplicarla en un proyecto de software real.
• No promueve una revisión unitaria (modular o por clases) sino un control estadístico de calidad.
• Requiere revisiones muy rigurosas en cada etapa del ciclo, y la industria del software no ha alcanzado tal madurez.

Ingeniería de sistemas

La Ingeniería de Sistemas se refiere a todos los aspectos del desarrollo de sistemas basados en computadora, tanto del hardware como del software y los procesos de diseño y distribución de sistemas. La Ingeniería de Software es solo parte de este proceso.

La ingeniería de sistemas se define como la aplicación efectiva de esfuerzos científicos y de ingeniería para transformar una necesidad operativa en una configuración definida de un sistema mediante el proceso iterativo de análisis de requisitos, la selección del concepto, y asignación, síntesis, soluciones de compromiso y optimización del diseño, prueba y evaluación.

En pocas palabras la ingeniería de sistemas es la aplicación de las ciencias matemáticas y físicas para desarrollar sistemas que utilicen económicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad.

Una de las principales diferencias de la ingeniería de sistemas respecto a otras disciplinas de ingeniería tradicionales, consiste en que la ingeniería de sistemas no construye productos tangibles. Mientras que los ingenieros civiles podrían diseñar edificios o puentes, los ingenieros electrónicos podrían diseñar circuitos, los ingenieros de sistemas tratan con sistemas abstractos con ayuda de las metodologías de la ciencia de sistemas, y confían además en otras disciplinas para diseñar y entregar los productos tangibles que son la realización de esos sistemas.

Para poder realizar un sistema basado en computadora se hace uso de varios elementos del sistema como:

Procedimientos: Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.

Documentación: Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.

Software: Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido.

Hardware: Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real.

Personas: Usuarios y operadores del hardware y software.

Unidad I: Introducción a la ingeniería del software

Contenido temático

Cuestionario elaborado por:  MBA. Tania Sequeira.
                                                          Docente Universitario
                                                          Escuela Ingeniería UPOLI.

1.Mediante las técnicas (cuadro sinóptico, dibujo o marco lógico conceptual) explique las características del software

2. Ejemplifique cada una de las aplicaciones del software.

Software de sistemas

Son los que software que están más próximos al hardware, la función de estos programas es servir al desarrollo o al funcionamiento de otros programas.

Ej.:

·         Sistemas operativos

·         Herramientas de programación (compiladores, ensambladores, etc...)

·         Controladores de dispositivos

Software de gestión

Estos programas utilizan grandes cantidades de información almacenadas en base de datos, además ayuda para la toma de decisiones.

Ej.:

·         Las transacciones que realizan los bancos.

Software de PC

Son las aplicaciones que se encuentran comúnmente en las computadoras personales.

Ej.:

·         Procesadores de textos

·         Hojas de cálculos

·         Juegos

Software empotrado

Son aquellos  que están instalados en productos  industriales como la electrónica.

Ej.:

·         Celulares

·         Microonda

·         Televisor

3. Mediante un dibujo, establezca los escenarios donde se reflejan los mitos y realidades del software, en cuanto a gestión, cliente y equipo desarrollador.

Mitos de gestión

Mito: Tenemos un libro que está lleno de estándares y procedimientos para construir software.

Realidad: ¿Pero se usa?, ¿conocen los trabajadores su existencia?, ¿refleja las practicas modernas en desarrollo del software?, ¿es completo? En muchos casos la respuesta a todas estas preguntas es no.

Mito: Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas, después de todo les compramos las computadoras mas nuevas.

Realidad: Se necesita mucho más que el último modelo de  computadora, herramientas de software, las cuales son mucho más importantes que el hardware para conseguir buena calidad y productividad, de que nos sirve un hardware de calidad si el software no lo es.

Mito: Si se falla en la planificación, se puede adelantar el tiempo perdido añadiendo más personal al equipo.

Realidad: dado a que no es un proceso mecánico añadir gente a un proyecto de software retrasado lo retrasa aun más, debido a que habría que capacitar al nuevo personal.

Mitos de cliente

Mito: Una declaración general de los objetivos del software es suficiente para comenzar a realizarlo.

Realidad: Una mala definición inicial es la principal causa de la falta de calidad de un software. Para evitar esto se debe de tener una exhaustiva comunicación el cliente con el analista.

Mito: Los requerimientos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente ya que el software es flexible.

Realidad: El impacto del cambio varía según el tiempo en que se introduzca.

Mitos de equipo desarrollador

Mito: Lo único que se entrega al terminar el proyecto es el programa funcionando.

Realidad: El programa es solo una parte de una configuración del software, también se tiene que realizar un manual de usuario.

4.       Explique las capas de desarrollo de software.

La primera capa es calidad

Consiste en la planificación de la calidad que tendrá el software, esto ira basado en normativas de calidad. Lo que se procura es realizar un software con la mejor calidad posible.

La segunda capa es el proceso

Consiste en cómo se realizara el proceso de desarrollo de software del software, ya sea en la obtención de la información, análisis, desarrollo, prueba del software, etc.

La tercera capa es Métodos

Son los métodos que se utilizaran para el desarrollo del software. Existen diferentes métodos para la elaboración del software se tiene que elegir la apropiada.

La cuarta capa es herramientas

Consiste en las herramientas que se utilizaran, ya sea en el proceso de obtención de la información como encuestas, entrevistas, etc. O en el proceso de desarrollo de software que serian los lenguajes de programación.

5. Testifique en cuales situaciones ha aplicado los modelos de desarrollo de software.

Unidad II: Gestión de proyectos de software.

1.Realizar un mural acerca de ofertas de cargos del área de informática que han publicado las empresas.

2.Del proyecto realizado a nivel de análisis y diseño estructurado(DC, DFD, Ficheros físicos) y orientados a objetos (D. casos de uso, de actividades e iteración), calcule las métricas orientadas al tamaño, punto de función y ampliadas así como las métricas de calidad.

3. Dado la tabla de riesgos (modificada a nuestra realidad económica) establezca ejemplos de cada categoría.

4. Preparar material didáctico acerca de la garantía de la calidad y gestión de configuración del software.

Concepto de calidad

La calidad se refiere a la concordancia con los requisitos funcionales y de rendimiento establecidos inicialmente.

Importante también para la calidad es que haya concordancia con los estándares especificados y con las características implícitas de todo producto software.

Si realizamos un producto con mala calidad (“se cuelga”, da errores, es difícil de usar, etc.) los clientes no quedan satisfechos.

El control de calidad es un conjunto de inspecciones, revisiones y pruebas utilizados a lo largo del proceso de desarrollo de software para verificar que se cumplen los requisitos fijados.

La generación de buenos documentos de lo que se va realizando es esencial para facilitar el proceso de control y para garantizar la calidad.

Los costes relativos para encontrar y reparar un defecto aumentan dramáticamente a medida que se cambia de prevención a detección y desde el fallo interno al externo.

Entre los costes de prevención se incluyen:

• ·         planificación de la calidad,
• ·         revisiones técnicas formales,
• ·         equipo de pruebas,
• ·         formación del equipo.

Entre los costes de evaluación se incluyen:

• ·         inspección del proceso y entre procesos,
• ·         mantenimiento del equipo,
• ·         pruebas.

Factores y métricas de calidad

• ·         Corrección. Grado en que un programa satisface los requisitos.
• ·         Fiabilidad. Grado en que se espera que un programa lleve a cabo sus funciones esperadas.
• ·         Eficiencia. Cantidad de recursos empleados para llevar a cabo su misión.
• ·         Integridad. Grado en que puede controlarse el acceso al software o a los datos por personal no autorizado.
• ·         Facilidad de uso. Esfuerzo requerido para usar el software desarrollado.
• ·         Facilidad de mantenimiento. Esfuerzo requerido para localizar y reparar un error en el software.

Revisiones del software

• ·         “Filtro” para el proceso de ingeniería del software.
• ·         Se aplican en varios momentos durante el desarrollo del software y sirven para detectar errores y defectos que puedan así ser eliminados.
• ·         Ventaja: “Purifican” las actividades de ingeniería del software.
• ·         Inconveniente: Retardan el “flujo” de las actividades del desarrollo.
• ·         No todas son efectivas.

Revisión técnica formal (RTF). Es el filtro más efectivo desde el punto de vista de garantizar la calidad.

Se puede definir como una actividad llevada a cabo por los ingenieros del software que busca y repara errores en la actividad actual antes de pasar a la siguiente actividad dentro de nuestra planificación.

Los objetivos de una RTF son:

• ·         Descubrir errores en la función, la lógica o la implementación de cualquier software.
• ·         Verificar que el software alcanza sus requisitos.
• ·         Garantizar que el software cumple los estándares.
• ·         Conseguir uniformidad en el desarrollo.
• ·         Hacer proyectos manejables (la complejidad crece exponencialmente con el tamaño).

En una reunión hay varias restricciones:

• ·         No debe haber más de cinco personas.
• ·         Debe prepararse por adelantado.
• ·         No debe durar más de dos horas.

Una RTF se hace de una pequeña parte específica, no se revisa todo, sino partes pequeñas (modularidad).

La RTF la dirige el jefe de revisiones, que no es el mismo que el jefe del proyecto.

Un registrador apunta todo lo que se analiza en la RTF.

Estándar ISO 9001

Estándar: (DRAE). Que sirve como tipo, modelo, norma, patrón o referencia.

ISO: International Organization for Standardization.

Adoptado por 130 países.

Si un producto no tiene la etiqueta ISO 9001 los usuarios dudan de su calidad.

Obtener la certificación ISO 9001 depende de todos los integrantes de la empresa, aparte de ser sinónimo de buenos productos.

Las actividades de GCS sirven para:

• ·         Identificar el cambio.
• ·         Controlar el cambio.
• ·         Garantizar su adecuada implementación.
• ·         Informar del cambio a todos aquellos que puedan estar interesados.

Hay que distinguir mantenimiento y GCS.

• ·         El mantenimiento es un conjunto de actividades de IS que se producen después de que el software se haya entregado al cliente y esté en funcionamiento.
• ·         La GCS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto y termina sólo cuando el software queda fuera de circulación.

Control de versiones

El control de versiones es una combinación de procedimientos y herramientas para gestionar versiones de los objetos de configuración creados durante el proceso del software.

Cada ECS tiene un conjunto de atributos que lo definen, bien sea un número de versión o una cadena de variables.

Los atributos de la versión N serán los mismos que los de la N+1, sólo habremos de cambiar los atributos de fecha de edición, número de versión, etc.

Imagen

Cuando se realizan cambios muy significativos se cambia el primer número, si es menos relevante, el segundo, y así dependiendo del número de dígitos considerado.

Imagen

Auditora de la configuración

• ·         Las RTF se centran en la corrección técnica del elemento modificado.
• ·         Una auditoría de configuración del software completa la revisión técnica formal al comprobar características que generalmente no tiene en cuenta la revisión.

Las tareas que se llevan a cabo son:

• ·         Examinar cada ECS para detectar consistencia con otros.
• ·         Detectar omisiones, redundancias, colisiones, efectos secundarios no deseados, ...
• ·         Ver si se ha registrado y divulgado cada cambio.
• ·         Comprobar si se han seguido los estándares.
• ·         Garantizar la calidad y hacer un informe de ello.

Si la auditoría es informal se incluye en la RTF (ahorro de tiempo), pero si es formal se hace independientemente.