1) Análisis y Diseño

¿Qué son el análisis y diseño orientado a objetos?

Ambos se encargan de situar el dominio del problema y su solución dentro de la perspectiva de objetos.
AOO presta especial atención a encontrar y describir los objetos o conceptos en el dominio del problema.
DOO presta especial atención a la definición de los objetos software y en cómo colaboran para satisfacer los requisitos.
Define la lógica del Soft a implementar en un lenguaje de programación
El Diseño es una representación significativa de ingeniería de algo que se va a construir.
Es el núcleo técnico de la ingeniería del software (diseño, generación de código y pruebas) y se aplica independientemente del modelo
de diseño de SW que se utilice.

Brevemente indique qué diferencia existe entre el Modelo del Análisis y el Modelo del Diseño.
- El modelo de análisis debe lograr tres objetivos:
 Describir lo que requiere el cliente
 Establecer la base para la creación de un diseño de software
 Definir un conjunto de requisitos que se puedan validar al final del desarrollo.
- El Modelo de diseño, pone énfasis en las descripciones detalladas y de alto nivel de la solución lógica, y como
estas satisfacen los requerimientos y restricciones. comienza con el modelo de los requisitos (que surge del
Modelo de Análisis), luego se obtienen los modelos detallados para las 4 áreas o niveles

Para entender y administrar la complejidad de un sistema se debe dividir el mismo en partes o fragmentos que se pueden
representar como modelos que describan y abstraigan sus aspectos esenciales.
 Modelo estático: describe las propiedades estructurales del sistema. Comprende el modelo conceptual, diagrama
de clases del sistema y los contratos.
 Modelo dinámico: describe las propiedades de comportamiento de un sistema. Comprende el diagrama de
secuencia del sistema, diagramas de colaboración y diagramas de actividades.

¿Con qué modelos está constituido el modelo global de un sistema y con qué se relacionan cada uno de ellos?
El modelo global de un sistema se constituye por:
a. Modelo de análisis: se relaciona con la investigación del dominio y del ámbito del problema, pero no con la
solución.
b. Modelo de diseño: se relaciona con la solución lógica del problema.

¿Cuáles son, según Pressman, las áreas o niveles del diseño?

Cada uno de los elementos del modelo de análisis proporciona la información necesaria para crear los cuatro modelos de
diseño que se requieren para una especificación completa de diseño.
a. Diseño de datos: transforma el modelo del dominio de información en las estructuras de datos que se necesitarán
para implementar el software.
b. Diseño arquitectónico: define la relación entre los elementos estructurales principales del software, los estilos,
patrones de diseño y restricciones.
c. Diseño de la interfaz: describe la forma en que el soft. se comunica con los usuarios. Una interfaz implica un flujo de
información (p.ej: datos y/o control) y un tipo específico de comportamiento
d. Diseño a nivel de componentes: transforma los elementos estructurales de la arquitectura del SW en una descripción
procedimental de los componentes del SW. Toma como base la información de la Especificación de Proceso,
Especificación de Control y del Diagrama de Transición de Estado del Modelo de Análisis.

¿Cuáles son los objetivos que persigue el correcto diseño de un sistema?

Los dos objetivos que persigue un correcto diseño de sistema son:
● La confiabilidad: cuando un sistema no produce fallas costosas o peligrosas al usarse.
● El fácil mantenimiento: decimos que al instalar un sistema generalmente se usa por períodos largos, en promedio
de 1 a 6 años. Las acciones para reducir el mantenimiento de un sistema son:
- definir con mayor precisión los requerimientos del usuario.
- preparar lo mejor posible la documentación del sistema.
- Procedimientos estándar para el diseño
- Correcto uso de las herramientas
¿Qué elementos debe contener una buena carpeta de diseño de un sistema? Enúncielos y de una breve
descripción de cada uno de ellos.
Cuando el diseño de un sistema de información está completo, las especificaciones son documentadas en una forma que
esbozan las características de la aplicación, a saber:
- Descripción del ámbito global: surge de la especificación del sistema y del modelo de Análisis.
- Cuadros de despliegue: las descripciones de las entradas y salidas del sistema a un nivel de detalle.
- Diseño o estructuras de los datos: todos los datos de los registros que componen los archivos, o tablas, así como
los diagramas relacionados con la base de datos. Especifica toda la estructura externa o interna de datos, y la
referencia cruzada que conecta objetos de datos con archivos específicos.
- Sistemas de codificación: decodificación de información codificada.
- El diseño arquitectónico o Especificaciones de los programas: cuadros, tablas y descripciones gráficas de los
módulos y componentes del software junto con la interacción entre cada uno de ellos, indicando su jerarquía.
- Especificación de procedimientos: procedimientos planificados para instalar y operar el sistema cuando esté
instalado.
- Plan de desarrollo: cronogramas que indican los tiempos necesarios para el desarrollo de las actividades.
- Costo del paquete: gastos anticipados para cada una de las etapas y componentes del costo, con proyecciones
de costo y beneficio.
- Referencia Cruzada de Requisitos: que servirá para:
● establecer que todos los requisitos se satisfacen mediante el diseño del software.
● indicar cuáles son los componentes críticos para la implementación de requerimientos específicos.
Se debe aclarar que la carpeta debe contener toda aquella información que haga a un mejor conocimiento del esfuerzo,
las restricciones, limitaciones a considerar, etc.

¿Qué pauta o pautas que considera para el rediseño de un sistema existente y qué implica esto?
En la medida de que un sistema tenga en la producción un gran mantenimiento, esto no cumple con la performance que
debería tener. Si el índice de mantenimiento de un sistema es alto, entonces el sistema debería ser rediseñado y esto
implica volver a pasar por todas las etapas del ciclo de vida del sistema.

¿Qué significa ‘meta del sistema’ y cuál es la diferencia con las funciones del sistema?
Las metas son los objetivos propuestos para el sistema. Se deben especificar las ventajas y/o facilidades que brindará el
mismo (rapidez, controles).
Las funciones son lo que el sistema tendrá que hacer: registrar, calcular, capturar, autorizar.

Indique qué diferencia existe entre los conceptos “funciones del sistema” y “atributos del sistema”. Dé 4
ejemplos del último.
Las “funciones del sistema” son lo que este habrá de hacer (ej: autorizar pagos) y los “atributos del sistema” son las
cualidades no funcionales que a menudo se confunden con aquellas (ej: facilidad de uso, tolerancia a fallas, tiempo de
respuesta, plataforma del sistema).

¿Qué debe tener en cuenta el analista para iniciar un nuevo sistema?

Se llega a esta conclusión cuando se agota la vida útil del sistema, que es cuando empieza a fallar continuamente y el
mantenimiento es alto y costoso. Por lo tanto es más barato hacer uno nuevo.

¿Qué es granularidad?
La granularidad es el grado en que un sistema se descompone en partes, los componentes de grano grueso tienden a
tener un comportamiento más fino que los componentes de grano fino, ya que los componentes de grano grueso hacen
más cosas, tienden a ser más grandes. En general podemos decir: “Los componentes de grano grueso son más fáciles
de usar, y los componentes de grano fino son más reutilizables”.

¿Qué es un diseño de un subsistema?

Un diseño de un subsistema es una descomposición abstracta de un sistema en un componente de grano grueso, cada
uno de los cuales puede ser un sistema importante por sí mismo.
¿Qué son los papeles o funciones de la organización?
Consiste en identificar los papeles de las personas en los procesos: el cliente, representación de venta, ingeniería de
software, etc. En las perspectivas AOO, este paso nos recuerda el análisis del dominio OO que expresamos como un
modelo conceptual.
Este modelo representa varias cosas en el dominio, no solo los papeles de las personas, sino todas las cosas de interés.

¿Cuáles son las categorías en que se dividen las funciones?

- Evidente: debe realizarse y el usuario deberá saber que se ha realizado. Por ejemplo, realizar pago, alta.
- Oculta: debe realizarse aunque no es visible para los usuarios. Por ejemplo, guardar.
- Superflua: es opcional; su inclusión no repercute significativamente en el costo ni a otras funciones. Por ejemplo,
edición, eliminación.

¿Cuáles son los objetivos del diseño de la entrada de un sistema? Dé una breve explicación de los mismos.
 Control de la cantidad de la entrada: se debe disminuir la cantidad de entrada
 Evitar los retrasos: se debe evitar los cuellos de botellas
 Evitar los errores en los datos: disminuir el volumen de datos a ingresar o detectar los errores lo más rápido
posible
 Evitar los pasos adicionales: reducir los pasos a seguir
 Mantener la sencillez del proceso: alcanzar todos los objetivos ya mencionados en la forma más sencilla posible

¿Qué son los requerimientos?

Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta primaria es identificar y
documentar lo que en realidad se necesita en una forma que claramente se lo comunique al cliente y a los miembros del
equipo de desarrollo.
Se recomiendan los siguientes artefactos en esta fase:
 Panorama general: breve descripción del sistema.
 Cliente: parte interesada en desarrollar el sistema.
 Metas: ventajas y/o necesidades que brindara el sistema (ej: pago rápido de los clientes, control automático del
inventario).
 Funciones del sistema: son las “acciones que el sistema debe hacer”. Para verificar si “x” es una función se
utiliza la siguiente oración: “el sistema deberá hacer “x”
se clasifican en :
o Evidentes: debe realizarse y es visible para el usuario.
o Oculta: debe realizarse y no es visible para el usuario.
o Superflua: es opcional y no repercute en otras funciones.
 Atributos del sistema: son cualidades no funcionales que a menudo se confunden con las funciones. (ej: facilidad
de uso, tiempo de respuesta, plataformas, tolerancia a fallas, etc.).

PRINCIPIOS Y CONCEPTOS DEL DISEÑO

Roger S. Pressman

 En el Proceso de Diseño no deberá utilizarse “orejeras”. Hay que tener en cuenta enfoques alternativos basados
en: requisitos del problema, recursos disponibles y los conceptos de diseño existentes.
 El diseño deberá poderse rastrear hasta el modelo de análisis. Debe poderse rastrear cómo se han satisfecho
los requisitos por el modelo de diseño.
 El diseño no deberá inventar nada que ya esté inventado. Se debe utilizar patrones ya existentes o adaptar estos
al problema.
 El diseño deberá minimizar la distancia intelectual entre el SW y el problema como si de la misma vida real se
tratara. La estructura del diseño del SW imita la estructura del dominio del problema.
 El diseño deberá presentar uniformidad e integración. Las reglas de estilo y formato deben definirse antes de
encarar un trabajo. Las interfaces entre componentes deben definirse cuidadosamente.
 El diseño deberá estructurarse para admitir cambios. Debe ser flexible.
 El diseño deberá estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos
o condiciones de operación aberrantes. Deberá ser adaptable para recibir cambios y terminar su CVU en forma
suave.
 El diseño no es escribir código y escribir código no es diseñar.
 El diseño deberá evaluarse en función de la calidad mientras se va creando, no después de terminarlo. Para
evaluar esto se dispone de conceptos y medidas de diseño que se verá más adelante.
 El diseño deberá revisarse para minimizar los errores conceptuales (semánticos). Deberá asegurarse de haber
afrontado los elementos conceptuales principales antes de preocuparse por la sintaxis del modelo de diseño.

Conceptos del diseño

Abstracción: se debe concentrar en el problema a algún nivel de generalización sin tener en consideración los datos
irrelevantes de bajo nivel. En el nivel más alto se utilizará el lenguaje del entorno del problema y en el más bajo se
establece la solución para implementarlo (generar el código fuente).
• Abstracción procedimental: es una secuencia nombrada de instrucciones que tiene una función específica y
limitada, p.e: abrir
• Abstracción de datos: es una colección nombrada de datos que describe un objeto de datos, p.e.: en abrir sería
puerta, que se compone de una serie de atributos que describen ese objeto. Entonces por añadidura la
abstracción abrir hace uso de los atributos de puerta.
• Abstracción de Control: implica un mecanismo de control de programa sin especificar los datos internos. P.e: el
semáforo de sincronización que se utilizar para coordinar las actividades en un sistema operativo.
Refinamiento: El paso a paso es una estrategia de diseño descendente que se realiza para refinar los niveles de detalle
procedimentales hasta alcanzar las sentencias del lenguaje de programación. Estos pasos implican decisiones de
diseño.
Modularidad: El SW se divide en componentes nombrados y abordados por separado, llamados generalmente módulos,
que se integran para satisfacer los requisitos del problema. Esto es recomendable siempre y cuando no se modularice de
más, porque en este caso la simplicidad de este concepto se verá abrumada por la complejidad de la integración.
Arquitectura del SW: Es la estructura jerárquica de los componentes del programa, la manera en que estos interactúan
y los datos que van a utilizar. En un sentido más amplio, los “componentes” se pueden generalizar para representar los
elementos principales del sistema y sus interacciones.
Jerarquía de Control: también denominada “estructura del programa” representa la organización de los componentes de
programa (módulos) e implica una jerarquía de control.
2) Arquitectura

¿Qué es la arquitectura del software?

La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema. Consiste en un conjunto de
patrones y abstracciones coherentes que proporcionan el marco. Se selecciona y diseña con base en objetivos
(prefijados para el sistema) y restricciones (limitaciones para implementar los sistemas).
Incluye el comportamiento del sistema, especialmente en función de responsabilidades de gran escala de los sistemas y
subsistemas, y sus colaboraciones, la arquitectura comprende las motivaciones o fundamentos de por qué el sistema
está diseñado de la forma que está.

La arquitectura del sistema afecta a:

 Rendimiento: la arquitectura debería identificar las operaciones críticas en un pequeño número de subsistemas
con tan poca comunicación como sea posible entre éstos.
 Protección: debería usarse una arquitectura estructurada en capas, con los recursos más críticos protegidos en
las capas más internas y aplicando una validación de seguridad de alto nivel en dichas capas.
 Seguridad: la arquitectura debería diseñarse para que las operaciones relacionadas con la seguridad se
localizarán en un único subsistema o en un pequeño número de subsistemas.
 Disponibilidad: la arquitectura debería diseñarse para incluir componentes redundantes y para que sea posible
reemplazar y actualizar componentes sin detener el sistema.
 Mantenibilidad: la arquitectura del sistema debería diseñarse usando componentes independientes de grano fino
que puedan modificarse con facilidad.

¿Qué entiende por diseño arquitectónico? (Sommerville)

“El diseño arquitectónico es el proceso creativo en el que se intenta establecer una organización del sistema que
satisfaga los requerimientos funcionales y no funcionales del propio sistema.”
El proceso de diseño inicial que identifica estos subsistemas y establece un marco para el control y comunicación de los
subsistemas se llama diseño arquitectónico.
Los diagramas de bloques presentan un dibujo de alto nivel de la estructura del sistema.

Ventajas del diseño arquitectónico según Sommerville

Tres ventajas de diseñar y documentar la arquitectura del software:
1. Comunicación entre los participantes (stakeholders): la arquitectura constituye una presentación de alto nivel,
utilizada como punto de discusión por varios participantes.
2. Análisis del sistema: realizar la arquitectura tempranamente, requiere realizar un análisis. Las decisiones que se
tomen tendrán un gran efecto sobre el cumplimiento de los requerimientos críticos, como los de rendimiento,
fiabilidad, y mantenibilidad.
3. Reutilización a gran escala: Un modelo de arquitectura del sistema, es por lo general la misma para sistemas con
requerimientos similares, por lo tanto, soportan la reutilización de software a gran escala

¿Qué es un modelo de repositorio?

Todos los datos compartidos se almacenan en una base de datos central a la que pueden acceder todos los
subsistemas.
- Cada subsistema mantiene su propia base de datos. Los datos se intercambian con otros subsistemas mediante el
paso de mensajes entre ellos.
Un modelo basado en una base de datos compartida se denomina modelo de repositorio.
Ventajas y desventajas.
1. eficiente de compartir grandes cantidades de datos. Sin embargo, los subsistemas deben estar acordes con el
modelo de datos del repositorio.
2. Los subsistemas que producen datos no necesitan conocer cómo se utilizan sus datos por otros subsistemas.
Sin embargo, mientras se genere un gran volumen de información la evolución se torna complicada.
3. Las actividades tales como copias de seguridad, protección, control de acceso y recuperación de errores están
centralizadas. Sin embargo pueden tener distintos requerimientos de protección, recuperación y políticas de
seguridad. Puede haber problemas con la redundancia de datos y las inconsistencias.

Modelo Cliente-Servidor
El sistema se organiza como un conjunto de servicios y servicios asociados, más unos clientes que acceden y usan los
servicios. Los principales componentes de este modelo son:
- Un conjunto de servidores que ofrecen servicios a otros subsistemas..
- Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores.
- Una red que permite a los clientes acceder a los servicios.
La ventaja más importante del modelo cliente-servidor es que es una arquitectura distribuida. Es fácil añadir un nuevo
servidor e integrarlo con el resto del sistema o actualizar los servidores de forma transparente sin afectar al resto del
sistema.
Puede no haber un modelo de datos compartidos entre los servidores, y los subsistemas pueden organizar sus datos de
formas diferentes. Esto significa que los modelos de datos específicos pueden establecerse para cada servidor con el fin
de optimizar su rendimiento.

Modelo de capas (Sommerville).

Organiza el sistema en capas, cada una de las cuales proporciona un conjunto de servicios. Cada capa puede pensarse
como una maquina abstracta cuyo lenguaje se define por los servicios proporcionados por la capa y se lo usa para
implementar el siguiente nivel de la máquina abstracta.
La aproximación por capas, soporta el desarrollo incremental de Sistemas. Soporta bien los cambios y es portable.
Una capa puede reemplazarse por una capa equivalente. Cuando las interfaces de la capa cambian, o se añaden nuevas
facilidades a una capa, solo se ve afectada la capa adyacente.
La desventaja es que la estructuración de los sistemas puede resultar difícil. Las capas internas pueden proporcionar
facilidades básicas que son requeridas por todos los niveles, lo que implica que la capa mas externa del sistema, no
solamente dependa de su predecesora inmediato.

Tipos:
 Bicapa: En el diseño de arquitectura de 2 capas, colocamos la lógica de aplicaciones junto con las definiciones de
las ventanas; que leen y escriben directamente en la base de datos. En el esquema de 2 capas no existe una
intermedia que separe la lógica.
Desventajas de la arquitectura de 2 capas:
 Imposibilidad de representar la lógica en componentes aislados; lo cual dificulta reutilizar el sw.
 Es difícil distribuir la lógica de las aplicaciones en un equipo diferente.

 Tricapa: abarca una interfaz para el usuario y el almacenamiento persistente de datos, las mismas se reseñan así:
A) Capa de presentación: ventanas, reportes, etc.
B) Capa de lógica de aplicaciones: tareas y reglas que rigen el proceso.
C) Capa de almacenamiento: mecanismos de almacenamiento persistentes de los datos.

La ventaja reside en que la misma aísla la Capa de Lógica de la Aplicación y la convierte en una capa intermedia bien
definida, reservada únicamente para la lógica del software. Actualmente es la arquitectura más común utilizada en los
sistemas informáticos.
Cabe destacar, que la capa intermedia de lógica de aplicaciones, puede dividirse en:
a. Entidades del Dominio: integrada por las clases que representan los objetos del dominio.
b. Servicios de Aplicación: que incluye las clases que contienen funciones que no pertenecen a ninguna entidad
del dominio. Por ejemplo, podemos incluir la generación de reportes, los servicios de seguridad, interaccion
con la BD y comunicaciones con sistemas externos, y los coordinadores de casos de uso.

 Multicapas: Se caracterizan por estar compuestas de estratos y particiones. Los estratos representan las capas
verticales. Las particiones representan las divisiones horizontales de subsistemas relativamente paralelos en una
capa. Esta arquitectura se obtiene al dividir las responsabilidades de la arquitectura de 3 capas. Por ejemplo, la capa
de servicios puede estar dividida en particiones tales como Seguridad y Persistencia
Motivos para su utilización:
- Aislamiento de la capa de Lógica de las Aplicaciones en componentes independientes, susceptibles a
reutilizarse.
- Distribución de las capas en varios nodos físicos de cómputo y en varios procesos, que mejora el
desempeño, la coordinación y el compartir la información en un sistema cliente-servidor.
- Asignación de los diseñadores que construyan determinadas capas.
 Multicapa Laxa: permite que los componentes de una capa interactúen con cualquier componente de otra capa
de nivel inferior.
El uso de este diseño puede mejorar el rendimiento porque el sistema no tiene que realizar redundancia de llamadas
entre capas. Sin embargo no proporciona un buen nivel de aislamiento entre las capas por lo que se hace más difícil el
sustituir una capa de bajo nivel sin afectar a más capas de nivel superior.

Vista Lógica:

Patrón Capas
Una capa es un elemento de gran escala, a menudo compuesto de varios paquetes o subsistemas.
Este patrón se relaciona con la arquitectura lógica.
Capas típicas:
 Presentación: ventanas de la GUI, informes.
 Aplicación: gestiona las peticiones de la capa de presentación, flujo de trabajo, estado de la sesión, transiciones
a ventanas/páginas, concentración/transformación de diferentes datos para la presentación.
 Dominio: gestiona las solicitudes de la capa de aplicación, implementación de las reglas de dominio.
 Servicios Técnicos: servicios técnicos de (relativamente) alto nivel y frameworks, Persistencia, Seguridad.
 Base: servicios técnicos de bajo nivel, utilidades y frameworks; estructuras de datos, hilos de ejecución, librerías
matemáticas, ficheros, base de datos, y E/S de redes.

Patrones
 Patrones de arquitectura: relacionados con el diseño a gran escala y de grano grueso, se aplican típicamente
durante las primeras iteraciones cuando se establecen las estructuras y conexiones más importantes. Ejemplo,
los patrones capas.
 Patrones de diseño: relacionados con el diseño de los objetos y frameworks de pequeña y mediana escala.
Conecta los elementos de gran escala que se definen mediante los patrones de arquitectura. Por ejemplo, el
patrón Fachada, que se puede utilizar para promocionar la interfaz de una capa a la siguiente

¿Bajo qué circunstancias se puede utilizar el concepto de “paquete” en UML y para qué sirve?
UML tiene un mecanismo (los paquetes), que permiten describir los grupos de elementos, o subsistemas. Un paquete es
un conjunto de cualquier tipo de elementos o modelo: clases, casos de uso, diagramas de colaboración u otros paquetes.
Un paquete se muestra gráficamente como una carpeta con etiquetas. Los paquetes subordinados se incluyen en su
interior.
Cuando el modelo de dominio crece puede llegar a ser tan amplio que quizás sea conveniente dividirlo en paquetes que
incluyen conceptos fuertemente relacionados, esto sirve de ayuda para mejorar la comprensión y para abordar trabajo de
análisis en paralelo
En la siguiente figura, vemos los agrupamientos lógicos de la Arquitectura Multicapas utilizando los Diagramas de
Paquetes de UML. A este diagrama le podemos llamar “Diagrama de Paquetes de la Arquitectura”.

Diagrama de Paquetes:
Mecanismos de UML para agrupar elementos del modelo y tratarlos como conjunto.
Representa la lógica del problema o del sistema.
Muestran información estática.
Se pueden utilizar líneas de dependencia para mostrar el acoplamiento entre los paquetes o los tipos de los paquetes.
Vista Fisica: Diagrama de despliegue utilizado para modelar el hardware mediante nodos, indicando las relaciones
entre ellos.

Dependencia entre paquetes

Si un elemento del modelo depende de algún modo de otro, se podría representar la dependencia con una relación de
dependencia, descripta por una línea con punta de flecha. Una dependencia entre paquetes indica que los elementos del
paquete dependiente conocen o están acoplados de algún modo con los elementos del paquete destino.

¿Cómo se particiona el Modelo del Dominio?

Para particionar en paquetes, ponga juntos los elementos que en el Modelo del Dominio:
1. Se encuentran en la misma área de interés –estre-chamente relacionados por conceptos u objetivos-
2. están juntos en una jerarquía de clases
3. participan en los mismos casos de uso
4. están fuertemente asociados

Servicios de alto nivel

 Entre los paquetes de servicios de alto nivel, podemos citar a:
 Reportes
 Interfaces de bases de datos
 Mecanismos de seguridad
 Pautas de comunicaciones entre procesos
 Preparados todos ellos con tecnología orientada a objetos.
 Normalmente, estos paquetes son desarrollados por los diseñadores de las aplicaciones.

Servicios de bajo nivel

 Los servicios de bajo nivel, en cambio, ofrecen prestaciones básicas, como la manipulación de ventanas y
archivos, y se pueden adquirir a un proveedor, u obtenerse de bibliotecas del lenguaje que se utilice.
 Las bibliotecas de soporte permiten crear ventanas, definir coordinadores de aplicaciones, acceder a bases de
datos y archivos, comunicaciones entre procesos, etc.

¿Qué entiende por modelo de referencia? (sommerville)

Son modelos más abstractos y describen una clase más amplia de sistemas.
Constituyen un modo de informar a los diseñadores sobre la estructura general de esta clase de sistemas. Los modelos
de referencia normalmente se obtienen a partir de un estudio del dominio de la aplicación.
Representan una arquitectura ideal que incluye todas las características que los sistemas podrían incorporar.

Organización del sistema (sommerville):

 Repositorio de datos.
 Servicios y servidores compartidos.
 Maquina abstracta o estilo por capas funcionales.
3) UML

¿Qué es UML?
Son las siglas del lenguaje unificado para la construcción de modelos; es una notación con la cual se construyen
sistemas por medio de conceptos OO. Permite expresar un modelo de análisis utilizando una notación de modelado con
unas reglas sintácticas, semánticas y prácticas.
Reglas que lo definen:
- Sintaxis: nos dice cómo mostrar y combinar los símbolos.
- Semántica: nos dice lo que significa cada símbolo y cómo interpretarlo, solo o combinado con otros.
- Prácticas: definen el significado de los símbolos a través de los cuales se obtiene el modelo y se hace
comprensible para otras personas (construcción de frases claras y comprensibles).

Vistas en UML:
- Del usuario: representa el sistema (producto) desde la perspectiva de los usuarios (actores) -> Caso de Uso.
- Estructural: datos y funcionalidad se muestran desde dentro del sistema. -> Modelo del Dominio.
- Del Comportamiento: representa los aspectos dinámicos o comportamiento del sistema
- De Implementación: representa aspectos estructurales y de comportamiento tal y como van a ser
implementados.
- Del entorno: aspectos estructurales y de comportamiento en el que el sistema a implementar se representa.

¿Qué es un modelo y un artefacto?

Los modelos son las partes en las que podemos dividir los sistemas de modo que estas describan y abstraigan sus
aspectos esenciales.
Los artefactos son diagramas y documentos que describen cosas. Son componentes de los modelos, a partir de los
artefactos creamos modelos.

¿Qué entiende por herramientas CASE? (Sommerville)

CASE significa Ingeniería del Software asistida por computadoras (Computer-Aided Software Engineering).
Comprende un amplio rango de diferentes tipos de programas que ayudan en las actividades del proceso de software,
como el análisis de requerimientos, el modelado del sistema, la depuración y las pruebas. Dichos programas nos proveen
de herramientas que soportan la automatización de algunas actividades, para ayudar a automatizar la plantación, el
análisis, diseño y generación de software.
Algunas actividades que se automatizan:
o El Desarrollo de modelos gráficos del sistema
o La comprensión del diseño utilizando un diccionario de datos (entidades y relaciones).
o La generación de interfaces del usuario.
o La depuración de programas.
o La conversión automática de programas de una versión anterior de un lenguaje de programación,
Limitaciones:
 Automatiza actividades rutinarias no hay creatividad
 No proporciona ayuda para la interactividad en el trabajo en equipo.

¿Cuáles son algunas de las razones que explican por qué se dice que UML estandariza los artefactos y la
notación, pero no define un proceso oficial de desarrollo?
Las razones que explican esto son:
- aumentar las probabilidades de una aceptación generalizada de la notación estándar del modelado, sin
obligación de adoptar un proceso oficial.
- la esencia de un proceso apropiado admite mucha variación y depende de las habilidades del personal, de la
razón de investigación, del desarrollo de la naturaleza del problema, de las herramientas y de muchos otros
factores.

Indique y describa brevemente los pasos de macronivel en UML.

Los pasos principales en la presentación de una aplicación son los siguientes:
- plantación y elaboración: planear, definir los requerimientos, construir prototipos, etc.
- construcción: la creación del sistema Transición de la implementación del sistema a su uso.
- Aplicación: la transición de la implementación del sistema a su uso.

DFD.
A medida que la información se mueve a través del software es modificada por una serie de transformaciones. El
diagrama de flujo de datos (DFD) es una técnica que representa el flujo de información y las transformaciones que se
aplican a los datos al moverse desde la entrada hasta la salida. El DFD es también conocido como grafo de flujo de datos
o como diagrama de burbujas.
Se puede usar el diagrama de flujo de datos para representar un sistema o un software a cualquier nivel de abstracción.
En el nivel 0 se llama Modelo Fundamental del Sistema o Modelo de Contexto, representando el software completo como una sola
burbuja de datos de entradas y salidas.

¿Qué es un tipo?
En el lenguaje UML, un tipo es una descripción de un conjunto de atributos similares con atributos y operaciones, pero
que no incluyan métodos. De ello se deduce que un tipo es una especificación de una entidad de software y no una
implementación.

Indique qué entiende por valores puros de datos y con qué otro nombre se los conoce. De 5 ejemplos.
Se entiende por valores puros de datos a los conocidos como atributos, en los cuales la identidad única no es
significativa (no se puede distinguir entre instancias aisladas del número 5). Por ejemplo, entero, reales, caracter,
cadena, booleano. También se los conoce como tipo de dato.

Diferencia entre concepto, funciones y atributo.

 Concepto: una idea, cosa u objeto.
 Atributo: es el valor lógico de un dato de un objeto. En el MC se incluyen sólo aquellos que tienen la necesidad
de recordar información. En el MC es preferible que los atributos sean simples, objetos de valor o valor puro de
datos
 Función: es lo que el sistema debe hacer.

¿Qué es un modelo conceptual?

Es una representación de conceptos u objetos en el dominio del problema, como por ej. “libro”, “empleado”, No describe
clases software ni responsabilidades. Utilizando la notación UML, un modelo del dominio se representa con un conjunto
de diagramas de clases en los que no se define ninguna operación. Pueden mostrar:
•Objetos del dominio o clases conceptuales.
•Asociaciones entre las clases conceptuales.
•Atributos de las clases conceptuales.
Se podría considerar como un diccionario visual de las abstracciones relevantes, vocabulario del dominio e información
del dominio.
¿Qué son los atributos de los conceptos?
Son valores lógicos de los datos de un concepto. En el modelo conceptual se incluye solo aquellos que tiene o indiquen
la necesidad de recordar información, y es preferible que los atributos sean simples, objetos de valor o valores puros de
datos (ej: booleano, fecha, número, cadena o texto, hora, dirección, código del producto, etc.). La regla en objetos es
relacionar conceptos con una asociación y no con un atributo.

¿Qué es una asociación?

Una asociación es una relación entre tipos (instancias) que indica alguna conexión significativa e interesante.
En UML se definen como “la relación semántica entre dos o más clasificadores que implica conexiones entre sus
instancias”.
Implican conocimiento de una relación que es necesario conservar durante algún tiempo.
Se representa como una línea entre clases con un nombre de asociación. La asociación es inherentemente bidireccional,
significa que desde las instancias de cualquiera de las dos clases, es posible el recorrido lógico hacia la otra.
En UML, ¿cuáles son las categorías de asociaciones de alta prioridad que se deben incluir en un modelo
conceptual?
Algunas de las categorías de asociaciones de prioridad alta que son, invariablemente, útiles incluirlas en un modelo del
dominio
A) “a” es una parte física o lógica de “b”.
B) “a” esta físicamente o lógicamente contenido en “b”.
C) “a” está registrado en “b”.

Agregación
La agregación es un tipo de asociación que se utiliza para modelar las relaciones todo-parte entre las cosas. El todo se
denomina compuesto.
Se representa en UML mediante un rombo hueco o relleno en el extremo del compuesto de una asociación todo-parte.
La agregación es una propiedad de un rol de asociación.
Considere mostrar una agregación cuando:
 El tiempo de vida de la parte está ligado al tiempo de vida del compuesto
 Existe un ensamblaje obvio todo-parte físico o lógico.
 Alguna propiedad del compuesto se propaga a las partes, como la ubicación.

Agregación de composición: rombo relleno.

La agregación de composición, o composición, significa que la parte es un miembro de un único objeto compuesto y que
existe una dependencia de existencia y disposición de la parte del compuesto.
Implica que solamente el compuesto posee la parte, y que se encuentran en una jerarquía de partes en forma de árbol;
es la forma de agregación más común que se presenta al modelar.

Agregación compartida: rombo hueco.

La agregación compartida significa que la multiplicidad en el extremo del compuesto podría ser más de uno, y es
representa mediante un rombo hueco. Implica que la parte podría estar simultáneamente en muchas instancias del
compuesto.

¿Qué entiende por Generalización?

La generalización es la actividad de identificar elementos comunes entre los conceptos y definir las relaciones de
superclase (concepto general) y subclase (concepto especializado).
La identificación de una superclase y las subclases es útil en un modelo del dominio porque su presencia nos permite
entender los conceptos en términos más generales, refinados y abstractos. La herencia es un mecanismo software para
hacer que las cosas de la superclase se apliquen a las subclases. Permite factorizar código de las subclases y subirlo
arriba de la jerarquía de clases, se utiliza Extends

¿Cuándo se debería definir una superclase conceptual?

Se debe hacer cuando:
 Cuando las subclases potenciales representan variaciones de un concepto similar.
 Las subclases se ajustarán a las reglas del 100% y del Es-un.
 Todas las subclases tienen el mismo atributo que se puede factorizar y expresar en la superclase.
Todas las subclases tienen la misma asociación que se puede factorizar y relacionar con la superclase

Papeles o roles.
Son los extremos de una asociación. Estos pueden tener nombre, expresión de multiplicidad, navegabilidad.

¿A qué se denomina multiplicidad y porque pone en manifiesto una restricción de diseño que será reflejada en el
software.
La multiplicidad define cuantas instancias de un tipo “a” pueden asociarse a una instancia del tipo “b” en un determinado
momento.

¿Qué es navegabilidad y cuántas formas conoce?

La navegabilidad es una propiedad de un rol que indica que es posible “navegar” unidireccionalmente a través de la
asociación desde objetos de la clase origen a objetos de la clase destino, significa generalmente la visibilidad de los
atributos. La visibilidad es la capacidad de un objeto para “ver” o hacer o tener referencia a otro.
Hay 4 formas comunes en que podemos conseguir o alcanzar la visibilidad del objeto “a” a un objeto “b”.
  Visibilidad de atributos: “b” es un atributo de “a”, es relativamente permanente porque persiste mientras existan
“a” y “b”.
 Visibilidad de parámetros: “b” es un parámetro de un método de “a”, es relativamente temporal porque persiste
sólo dentro del ámbito del método.
 Visibilidad declarada localmente: se declara que “b” es un objeto local (no un parámetro) dentro de un método de
“a”. También es una visibilidad relativamente temporal porque persiste sólo dentro del ámbito del método. Existen
dos medios habituales con que se logra esta visibilidad, ellas son:
o Crear una nueva instancia local y asignarla a una variable local.
o Asignar a una variable local el objeto devuelto proveniente de la llamada a un método.
 Visibilidad global: en alguna forma “b” es visible globalmente para “a”, es permanente porque persiste mientras
existan “a” y “b”.
Durante la implementación esto se transforma en un atributo de la clase origen que hace referencia a una instancia de la
clase destino.

La mejor forma de relacionar 2 objetos (como por ejemplo, datos_factura y productos_vendidos_factura) es a

través del atributo número de factura.
Falso. La asociación entre objetos se refleja con la visibilidad que presentan entre ellos permitiendo la interacción que
requieran.
Se representa en el diagrama de clases con una asociación con extremo de flecha desde la clase que ve hacia la clase
observada.

Objeto:
Un objeto es una entidad que tiene un estado y un conjunto de operaciones definidas que operan sobre ese estado. El
estado se representa como un conjunto de atributos del objeto. Las operaciones asociadas proveen servicios a otros
objetos. Se crean conforme a una definición de clases de objetos.

Clase
Descripción de un conjunto de objetos, comparten los mismos atributos, operaciones, métodos, relaciones y semántica

En la notación de UML, ¿cómo se grafican una clase, una instancia y una instancia con nombre? ¿Para qué
sirven estas últimas?
- Clase: es una construcción que se utiliza como un modelo para crear objetos de ese tipo. El modelo describe los
datos y el comportamiento que todos los objetos de la clase comparten (atributos y métodos).
- Instancia: es un objeto de una determinada clase. La clase que se utilizó para crear esa instancia se puede
considerar como del tipo de ese objeto. Por ejemplo, el objeto “:Persona” sería del tipo “Persona”.
- Instancia con nombre: es un objeto particular identificable por su nombre, por ejemplo “p:Persona”.

¿Qué describe el diagrama de clases del diseño en uml y cuáles son sus componentes?
Describe gráficamente las especificaciones de las clases de sw y de las interfaces. A diferencia del MC, este diagrama
contiene las definiciones de las entidades del software en vez de conceptos del mundo real.
Contiene: clases, asociaciones y atributos; interfaces con sus operaciones y constantes; métodos, información sobre los
tipos de los atributos; navegabilidad; dependencias.
Pasos para su creación:
1. Identificación y representación de las clases software a partir de los diagrama de colaboración
2. Dibujar diagramas de clases
3. Añadir los nombres de los métodos y atributos
4. Añadir más información sobre los tipos en atributos y métodos
5. Añadir asociaciones y navegabilidad
6. Añadir las relaciones de dependencias.

¿Qué entiende como “relación general de dependencia en UML”? ¿Cuál es su notación?

UML incluye una relación de dependencia general, que indica que un elemento (de cualquier tipo, como clases, casos de
uso, etc) tiene conocimiento de otro elemento. Se representa mediante una línea de flecha punteada. En los diagramas
de clases la relación de dependencia es útil para describir la visibilidad entre clases que no es de atributo; en otras
palabras, declaración de visibilidad de parámetro, global o local.
Caso de Uso:
Es un documento narrativo que describe la secuencia de eventos de un actor, que utilizan un sistema para completar un
proceso. Presenta actores y tipo de descripción. CU expandido muestra más detalle que uno de alto nivel, este tipo de
casos suelen ser útiles para alcanzar un conocimiento más profundo de los procesos y los requerimientos. Presenta
actores, propósito, resumen tipo, referencias cruzadas, curso normal de eventos, alterno.
Componentes: título, actores, resumen, propósito, tipo de descripción, referencia cruzada, curso normal de eventos,
curso alterno de eventos.

¿Qué son los actores?

Es cualquier entidad que participe o pueda tener interés en la historia de algún caso de uso incluyendo al propio sistema
cuando solicita servicios a otros sistemas. Se escribe con mayúscula en la narrativa para facilitar su identificación, y
puede ser el iniciador, que produce la estimulación inicial del sistema, o bien puede ser participante.
Los actores pueden ser:
- seres humanos que desempeñan cierto papel.
- sistemas de cómputos.
- aparatos electrónicos o mecánicos.
Existen tres tipos de actores externos con relación al sistema a desarrollar:
● Principal: Tiene objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema. Es quien
estimula principalmente al sistema con eventos de entrada.
● De Apoyo: Proporciona un servicio al sistema en desarrollo. (Generalmente a otro sistema informático)
● Pasivo: Se interesa en el comportamiento del caso de uso.

Define qué se entiende por “Caso Real de Uso”.

Un caso de uso real describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida,
así como de su implementación global.
Por ejemplo, si interviene una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas en
cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz.
Incluye las mismas secciones que un caso de uso: Precondiciones, Postcondiciones, Actor, Flujo básico, Flujo alterno.

¿Cuándo debería un paso importante o una actividad ramificada de un Caso de Uso escribirse como una parte
de una subsección y no como un caso de uso aparte?
Escriba los pasos principales o las actividades ramificadas de un Caso de Uso como caso independiente cuando:
 Se duplican en otros casos
 Son complejos y largos, y su separación facilita colocarlos en unidades manejables y comprensibles

DSS
Da una descripción gráfica de las interacciones del actor y de las operaciones a que da origen.
Es una parte de lo que se conoce como Comportamiento del Sistema
Muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los
eventos internos del sistema.

¿Qué entiende por “evento” y “operación” de un sistema en UML?

Estos conceptos pertenecen a los Diagramas de Secuencia del Sistema, los cuales brindan una descripción gráfica de
las interacciones del actor y de las operaciones a las que da origen. Es una parte de lo que se conoce como
comportamiento del Sistema (describir lo que hace sin explicar de qué manera lo hace).
- Evento del sistema: hecho externo de entrada que un actor produce en un sistema y origina una operación de
respuesta. Se debe utilizar para el nombre de un evento un verbo imperativo (agregar, introducir, terminar,
efectuar, etc).
- Operación de un sistema: es una acción que este ejecuta en respuesta a un evento del sistema.

¿Qué es un contrato?
Es un documento que describe el comportamiento detallado del sistema en función de los cambios de estado de los
objetos del modelo del dominio después de la ejecución de una operación del sistema (evento del DSS). Enfatizando lo
que sucederá y no cómo se conseguirá.
Las secciones que presenta un contrato son:
 ● Operación: Nombre de la operación con sus respectivos parámetros.
● Referencias cruzadas: (Opcional) Casos de uso en los que puede tener lugar esta operación.
● Precondiciones: Suposiciones sobre el estado del sistema o de los objetos del modelo del dominio antes de la
ejecución de la operación. Se asumen que son verdad por lo que no se comprobará en la lógica de la operación.
● Postcondiciones: Describe los cambios en el estado de los objetos del Modelo del dominio. Comprende la
creación y eliminación de instancias, formación o rotura de asociaciones y cambio en los atributos de un objeto.
No son acciones, sino, declaraciones que son verdad cuando la operación ha terminado.
Para expresar las postcondiciones se debe hacerlo en forma pasiva declarativa, en pretérito (Fue creada..., Se asoció...,
Se estableció..., etc.) para destacar la declaración de un cambio de estado.

Así como los casos de uso nos indican los procesos del dominio y el mc cuáles son los conceptos, términos,
etc., ¿Qué interrogantes nos contestan los artefactos denominados diagramas de secuencia y contratos?
Los DSS nos indican cuáles son los eventos, ósea las acciones de los actores externos y las operaciones internas del
sistema. Los contratos, nos indican que hacen cada una de estas operaciones.

¿Qué entiende como comportamiento de un sistema? Indique qué artefactos de UML sirven para representarlos.
El comportamiento de un sistema es una descripción de lo que hace el sistema, sin explicar en qué lo hace ni cómo lo
hace. Para representarlo, se utilizan los diagramas de secuencia y los contratos.

Las postcondiciones tiene una relación muy estrecha con otro artefacto de UML, ¿cuál es, por qué y qué puede
ocurrir con el diseño de este?
Las postcondiciones de los contratos se relacionan estrechamente con el modelo del dominio ya que con él podremos
responder a las preguntas de qué instancias crear o qué asociaciones formar.
Además de los contratos puede surgir la necesidad de mejorar el modelo del dominio, agregando conceptos, atributos o
asociaciones.

En UML, ¿qué son los diagramas de interacción y cuando se realizan? ¿Cuáles son los artefactos en UML que
deben estar previamente construidos y cuál es su importancia para elaborar diagramas de interacción?
Un diagrama de interacción es un gráfico que explica el modo en que los objetos interactúan por medio de mensajes para
realizar las tareas. Éstos se realizan en la fase de diseño de un Ciclo de Desarrollo. Para su elaboración, previo deben
estar hechos:
- Modelo de Casos de Uso: representa los requerimientos funcionales del sistema desde el punto de vista del
usuario. La documentación de los casos de uso y los contratos nos dan una idea aproximada de lo que el
sistema deberá hacer.
- Diagrama de Secuencia del Sistema: muestra los escenarios del caso de uso mediante eventos del sistema.
- Modelo del Dominio: se utiliza para inspirar la presencia y nombre de algunas clases software. El modelo del
dominio es útil porque nos ayuda a crear un modelo de diseño con un salto en la representación más bajo entre
el diseño y el mundo real.
- Contratos: para describir los efectos de los eventos del sistema en término de cambios de los objetos del
dominio.

¿Cuál es el nombre de los diagramas utilizados en UML para representar interacciones de mensajes, en qué se
diferencian y cuál es la ventaja de uno sobre otro?
Los Diagramas de secuencia (formato con el aspecto de una valla) y los diagramas de colaboración (formato de grafo o
red). La ventaja de este último es que es de menores dimensiones, es mejor para ilustrar bifurcaciones complejas,
iteraciones y comportamiento concurrente.

Diagramas de colaboración.
Ilustran las interacciones entre objetos en un formato de grafo o red. Su punto de partida es hacer cumplir las
postcondiciones de los contratos de una operación.

Indique cuál es la directriz para elaborar los diagramas de iteracion en UML.

Para los diagramas de colaboración:
A) Elaborar un diagrama para cada operación del sistema o mensaje, incluyendo a este como el mensaje inicial.
B) Si el DC se hace muy grande, se lo puede dividir en diagramas más pequeños.
 C) Diseñar un sistema de objetos interactivos que realicen tareas, usando las responsabilidades, postcondiciones y
la descripción de los CU. Aplicar patrones para mejorar el diseño.
Para los diagramas de secuencia:
A) Trazar una línea que represente el sistema.
B) Identificar los actores.
C) Identificar los eventos generados por los actores dentro del curso normal de eventos.
D) A la izquierda del diagrama se puede incluir o no el texto del CU.

Al usar un * en UML, se está indicando una operación importante. Diga cómo se llama ésta, en qué artefacto y
explique cómo se utiliza la misma sobre una colección (“multiobjeto”).
El “*” se usa para denotar la operación llamada iteración. Se la utiliza en los Diagramas de Colaboración, e indica que se
manda un mensaje a cada uno de los miembros de la colección asociada al multiobjeto, indicando también el “*” del
marcador de multiplicidad al final del enlace.

¿Cómo se indica el orden de los mensajes en UML y cómo se denota la anidación?

El orden de los mensajes se indica en forma secuencial, donde el primer mensaje no se numera. El orden y el
anidamiento de los mensajes siguientes se indican con un esquema legal de numeración, donde a los mensajes
anidados se les ha antepuesto un número. La anidación se denota anteponiendo el número del mensaje de entrada al del
mensaje de salida.
Los mensajes se pueden representar por medio de una flecha con un nombre y situada sobre una línea del vínculo.

¿Qué son los valores de retorno, en qué diagramas de utilizan y cuál es su notación en UML?
A veces los mensajes pueden devolver valores. A estos se les llama valores de retorno. El nombre de la variable a la cual
se le asigna dicho valor se antepone al mensaje en los Diagramas de Colaboración, junto con un operador de asignación
(“:=”);

Diagrama de estados.
Describe visualmente los estados y eventos más interesantes de un objeto; así como su comportamiento frente a un
evento, se representan con flechas, etiquetadas. Los estados se representan en rectángulos de esquinas redondeadas.
Es habitual incluir un pseudo-estado inicial, que pasa automáticamente a otro estado cuando se crea la instancia.
Muestra el ciclo de vida de un objeto: qué eventos experimenta, sus transiciones y los estados en los que se encuentra
entre estos eventos.
Durante las Fases de Diseño e Implementación, hay que preparar e implementar un Diseño que garantice que no ocurran
eventos fuera de la secuencia, para evitar cualquier condición de error.
Por ejemplo, no debe permitirse que CAJA reciba un pago si no ha concluído aún la Venta. Este recaudo deberá tenerse
en cuenta al programar.

Diagrama de estado del sistema global: Es la unión de todos los Diagramas de Estado; y resulta útil mientras el
número total de eventos sistémicos sea lo suficientemente pequeño que lo tornen manejable.

¿Qué es evento, estado y transición?

 Evento: acontecimiento importante o digno de señalarse.
 Estado: condición de un objeto en un momento determinado (o sea, el lapso que transcurre entre dos eventos).
 Transición: relación entre dos “estados”. Indica que cuando sucede un “evento”, el objeto pasa del “estado”
anterior al siguiente “estado”.

Diga si considera falso o verdadero el siguiente concepto, en qué contexto y por qué. “No hace falta asociar las
instancias de la clase venta a la descripción de los items que la componen”.
En general es falso, porque siempre hace falta reconstruir la venta, imprimir un recibo, recalcular el total, etc. Solo sería
verdadero en aquel contexto donde la venta es de un solo producto.

¿Qué es glosario o diccionario modelo?

Es un artefacto del uml que incluye y define todos los términos que requieran explicación para mejorar la comunicación y
reducir el riesgo de malos entendidos.
Diagrama de Actividades:
Es un caso especial de diagrama de estados, Sirven para visualizar, especificar, construir y documentar la dinámica de
una sociedad de objetos o emplearse para modelar el flujo de control de una operación.
Podemos modelar procesos, algoritmos o casos de uso.

4) Ciclos de vida

Sistema: Conjunto de elementos que interactúan entre sí para lograr un objetivo determinado
Sistema de Información: Conjunto de recursos que almacenan, procesan, controlar y producen la información de toda
una empresa u organización.

¿Qué es un ciclo de vida?

Es un marco de referencia que contiene procesos, actividades y tareas involucradas en el desarrollo, la explotación y el
mantenimiento del productos softwares; abarcando la vida del sistema desde la definición de los requisitos hasta el
desmantelamiento para su uso.
Fases:
Planificación – Análisis – Diseño – Codificación – Prueba – Implementación – Mantenimiento – Desmantelamiento.

Objetivos del ciclo de vida de desarrollo de sistemas de la información (CVS).

 Definir las actividades a llevarse a cabo en el desarrollo
 Lograr congruencia entre los proyectos de desarrollo al interior y exterior de la organización
 Proporcionar puntos de control y revisión administrativos
 Organizar las actividades de manera lógica
 Controlar la calidad del sistema

¿Qué entiende por modelos genéricos según (Sommerville)?

Son abstracciones obtenidas a partir de varios sistemas reales, encapsulando sus características principales.
Existen modelos genéricos de las arquitecturas de sistemas, que ayudan a entender y comparar aplicaciones, validar y
evaluar diseños y componentes.
También hay modelos genéricos de procesos, los cuales son marcos de procesos que pueden ser extendidos y
adaptados para crear procesos de ingeniería del software más específicos.
Ejemplos de modelos genéricos de procesos del software son:
 Modelo en cascada: Toma las distintas actividades de especificación, desarrollo, validación y evolución y las
representa como fases separadas
 Desarrollo incremental: Intercala las actividades de especificación, desarrollo y validación. El sistema es
desarrollado como una serie de incrementos.
 Ingeniería del software basada en componentes: Este enfoque se basa en la existencia de un número de
componentes y marcos de trabajos de integración reusables. se enfoca en integrar estos componentes en un
sistema.

¿Cuáles son los modelos de proceso o de desarrollo de sw?

 Desarrollo convencional o de cascada
 Desarrollo Iterativo e Incremental = Espiral – Evolutivo (Desarrollo exploratorio – prototipos desechables)
 RUP (rational unified proccess)
 Ingeniería del sw basada en componentes

Modelos de Procesos Prescriptivos

¿Qué es y qué entiende usted Desarrollo en cascada?
Un enfoque sistemático y secuencial para el desarrollo del software, comienza con la especificación de requerimientos
por parte del cliente y avanza a través de la planeación, modelado, construcción y despliegue, para concluir con el apoyo
al software terminado.

Ventajas:
 útil en sistemas grandes.
 cuando requerimientos no cambian: debido a costosas iteraciones.
  cuando los programadores están dispersos.
 cuando piden documentación formal: producida en cada fase.
 Se usa cuando los cambios en el futuro son inexistentes o improbables

Desventajas:
 Los cambios generan confusión conforme el equipo del proyecto avance
 hay que llegar a etapa final para mostrar el sistema.
 excesiva documentación.
 se tarda en detectar errores.
 Secuencialidad

Indique por lo menos dos problemas del desarrollo iterativo e incremental.

-Incremental significa que se construye sobre lo que está hecho y se agregan funcionalidades.
-Iterativo significa que surge de hacer repeticiones; el producto no queda cerrado en la primera ejecución del proceso de
desarrollo, por el contrario, queda abierto a nuevos cambios en próximas iteraciones.

En un proceso iterativo e incremental se debe analizar el impacto de cada nuevo cambio para no destruir lo anterior, sino
modificarlo.

Tipos:
a. Entrega Incremental: la especificación, el diseño y la implementación del software se dividen en una serie de
incrementos, los cuales se desarrollan por turnos.
b. Desarrollo en espiral: el desarrollo gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con
el desarrollo final del mismo.

Ventajas:
 Los clientes no tienen que esperar hasta que el sistema este completo. El primer incremento satisface los
requerimientos
 Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los
requerimientos de los incrementos posteriores.
 Existe bajo riesgo de un fallo total del proyecto.

Problemas:
 Problemas de administración: estos sistemas cambian tan rápido que no es rentable producir una gran cantidad
de documentación (mayor gasto)
 Problemas contractuales: (requerimientos inciertos => costos inciertos).
 Problemas de validación: al no existir una especificación del sistema, no hay pruebas con anticipación y son al
azar.
 Problemas de mantenimiento: aparte de los desarrolladores, se puede tener problemas para entender el
software, ya que los cambios continuos corrompen la estructura de cualquier sistema.
 Además requiere de un cliente involucrado durante todo el curso del proyecto, y sufre fuertes penalizaciones en
proyectos cuyos requerimientos están previamente definidos.

¿Cuántos tipos de desarrollo evolutivo conoce? Descríbalo.

La idea de este modelo, es presentar una versión inicial, exponiéndola a los comentarios del usuario y refinándolo a
través de diferentes versiones, hasta el desarrollo final. Es útil para el desarrollo de pequeños y medianos sistemas.
Las actividades de especificación, desarrollo, y validación están entrelazadas, con una rápida retroalimentación.
Tipos:
a. Desarrollo Exploratorio: el objetivo es trabajar con el cliente, explorar sus necesidades y entregan un sistema
final.
b. Prototipos Desechables: comprende los requerimientos del cliente y desarrolla una versión mejorada ellos (el
prototipo experimenta con los requerimientos del cliente que no se comprenden claramente).

Ventajas:
 permite actividades concurrentes.
 permite entregas parciales.
 programación extrema.
 Satisface las necesidades inmediatas de los usuarios.
 La especificación se puede desarrollar en forma creciente.
Desventajas:
 el proceso no es visible: no es rentable documentar versiones si los sistemas se desarrollan rápidamente.
 a menudo los sistemas tienen estructura deficiente.
 Los cambios a introducir son cada vez más difíciles y costosos.

¿Qué es y qué entiende usted por desarrollo en espiral?

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Boehm, utilizado en Ingeniería de software. Las
actividades se disponen de forma espiral, en donde cada vuelta corresponde a una iteración.
Las actividades se eligen en función del análisis de riesgo, comenzando por el bucle interior. Se utilizan prototipos y es
un modelo iterativo e incremental. Es un enfoque realista para el desarrollo de sistemas a gran escala, ya que evoluciona
a medida que el proceso avanza, se puede comprender y reaccionar mejor ante los riesgos
Consta de pocas etapas, las cuales se van realizando en una manera continua y cíclica.
Cada ciclo de espiral se divide en 4 etapas:
 Definición de objetivos: objetivos específicos. Restricciones de los procesos y el producto, y se estipula un plan
detallado de administración. Identifican los riesgos del proyecto. Estrategias alternativas
 Evaluación y reducción de riesgos. Análisis detallado para cada uno de los riesgos del proyecto. Pasos a seguir
para reducir dichos riesgos.
 Desarrollo y validación. Elección de un modelo para el desarrollo del sistema.
 Planeación. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la
espiral.
Problemas:
 Difícil convencer a los clientes de que es controlable
 Demanda mucha experiencia en la evaluación del riesgo

Según Sommerville, ¿qué entiende por Ingeniería del Software basada en componentes? Mencione por lo menos
2 ventajas que considere para su uso.
Se basa en la reutilización informal de componentes de software y de algunos marcos de trabajo de integración para
éstos, dando a los ingenieros varios beneficios en cuanto a la mensurabilidad. Si la reutilización se vuelve parte de la
cultura, el equipo de ing tiene la posibilidad tanto de reducir el ciclo de tiempo de desarrollo, como el costo del proyecto.

Etapas:
 Se investiga y evalúa para el tipo de aplicación a tratar, productos disponibles basados en componentes
 Se considera los aspectos de integración de los componentes
 Se diseña una arquitectura de sw para que reciba los componentes
 Se integran los componentes en la arq.
 Se efectúan pruebas, para asegurar la funcionalidad apropiada.

 Análisis de Componentes (buscar componentes de concordancia total o parcial)

 Modificación de requerimientos (requerimientos vs. Componentes) >> buscar alternativas
 Diseño del sistema con reutilización: diseño de un marco de trabajo para el sistema (disponibilidad vs nuevo diseño)
 Desarrollo e Integración: Desarrollo de nuevo SW no disponible como componente e integración del mismo

Ventajas:
 reduce la cantidad de software a desarrollar.
 disminuye los costos.
 minimiza los riesgos.
 permite una entrega rápida del software.

Desventajas
 El Proceso a veces no cumple acabadamente con los requerimientos del usuario
 Se pierde parte del control sobre la evolución del sistema

Según sommerville que entiende por RUP (proceso unificado de rational)

Reúne todos los elementos de los modelos de proceso genéricos vistos, e ilustra buenas prácticas en la especificación y
el diseño, cuyas fases están más relacionadas con asuntos de negocio más que técnicos. Se describe desde tres
perspectivas:
- Dinámica: muestra las fases del modelo sobre el tiempo
- Estática: muestra las actividades del proceso que se representa
- Práctica: sugiere buenas prácticas a utilizar durante el proceso.

Fases:
- Inicio: se establece un caso de negocio para el sistema, se identifican entidades externas que interactuaran con el sist.
- Elaboración: se comprende el dominio del problema, se establece un marco de trabajo arquitectónico, se desarrolla el
plan de proyectos, y se identifican los riesgos claves.
- Construcción: el diseño, programación y pruebas del sistema.
- Transición: el sistema pasa de un entorno de desarrollo a la comunidad del usuario trabajando en un entorno real

Ventajas:
 permite empezar sin tener todos los requerimientos.
 fácil de cambiar durante realización.
 en transición, no versiones beta sino ejecutables.

Desventajas:
 necesitan experimentados.

¿Qué entiende por métodos ágiles de desarrollo de software? ¿Cuál es la principal característica y en qué
ámbitos los utilizaría?
Las metodologías ágiles se caracterizan porque permite centrarse en el software mismo en vez de su diseño y
documentación.
Dependen de un enfoque iterativo para la especificación, desarrollo y entrega del software. Fueron diseñados para
apoyar el desarrollo de aplicaciones de negocio donde los requerimientos del sistema cambian rápidamente durante el
proceso de desarrollo.
Pensados para entregar software funcional a los clientes de forma rápida, Idóneos para el desarrollo de sistemas de
negocio pequeños y de tamaño medio y para el desarrollo de productos para ordenadores personales.

Se valora:
 a los individuos y las interacciones sobre los procesos y las herramientas.
 al software operativo sobre la documentación exhaustiva.
 la colaboración con el cliente sobre la negociación del contrato.
 la respuesta al cambio sobre el seguimiento de un plan.
Ejemplos: programación extrema (XP), Desarrollo Rápido de Aplicaciones (RAD), Desarrollo de prototipo, SCRUM.
(RAD: Las Técnicas de desarrollo rápido de aplicaciones (RAD) evolucionaron de los llamados lenguajes de cuarta
generación de los años 80 y se utilizan para desarrollar aplicaciones con un uso intensivo de datos
Usan un conjunto de herramientas que permiten crear datos, buscarlos, visualizarlos y presentarlos en informes.)

Principios de métodos ágiles:

 Participación del cliente: deben estar implicados en todo el proceso de desarrollo; proporcionan y priorizan los
nuevos requerimientos y evalúan las iteraciones.
 Entrega incremental: el software se desarrolla en incrementos, donde el cliente especifica qué requerimientos incluir
en cada incremento.
 Personas, no procesos: se explotan las habilidades del equipo de desarrollo.
 Aceptar el cambio: se debe contar con que los requerimientos del sistema cambian, por lo que se lo diseña para dar
cabida a los cambios.
 Mantener la simplicidad: eliminar la complejidad del sistema tanto en el software a desarrollar como en el proceso de
desarrollo.

¿Qué entiende por modelo de desarrollo rápido de Software?

Modelos diseñados para producir software útil de forma rápida. Son procesos iterativos donde se entrelazan la
especificación, diseño, desarrollo y pruebas. El soft no se desarrolla, ni se utiliza en su totalidad, sino, lo hace en una
serie de incrementos, donde por cada nuevo incremento, se incluye nuevas funcionalidades.
Implementa prioridades, y retroalimentación de requerimientos, lo cual conlleva una mejora continua.

Motivos
  Los sistemas operan en un entorno cambiante.
 Responden a nuevas oportunidades en mercado y a condiciones económicas cambiantes.
 Al ser parte de casi todas las operaciones de negocio, el sistema se tiene que desarrollar rápidamente.

Características
 Los procesos de especificación, diseño e implementación son concurrentes.
 La documentación se minimiza.
 Se desarrolla de forma incremental.
 Los incrementos son evaluados por todos los interesados en el sistema (administradores, ingenieros en
sistemas, probadores, usuarios, etc).
 Las interfaces del usuario se desarrollan utilizando un sistema de desarrollo iterativo.

¿Cuál es la diferencia entre lo que se denomina ciclo de vida iterativo y ciclo de vida en cascada? ¿Cuál se utiliza
en UML y por qué?
- El ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento secuencial de un sistema en diversos ciclos
de desarrollo de análisis, diseño, implementación y prueba.
- Un ciclo de vida en cascada se basa en actividades (análisis, diseño, entre otras) que se llevan a cabo una vez que se
cuenta con todos los requerimientos que el sistema debe cumplir.
UML usa un ciclo de vida iterativo porque otorga las siguientes ventajas:
 la complejidad nunca resulta abrumadora.
 se produce retroalimentación en una etapa temprana porque la implementación se efectúa rápidamente con una
pequeña parte del sistema.

Software: “Es la suma total de los programas de ordenador, procedimientos, reglas, la documentación asociada y los
datos que pertenecen a un sistema de cómputo" y "un producto de software es un producto diseñado para un usuario".

PROCESO DEL SOFTWARE (SW)

“Conjunto de actividades que conducen a la creacion de un producto software”
“Las actividades pueden comenzar de cero o ampliar y modificar los sistemas existentes y configurando e integrando SW
comercial o componentes del sistema”
“Un Modelo del Proceso de SW es una representación abstracta de un proceso del SW”

MODELOS DE PROCESO DEL SOFTWARE ALGUNAS ACTIVIDADES COMUNES

 Especificación del software: definir funcionalidad del sw y restricciones en su operación
 Diseño e implementación del sw: producir sw cumpliendo lo anterior
 Validación del sw: asegurar que el sw hace lo que el cliente desea
 Evolución del sw: el sw debe crecer para cubrir nuevas necesidades

Buenas Prácticas Recomendadas

 Desarrolle el SW en forma iterativa: planificar incrementos del SW basado en las prioridades del usuario.
 Gestione los requerimientos: Documentar los mismos, conocer los cambios y analizar su consideración o no.
 Utilice arquitectura basadas en componentes: Estructurar la arquitectura de esa forma.
 Modele el SW visualmente: Utilizar modelos gráficos UML para presentar vistas estáticas y dinámicas del SW.
 Verifique la calidad del SW: cumplir con los estándares.
 Controle los cambios del SW: Gestionar estos a través usando un sistema de gestión de cambios y
procedimientos y herramientas de gestión de configuraciones.
5) Patrones

¿Qué es un patrón y cuáles son las ventajas de su uso?

Un patrón es un par problema/solución con nombre que se puede aplicar en nuevos contextos, con consejos acerca de
cómo aplicarlo en nuevas situaciones y discusiones sobre sus compromisos.
Para que un patrón sea solución debe poder resolver problemas similares y ser reusable.
o Apoya la identificación e incorporación de ese concepto en nuestro conocimiento y memoria.
o Facilita la comunicación.

¿Cómo define UML una responsabilidad?

UML define una responsabilidad como “un contrato u obligación de un clasificador”. Las responsabilidades están
relacionadas con las obligaciones de un objeto en cuanto a su comportamiento.

En patrones hay dos categorías de responsabilidades, ¿cuáles son?

a) Conocer (tiene que ver con los atributos del Modelo Conceptual):
 Conocer los datos privados encapsulados
 Conocer los objetos relacionados
 Conocer las cosas que puede derivar o calcular
b) Hacer (hacer algo él mismo):
 Crear un objeto o hacer un cálculo
 Iniciar una acción en otros objetos
 Controlar y coordinar actividades en otros objetos

Una responsabilidad no es lo mismo que un método, pero los métodos se implementan para llevar a cabo
responsabilidades.

¿Qué significan las siglas GRASP? ¿Cuál es su función más importante y cuáles son los 5 más importantes?
Patrones GRASP (patrones generales de software para asignar responsabilidades): describen los principios
fundamentales de la asignación de responsabilidades a objetos, expresados en forma de patrones. Se aplica durante la
elaboración de los diagramas de interacción. Los patrones sirven para mejorar la calidad del diseño.
Ventajas de su uso:
- apoya la identificación e incorporación de ese concepto en nuestro conocimiento y memoria.
- facilita la comunicación entre los desarrolladores.

Los cinco patrones básicos (GRASP) comunes y que se refieren a aspectos fundamentales del diseño y la asignación de
responsabilidad son:

● Experto en información.
Solución: asignar una responsabilidad al experto en información (la clase que tiene la información necesaria
para realizar la responsabilidad).
Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?
El cumplimiento de la responsabilidad a menudo requiere información que se encuentra dispersa por diferentes clases de
objetos. Esto implica que hay muchos expertos en información “parcial” que colaborarán en la tarea.
En algunas ocasiones, la solución que sugiere el Experto no es deseable, normalmente debido a problemas de
acoplamiento y cohesión.
Beneficios:
 mantiene el encapsulamiento de la información, esto conlleva un bajo acoplamiento, lo que da lugar a sistemas
más robustos y más fáciles de mantener.
 Distribuye el comportamiento entre las clases que contienen la información requerida, estimula las definiciones
de clases más cohesivas y “ligeras” siendo más fáciles de entender y mantener.

● Creador.
 Solución: Asigna a la clase “b” la responsabilidad de crear una instancia de la clase “a” en uno de lo siguientes
casos:
 “b” agrega los objetos “a”.
 “b” contiene los objetos “a”.
 “b” registra las instancias de los objetos “a”.
 “b” utiliza específicamente los objetos “a”.
 “b” tiene los datos de inicialización que serán transmitidos a “a” cuando este objeto sea creado (así que
“b” es un experto respecto a la creación de “a”).
Problema: ¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase?
El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos.
La intención básica del patrón Creador es encontrar un creador que necesite conectarse al objeto creado en
alguna situación.
Beneficios:
 Se soporta bajo acoplamiento, lo que implica menos dependencias de mantenimiento y mayores
oportunidades para reutilizar

● Bajo acoplamiento.
Solución: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.
Problema: ¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización?
Impulsa la asignación de responsabilidades de manera que su localización no incremente el acoplamiento hasta un nivel
que nos lleve a los resultados negativos que puede producir un acoplamiento alto. Una clase con alto acoplamiento es
difícil de entender de manera aislada y difícil de reutilizar por las dependencias que posee.
Beneficios:
 No afectan los cambios en otros componentes.
 Fácil de entender de manera aislada.
 Conveniente para reutilizar.

● Alta cohesión.
Solución: asignar una responsabilidad de manera que la cohesión permanezca alta.
Problema: ¿Cómo mantener la complejidad dentro de límites manejables?
Una clase con baja cohesión es difícil de entender, de reutilizar, de mantener y son delicadas, porque son afectadas por
los cambios.
Una clase con alta cohesión tiene un número relativamente pequeño de métodos,
Beneficios:
 Se incrementa la claridad y facilita la comprensión del diseño.
 Se soporta a menudo bajo acoplamiento.
 Se simplifica el mantenimiento y las mejoras en funcionalidad

● Controlador.
Solución: asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que
representa una de las siguientes opciones:
 representa el sistema global, dispositivo o subsistema (controlador de fachada).
 representa un escenario de caso de uso en el que tiene lugar el evento del sistema, a menudo
denominado <NombreDelCasoDeUso>Manejador.
Problema: ¿Quién debe ser el responsable de gestionar un evento de entrada al sistema?
Un evento del sistema de entrada es un evento generado por un actor externo. Se asocian con
operaciones del sistema.
Beneficios
 Aumenta el potencial para reutilizar y las interfaces conectables. Asegurando que la lógica de la aplicación no se
maneja en la capa de interfaz.
 Razonamiento sobre el estado de los casos de uso

¿Cuándo se debería escoger un controlador de casos de uso?

Se debería utilizar cuando:
 La asignación de responsabilidades a un controlador de fachada lleva a diseños con baja cohesión o alto
acoplamiento
 Cuando hay muchos eventos del sistema repartidos en diferentes procesos; el controlador factoriza la gestión en
clases separadas manejables.
¿Qué entiende por “controlador saturado” y cuáles pueden ser las razones que dan lugar a este término? En el
manejo de los eventos, ¿cómo se denomina a la clase controlador que tiene baja cohesión y cuáles son las
razones que indicarían esta situación?
Cuando una clase controlador no está centrada en algo concreto y gestiona demasiadas áreas de responsabilidad, se
denomina “controlador saturado” y las razones pueden ser:
● Existe una única clase controlador que recibe todos los eventos del sistema en el sistema, y hay muchos.
● El propio controlador realiza muchas de las tareas necesarios para llevar a cabo los eventos del sistema, sin
delegar trabajo.
● Un controlador tiene muchos atributos y mantiene información significativa sobre el sistema o el dominio, que
debería haberse distribuido a otros objetos.
Soluciones:
1. Añadir más controladores.
2. Diseñe el controlador de manera que, ante todo, delegue el cumplimiento de cada responsabilidad de una
operación del sistema a otros objetos.

Según el patrón controlador ¿quién debería encargarse de atender un evento del sistema?
Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase que represente una de
las siguientes opciones:
A- El “sistema global” (controlador de fachada) ej: tpdv
B- La empresa u organización global (controlador de fachada) ej: tienda.
C- Algo en el mundo real que es activo (ej: el rol de una persona-cajero-) y que pueda participar en la tarea
(controlador de tareas).
D- Un manejador artificial de todos los eventos del sistema de un caso de uso. (controlador de caso de uso).

¿Qué entiende por “cohesión funcional” en el diseño orientado a objetos? ¿Cuándo hay alta cohesión?
Es una medida de cuan relacionadas y enfocadas están las responsabilidades de una clase. Una alta cohesión
caracteriza a las clases con responsabilidades estrechamente relacionadas que no realicen un trabajo enorme. Ejemplo:
Si una persona tiene demasiadas responsabilidades no relacionadas, entonces la persona no es efectiva.

Fabricación Pura

Problema
¿Qué objetos deberían tener la responsabilidad cuando no quiere violar los objetivos de Alta Cohesión y Bajo
Acoplamiento, u otros, pero las soluciones ofrecidas por otros patrones no son adecuadas?

Solución
Asigne un conjunto de responsabilidades altamente cohesivo a una clase artificial o de conveniencia que no representa
un concepto del dominio del problema. La asignación de responsabilidades a esta fabricación soportan alta cohesión y
bajo acoplamiento, de manera que el diseño de la fabricación es muy limpio o puro.
Por ejemplo: almacenamiento persistente.

Beneficios
 Soporta Alta Cohesión.
 El potencial para reutilizar podría aumentar

Indirección

Problema
¿Dónde asignar una responsabilidad para evitar el acoplamiento directo entre dos (o más) cosas? ¿Cómo desacoplar los
objetos de manera que se soporte el bajo acoplamiento y el potencial para reutilizar permanezca más alto?

Solución
Asigne la responsabilidad a un objeto intermedio que medie entre dos componentes o servicios de manera que no se
acoplen directamente.
Por ejemplo: AdaptadorCalculadorDeImpuestos. Protege el diseño interno frente a las variaciones de las interfaces
externas.

Beneficios
  Disminuir el acoplamiento entre los componentes.

Diferencia entre Fabricación Pura e Indirección

Fabricación Pura crea algo que no está en el dominio (que puede ser una clase que sirva de intermediaria para algo, o
no). Indirección crea una clase intermedia (que puede ser Fabricación Pura o no).

6) Prototipos

¿Qué entiende por prototipos? Indique por lo menos dos beneficios - Desventajas
Es una versión inicial de un sistema software utilizado para demostrar conceptos, probar opciones de diseño y, en
general, informarse más del problema y sus posibles soluciones.
Se puede utilizar de varias maneras en un proceso de desarrollo de software:
- En ingeniería de requerimientos, ayuda con la obtención y validación de los requerimientos.
- En el diseño del sistema, explora soluciones software particulares y apoya el diseño de las interfaces de usuario.
- En las pruebas, ejecuta pruebas back-to-back con el sistema a entregar al cliente.
Beneficios del prototipado del software:
- Mejora la usabilidad del sistema.
- Una mejor concordancia entre el sistema y las necesidades del usuario.
- Mejora en la calidad del diseño.
- Mejora en el mantenimiento.
- Reducción en el esfuerzo de desarrollo.
- Existen oportunidades para detener el desarrollo de un sistema que no es funcional.
Desventajas del prototipo:
- No es bueno para la calidad del soft.
- No tiene en cuenta el mantenimiento posterior.
- No considera aspectos globales del sistema.
- Los usuarios y analista pueden adoptar a un prototipo como un sistema terminado cuando es inadecuado.
Desventajas de usar el prototipo como sistema final:
- Difícil ajustar el prototipo a los requerimientos no funcionales (rendimiento, protección, robustez y fiabilidad).
- el cambio rápido implica documentación insuficiente lo que no conveniente para el mantenimiento a largo plazo.
- los cambios realizados durante el desarrollo degradan la estructura del sistema.
Mencione y describa los tipos de prototipos.
o Prototipado de interfaz de usuario: modelos de pantallas.
o Prototipado funcional (operacional): implementa algunas funciones, y a medida que se comprueba que son las
apropiadas, se corrigen, refinan y se añaden cosas.
o Modelo de rendimiento: evalúan el rendimiento de una aplicación crítica.
o Rápidos o desechables:
 Comienza con las partes menos entendidas del sistema
 Sirven al análisis y validación de los requisitos
 Se redacta la especificación del sistema y se lo desecha
 La aplicación se desarrolla siguiendo un paradigma diferente
 Si no se desecha es un problema
o Evolutivos:
 Comienza con un sistema relativamente simple que implementa los requisitos más importantes o más
conocidos.
 El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos.
 Finalmente se convierte en el sistema requerido
 Actualmente se usa en el desarrollo de sitios webs y en aplicaciones de comercio electrónico
o Horizontal: modela muchas características de un sistema pero con poco detalle. Desarrolla completamente
algunas funciones.
o Vertical: modela pocas características de un sistema pero con mucho detalle. Desarrolla parcialmente todas las
funciones.

Sintéticamente, ¿en qué consiste el modelo de proceso de desarrollo o paradigma de prototipos?

Es un modelo que pone énfasis en la especificación de requerimientos a través de la construcción de prototipos que
aproximan al usuario a la idea final del sistema.
a. Se identifica en forma global los requerimientos para el soft en función a lo conocido y las áreas necesarias.
b. A través de un “diseño rápido” se construye un prototipo con los aspectos del sistema que serán visibles para el
usuario.
c. Se evalúa el prototipo y se lo usa para refinar los requisitos del software a desarrollar.

El modelo de construcción de prototipos se recomienda usarlo cuando:

 el cliente define un conjunto de objetivos generales para el software.
 no identifica los requerimientos detallados de entrada, proceso o salida.
 no se está seguro de la eficacia de un algoritmo.

¿Qué es una interfaz (o GUI) y cuáles son sus objetivos?

La GUI (Interfaz Gráfica del Usuario) es la frontera entre el usuario y el sistema. Representa el medio de comunicación
entre los usuarios y una computadora. Es un proceso iterativo e incremental donde los usuarios interactúan con los
diseñadores y con los prototipos de la interfaz para decidir sobre: las características, organización, apariencia y
funcionamiento de la interfaz de usuario del sistema. Debe cumplir con los siguientes objetivos:
- Decir al sistema las acciones a realizar.
- Facilitar el uso del sistema
- Evitar los errores del usuario.

Enuncie y describa brevemente los principios de diseño de interfaces de usuario que enseña Sommerville.
a. Familiaridad del usuario: utilizar términos y conceptos obtenidos de la experiencia de las personas que más
utilizan el sistema.
b. Uniformidad: las operaciones comparables se activen de la misma forma.
c. Mínima sorpresa: El comportamiento del sistema no debe provocar sorpresas a los usuarios.
d. Recuperabilidad: incluir mecanismos para permitir a los usuarios recuperarse de los errores.
e. Guía de usuario: proporcionar retroalimentación significativa y características de ayuda sensible al contexto,
cuando ocurran errores.
f. Diversidad de usuario: características de interacción apropiadas para los diferentes tipos de usuarios.

¿Qué entiende por “uniformidad” como un principio de diseño para una interfaz?
Significa que los comandos y menús del sistema deben tener el mismo formato, los parámetros deben pasarse a todos
los comandos de la misma forma y la puntuación de los comandos debe ser similar. De esta forma, se reduce el tiempo
de aprendizaje del usuario.
Esta uniformidad es importante, ya que evita errores cuando, por ejemplo, un mismo comando del teclado significa
situaciones diferentes según las aplicaciones. Es por esto que, en lo posible, los comandos con significados similares en
aplicaciones diferentes se deben expresar de la misma forma.

Factores humanos que deben considerarse en el diseño de la interfaz de usuario (sommerville).

o Memoria limitada a corto plazo, la información no debe ser abundante.
o Posibilidad de cometer errores aumentando el estrés, lo que a su vez genera una mayor preocupación y
posibilidad de errores.
o Amplio rango de capacidades entre los usuarios. No se debe diseñar par las propias capacidades y pensar que
los otros se adaptaran.
o Diferentes preferencias de interacción. con imágenes o texto; manipulación directa o mediante comandos.

¿Cuáles son las reglas de oro para el diseño de la interfaz? Explique (Pressman).
1. Dar control al usuario:
 No obligar a hacer acciones innecesarias
 Interacción flexible
 Ocultar detalles técnicos
 Interacción directa con los objetos que aparecen en la ventana
2. Reducir la carga de memoria del usuario:
 Establecer valores por defecto
 Reducir la memoria a corto plazo
  Basar el diseño en metáforas del mundo real
 Desglosar la información en forma progresiva
3. Construir una interfaz consecuente:
 Toda la información visual está organizada de acuerdo con el diseño estándar que se mantiene en todas las
presentaciones de pantalla.
 Todos los mecanismos de entrada se limiten a un conjunto limitado y se utilicen consecuentemente
 Los mecanismos para ir de tarea a tarea se hayan definido e implementado consecuente-mente.
Principios para construir una interfaz consecuente:
1- Permitir que el usuario realice una tarea en el contexto adecuado.
2- Mantener la consistencia en toda la familia de aplicaciones.
3- Los modelos interactivos anteriores han esperanzado al usuario, no realicemos cambios a menos que exista
alguna razón convincente para hacerlo.

¿Qué entiende por “facilidad de uso de la UI” en el proceso de diseño de una interfaz?
Es una medida de la manera en que un sistema facilita el aprendizaje, reduce la posibilidad de errores, les permite ser
eficientes y los deja satisfechos con el sistema. Algunas preguntas que ayudan a verificar la facilidad de uso son:
- ¿es posible usar el sistema sin ayuda ni enseñanza continua?
- ¿el sistema se ha adecuado al entorno físico y social en el que será usado?
- ¿El usuario sabe dónde se encuentra en cada momento?
- ¿la interfaz tolera los errores que se cometen? ¿la interacción es simple?

Tipos de interacción del usuario con la UI.

La interacción del usuario significa emitir comandos y datos asociados al sistema informático. 5 estilos principales:
● Manipulación directa: el usuario interactúa directamente con los objetos de la pantalla, mediante un dispositivo
apuntador que indica el objeto a manipular y la acción, la cual especifica lo que se debe hacer con ese objeto.
-Ventajas: interacción rápida e intuitiva. Fácil de aprender.
-Desventajas: puede ser difícil de implementar.
● Selección de menú: el usuario selecciona un comando de una lista de posibilidades (un menú).
-Ventajas: evita errores del usuario. Se requiere teclear poco.
-Desventajas: lenta para usuarios experimentados. Complejo si existen muchas opciones en el menú.
● Rellenado de formularios: el usuario rellena los campos de un formulario. Algunos campos pueden llevar menús
asociados, y el formulario puede tener botones.
-Ventajas: introducción de datos sencilla.
-Desventajas: ocupa mucho lugar en la pantalla.
● Lenguajes de comandos. El usuario emite un comando especial y los parámetros asociados para indicar al sistema
qué hacer.
-Ventajas: poderoso y flexible.
-Desventajas: difícil de aprender; gestión pobre de errores.
● Lenguaje natural. El usuario emite un comando en lenguaje natural, él se analiza y traduce a comandos del sistema.
-Ventajas: accesible a usuarios casuales. Fácil de ampliar.
-Desventajas: se requiere teclear más. No son fiables.

¿Cuál es el proceso de diseño de la UI (interfaz de usuario) según Sommerville? Indique las tres actividades.
Es un proceso iterativo donde los usuarios interactúan con los diseñadores y prototipos de la interfaz para decidir las
características, organización, apariencia y funcionamiento de la UI del sistema.
Existen tres actividades esenciales en este proceso:
  Análisis del usuario: Se desarrolla una comprensión de las tareas que este realiza, su entorno de trabajo, junto
con otros sistemas que utiliza, y las personas con las que interactúa. se realizan entrevistas, estudios
etnográficos, etc.
 Prototipo del sistema: Es el diseño y el desarrollo de la Interfaz en un proceso iterativo con el usuario, siendo
representada en forma tangible, para poder ser evaluado eficazmente.
- prototipos en papel: se muestran a usuarios finales.
- prototipos automatizados: a disposición de usuarios para pruebas y simulación de actividades.
Se debe trabajar con los usuarios para simular la utilización del sistema.
 Evaluación de la UI: Permanentemente debe ser sometido a evaluación para proceder a nuevos ciclos de
desarrollo iterativo en función de las experiencias reales. Consiste en evaluar la forma en que se utiliza una
interfaz y verificar que cumple los requerimientos del usuario.
Forma parte del proceso de Verificación y validación.

Atributo Descripción

Aprendizaje ¿Cuánto tiempo tarda un usuario nuevo en ser productivo con el nuevo sistema?

Velocidad de ¿Cómo responde el sistema a las operaciones de trabajo del usuario?

funcionamiento

Robustez ¿Qué tolerancia tiene el sistema a los errores del usuario?

Recuperación ¿Cómo se recupera el sistema a los errores del usuario?

Adaptación ¿Está muy atado el sistema a un único modelo de trabajo?

Existen varias técnicas menos costosas y sencillas en la evaluación de interfaces que pueden identificar deficiencias
específicas en el diseño de interfaces:
● Cuestionarios: recopilan información de lo que opinan los usuarios de la interfaz. Es una técnica económica.
● La observación de los usuarios cuando trabajan con el sistema teniendo en cuenta los recursos que utilizan, los
errores cometidos, etc.
● Instantáneas de videos del uso típico del sistema. El análisis completo por medio de video es caro aunque
permite descubrir demasiados movimientos de las manos o movimientos forzados del ojo.
● La inclusión de código en el software que recopila información de los recursos más utilizados y de los errores
más comunes.

Características:
• Un alto grado de iteración.
• Un muy alto grado de participación del usuario.
 • Un uso extensivo de prototipos.
• Normalmente pocos días de desarrollo (10% del proyecto).
• Funcionalidad limitada.
• Poca fiabilidad.

¿Cuál es el proceso de diseño de interfaz según Pressman?

El proceso de diseño de interfaz según Pressman consta de 4 etapas dispuestas en forma de espiral, donde cada vuelta
corresponde a una nueva iteración.
Etapas:
o Análisis de usuarios, tareas y entornos.
o Diseño de la interfaz.
o Implementación.
o Validación de la interfaz.

7) Verificacion y validación (pruebas)

Validación y verificación.

La verificación y la validación tienen lugar en cada etapa del proceso del software. V&V comienza con revisiones de los
requerimientos y continúa con revisiones del diseño e inspecciones del código hasta la prueba del producto.

● Validación: ¿Estamos construyendo el producto correcto? El objetivo de la validación es asegurar que el sistema software
satisface las expectativas.
● Verificación: ¿Estamos construyendo el producto correctamente? La verificación implica comprobar que el software está de
acuerdo con su especificación. Debería comprobarse que satisface sus requerimientos funcionales y no funcionales.

Actividades:

 Revisiones técnicas formales

 Auditorías de calidad y configuración
 Monitorización de rendimientos
 Estudios de factibilidad
 Revisión de la base de datos
 Análisis de algoritmos
 Pruebas de desarrollo
 Pruebas de validación y de instalación
 Simulación
 Revisión de la documentación

Dentro del proceso V&V, existen dos aproximaciones complementarias para el análisis y comprobación de los sistemas:

1. Las inspecciones de software analizan y comprueban las representaciones del sistema tales como el documento de
requerimientos, los diagramas de diseño y el código fuente del programa. Pueden usarse las inspecciones en todas las
etapas del proceso. Las inspecciones de software y los análisis automáticos son técnicas de V&V estáticas, ya que no se
necesita ejecutar el software en una computadora.
2. Las pruebas de software implican ejecutar una implementación del software con datos de prueba. Se examinan las salidas
del software y su entorno operaciones para comprobar que funciona tal y como se requiere. Las pruebas son una técnica
dinámica de verificación y validación.
Existen dos tipos de pruebas que pueden utilizarse en diferentes etapas del proceso del software:

- Las pruebas de validación intentan demostrar que el software satisface los requerimientos del cliente.
- Las pruebas de defectos intentan revelar defectos en el sistema en lugar de simular su uso operacional. El objetivo es hallar
inconsistencias entre un programa y su especificación.
Normalmente los procesos de V&V y depuración se intercalan. Los procesos de V&V intentan establecer la existencia de defectos en
el sistema software, mientras que la depuración es un proceso que localiza y corrige estos defectos.
V&V en los modelos de proceso
Modelo Lineal Secuencial: fase de prueba.

Modelo Evolutivo: validación.

UP: Testing o Prueba.

PRUEBAS

Las dos actividades fundamentales de pruebas son la prueba de componentes (probar las partes del sistema) y la prueba del sistema
(probar el sistema como un todo).

El objetivo de la etapa de la prueba de componentes es descubrir defectos probando componentes de programas individuales.
Durante las pruebas del sistema, estos componentes se integran para formar subsistemas o el sistema completo. En esta etapa, la
prueba del sistema debería centrarse en establecer que el sistema satisface sus requerimientos funcionales y no funcionales, y que
no se comporta de forma inesperada.

Objetivos:
1. Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.
2. Descubrir defectos en el software en que el comportamiento de éste es incorrecto, no deseable o no cumple su
especificación.
El primer objetivo conduce a las pruebas de validación, mientras que el segundo conduce a la prueba de defectos, en los que los
casos de prueba se diseñan para exponer los defectos.

Pruebas de Componentes
Las pruebas de componentes son el proceso de probar los componentes individuales en el sistema.
Existen diferentes tipos de componentes que pueden probarse en esta etapa:
 funciones individuales o métodos dentro de un objeto.
 clases de objetos que tienen varios atributos y métodos.
 componentes compuestos formados por diferentes objetos o funciones.
Las pruebas de clases de objetos deberían incluir:
 pruebas aisladas a todas las operaciones.
 la asignación y consulta de todos los atributos del objeto
 ejecutar el objeto en todos sus posibles estados.

Pruebas de interfaces

Muchos componentes en un sistema no son simples funciones u objetos, sino que son componentes compuestos formados por
varios objetos que interactúan. Se accede a las funcionalidades de estos componentes a través de sus interfaces definidas. Las
pruebas de estos componentes se ocupan principalmente de probar que la interfaz del componente se comporta de acuerdo con su
especificación.

Pruebas del Sistema

Las pruebas del sistema implica integrar dos o más componentes que implementan funciones del sistema o
características y probar este sistema integrado.
En un proceso de desarrollo iterativo, que se ocupan de probar un incremento que va a ser entregado al cliente o en su
defecto el sistema completo.
Existen dos fases distintas de pruebas del sistema:
1. Pruebas de integración: el equipo de pruebas tiene acceso al código fuente del sistema. Se ocupa principalmente
de encontrar defectos en el sistema. La principal dificultad es la localización de errores y donde han ocurrido.
2. Pruebas de entregas: se prueba una versión del sistema que podría ser entregada a los usuarios. Su prioridad es
validar que el sistema satisface sus requerimientos, mostrando que entrega la funcionalidad especificada,
 rendimiento y confiabilidad, y que no falla durante su uso normal. Cuando se prueban las entregas del sistema,
debería intentarse “romper” el software; es decir, el objetivo debería ser seleccionar entradas que tienen una alta
probabilidad de generar fallos en la ejecución del sistema. Por lo general son pruebas de caja negra.

Pruebas de rendimiento

Se ocupan tanto de demostrar que el sistema satisface sus requerimientos como de descubrir problemas y defectos en el
sistema.
Implican estresar el sistema realizando demandas que están fuera de los límites del diseño del software. Tiene como
objetivo:
 probar el comportamiento de fallo de ejecución del sistema, el cual no debe provocar la corrupción de los datos o
pérdidas inesperadas de servicios.
 sobrecargar el sistema y provocar que se manifiesten defectos que normalmente no serían descubiertos. Ejemplo: que se
tilde.

Diseño de Casos de Prueba

Caja Negra: Aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que
produce, sin tener en cuenta su funcionamiento interno. Se interesa en la forma de interactuar con el medio que le rodea
entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace.

Caja Blanca: se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos
funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas, entiendo como lo hace, a través
de códigos fuentes.

Según Sommerville, ¿qué diferencia hay entre lo que se conoce como un plan de prueba y un procesamiento de prueba?

Un plan de prueba traza las clases de prueba que se llevaran a cabo.

Un procedimiento de prueba define los casos de prueba específicos en un intento para descubrir errores de acuerdo con los
requisitos.

Cuando hablamos de pruebas de software, ¿qué entiende usted por “prueba de humo”? Explique 2 beneficios de su aplicación.

Es una prueba de integración, comúnmente utilizada cuando se desarrolla un producto software empaquetado. Es una prueba que
ejercita el sistema entero de principio a fin, no ha de ser exhaustiva, pero será capaz de descubrir importantes problemas.

En esencia, la prueba de humo comprende las siguientes actividades:

1. Los componentes software que han sido traducidos a código se integran en una “construcción”. Una construcción incluye
ficheros de datos, librerías, módulos reutilizables y componentes de ingeniería que se requieran.
2. Se diseña una serie de pruebas para exponer los errores que evitarán a la construcción realizar adecuadamente
su función. La intención debe ser descubrir errores “paralizantes” que tengan la mayor probabilidad de retrasar el
proyecto.
3. La construcción se integra con otras construcciones, y todo el producto se somete a prueba de humo
diariamente.

Beneficios:
 Se minimiza el riesgo de integración. Puesto que las pruebas de humo se realizan diariamente, las
incompatibilidades y otros errores paralizantes pueden descubrirse tempranamente, reduciendo la probabilidad
de impacto en la planificación por errores sin descubrir.
 Se perfecciona la calidad del producto final: por estar orientada a la construcción, esta prueba también
descubrirá errores funcionales, además de los defectos de diseño a nivel de componente y de arquitectura.
 Se simplifican el diagnóstico y la corrección de errores: es probable que los errores sin descubrir durante la
prueba de humo se asocien a “nuevos incrementos de software”; es decir, el software que se acaba de añadir a
la construcción es causa probable de un error recientemente descubierto
  El progreso es más fácil de valorar. Con cada día que transcurre, más software se integra y se demuestra que
funciona. Esto incrementa la moral del equipo y brinda a los gerentes un buen indicio de que se está
progresando.

Pruebas de Regresión
Las pruebas de regresión pueden realizarse para asegurar que no se introdujeron nuevos errores (bugs). Ayudan a garantizar que los
cambios (debidos a pruebas o por otras razones) no introducen comportamiento no planeado, errores adicionales o carencias de
funcionalidad.
Por lo tanto, se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se
vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa.

La suite de prueba de regresión (el subconjunto de pruebas que se va a ejecutar) contiene tres clases diferentes de casos de prueba:
• Una muestra representativa de pruebas que ejercitará todas las funciones de software.

• Pruebas adicionales que se enfocan en las funciones del software que probablemente resulten afectadas por el cambio.
• Pruebas que se enfocan en los componentes del software que cambiaron.

AUDITORIAS

 Auditar es examinar la gestión económica de una entidad a fin de comprobar si se ajusta a lo definido por la ley.
 La auditoría de desarrollo: trata de verificar la existencia y aplicación de procedimientos de control permitan
garantizar que el desarrollo de sistemas de información se ha llevado a cabo según los principios de ingeniería, o
determinar las deficiencias existentes en este sentido.
 La Auditoría de Sistemas: comprueba la existencia de procedimientos de control, su correcta definición y
aplicación. Determina las deficiencias que existan al respecto y los riesgos asociados a la falta de control.

Auditoría de Sistemas de Información

Tiene como objetivo comprobar los procedimientos abarcados desde el análisis hasta la aplicación, para llevar a cabo el sistema:
Análisis, Diseño, Programación, Prueba, Entregas, etc.
Los riesgos que pueden darse por la falta de control son: que el sistema no sea lo que busca el cliente.

Riesgos tecnológicos, riegos económicos, riegos del proyecto.

La Auditoría de Sistemas es un examen y verificación del cumplimiento de los controles y procedimientos utilizados para
la confidencialidad, integridad y disponibilidad de los sistemas de información.
El control puede realizarse de manera:

 interna: dentro de la misma organización hay un grupo de personas o empleados que realizan pruebas.
 externa: cuando se contrata a un grupo de auditores, se les entrega la información del sistema y ellos controlan. Siendo
este mejor, ya que no se pasan por alto errores y se verifican más procedimientos.

Auditoría de Diseño

Diseño técnico del Sistema

Arquitectura física Se debe asegurar que el sistema se adapte a los requerimientos especificados por el sistema y que
la arquitectura física responde a los estándares definidos por la organización.
Se debe diseñar la estructura física de datos adaptando las especificaciones del sistema al entorno tecnológico.
Arquitectura lógica se debe comprobar que los componentes del sistema tengan un mínimo acoplamiento y alta
cohesión interna.
Todos los artefactos o documentos producidos en el diseño deben estar completos en sus partes (de acuerdo a los
estándares).
Se tiene que documentar el plan de pruebas que permita verificar cada componente del sistema por separado, el
funcionamiento de los subsistemas y, una vez integrados, el sistema en si.
Auditoría de datos

Arquitectura o diseño de la base de datos

Controlar si responde a los estándares de seguridad establecidos por la organización. “habeas Data”

8) Informacion, Archivos y Base de Datos

¿Cuál es la diferencia entre dato e información?

Dato: representa un valor relevante.
Información: Conjunto organizado de datos que procesados, constituyen un bien activo que nos permite tomar decisiones

¿Cuáles son las 3 condiciones que debe cumplir la información obtenida por el sistema para que la misma sea
valiosa para la operación?
- Oportuna.
- Precisa.
- Concisa (no debe ser redundante).
- Comprensiva (debe ser de fácil lectura y comprensión).
Propiedades características de la Información.
.
 Integridad asegura que su contenido permanezca invariable a menos que sea modificado por personas y/o
procesos debidamente autorizados.
 Operatividad o disponibilidad tenerla accesible para ser procesada y/o consultada.
 Confidencialidad o privacidad sea sólo conocida por personas y/o procesos debidamente autorizados. El
objetivo, prevenir la divulgación no autorizada de la información.
 Autenticidad propiedad de poder reconocer y certificar el origen y/o destino de la información.

¿Qué son los métodos de acceso? En una estructura simple, ¿cuántos existen?
Los métodos de acceso son aquellos que recuperan (método accesor) o establecen (método mutador) el valor de los
atributos. Una estructura común consiste en contar con un accesor y un mutador por cada atributo y declarar privados
todos los atributos (para obligar al encapsulamiento). Estos no se incluyen en la descripción del diagrama de clases
DER
Modelo Entidad - Relación (DER): Percepción del mundo real, identificando entidades (con sus atributos) y las relaciones
entre ellos. Presenta:
Entidades que pueden ser:
Fuertes: Su existencia no depende de otra.
Débiles: No pueden existir sin otra. Su clave es la misma que la de la cual depende.
Y atributos. Las entidades se representan mediante un rectángulo, y los atributos mediante una elipse.

En la organización de datos que almacena el sistema, el analista debe alcanzar la optimización y eficiencia de los
mismos. ¿A través de qué procesos se consigue esto? ¿En qué consisten? Mencione dos de las causas para
llegar al mismo.
El proceso para alcanzar la optimización y eficiencia de los datos es el de normalización. Este proceso se realiza para
evitar las duplicaciones de datos en diferentes archivos y para evitar inconsistencia y anomalías en los mismos. Por
medio de la normalización, un conjunto de datos en un registro se reemplaza por varios registros que son más simples y
predecibles y manejables. Se lleva a cabo por 4 razones:
- estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos.
- permitir la recuperación de los datos en respuesta a las solicitudes de consultas y reportes.
- simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.
- reducir la necesidad de reestructurar y reorganizar los datos cuando surjan nuevas aplicaciones.

¿Qué es una clave candidata?

Es un atributo que puede identificar unívocamente a cada miembro de una entidad o archivo; a su vez, una entidad o
archivo puede tener uno o varios o ningún identificador único. Normalmente, se elige a uno de los identificadores únicos
para facilitar la diferencia y procesamiento de los datos.

¿Cuál es la condición para que un atributo o campo puede ser definido como clave primaria o índice primario de
un archivo?
- No se puede dar valor indefinido o desconocido a la clave.
- Debe ser de uno natural para los usuarios.
- Identificar unívocamente al dueño del atributo.
- La cantidad de atributos que la componen debe ser la menor cantidad posible.
- La cantidad de caracteres que la componen debe ser la menor posible.

¿Cuáles son los grandes grupos de estructura de archivos? (2 diferencias)

Se conocen 2 grandes grupos de estructura de archivos; estos son:
- archivos convencionales: un archivo es una colección de información localizada o almacenada como una unidad
en alguna parte del disco. Conjunto de tablas.
- base de datos: sistema que contiene todos los archivos disponibles. Las BD organizan la información sin
considerar los archivos como unidades independientes, sino como paquetes relacionados entre sí, y brindan
servicios para manejar la información. Están manejadas por un software especial DBMS (sistema de
administración de bases de dato).

¿Cuál es la diferencia existente con respecto a los archivos lógicos en una estructura de Base de Datos y en un
ambiente de archivos convencionales?
En las BD, los registros son parte del mismo archivo lógico o BD que serán utilizados por todas las aplicaciones; sin
embargo en los archivos convencionales cada aplicación está separada de las demás y los datos para cada una se
localizan en diferentes archivos lógicos.
● Portabilidad: los archivos tienen la ventaja de ser portables con respecto a la BD. La portabilidad en la BD es
más traumática, aunque con las nuevas tecnologías se amplificó mucho.
● Herramientas: las BD han generado herramientas consistentes por lo que los desarrolladores de AC realizaron
mejoras para acercarse a las BD.

Indique cómo se clasifican los archivos según la utilización que se les dé?
 Archivo maestro: utilizado para guardar información permanente.
 Archivos de transacciones, novedades o movimientos.
 Archivos de trabajo: archivos que me sirven para la ejecución del programa o del trabajo, y luego se destruyen.
 Archivos de unión: unir dos procesos, una vez que finaliza la comunicación entre los procesos los archivos se
destruyen.
 Archivo de tabla: archivos pequeños, que guardan generalmente códigos.

¿Cómo se relacionan en UML 2 objetos que tienen datos estrechamente vinculados y como se los hace en una
BD relacional. De un ejemplo de este último.
En UML, para relacionar tipos u objetos se debe recurrir a la asociación. En una BD relacional, esto se hace a través de
un tipo de atributo de clave foránea (por ejemplo, número de factura).

SALIDA EN LÍNEA
Características:
 La respuesta inmediata a las solicitudes del usuario;
 La demanda poco predecible;
 Contacto directo entre la computadora y el usuario.
Interface: es la frontera entre el usuario y la aplicación del sistema de cómputo (el punto donde la computadora y el
usuario interactúan).
Objetivos:
 Decir al sistema las acciones a realizar;
 Facilitar el uso del sistema y;
 Evitar los errores del usuario.
Características:
 a) Los dispositivos utilizados para introducir y recibir datos (teclado, mouse, scanner, touch screen, la voz, etc.),
b) El diálogo que conduce la interacción entre el sistema y el usuario y
c) Los métodos y patrones que se siguen al mostrar la información (cómo se muestra u organiza la información).

Diseño del diálogo: el diálogo es la forma en la que el usuario interactúa con el sistema de cómputo y con la aplicación.
Determina la “amigabilidad” del sistema e influye en la decisión del usuario al usar el sistema.
Diagramas de diálogo: son los conocidos como “interrelación de pantallas”, “secuencia o concatenación de pantallas”,
etc.

¿Qué entiende por paginación y scrolling? ¿Para qué sirven?

Según la naturaleza de la aplicación, puede que exista mucha información que es importante mostrarla en una sola
pantalla. La paginación y scrolling son métodos para manejar esta situación.
● Paginación: consiste en presentar información en múltiples páginas, teniendo en cuenta que el usuario puede ir
hacia delante o hacia atrás.
● Scrolling: se la necesita cuando los usuarios necesitan rastrear líneas de información específicas en un cúmulo
de datos. Con esta estrategia, las líneas se mueven hacia arriba o hacia abajo y a medida que se agrega una
línea nueva desaparece otra.
La diferencia es que en la paginación desaparece una pagina y aparece otra y con scrolling presenta un pantallazo y
se desplaza el texto línea por línea.

¿Cuántas estrategias de diálogo conoce para una conversación en línea? Explique brevemente cada uno de
ellos.
● Estrategia general del diálogo: conducción por menú, teclado.
● Diálogo de entrada de datos: forma o bosquejo que muestra la información a introducir.
● Paginación y scrolling
● Mensajes y comentarios: tiene como finalidad: indicar el estado del proceso, indicar que se ha detectado un
error, solicitar al usuario que elija una acción y verificar que una acción elegida sea la correcta;
● Asignación de teclas: aunque se use el mouse, teclado, etc. se debe usar o programar teclas de propósito
especial como alternativas del diálogo;
● Sistemas de ayuda: sirven para informar a los usuarios del sistema.

Acciones de procesamiento: al diseñar se debe cumplir cómo realizar las siguientes acciones:
 Edición de datos: cambiar el valor de un campo capturado previamente;
 Almacenamiento de datos: la transferencia de los datos desde la captura a un medio;
 Recuperación de datos: traerlos desde el almacenamiento para mostrarlos, editarlos o producir una salida).
 Captura de datos: descripción de los campos y su posición en la pantalla;

¿Cómo se relacionan en UML 2 objetos que tienen datos estrechamente vinculados y cómo se lo hace en una BD
relacional?. Dé un ejemplo de este último.
En UML para relacionar tipos u objetos se debe recurrir a la asociación. En una BD relacional esto se hace a través de un
tipo de atributo de llave foránea (Ej. N° de factura).

Según Pressman, para una solución modular se pueden exponer muchos niveles de abstracción, ¿qué significa
este concepto?
Significa que se debe concentrar en el problema a algún nivel de generalización sin tener en consideración los datos
irrelevantes de bajo nivel. En el nivel más alto, se utilizará el lenguaje del entorno del problema y en el más bajo se
establece la solución para implementarlo (generar código fuente).

Mencione por lo menos 2 acciones para reducir el mantenimiento de un sistema.

El mantenimiento es el proceso de introducir cambios en un sistema luego de que éste fue entregado. Existen tres tipos
de mantenimiento de software: para reparar defectos del software, para adaptar el software a diferentes entornos
operativos o para añadir o modificar funciones del sistema.
Normalmente, resulta rentable invertir esfuerzo en el diseño e implementación para reducir los costos de mantenimiento.
a. Preparar lo mejor posible la documentación.
 b. Definir con mayor precisión los requerimientos del usuario durante el desarrollo.
c. Usar procedimientos estándar y más efectivos para el diseño.
d. Hacer un mejor uso de las herramientas y técnicas existentes.
e. Dirigir el proceso de Ingeniería de Sistemas en forma efectiva.

9) Entrada de Datos
Entrada de Datos.
Mencione por lo menos 2 objetivos que se persigue en el diseño de la entrada de un sistema de información y de
una breve explicación de los mismos.
El diseño de la entrada es lo que une al mundo y sus usuarios con el sistema de información.
Objetivos del diseño de la entrada:
- control de la cantidad de entrada. Se apunta a disminuir los requerimientos de datos de manera que se reduzcan
los costos y a acelerar los procesos de carga de información.
- evitar los retrasos: evitar los cuellos de botella, utilizando técnicas disponibles para hacerlo evitar los errores en
los datos: disminuyendo el volumen de datos que deben ingresarse por cada transacción o detectándose los
errores lo más rápido posible.
- evitar los pasos adicionales: se debe asegurar que el proceso sea lo más eficiente posible reduciendo los pasos
a seguir.
- mantener la sencillez del proceso: alcanzar todos los objetivos mencionados en la forma más sencilla posible.

En los lineamientos para la captura de datos es importante considerar algunos aspectos para no proporcionar
como entrada algunos requerimientos innecesarios? ¿Cuáles son?
Existen dos tipos de datos que deben proporcionarse como entradas cuando se procesan transacciones:
1. Datos variables: son aquellos datos que cambian para cada transacción o toma de decisiones
2. Datos de identificación: es el dato que identifica en forma única al registro que será procesado
No se deben requerir:
a. Datos constantes: aquellos idénticos para cualquier transacción.
b. Detalles que el sistema puede recuperar: datos almacenados que el sistema puede recuperar con rapidez de sus
archivos
c. Detalles que el sistema puede calcular: recursos que se pueden producir al pedir que el sistema utilice
combinaciones de datos almacenados y proporcionados.

¿Qué aspectos se debe considerar en la entrada?:

1. ¿Se encuentran los datos en una forma utilizable o que puede ser leída por el sistema?
2. ¿Cuál es el mejor método para ingresar los datos y que al mismo tiempo minimice la cantidad de entrada, el
número de errores en los datos y el tiempo necesario para ingresarlos?

Validación de la entrada: en principio el analista debe suponer que se presentarán errores en la entrada de los datos,
para ello debe validarlos y evitarlos durante la entrada. Los que más ocurren son:
1. Pruebas de existencia: o sea que el campo contenga datos;
2. Pruebas de límites y rangos: o sea que los valores ingresados estén dentro de los extremos predefinidos
posibles;
3. Pruebas de combinación: validan el hecho de que varios datos tengan al mismo tiempo valores aceptables
(p.ej: si la operación es con tarj.de crédito debe estar especificado el n° de la misma);
4. Procesamiento duplicado: en áreas importantes se deben procesar los datos más de una vez, en el mismo o
en diferentes equipos (p.ej: programa espacial);
5. Modificación de los datos de la transacción: se realiza ya sea mediante corrección automática (completando
el dato automáticamente), uso de dígitos de verificación, etc.).
Salida de Datos.
La salida es la información que se entrega a los usuarios por medio del sistema de información, ya sea impresa o por
pantalla.. Algunos datos requieren un procesamiento externo antes de que se conviertan en salida adecuada; y otros
datos son guardados y considerados salida cuando se les recupera con poco o ningún procesamiento.
La salida impresa se especifica cuando se necesita:
 enviar por correo un documento ya sea a un cliente o proveedor.
 imprimir un registro de datos.
 notificar cierta información.
 hacer llegar al mismo tiempo un gran volumen de información a varias personas.
Las fuentes de información para el diseño de la salida impresa son:
 requerimientos de datos.
 diccionario de datos, en el cual se incluyen los nombres de los elementos de datos y la longitud requerida.
 requerimientos funcionales.

¿Qué aspectos o circunstancias se consideran para diseñar la salida de un sistema?

Este término se usa para denotar cualquier información producida por un sistema de información, ya sea impresa o en un
pantalla. Al diseñarla, el analista:
 Identifica la salida específica que es necesaria para satisfacer los requerimientos de información,
 Selecciona los métodos para presentar dicha información,
 Crea los documentos, reportes o formatos que contienen la información producida por el sistema.

Objetivos de la salida.
- Expresar información relacionada con actividades pasadas, estado actual o proyecciones para el futuro.
- Señalar eventos importantes, oportunidades, problemas o advertencias.
- Iniciar una acción.
- Confirmar una acción.

Condiciones que se deberían cumplir:

- Diseñar la salida para que sirva el propósito deseado
- Diseñar para que se ajuste al usuario
- Entregar la cantidad adecuada de salida
- Asegurarse de que la salida se encuentra donde se necesita
- Entregar la salida a tiempo
- Seleccionar un método de salida adecuado

Aspectos a considerar en la salida:

● ¿Quiénes recibirán la salida? (cliente interno o externo, etc).
● ¿Cuál es el uso que se le pretende dar? (cliente interno o externo, gerente u operario, etc.).
● ¿Cuántos detalles son necesarios?
● ¿Cuándo y con qué frecuencia es necesaria la salida? (periodicidad)
● ¿Qué método utilizar? (impresa o por pantalla, señal audible o no, etc).

¿Cómo presentar la información?

- Formato tabular: en forma de tablas (información detallada, con pocos comentarios, con etiquetas para cada
columna, con totales, etc).
- Formato gráfico: son gráficos orientados generalmente a brindar información a nivel general. Existen gráficos de
sectores (círculo), curvas, barras y escalones, mapas, etc.

Tipos de Salida:
 Documentos:
Son salidas externas por que se dirigen a clientes, proveedores, accionistas, etc. Generalmente tiene una forma pre-impresa. Un
documento puede ser recibos de servicios públicos, facturas, cheques, resúmenes de cuenta, tickets de pago.
 Reportes:
Los reportes son salidas externas, es decir que permanecen dentro de la organización. Pueden ser resúmenes, reportes,
históricos, o excepciones.
 Mesajes:
Pueden ser tanto internos como externos

¿Qué es un documento de retorno?

El documento de retorno es un documento impreso emitido por el sistema, que más adelante regresará como
documento de entrada, contiene en una sección todos los detalles relacionados con el cliente, número de
cuenta, importe a pagar. Estos detalles están impresos en caracteres especiales.
Si cumple con este requisito, debe ser considerado como un concepto más en el modelo conceptual.

Consideraciones para el diseño.

 La información constante: permanece igual cada vez que es impreso el reporte o detalles pre-impresos. Por
ejemplo, encabezados, títulos y nombres del documento, nombre de la organización y dirección, notas y
comentarios.
 La información variable puede variar cada vez que el reporte o documento es impreso. Por ejemplo, detalles,
resúmenes y totales, marcas de control, separadores.
 Los reportes y documentos deben leerse de izquierda a derecha y de arriba hacia abajo.
 Los datos más importantes deben ser los más fáciles de encontrar (van hacia el margen izquierdo).
 Todas las páginas deben tener un título y un número de página, además de contener la fecha
 Todas las columnas deben estar etiquetadas. Se deben evitar abreviaturas.
 Encabezado: es el título.
 Datos y detalles: se debe especificar las etiquetas de cada columna que se utilice.
 Notas al pie u aclaratorias
 Reverso: información guía o aclaratoria como servicio.

Diseño de la salida en pantalla:

Rigen en general los mismos principios utilizados para la salida impresa, salvo aquellos que, obviamente, por las
características físicas de este medio no se puedan considerar.
El diseño dependerá de las características del monitor, a saber:
 Dimensiones físicas de la pantalla.
 Número de renglones y columnas de datos que pueden ser mostrados al mismo tiempo.
 Grado de resolución (alta, mediana o baja).
 Número de colores disponibles.
 Métodos de realce (subrayado, negritas, parpadeo, diferentes intensidades, etc.).
En general para el diseño se utiliza el principio de reconocer áreas de trabajo (títulos, detalle, pie, ventanas, etc.).

¿Bajo qué condiciones se deben implementar las formas pre impresas en el diseño?
Entre las situaciones más representativas donde debe considerarse el uso de formas pre impresas se encuentran las
siguientes:
- reglamento o requerimientos legales que obliguen el uso de formas pre impresas.
- destinatarios que esperan en formato estándar.
- la inclusión de un prototipo de la organización. Una marca registrada o símbolo que deben estar incluidos en la
forma.
- trabajo artístico o gráfica que tendrán mejor apariencia si se pre imprimen.

Razones que impulsan usar el formato gráfico:

1. Para mejorar la efectividad de los reportes que como salida se envían a los usuarios que deben recibirlos;
2. Para manejar mejor el volumen de información; y
3. Para ajustarse a preferencias personales.