Capitulos 8-17 Resumen - INGENIERIA DEL SOFTWARE: UN ENFOQUE PRACTICO PDF

Preview

Summary

Resumen de los capitulos 8 al 17 del libro Ingenieria de Software Un Enfoque Practico de Pressman...

Description

Capítulo 8 1. Cuando se "escribe" un programa, se diseña software? En que difieren el diseño del software y la codificación? Respuesta: cuando se escribe un programa, no se está diseñando. El diseño es un paso anterior a la codificación. El diseño permite modelar el sistema o producto que se va a construir. El diseño es el lugar en el que se establece la calidad del software. 2. Si el diseño no es un programa (y no lo es) entonces Que es? Respuesta: El diseño de software agrupa el conjunto de principios, conceptos y prácticas que llevan al desarrollo de un sistema o producto de alta calidad. El diseño del software comienza una vez que se han analizado y modelado los requerimientos, es la última acción de la ingeniería de software dentro de la actividad de modelado y prepara la etapa de construcción (generación y prueba de código). 3. Como se evalúa la calidad del diseño del software? Respuesta: McGlaughlin sugiere 3 características que funcionan como guía para evaluar un buen diseño. 

 

Debe implementar todos los requerimientos explícitos contenidos en el modelo de requerimientos y dar cabida a todos los requerimientos implícitos que desean los participantes Debe ser una guía legible y comprensible para quienes generan el código y para los que lo prueban y dan el apoyo posterior. Debe proporcionar el panorama completo del software y abordar los dominios de los datos, las funciones y el comportamiento desde el punto de vista de la implementación.

6. Defina con sus propias palabras a la arquitectura del software. Respuesta: La arq de soft aluda a "la estructura general de este y a las formas en las que ésta da integridad conceptual a un sistema". La arq es la estrucutura de organizacion de los componentes de un programa (modulos), la forma en que estos interactuan y la estructura de datos que utilizan. 8. Describa con sus propias palabras la separacion de problemas. hay algun caso en el que no sea apropiada la estrategia divide y venceras? como afecta esto al argumento a favor de la modularidad?

Respuesta: la división de problemas es un concepto de diseño que sugiere que cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos susceptibles de resolverse u optimizarse de manera independiente. A la hora de dividir en módulos (mientas más pequeño el modulo es mas fácil construcción), hay que tener en cuenta un factor determinante que es el costo asociado a la integración de dichos módulos. Existe un número M de módulos que arrojarían el mínimo costo de desarrollo, pero no se dispone de las herramientas necesarias para predecir M con exactitud. 14. Rediseñar significa que se modifica todo el diseño en forma iterativa? si no es asi que significa? Respuesta: no, rediseñar es el proceso de cambiar un sistema de software en forma tal que no se altera el comportamiento externo del código (diseño), pero si se mejora su estructura interna. 15. Describa en breves palabras cada uno de los 4 elementos del modelo de diseño. Respuesta: El modelo de diseño incluye 4 elementos distintos. Conforme de desarrolla cada uno, surge una visión más completa del diseño. Elemento de diseño de datos crea un modelo de datos o información que se representa en un nivel de abstracción elevado. El elemento arquitectónico emplea información obtenida del dominio de la aplicación, del modelo de requerimientos y de los catálogos disponibles de patrones y estilos para obtener una representación estructural completa del software. Los elementos del diseño de la interfaz modelan las interfaces internas y externas y la del usuario. Los elementos en el nivel de componentes definen cada uno de los módulos que constituyen la arquitectura.

Capítulo 9 9.2 Diga dos o tres ejemplos de aplicaciones para cada uno de los estilos arquitectónicos mencionados en la sección 9.3.1 Arquitectura centrada en datos  

Navegador web – Servidor web Sistema de facturación

Arquitectura de Flujo de Datos  

Datamining Data were house

Arquitectura de llamar y regresar  

Máquina Virtual Programas modulares

Arquitectura Orientada a objeto  

Aplicaciones Móviles Aplicaciones web

Arquitectura en capas  

Sistema Operativo Aplicaciones de Red

9.3 Algunos de los estilos arquitectónicos citados en la sección 9.3.1 tienen naturaleza jerárquica, mientras que otros no. Elabore una lista de cada tipo. ¿Cómo se implementarían los estilos arquitectónicos que no son jerárquicos? Jerárquicos  

Arquitectura llamar y regresar Arquitectura en Capas

No jerárquicos   

Arquitectura centrada en datos Arquitectura orientada a objetos Arquitectura de flujo de datos

Una de las posibles implementaciones de los modelos no jerárquicos, es que sean combinados con uno de los modelos jerárquicos, para tener así una estructura ordenada y poder tener una visión general más organizada.

Capítulo 10 10.1. En ocasiones resulta difícil definir el término componente. Primero dé una definición general y luego otras más explícitas para el software orientado a objetos y para el tradicional. Por último, elija tres lenguajes de programación con los que esté familiarizado e ilustre la manera en la que cada uno define un componente. Un componente es una parte modular, desplegable y sustituible de un sistema, que incluye la implantación y expone un conjunto de interfaces. Desde un punto de vista orientado a objetos, un componente es un conjunto de clases que colaboran. Cada clase dentro de un componente se elabora por completo para que incluya todos los atributos y operaciones relevantes para su implantación. Además deben definirse todas las interfaces que permiten que las clases se comuniquen con otras clases de diseño. En el contexto de la ingeniería de software tradicional, un componente es un elemento funcional de un programa que incorpora la lógica de procesamiento, las estructuras de datos internas que se requieren y una interfaz que permite la invocación del componente y el paso de los datos.

10.2. ¿Por qué son necesarios los componentes de control en el software tradicional y por qué en general no se requieren en el orientado a objetos? En general no se requieren en el software orientado a objetos debido a que en éste sólo se elaboran clases de análisis (para los componentes relacionados con el dominio del problema) y clases de infraestructura (para componentes que dan servicios de apoyo para el dominio del problema); en cambio, en el software tradicional se encuentra un componente llamado módulo, que además de funcionar como componente del dominio del problema y como componente de infraestructura, debe funcionar como componente de control, que coordine la invocación de todos los demás componentes del dominio del problema. 10.3. Describa con sus propias palabras el PAC. ¿Por qué es importante crear abstracciones que sirvan como interfaz entre los componentes? El principio Abierto-Cerrado (PAC), nos dice que un componente debe especificarse de manera tal que pueda extenderse, sin necesidad de modificarlo. Es importante crear abstracciones porque sirven como búfer entre la funcionalidad que sea probable extender y la clase de diseño en sí. 10.4. Describa el PID con sus propias palabras. ¿Qué pasaría si un diseñador dependiera demasiado de las concreciones?

El principio de inversión de la dependencia (PID), dice que es mejor depender de las abstracciones, que de las concreciones. Mientras más dependa un componente de otros componentes concretos (y no de abstracciones) más difícil será ampliarlo.

10.7. ¿Es razonable decir que los componentes del dominio del problema nunca deben tener acoplamiento externo? Si está de acuerdo, ¿qué tipos de componente tendrían acoplamiento externo? No es razonable, ya que el acoplamiento externo sucede cuando un componente se comunica con componentes de infraestructura, y este tipo de acoplamiento es necesario. El software debe tener comunicación interna y externa. 10.9. ¿Son lo mismo el refinamiento stepwise y el rediseño? Si no es así, ¿en qué difieren? En ambos, se mejora la estructura interna del diseño, pero lo logran de maneras distintas: el refinamiento stepwise dando en forma escalonada mas detalles (desde un nivel de abstracción alto hasta uno de nivel bajo), y el rediseño se lleva a cabo una vez terminado el diseño, simplificando y optimizando el diseño o código, sin que cambie su función o comportamiento. 10.10. ¿Qué es un componente de webapp? Un componente de webapp es un paquete cohesivo de contenido y funciones que brindan al usuario final alguna capacidad solicitada. 10.14. ¿Por qué es importante la “lotificación” en el proceso de revisión del diseño en el nivel de componentes?

Porque la comprensión humana mejora cuando se encuentran patrones lógicos que es fácil reconocer, lo que se logra con el uso de un número limitado de construcciones lógicas. Éstas construcciones permitirían al lector reconocer elementos de procedimiento de un módulo, sin necesidad de leer el diseño o el código línea por línea.

Capítulo 11 11.12. Dé algunos ejemplos que ilustren por qué la variabilidad del tiempo de respuesta llega a ser importante. La variabilidad se refiere a la desviación del tiempo de respuesta promedio. Cuando la variabilidad es significativa, el usuario siempre se sale de balance, e interpreta que algo no anda bien.

Estas son preguntas que aparecen al costado del libro…

¿Qué se necesita saber sobre el ambiente cuando comienza el diseño de la interfaz de usuario? • ¿Dónde se encontrará físicamente la interfaz? • ¿El usuario estará sentado, de pie o haciendo otras tareas no relacionadas con la interfaz? • ¿El hardware de la interfaz cumple las restricciones de espacio, iluminación o ruido? • ¿Hay consideraciones especiales de factores humanos generadas por los factores ambientales? La información recabada como parte del análisis se utiliza para crear un modelo de análisis de la interfaz. Con este modelo como base comienza la acción de diseñar.

¿Cómo se aprende lo que el usuario quiere de la interfaz? Entrevistas. Información de ventas. El personal de ventas habla con los usuarios de manera regular y recaba información que ayuda al equipo de software a clasificarlos y a entender mejor sus requerimientos. Información de mercadotecnia. El análisis del mercado es invaluable para la definición de segmentos del Mercado

Información de apoyo. El equipo de apoyo habla a diario con los usuarios. Constituye la fuente de información más probable acerca de lo que funciona y lo que no, lo que les gusta a los usuarios y lo que les desagrada, qué características generan preguntas y cuáles son fáciles de usar.

Capítulo 12 Analice las tres “partes” de un patrón de diseño y dé un ejemplo concreto de cada uno en algún campo distinto del software. Un patrón de diseño es una regla de tres partes, que expresa una relación entre cierto contexto, un problema y una solución. El contexto permite al lector entender el ambiente en el que reside el problema y qué solución sería apropiada en dicho ambiente. El problema es aquello que se quiere resolver. La solución es aquello que nos permite dar por concluido al problema. Un determinado problema puede tener muchas soluciones.

¿Cuál es la diferencia entre un patrón no generativo y uno generativo? Un patrón no generativo describe un contexto y un problema, pero no ofrece ninguna solución clara. Un patrón generativo es un patrón que describe un aspecto importante y repetitivo de un sistema, y que provee una manera de construir dicho aspecto dentro de un sistema de fuerzas que son únicas en un contexto determinado. Idealmente, podría usarse un conjunto de patrones de diseño generativos para “generar” una aplicación o sistema basado en computadora cuya arquitectura permita adaptarlo al cambio. ¿En qué difieren los patrones arquitectónicos de los patrones de componentes?

Los patrones arquitectónicos describen problemas de diseño de base amplia que se resuelven con el empleo de un enfoque estructural. Los patrones de componentes (también llamados patrones de diseño) se enfocan a problemas asociados con el desarrollo de subsistemas y componentes, así como a la manera en la que se comunican entre sí y su ubicación dentro de una arquitectura mayor.

¿Qué es estructura y en qué difiere de un patrón? ¿Qué es un idioma y en qué se diferencia de un patrón? Una estructura no es un patrón arquitectónico, sino un esqueleto con varios “puntos de conexión” (también llamados ganchos o ranuras) que permiten adaptarlo a un dominio de problema específico. Los puntos de conexión permiten integrar clases o funciones específicas de un

problema dentro del esqueleto. En un contexto orientado a objetos, una estructura es un conjunto de clases que cooperan.

Un lenguaje de patrón agrupa un conjunto de patrones, cada uno de los cuales se describe con el uso de un formato estandarizado e interrelacionado para mostrar cómo colaboran los

patrones para resolver problemas en un dominio de aplicación.

Capítulo 13 13.1) ¿Por qué es insuficiente para elaborar webapps la filosofía de diseño del “ideal artístico”? ¿Hay algún caso en el que ésa sea la filosofía por seguir? Es insuficiente porque cuando una webapp tiene funciones complejas o el tamaño de ella incluye miles de objetos y clases de análisis el diseño no puede ser ligero como propone este enfoque. 13.7) ¿Cuál es la diferencia entre la arquitectura del contenido y la de una webapp? Arquitectura de contenido: se centra en la manera en que los objetos de contenido se estructuran para su presentación y navegación. Arquitectura de webapp: se aboca a la forma en que la aplicación queda estructurada para administrar la interacción con el usuario, manejar tareas de procedimientos y navegar. 13.11) ¿Cuál es la diferencia entre la sintaxis de navegación y la semántica de ésta? Sintaxis de navegación: es cómo se organiza la navegación ya sea en pestañas, mapa de sitio, etc

Semántica de navegación: es la forma de navegación. Unidades semánticas de navegación (USN) y fdN (formas de navegar).

Capítulo 17 1) Con sus palabras describa la diferencia entre verificación y validación. ¿Ambas usan los métodos de diseño de casos de prueba y estrategias de pruebas? Respuesta: Verificación es el conjunto de actividades que garantizan que el software este implementado correctamente para una aplicación o función determinada. Validación es el conjunto de tareas que me aseguran que el software que se está construyendo siga los requerimientos del cliente para que este lo apruebe como correcto. Ambas usan los mismos métodos de diseño de casos de prueba y estrategias de pruebas. 2) Mencione algunos problemas que pueden asociarse con la creación de un grupo de prueba independiente. ¿Los GPI y el SQA se integran con las mismas personas? Respuesta: GPI (Grupos de Prueba Independientes), no dependen de la organización de desarrollo de software sino que reportan a entidades externas de calidad. 4) ¿Por qué un módulo altamente acoplado es difícil para la prueba de unidad? Respuesta: Mientras crece el acoplamiento de un módulo, es difícil realizar la prueba de unidad debido a que el módulo altamente acoplado tendrá un alto grado de dependencia de otros módulos, y al realizar una prueba de cualquier tipo en especial la prueba de unidad, es bastante complicado realizarla. 8) ¿Quién debe realizar la prueba de validación: el desarrollador o el usuario del software? Justifique su respuesta.

Respuesta: El que debe realizar la prueba de validación es el usuario de software, ya que es el que determina los requerimientos y lineamientos principales sobre los cuales el desarrollador lleva a cabo el diseño y construcción del software. La prueba es con fin de averiguar si el software desarrollado es del gusto y cumple con los requerimientos del usuario....