Integrador anlisis y diseo de software resumen.pdf

lOMoARcPSD|13420236 Análisis y Diseño de Software. Modulo 1 y 2 Análisis y Diseño de Software (Universidad Siglo 21) Escanea para abrir en Studocu Studocu no está patrocinado ni avalado por ningún colegio o universi...

lOMoARcPSD|13420236 Análisis y Diseño de Software. Modulo 1 y 2 Análisis y Diseño de Software (Universidad Siglo 21) Escanea para abrir en Studocu Studocu no está patrocinado ni avalado por ningún colegio o universidad. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Modelos, conceptos y tipos de metodologías ¿Qué es un modelo y por qué modelamos? Un modelo es una simplificación de la realidad. Proporciona los planos de un sistema. Pueden ser planos generales, que ofrecen una visión global del sistema en consideración, así como detallados. Un buen modelo incluye, para un nivel de abstracción dado, los elementos que tienen gran influencia y omite aquellos menores que no son relevantes. Todo sistema puede ser caracterizado desde diferentes perspectivas, utilizando diferentes modelos. Un modelo puede ser estructural y resaltar la organización del sistema o de comportamiento, destacando su dinámica. Se construyen modelos para comprender mejor el sistema que estamos desarrollando. A través del modelado, se persiguen los siguientes objetivos:  Visualizar cómo es o queremos que sea un sistema.  Especificar la estructura o el comportamiento de un sistema.  Obtener plantillas que sirven de guía en la construcción de un programa.  Documentar las decisiones que se han adoptado. Construimos modelos de sistemas complejos porque es difícil comprender el sistema en su totalidad. El ser humano tiene una capacidad limitada para comprender y abordar la complejidad, por ello, a través del modelado podemos reducir el problema que se está estudiando y enfocarnos en un aspecto a la vez. En general, aun en el proyecto más simple, los desarrolladores siempre realizan alguna actividad de modelado como un bosquejo en hoja de papel o en algún software graficador. Sin embargo, estos modelos informales no proporcionan frecuentemente un lenguaje común que pueda compartirse entre todos los desarrolladores y no siempre queda debidamente documentado. Principios básicos de modelado “La elección de los modelos a crear tiene mucha influencia sobre cómo se aborda el problema y cómo se da forma a la solución”. Esto quiere decir que hay que elegir bien los modelos. Los adecuados pueden arrojar mucha luz sobre los problemas de desarrollo más complicados y brindar una comprensión que no podríamos obtener de otra manera. Ahora bien, si se incurre en la utilización de modelos erróneos o inadecuados, estos desorientarán haciendo que uno se centre en cuestiones irrelevantes. “Todo modelo puede ser expresado a distintos niveles de precisión”. Los mejores tipos de modelos son aquellos que permiten elegir el grado de detalle dependiendo de quién está viendo el sistema y por qué necesita verlo. Lo que un usuario final espera de un modelo del sistema no es lo mismo que necesita un diseñador. Un analista o un usuario final se centrarán en “qué” hace el sistema; un diseñador/desarrollador se centrará en el “cómo”. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 “Los mejores modelos son los que están ligados a la realidad”. Todos los modelos simplifican la realidad; lo importante es que esta simplificación no enmascare ningún detalle importante. Es mejor tener modelos que tengan una clara conexión con la realidad y donde esta conexión sea débil saber concretamente cómo se apartan estos modelos del mundo real. “No es suficiente confeccionar un único modelo. Todo sistema no trivial se aborda mejor a través de un conjunto de modelos casi independientes”. Tipos de metodologías  Concepto de metodología: En principio podemos definir una metodología como “un conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para los desarrolladores de sistemas de información”. De acuerdo a esta definición, una metodología es entonces un conjunto de componentes que especifican: - Cómo dividir un proyecto en etapas. - Las tareas que se llevan a cabo en cada etapa. - Las salidas que se producen y cuándo se deben producir. - Las restricciones que se aplican. - Las herramientas que se van a utilizar. - Cómo se gestiona y controla un proyecto. Una metodología, por lo tanto, representa el camino para desarrollar software de manera sistemática. Se mencionan a continuación algunos conceptos relacionados con las metodologías:  Métodos: indican cómo construir técnicamente un sistema. Abarcan un amplio espectro de tareas que incluyen la comunicación, el análisis de los requisitos, el modelado de diseño, la construcción de programas, la realización de pruebas y el soporte  Técnica: es un método estructurado y repetible para lograr una tarea específica.  Herramientas: suministran un soporte automatizado o semiautomatizado para el proceso y los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería de software asistido por computadora (CASE). Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Objetivos de las metodologías Se pueden identificar, de forma general, tres necesidades principales que se intentan cubrir con una metodología:  Mejores aplicaciones. De todos modos, hay que tener en cuenta que el seguimiento de una metodología no basta para asegurar la calidad del producto, sino que esto depende de muchos pequeños factores.  Un mejor proceso de desarrollo que identifica las salidas o productos intermedios de cada fase, lo que permite planificar y controlar el proyecto.  Un proceso estándar en la organización, lo que aporta entre otros beneficios una mayor integración entre los proyectos de sistemas en marcha y una mayor facilidad en el cambio de personal de un proyecto a otro. Entre los objetivos que pueden tener las metodologías, podemos mencionar: - Registrar los requisitos de un sistema de información de manera apropiada. - Proporcionar un método sistemático de desarrollo de forma que se pueda controlar su progreso. - Construir un sistema de información dentro de un tiempo apropiado y costos aceptables. - Construir un sistema bien documentado y que sea fácil de mantener. - Ayudar a identificar lo más pronto posible cualquier cambio que sea necesario a realizar dentro del proceso de desarrollo. - Proporcionar un sistema que satisfaga a todas las personas afectadas por este, ya sean clientes, directivos, auditores, usuarios- Características deseables en una buena metodología Entre las características deseables que debería incluir una metodología se pueden destacar las siguientes:  Existencia de reglas predefinidas: la metodología debería indicar formalmente reglas que definan sus fases, las tareas, productos intermedios, técnicas y herramientas a utilizar.  Cobertura total del ciclo de desarrollo: debe indicar los pasos a seguir para cubrir desde el planteamiento de un sistema hasta su mantenimiento.  Verificaciones intermedias: debe contemplar la realización de verificaciones sobre los productos generados en cada fase para comprobar su corrección.  Enlace con procesos de gestión: debe proporcionar una forma de desarrollar software de manera planificada, controlada y de calidad.  Comunicación efectiva: debería proporcionar un medio de comunicación efectiva entre los desarrolladores para facilitar el trabajo en grupo y con los usuarios.  Utilización sobre un abanico amplio de proyectos: debe ser flexible para poder emplearse en proyectos de diverso tamaño, variedad y entorno. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Fácil formación: la organización debe formar a su personal en todos los procedimientos y técnicas definidos por la metodología.  Uso de herramientas CASE: la metodología debe ser soportada por herramientas automatizadas que mejoren la productividad del equipo de desarrollo y la calidad de los productos obtenidos.  Contener actividades que mejoren el proceso de desarrollo: es necesario definir mediciones que indiquen la calidad y el costo asociado a cada etapa del proceso. Estos datos se utilizarán para analizar y modificar el proceso para su mejora.  Soporte al mantenimiento: el campo de la evolución del software debería ser tenido en cuenta por las metodologías para facilitar las modificaciones sobre los sistemas existentes.  Soporte de la reutilización de software: se deberían incluir procedimientos para la creación, mantenimiento y recuperación de componentes reutilizables que no se limiten solo al código. La aplicación de patrones de software en las distintas etapas del proceso de desarrollo ayuda a la reutilización de soluciones de análisis y diseño. Tipos de modelos de proceso 1) El ciclo de vida clásico o en cascada: El modelo en cascada, llamado también ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo de software tal como se visualiza en la siguiente figura. El modelo en cascada es el más antiguo para la ingeniería de software, sin embargo, las críticas realizadas a este durante las décadas precedentes ocasionaron que aun sus más fervientes seguidores se hayan cuestionado su eficacia. Entre los problemas que presenta el modelo en cascada podemos enunciar:  Los proyectos reales rara vez siguen el flujo secuencial que propone el modelo.  Frecuentemente es difícil para el cliente definir todos los requisitos de manera explícita en el inicio del proyecto. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Una versión funcional de los programas solo estará disponible cuando el proyecto esté bastante avanzado, por lo que el cliente deberá tener paciencia.  La naturaleza lineal del modelo en cascada conduce a situaciones en las cuales algunos miembros del equipo de trabajo deben esperar a otros para terminar tareas dependientes, lo cual “bloquea” el avance del proyecto. 2) Modelos de procesos incrementales: Muchas veces los requisitos iniciales del software están bien definidos, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, es probable que sea necesario proporcionar de manera rápida un conjunto limitado de funcionalidad para el usuario y luego refinarla y expandirla en las entregas posteriores del software. Se presentan a continuación dos modelos de proceso de este tipo:  El modelo incremental: El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Como se muestra en la siguiente figura, este aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos en el software. Con frecuencia, el primer incremento es un producto esencial, es decir, se consideran los requisitos básicos pero muchas características complementarias aún no se incorporan. El producto se muestra al cliente y como resultado de la evaluación se desarrolla un plan para el incremento siguiente que afronta la modificación del producto esencial a fin de satisfacer mejor las necesidades del cliente e incorporar características y funcionalidades adicionales. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  El modelo DRA: El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a “alta velocidad” del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción basado en componentes. Como todos los modelos de proceso, este enfoque presenta algunos inconvenientes: - Para proyectos grandes escalables se necesitan suficientes recursos humanos para crear el número correcto de equipos DRA. - Los proyectos DRA pueden fracasar si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en tiempo breve. - Es problemática la construcción de los componentes necesarios para el DRA si el sistema no se puede modular en forma apropiada. - Si el alto rendimiento es un aspecto importante y se alcanzara al convertir interfaces en componentes del sistema, este enfoque puede no funcionar. - El modelo DRA no es apropiado cuando los riesgos técnicos son altos, por ejemplo, cuando la nueva aplicación requerirá muchas nuevas tecnologías. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 3) Modelos de procesos evolutivos: Los modelos evolutivos son iterativos y se caracterizan por la forma en que permiten que se desarrollen versiones cada vez más completas del software. Se presentan a continuación dos modelos de proceso de este tipo:  Construcción de prototipos: Frecuentemente los clientes definen un conjunto de objetivos generales para el software, pero no identifican los requisitos detallados de entrada, proceso o salida. En estos casos y en muchas otras situaciones un modelo de construcción de prototipos puede ser de utilidad. Si bien la construcción de prototipos se puede utilizar como un modelo de proceso independiente, se emplea más comúnmente como una técnica que puede implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos. La construcción de prototipos también plantea algunos inconvenientes: - El cliente ve lo que parece una versión en funcionamiento del software sin saber que por la prisa de hacer funcionar el prototipo no se ha considerado la calidad del software global o la facilidad de mantenimiento a futuro y le cuesta comprender que debe construirse otra vez para mantener los altos niveles de calidad. - Muchas veces el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez y luego se familiariza con las selecciones realizadas y se olvidan las razones por las que son inapropiadas. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  El modelo en espiral: El modelo en espiral que fue propuesto originalmente por Boehm es un modelo de proceso de software evolutivo que combina la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Cuando se aplica este modelo, el software se desarrolla en una serie de entregas evolutivas. A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de todo el ciclo de vida del producto de software siguiendo su evolución. Características de los modelos orientados a objetos El paradigma orientado a objetos En los modelos orientados a objetos, el sistema se puede ver (en términos de percepción) como una colección de objetos que colaboran entre sí para obtener un objetivo común. Las operaciones que modifican el estado de los objetos son sencillas; los objetos se construyen a partir de otros, lo que lleva a que los sistemas se puedan construir a partir de componentes probados. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 El análisis y diseño orientado a objetos tiene algunas características importantes:  Cambian nuestra forma de pensar sobre los sistemas. Para la mayoría de las personas la forma de pensar OO es más natural. Comenzamos a aprender sobre ellos desde la infancia (por ejemplo, al agitar un sonajero, este hace ruido). Desde una etapa muy temprana categorizamos los objetos y descubrimos su comportamiento.  Los sistemas suelen construirse a partir de objetos ya existentes. Esto lleva a un alto grado de reutilización, a una disminución de costos, un menor tiempo de desarrollo y una mayor confiabilidad del sistema.  La complejidad de los objetos que podemos utilizar sigue en aumento, puesto que nuevos objetos se construyen a partir de otros, que a su vez están constituidos por otros objetos, y así sucesivamente.  Ayuda a explotar la potencia expresiva de los lenguajes de programación basados en objetos y orientados a objetos. Elementos del modelo de objetos Para todo lo que se considere “orientado a objetos” (un lenguaje de programación, una herramienta CASE, técnicas de modelado, un proceso de desarrollo, por ejemplo) el marco de referencia conceptual es el modelo de objetos. Hay cuatro elementos fundamentales en este modelo:  Abstracción.  Encapsulamiento.  Modularidad.  Jerarquía. Abstracción: Una abstracción se centra en la visión externa de un objeto y sirve para separar el comportamiento esencial de un objeto de su forma de implementación. En el desarrollo del modelo de objetos de un sistema se tratará de construir abstracciones de entidades que imiten directamente el vocabulario de un determinado dominio de problema. Encapsulamiento: La abstracción y el encapsulamiento son conceptos complementarios: mientras que la abstracción se centra en el comportamiento observable de un objeto, el encapsulamiento lo hace en la implementación que da lugar a este comportamiento. El encapsulamiento se consigue mediante la ocultación de información, por el cual se ocultan todos los aspectos de un objeto que no contribuyen a sus características esenciales. Modularidad: la modularización consiste en dividir un programa en módulos que pueden compilarse separadamente, pero que tienen conexiones con otros módulos. Jerarquía: La jerarquía es una forma de clasificar u ordenar las abstracciones. Frecuentemente un conjunto de abstracciones forma una jerarquía y la Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 identificación de esta en el análisis y diseño simplifica en gran medida la comprensión del problema. Las dos jerarquías más importantes son: Su estructura de clases: la “jerarquía de clases” está dada por la herencia. Su estructura de objetos: la “jerarquía de objetos” está dada por la agregación. No desarrollamos aquí estos conceptos porque se verán más adelante en las secciones “Relaciones entre clases” y “Relaciones entre objetos”. Objetos y clases Objeto (Concepto) Un objeto representa un elemento, unidad o entidad individual e identificable, ya sea real o abstracta, con un papel bien definido en el dominio del problema. Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares están definidos en su clase común.  Estado: el estado de un objeto abarca todas las propiedades (normalmente estáticas) de este más los valores actuales (normalmente dinámicos) de cada una de esas propiedades  Comportamiento: El comportamiento de un objeto representa su actividad visible y comprobable exteriormente. Una operación representa un servicio que todos los objetos de una clase ofrecen a sus clientes. Se reconocen cinco tipos de operaciones sobre un objeto. Los tres tipos más comunes son los siguientes: - Modificador: una operación que altera el estado de un objeto (modifica el valor de alguno/s de sus atributos. - Selector: una operación que accede al estado de un objeto (a alguno/s de sus atributos) pero no altera ese estado. - Iterador: una operación que permite acceder a todas las partes de un objeto en algún orden perfectamente establecido. - Constructor: una operación que crea un objeto y/o inicializa su estado. - Destructor: una operación que libera el estado de un objeto y/o destruye el propio.  Identidad: En el paradigma orientado a objetos, la identidad es la propiedad que tiene un objeto que le permite distinguirse de todos los demás. La mayoría de los sistemas de bases de datos utilizan claves de identificación para distinguir objetos persistentes, mezclando el valor de un dato con la identidad. Clase (Concepto) Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Responsabilidades de una clase: Una responsabilidad es un contrato o una obligación de una clase. Al crear una clase, se está expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento. A un nivel más abstracto, estos atributos y operaciones son simplemente las características por medio de las cuales se llevan a cabo las responsabilidades de una clase. Vistas de una clase: Debemos distinguir entre la visión externa (interfaz) y la interna (implementación) de una clase. La interfaz de una clase proporciona su visión externa y por lo tanto enfatiza la abstracción a la vez que oculta su estructura y su comportamiento. Se compone principalmente de las declaraciones de todas las operaciones aplicables a instancias de esta clase (objetos), pero también puede incluir la declaración de constantes, variables y excepciones que se necesiten para completar la abstracción. Se puede especificar la interfaz de una clase con cualquiera de los tres niveles de visibilidad disponibles:  Pública: una declaración accesible a todos los clientes de esa clase.  Protegida: una declaración accesible solo a la propia clase, sus subclases y clases amigas.  Privada: una declaración accesible solo a la propia clase y sus clases amigas. Por otro lado, la implementación de una clase es su visión interna, que engloba los secretos de su comportamiento. La implementación de una clase se compone de la implementación de todas las operaciones definidas en su interfaz. La implementación de estas características dependerá de cómo lo maneje el lenguaje de programación elegido.  Atributos: un atributo es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad. Una clase puede tener cualquier número de atributos o no tener ninguno. Un atributo representa alguna propiedad del elemento que se está modelando que es compartida por todos los objetos de esa clase.  Operaciones: una operación es la implementación de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre su comportamiento.  Relaciones entre objetos: Un objeto por sí mismo no es demasiado interesante. Los objetos contribuyen al comportamiento de un sistema colaborando con otros. Hay dos tipos de relaciones que se pueden dar entre objetos: enlaces y agregación. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 - Enlaces: Un objeto colabora con otros a través de sus enlaces con estos. Esto quiere decir que denota la asociación específica por la cual un objeto (el cliente) utiliza los servicios de otro objeto (el servidor) o a través de la cual un objeto puede comunicarse con otro. - Agregación: La agregación denota una jerarquía todo/parte, en la cual un objeto del todo tiene o contiene objetos de la parte. La agregación puede o no denotar contención física. Relaciones entre clases Las clases, al igual que los objetos, no existen aisladamente. Para un dominio de problema específico, las abstracciones clave suelen estar relacionadas por vías diversas e interesantes, formando la estructura de clases. Existen tres tipos básicos de relaciones entre clases, en UML: Generalización/especialización, que denota una relación del tipo “es un”, “padre/hijo”, conocida como herencia. Asociación, que denota alguna dependencia semántica entre clases de otro modo independientes. Dependencia, es una relación de uso, se usarán cuando se quiera indicar que un elemento utiliza a otro. Uno de los usos más frecuentes de la dependencia es para modelar una visibilidad temporal desde los objetos de una clase hacia los objetos de otra. Herencia La herencia es una implantación de la generalización. La generalización establece que las propiedades de un tipo se aplican a sus subtipos. La herencia hace que la estructura de datos y operaciones de una clase (padre) estén disponibles para su reutilización por parte de sus subclases (hijos). La herencia de las operaciones de una superclase permite que las clases compartan el código (en vez de volverlo a definir). La herencia de estructura de datos permite la reutilización de la estructura. A menudo, una subclase añade atributos y operaciones a los que hereda de sus padres, pero también puede redefinir el comportamiento heredado. Una operación de un hijo con la misma signatura (nombre, parámetros y valor de retorno) que una operación del padre, redefine la operación heredada del padre; esto se conoce como polimorfismo, haciendo alusión a una operación que adopta varias formas de implementación según haya sido redefinida en las clases hijas. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Una clase puede tener uno o más padres o bien no tener ninguno. Una clase sin padres y uno o más hijos se denomina raíz o clase base. Una clase sin hijos se denomina clase hoja. Una clase con un único padre se dice que utiliza herencia simple; una clase con más de un padre se dice que utiliza herencia múltiple. Las clases hojas son de las que se espera que existan instancias, es decir objetos, por ello se las denomina también clases concretas. Las clases sin instancias se llaman clases abstractas. Una clase abstracta se redacta con la idea de que las subclases añadan elementos a su estructura y comportamiento, usualmente completando la implementación de sus métodos. De modo que nunca existirán objetos de una clase abstracta. Asociación Una asociación es una relación estructural que especifica que los objetos de una clase están conectados con los objetos de otra. Una asociación solo denota una dependencia semántica entre dos clases, pero no establece la forma exacta en que una se relaciona con la otra; solo puede denotarse esa semántica nombrando el papel que desempeña cada clase en relación con la otra. Dada una asociación entre dos clases, se puede navegar desde un objeto de una clase hasta uno de la otra. Un concepto importante a modelar respecto de una asociación es la navegación. La navegación de una asociación específica que dado un objeto perteneciente a la clase de un extremo se puede llegar fácil y directamente a los objetos de la clase del otro extremo, normalmente debido a que el objeto inicial almacena algunas referencias a los objetos en el destino. La dirección de la navegación indica qué clase es la que contiene la referencia hacia la otra (determina “quién conoce a quién”). Agregación La agregación es un tipo especial de asociación. Las relaciones de agregación entre clases tienen un paralelismo directo con las relaciones de agregación entre los objetos correspondientes a esas clases. La agregación es una relación “todo/parte” en la cual una clase representa una cosa grande (el “todo”), que consta de elementos más pequeños (las “partes”). Representa una relación del tipo “tiene un”, o sea, un objeto del todo tiene objetos de la parte. La agregación puede o no denotar contención física. Tenemos entonces dos posibilidades en cuanto a la relación de agregación. Agregación por valor un tipo de relación en la que el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es también llamada composición (el objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). En este tipo de relación el objeto “parte” no existe independientemente del objeto “todo” que lo contiene. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Agregación por referencia Es un tipo de relación, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada “agregación” (el objeto base utiliza al incluido para su funcionamiento). Algunos autores llaman también a esta forma de agregación “compartida” porque es posible que un objeto “parte o contenido” corresponda a más de un objeto “todo o contenedor”. Dependencia Este tipo de relación se define en el libro de UML como una relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro que la utiliza. Esto representa la dependencia que tiene una clase de otra. Generalmente, las dependencias se utilizan para indicar que una clase utiliza a otra como argumento en la signatura de una operación, esto significa que la clase dependiente obtiene visibilidad de la otra porque recibe un objeto como parámetro de alguna operación. Diagrama de clases Los diagramas de clases son los más utilizados en el modelado de sistemas orientados a objetos. Un diagrama de clases muestra un conjunto de clases, así como sus relaciones. Se utilizan para modelar la vista de diseño estática de un sistema. Principalmente, esto incluye modelar el vocabulario del sistema. En un diagrama de clases podemos encontrar: Clases. Relaciones: herencia, asociación (su variante: agregación), dependencia. Indicadores de multiplicidad y navegabilidad. Nombre de rol. Metodologías estructuradas vs. metodologías orientadas a objetos El tema del carácter del software es tratado por Booch entre otros autores, al explicar que la “complejidad innata” del software se deriva de lo siguiente: La complejidad del dominio del problema. La dificultad de gestionar el proceso de desarrollo. La flexibilidad que se puede alcanzar a través del software. Los problemas de caracterizar el comportamiento de sistemas discretos. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 La técnica para dominar la complejidad de un sistema es descomponerlo en partes más y más pequeñas, cada una de las cuales se puede refinar en forma independiente. Tenemos dos formas de descomponer un sistema complejo: Descomposición algorítmica: es la forma de descomposición sustentada por el análisis y diseño estructurado. En este caso se divide el sistema en elementos funcionales relacionados estructuralmente entre sí. Esta visión enfatiza el orden de los eventos. Descomposición orientada a objetos: en este caso la descomposición consiste en determinar un conjunto de agentes autónomos (objetos) que colaboran para llevar a cabo algún comportamiento de nivel superior. Esta visión resalta los agentes que causan acciones o son sujetos de estas acciones. Vistas de UML ¿Qué es UML? Como lo presentan sus creadores, Booch, Jacobson y Rumbaugh (1999), el lenguaje unificado de modelado (unified modeling language, UML) es un lenguaje estándar para escribir “planos” de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. UML, como lo establecen sus autores, es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en la web. UML es solo un lenguaje (no es una metodología) y, por lo tanto, es solo una parte de un método de desarrollo de software; fue diseñado de forma independiente del modelo de proceso de software a aplicar, aunque para emplearlo óptimamente, sus autores aconsejan utilizar un proceso que sea dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. UML es un lenguaje que permite:  Visualizar: un modelo explícito facilita la comunicación. Algunas cosas se modelan mejor textualmente, otras de forma gráfica. En todos los sistemas hay estructuras que trascienden lo que puede ser representado en un lenguaje de programación. UML es uno de estos lenguajes gráficos, pero es algo más que un conjunto de símbolos gráficos. Detrás de cada símbolo en la notación UML hay una semántica bien definida.  Especificar: aquí especificar significa construir modelos precisos, no ambiguos y completos. UML cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de software. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Construir: UML no es un lenguaje de programación visual, no obstante, sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programación. Esto significa que es posible hacer correspondencias desde un modelo UML a un lenguaje de programación como Java, C++ o Visual Basic, incluso a tablas en una base de datos relacional o al almacenamiento persistente de una base de datos orientada a objetos.  Documentar: una organización de software que trabaje bien produce toda clase de artefactos además de código ejecutable. Estos artefactos incluyen, entre otros: requisitos, arquitectura, diseño, código fuente, planificación de proyectos, pruebas, prototipos, versiones. “Artefacto” es un término general para cualquier tipo de información creada, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Principales elementos del lenguaje Los tres elementos principales de UML son: - Los bloques básicos de construcción de UML - Las reglas que dictan cómo pueden combinarse esos bloques - Algunos mecanismos comunes que se aplican a lo largo del lenguaje.  Los elementos estructurales, en su mayoría, son las partes estáticas de un modelo y representan cosas que son conceptuales o materiales.  Los elementos de comportamiento son las partes dinámicas de los modelos UML, representan comportamiento en el tiempo y el espacio.  Los elementos de agrupación son las partes organizativas de los modelos UML, representan las cajas en las que puede descomponerse un modelo. Hay un elemento de agrupación principal: los paquetes, que representan un mecanismo de propósito general para organizar elementos en grupos. Un paquete es puramente conceptual, solo existe en tiempo de desarrollo. Gráficamente se visualiza como una carpeta.  Los elementos de anotación son las partes explicativas de los modelos UML, comentarios que se pueden aplicar para hacer observaciones sobre cualquier elemento del modelo. Vistas de un sistema con UML Cada uno de los involucrados en el proyecto de desarrollo realizan diferentes actividades a lo largo del proyecto y cada uno mira al sistema de formas diferentes. La arquitectura de un sistema es el artefacto más importante que se puede emplear para manejar estos distintos puntos de vista. Tal como se plantea en el libro de UML, entendemos por arquitectura el conjunto de decisiones significativas sobre los siguientes aspectos: Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  La organización de un sistema de software.  La selección de elementos estructurales y sus interfaces.  Su comportamiento (colaboraciones entre esos elementos).  La composición de los elementos estructurales y de comportamiento en subsistemas cada vez más grandes.  El estilo arquitectónico que guía esta organización (los elementos estáticos y dinámicos y sus interfaces, colaboraciones y su composición).  La arquitectura de un sistema se puede describir a través de cinco vistas relacionadas entre sí, como se muestra en el siguiente gráfico: El proceso unificado de desarrollo Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En la ingeniería de software el objetivo es construir un producto de software o mejorar uno existente de modo que satisfaga las necesidades del usuario de forma eficiente y predecible. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. La comunidad de desarrolladores necesita una forma coordinada de trabajar, un proceso que integre las múltiples facetas del desarrollo, un método común que haga lo siguiente:  Proporcionar una guía para ordenar las actividades de un equipo. Dirigir las tareas de cada desarrollador por separado y del equipo como un todo.  Especificar los artefactos que deben desarrollarse.  Ofrecer criterios para el control y la medición de los productos y actividades del proyecto. El proceso unificado es un proceso de desarrollo de software que utiliza el lenguaje unificado de modelado (UML) para preparar todos los esquemas de un sistema de software y fue propuesto por los mismos creadores de UML: Boock, Jacobson y Rumbaugh. Los aspectos definitorios del proceso unificado se resumen en tres frases claves: está dirigido por casos de uso, centrado en la arquitectura y es un proceso iterativo e incremental.  Dirigido por caso de uso: Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales del sistema para cada usuario.  Centrado en la arquitectura: La arquitectura de un sistema de software se describe mediante distintas vistas que incluyen los aspectos estáticos y dinámicos más significativos del sistema. Las distintas vistas y el conjunto de decisiones significativas que abarca la arquitectura se trataron ya en el punto “Vistas de un Sistema con UML”. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Iterativo e incremental: El desarrollo de un producto de software puede demandar un tiempo considerable. Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo y los incrementos, al crecimiento del producto. Para lograr efectividad, iteraciones deben estar controladas, es decir, deben seleccionarse y ejecutarse en forma planificada. Lo que se implementará en una iteración se selecciona con base en dos factores: 1) La iteración trata un grupo de casos de uso que amplían la utilidad de lo desarrollado hasta el momento. 2) La iteración trata los riesgos más importantes. Fases dentro de un ciclo El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versión del producto para los clientes y consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase a su vez puede tener varias iteraciones. Cada ciclo produce una nueva versión del sistema, que es un producto preparado para su entrega. Consta de código fuente incluido en componentes que pueden compilarse y ejecutarse, manuales y otros productos asociados. Fases del proceso unificado Cada ciclo del proceso unificado se divide en cuatro fases, cada una de las cuales puede tener varias iteraciones, como ya vimos. Estas fases son las siguientes:  Fase de inicio: principalmente responde a las preguntas sobre cuáles son las principales funciones del sistema para sus usuarios más importantes, cómo podría ser la arquitectura del sistema y cuál es el plan del proyecto, además de cuánto costará desarrollar el sistema. Se realiza un modelo de casos de uso simplificado, con los más críticos; la arquitectura es un esbozo que muestra los principales subsistemas, se identifican y priorizan los riesgos, se planifica en detalle la fase de elaboración y se estima el proyecto.  Fase de elaboración: se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. La arquitectura se expresa en forma de vistas de todos los modelos del sistema (decimos vista de los modelos porque no son los modelos completos, ya que faltan incorporar casos de uso). Se crea una línea base de la arquitectura.  Fase de construcción: aquí la línea base de la arquitectura crece hasta convertirse en el sistema completo, obteniendo así un producto preparado para ser entregado a los usuarios.  Fase de transición: en esta fase el producto se convierte en una versión beta. Un número reducido de usuarios, con experiencia, prueba el sistema e Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 informa defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan las mejoras sugeridas. Esta fase incluye además las tareas de formación del cliente, ayuda en línea y asistencia. Conceptos básicos del proceso Los términos que se definen a continuación se utilizarán a lo largo de todo el desarrollo del proceso unificado. Flujo de trabajo (workflow): Es un conjunto de actividades. Un flujo de trabajo determina cómo fluye el trabajo de un trabajador a otro. Para ello se ha identificado primero qué tipos de trabajadores participan en el proceso. Luego qué artefactos se necesitan crear durante el proceso por cada tipo de trabajador. Entonces se puede describir cómo fluye el proceso a través de los distintos trabajadores y cómo ellos crean, producen y utilizan los artefactos de los demás. Artefacto: Es un término general para cualquier tipo de información creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Por ejemplo, los diagramas UML y su texto asociado, los bocetos de la interfaz del usuario, componentes de código fuente, componentes ejecutables, entre otros. Trabajador: Se denomina así a los puestos de trabajo a los cuales se pueden asignar personas dentro del proyecto. Un tipo de trabajador es un papel que una persona puede desempeñar en el desarrollo de software. Puede ser un especificador de casos de uso, un arquitecto, un ingeniero de componentes, un ingeniero de pruebas, por mencionar algunos. Cada trabajador es responsable de un conjunto completo de actividades y de producir un número determinado de artefactos. Actividades: Son trabajos significativos para una persona que actúa como trabajador. Flujos de trabajo fundamentales En cada una de las iteraciones del ciclo de vida del proceso unificado se recorre cada uno de los flujos de trabajo fundamentales que son:  Requisitos.  Análisis.  Diseño.  Implementación.  Prueba. Flujos de trabajo por iteración en cada fase Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Conceptos básicos Requerimiento: Un requerimiento es una característica del sistema o una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito de este. Propósitos de los requerimientos: Permiten que los desarrolladores expliquen cómo han entendido lo que el cliente pretende del sistema. Indican a los diseñadores qué funcionalidad y características va a tener el sistema resultante. Indican al equipo de pruebas qué demostraciones llevar a cabo para convencer al cliente de que el sistema que se le entrega es lo que había ordenado. Características de los requerimientos: Teoría y práctica, para asegurar que los desarrolladores y los clientes comprendan y utilicen correctamente los requerimientos, es importante que estos últimos sean de alta calidad. Con este Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 objetivo, debe comprobarse que los requerimientos posean las siguientes características:  Correcto: tanto los clientes como los desarrolladores deben revisar los requerimientos definidos para asegurarse de que no contengan errores.  Consistente: “un requerimiento es consistente si no es contradictorio con otro requerimiento”  Completo: un requerimiento está completo si no necesita ampliar detalles en su redacción para su comprensión. “Un conjunto de requerimientos es completo si todos los estados posibles, cambios de estado, entradas, productos y restricciones están descriptos en alguno de los requerimientos”  Realista: debe comprobarse que el sistema pueda hacer lo que el cliente está pidiendo. A veces, cuando el tiempo de desarrollo es largo, el cliente intenta anticiparse a las mejoras en tecnologías disponibles e impone requerimientos sobre el estado del arte.  Necesario: “un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir”  Verificable: “un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de distintos métodos de verificación”  Rastreable: debe ser posible rastrear cada función del sistema hasta el conjunto de requerimientos que la establece. Tipos de requerimientos Una clasificación típica de los requerimientos de un sistema de software es la siguiente: 1) Requerimientos funcionales; 2) Requerimientos no funcionales. Requerimientos funcionales: Definen las funciones que el sistema será capaz de realizar y describen cómo debe comportarse el sistema ante determinado estímulo. Describen la funcionalidad o los servicios que se espera que el sistema provea, detallando las transformaciones que este realiza sobre las entradas para producir salidas. Requerimientos no funcionales: Son restricciones de los servicios o funciones sobre el sistema, que limitan la elección de alternativas en la etapa de diseño y construcción del sistema. Los requerimientos no funcionales son características que, de una u otra forma, pueden limitar el sistema, como, por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, entre otras. Clasificación de requerimientos no funcionales Requerimientos del producto: Estos requerimientos especifican el comportamiento del producto, como, por ejemplo: Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Requerimientos de desempeño en la rapidez de ejecución. Por ejemplo: “La consulta de disponibilidad de habitaciones deberá realizarse en un tiempo menor de 20 segundos”.  Requerimientos de tamaño de memoria requerida, tamaño en disco necesario.  Requerimientos de fiabilidad que fijan la tasa de fallas para que el sistema sea considerado aceptable.  Requerimientos de portabilidad, como, por ejemplo: “Se debe poder acceder a la aplicación desde navegadores webs Internet Explorer 6.0 o superiores, y navegadores Mozilla Firefox a partir de la versión 4.0”. Requerimientos organizacionales: Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Requerimientos externos: Este apartado cubre todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Estos incluyen:  Requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con otros sistemas.  Requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley.  Requerimientos éticos para asegurar que será aceptado por el usuario y por el público en general. Categorías de los requerimientos Shari Pfleeger (2002) plantea que, en general, es útil separar los requerimientos en tres categorías: 1) requerimientos que deben ser absolutamente satisfechos; 2) requerimientos que son muy deseables, pero no indispensables; 3) requerimientos que son posibles, pero que podrían eliminarse. Los problemas con los requerimientos  Los requerimientos pueden ser tediosos (una extensa lista y/o documentos).  Los requerimientos pueden estar desorganizados. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Los requerimientos, como lo expresan los usuarios, pueden ser imprecisos, ambiguos o erróneos.  La captura de requisitos es un proceso continuo (mientras más estudiamos el sistema, más aprendemos de él y más cambia).  Los clientes no siempre conocen sus verdaderas necesidades; en muchos casos, “creen” estar seguros de ellas. Es nuestro trabajo encontrarlas. Ingeniería de requerimientos Concepto: La ingeniería de requerimientos es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema. esquema de procesos comprendidos por la ingeniería de requerimientos. Elicitación Concepto: proceso en “donde se adquiere el conocimiento del trabajo del cliente/usuario, se busca comprender sus necesidades y se detallan las restricciones medioambientales” Resultado: el conjunto de los requerimientos de todas las partes involucradas. Técnicas: entrevistas, cuestionarios, observación, análisis de documentos, torbellino de ideas, JAD, son las principales. Especificación Concepto: esta etapa es un proceso de descripción del requerimiento durante el cual se producirá el documento de especificación de requerimientos del software (ERS). Resultado: una forma de contrato entre usuarios y desarrolladores que define el comportamiento funcional deseado del software (y otras propiedades, como performance, confiabilidad, seguridad) sin mostrar cómo será alcanzada tal funcionalidad. Técnicas: la técnica más utilizada en el momento es la de casos de uso, con otras herramientas gráficas complementarias. Validación Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Concepto: es el proceso que certifica que se ataca el problema correcto. Este proceso final se nutre de los anteriores y realiza la integración y validación final de lo obtenido en cada una de las etapas anteriores Resultado: modelo de requerimientos en línea con las expectativas de los usuarios. Técnicas: revisiones de requerimientos, prototipos, generación de casos de prueba, análisis de consistencia automático. La captura de requisitos en el PUD En el proceso unificado de desarrollo (PUD), el propósito fundamental del flujo de trabajo de requisitos es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una descripción, suficientemente buena, de los requisitos del sistema como para que los desarrolladores lleguen a un acuerdo con el cliente sobre qué debe hacer y qué no debe hacer el sistema. Más allá de cuál sea el punto de partida para el descubrimiento de los requisitos (modelado del negocio, del dominio, especificación de requisitos hecha por el cliente), hay una serie de pasos que están siempre presentes:  enumerar los requisitos candidatos;  comprender el contexto del sistema;  encontrar requisitos funcionales;  encontrar requisitos no funcionales. 1) Enumerar los requisitos candidatos: Durante el desarrollo del sistema, todos los involucrados en el proyecto (clientes, usuarios, analistas, desarrolladores y otros) presentan buenas ideas que pueden convertirse en requisitos verdaderos. Conviene entonces confeccionar una “lista de características” con estas ideas a las que consideramos requisitos candidatos. Esta lista se aumenta con la aparición de nuevas “ideas” y disminuye cuando algunas características se convierten en verdaderos requisitos y pasan a modelarse como casos de uso. 2) Comprender el contexto del sistema: Para capturar los requisitos correctos que nos lleven a construir el sistema correcto, se requiere un firme conocimiento del contexto en el que se emplaza el sistema. Hay, por lo menos, dos formas de expresar el contexto de un sistema, de manera tal que sea de utilidad para los desarrolladores del sistema: el modelado del dominio y el modelado del negocio.  Un modelo de dominio (también conocido como “modelo de objetos del dominio del problema”) describe los conceptos importantes del contexto como objetos del dominio y enlaza estos objetos entre sí.  El modelado del negocio se realiza para describir los procesos del negocio, con una visión orientada a objetos, con el objetivo de comprenderlos. El modelado de negocio es parte de la ingeniería de negocios, que es una Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 técnica que tiene por objetivo mejorar los procesos de negocio de la organización. Modelo de negocio Un modelo de casos de uso del negocio describe procesos de un negocio y sus interacciones con el exterior. Su propósito principal es describir cómo es usado el negocio por sus usuarios, en este caso, sus clientes y socios. El modelado de negocio está soportado por dos tipos de modelos de UML (definidos en la extensión de UML relativa al negocio):  Modelo de casos de uso de negocio: presenta una vista externa del negocio, la cual define lo que es esencial que el negocio realice para entregar el resultado deseado a sus clientes (actores del negocio).  Modelo de objetos del negocio: es una vista interna del negocio que describe cómo cada caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores de negocio que utilizan un conjunto de entidades de negocio Notación y elementos básicos del modelado de negocio Los elementos básicos que están presentes en el modelado de negocio son:  Actor de negocio: Representa un rol en relación al negocio, desempeñado por algo o alguien en el entorno del negocio. Un actor, normalmente, corresponde a un ser humano, pero hay circunstancias en que un sistema de información juega el rol de un actor.  Caso de uso de negocio: Es una secuencia de acciones que realiza un negocio para producir un resultado observable de valor para un actor individual del negocio. Los casos de uso de negocio capturan y modelan los procesos de negocio.  Trabajador de negocio: “Representa un rol o conjunto de roles en el negocio. Un trabajador de negocio interactúa con otros trabajadores y manipula entidades de negocio mientras participa en las realizaciones de los casos de uso de negocio”  Entidad de negocio: Representa una abstracción de algo que los trabajadores de negocio toman, inspeccionan, producen o utilizan cuando ejecutan un caso de uso de negocio. Puede representar: - un documento; - una parte esencial de un producto; - algo menos tangible, como el conocimiento o información acerca de un cliente, proveedor, artículos y otras abstracciones clave. Derivación del sistema de información a partir del sistema de negocio Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Un buen entendimiento de los procesos de negocio es importante para poder construir el sistema de soporte correcto. Es en la vista interna del negocio, capturada por el modelo de objetos, que se puede ver la conexión más estrecha con respecto a cómo deberían verse los modelos del sistema de información. Modelo de negocio y modelo de casos de uso del sistema de información Las reglas que enunciamos a continuación nos servirán para poder derivar los actores y casos de uso del sistema de información a partir del modelo de negocio realizado. 1) Para cada trabajador del negocio se deberá determinar si va a utilizar el sistema de información. Si la respuesta es sí, entonces:  Se identificará un actor del sistema de información con el mismo nombre del actor de negocio.  Analizar sus responsabilidades: determinar cuáles implican el uso del sistema de información e identificar un caso de uso del sistema por cada una de ellas. 2) Si en el modelo de negocio tenemos trabajadores de negocio automatizados, entonces:  El actor de negocio pasará a ser actor del sistema de información.  Las responsabilidades del trabajador de negocio automatizado pasarán a ser casos de uso del sistema de información. Modelo de negocio y clases del modelo de dominio y modelo de análisis Las reglas que enunciamos a continuación nos servirán para poder encontrar clases del modelo de dominio y del modelo de análisis del sistema de información a partir de las entidades de negocio. 1) Para cada entidad de negocio, determinar si va a ser soportada por el sistema de información. En este caso:  Se identificará una clase del modelo de objetos del dominio de problema con el mismo nombre que la entidad de negocio.  Se identificará una clase de entidad del modelo de análisis. 2) Las relaciones entre entidad de negocio que serán soportadas por el sistema de información pasarán a ser relaciones entre clases del dominio de problema y del modelo de análisis. Modelo de dominio Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 El modelo de dominio (también llamado “modelo de objetos del dominio de problema” y frecuentemente encontrado por las siglas MODP) captura los tipos de objetos más importantes en el contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los “eventos” que suceden en el entorno en el que se desenvuelve el sistema. El principal diagrama UML para describir el dominio es el diagrama de clases. Utilidad del modelo de dominio El modelado del dominio debe contribuir a la comprensión del problema que se supone que el sistema resuelve. Para desarrollar este modelo, debe conformarse un equipo en el que estén presentes tanto los expertos del dominio (usuarios) como gente con experiencia en modelado, coordinado por los analistas del dominio. El modelo de dominio ayuda a los usuarios, clientes, desarrolladores y otros participantes del proyecto a utilizar un vocabulario común. La terminología común es necesaria para compartir el conocimiento con los otros. Las clases del dominio que aquí se encuentren se utilizarán al describir los casos de uso y diseñar el prototipo de interfaz de usuario (dentro del flujo de trabajo de requisitos) y para sugerir clases internas al sistema en desarrollo durante el análisis. Diagrama de clases del dominio de problema Como ya vimos en la Unidad 1, un diagrama de clases (en UML) es un diagrama que muestra un conjunto de clases, interfaces, sus colaboraciones y relaciones. Se utiliza para modelar la vista de diseño estática de un sistema. Con UML, los diagramas de clases se emplean para visualizar el aspecto estático de los bloques de construcción básicos del sistema y sus relaciones, y para especificar los detalles para construirlos. Pautas para su construcción Se enumeran, a continuación, algunas pautas, en forma de consejos, a seguir cuando se está confeccionando un diagrama de clases:  Debe comunicar un aspecto de la vista de diseño estática de un sistema.  Debe contener solo los elementos esenciales para comprender ese aspecto.  Debe proporcionar detalles en forma consistente con el nivel de abstracción, mostrando solo aquellos adornos que sean esenciales en dicho nivel.  Se deben distribuir sus elementos de modo de minimizar los cruces de líneas.  Organizar los elementos de modo que los que sean semánticamente cercanos lo estén también físicamente.  Usar notas y colores sobre aspectos importantes que se quieran destacar. Captura de requerimientos Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Encontrar requisitos funcionales: La técnica específica para identificar los requisitos funcionales del sistema se basa en los casos de uso. Los casos de uso capturan tanto los requisitos funcionales como los no funcionales, específicos de cada caso de uso. Cada usuario quiere que el sistema haga algo para él, es decir que tendrá distintos modos de utilizar el sistema. Cada una de estas formas de utilizar el sistema es un caso de uso. Entonces, si se pueden describir todos los casos de uso que necesita el usuario, se podrá saber lo que debe hacer el sistema. Encontrar requisitos no funcionales: Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementación, dependencias de la plataforma, consideraciones de rendimiento, seguridad, flexibilidad, facilidad de mantenimiento, entre otras. Algunos requisitos no funcionales serán aplicables a todos los casos de uso en general y algunos pueden ser específicos para un caso de uso o solo un número determinado de ellos. El modelo de caso de uso Los casos de uso proporcionan un medio intuitivo y sistemático para capturar los requisitos funcionales poniendo énfasis en el valor agregado para cada usuario individual o para cada sistema externo. La utilización de los casos de uso hace que los analistas deban pensar en términos de quiénes son los usuarios y qué necesidad u objetivos de la empresa pueden cumplir. El principal esfuerzo de la etapa de requisitos es desarrollar un modelo del sistema que se va a construir, y la utilización de los casos de uso es una forma adecuada para ello, debido a que los requisitos funcionales se estructuran naturalmente mediante los casos de uso; los requisitos no funcionales suelen ser específicos de un caso de uso y pueden tratarse en ese contexto. Flujo de trabajo del modelado de casos de uso Dentro del PUD (proceso unificado de desarrollo), el primer flujo de trabajo es el de requisitos. Al igual que se irá haciendo con los restantes en las siguientes unidades, mencionaremos los artefactos que se crean en este flujo de trabajo, los trabajadores participantes y las actividades a realizar:  Artefactos: Los artefactos fundamentales que se utilizan en la captura de requisitos son: - modelo de casos de uso, que incluye los casos de uso y los actores; - descripción de la arquitectura; - glosario; - prototipo de la interfaz del usuario.  Trabajadores: Los trabajadores responsables por los artefactos que se producen en el modelado de casos de uso son: - analista de sistemas; Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 - especificador de casos de uso; - diseñador de interfaz de usuario; - arquitecto.  Actividades: Las actividades a realizar por los trabajadores para producir los distintos artefactos son: - encontrar actores y casos de uso; - priorizar casos de uso; - detallar los casos de uso; - prototipar la interfaz del usuario; - estructurar el modelo de casos de uso. Artefactos del flujo de trabajo de requisitos Modelo de casos de uso: El modelo de casos de uso permite que los desarrolladores y los clientes lleguen a un acuerdo sobre los requisitos, es decir, sobre lo que debe cumplir el sistema, y constituye la entrada principal para el análisis, el diseño y las pruebas. El modelo de casos de uso es un modelo que contiene actores, casos de uso y las relaciones entre estos. Si el modelo de casos de uso es grande, es decir, si el número de ellos es elevado, es útil introducir paquetes en el modelo para tratar su tamaño. Actor: Un actor es el rol que juega un usuario en un caso de uso. Normalmente, un actor representa un rol, que es representado por una persona, un dispositivo de hardware o, incluso, otro sistema al interactuar con nuestro sistema. Podemos distinguir la siguiente clasificación de actores según el objetivo a cumplir en relación a los casos de uso:  Actor primario: tiene un objetivo claro que debe ser tenido en cuenta y concretado con la ayuda del sistema de información.  Actor secundario: es de quien el sistema necesita ayuda para cumplir con el objetivo del actor primario. Glosario: Se puede utilizar un glosario para definir términos comunes importantes que los analistas y otros desarrolladores utilizan al describir el sistema. Un glosario es muy útil para lograr consenso en la definición de distintos conceptos y para reducir el riesgo de confusiones. Descripción de la arquitectura: La descripción de la arquitectura contiene una vista del modelo de casos de uso, que representa los casos de uso significativos. La vista de la arquitectura del modelo de casos de uso debería incluir los casos de uso que describan alguna funcionalidad importante y crítica, Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 o que impliquen algún requisito importante que deba desarrollarse pronto, dentro del ciclo de vida del software. Caso de uso: Un caso uso representa cada forma en que los actores usan el sistema. Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Un caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores. Podemos establecer la categoría de los casos de uso como:  Esenciales: describen la funcionalidad principal o esencial que tiene que cumplir el sistema. Comprenden los principales procesos que debe ejecutar el sistema de información.  De soporte: comprenden la funcionalidad que surge a partir de analizar aquello que se necesita para que puedan funcionar los casos de uso esenciales. También aquí se consideran los casos de uso del usuario, que comprenden la funcionalidad requerida para administrar los datos de los usuarios del sistema y los permisos asignados a estos. Otra forma de clasificar los casos de uso es la siguiente:  Concreto: se le llama así al caso de uso que es iniciado por un actor y que constituye un flujo de eventos completo.  Abstracto: es el caso de uso que no es iniciado nunca por un actor, sino que únicamente es instanciado (iniciado) por otro caso de uso. Surge a partir de relaciones de extensión, inclusión o generalización. La descripción de un caso de uso puede incluir:  Diagramas de estados: especifican el ciclo de vida de las instancias de casos de uso.  Diagramas de actividad: describe el ciclo de vida con más detalle, indicando la secuencia temporal de acciones que tienen lugar dentro de cada transición.  Diagramas de colaboraciones y de secuencia: describen las interacciones entre una instancia típica de un actor y una instancia típica de un caso de uso. Prototipo de interfaz del usuario: “Los prototipos de interfaz del usuario nos ayudan a comprender y especificar las interacciones entre actores humanos y el sistema durante la captura de requisitos” No solo nos ayuda a desarrollar una interfaz gráfica mejor, sino a comprender mejor los casos de uso. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Diagrama de casos de uso: Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema o un subsistema. Estos diagramas facilitan que los sistemas y subsistemas sean abordables y comprensibles al presentar una vista externa de cómo pueden utilizarse estos Simbología del diagrama de casos de uso: En la siguiente figura se muestran los distintos elementos que pueden estar presentes en un diagrama de casos de uso. Nombre de caso de uso: Cada caso de uso debe tener un nombre que lo distinga de los demás. Puede ser un nombre simple (una simple cadena de texto) o un nombre de camino (path) en el caso de que esté precedido por el nombre del paquete en que está incluido el caso de uso. Nombre de actor: El nombre del actor debe reflejar el rol que cumple un usuario al interactuar con el caso de uso al que está conectado y no debe reflejar a un usuario en particular. Relación de generalización entre actores: Pueden definirse categorías generales de actores y especializarlos a través de relaciones de generalización. Los actores especializados (hijos) heredan el comportamiento del actor padre. Relaciones entre casos de uso: Los casos de uso pueden organizarse especificando relaciones de generalización, inclusión y extensión entre ellos. “Estas relaciones se utilizan para:  factorizar el comportamiento común (extrayendo ese comportamiento de los casos de uso en los que se incluye)  factorizar variantes (poniendo ese comportamiento en otros casos de uso que lo extienden)”  simplificar un caso de uso extrayendo una parte compleja y ubicándola en otro caso de uso. Relación de generalización entre casos de uso: La generalización entre casos de uso es como la generalización entre clases. En este contexto, significa que el caso de uso hijo hereda el comportamiento del caso de uso padre. El hijo puede modificar y/o agregar comportamiento al heredado. La generalización se emplea para simplificar la forma de trabajo y la comprensión del modelo de casos de uso y para reutilizar casos de uso “semifabricados”. Un caso de uso “semifabricado” existe solamente para que otros lo reutilicen. Relación de inclusión entre casos de uso: Una relación de inclusión entre casos de uso significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. El caso de uso incluido nunca es instanciado por un actor, sino que es Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 instanciado por el/los caso/s de uso que lo incluyen. Por ello, un caso de uso de inclusión es siempre un caso de uso abstracto. Una característica de la relación de inclusión es que el caso de uso base siempre deberá invocar la ejecución del caso de uso incluido para completar su objetivo; es decir, el caso de uso base no está completo si no se ejecuta la funcionalidad del caso de uso de inclusión. La inclusión se representa como una dependencia estereotipada con la palabra include o en forma abreviada inc, dirigida desde el caso de uso base hacia el caso de uso incluido. Relación de extensión entre casos de uso: Una relación de extensión entre casos de uso significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso. El caso de uso base puede ejecutarse aisladamente, pero, bajo ciertas condiciones, su funcionalidad será extendida por la del caso de uso de extensión. La extensión se puede ver como que el caso de uso de extensión incorpora su comportamiento en el caso de uso base. Una relación de extensión se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma, se separa el comportamiento opcional del obligatorio. Actividades del flujo de trabajo de requisitos: Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos. Describimos un flujo de trabajo como una secuencia de actividades que están ordenadas, de modo que una actividad produce una salida que sirve de entrada a la siguiente. A pesar de ello, en el mundo real, no siempre trabajamos estrictamente en secuencia. Se puede trabajar por múltiples vías que producen un resultado final equivalente. Una actividad puede ser retomada muchas veces (recordemos que estamos en un proceso de desarrollo iterativo) y cada una de estas puede acarrear la ejecución de un solo fragmento de la actividad Encontrar actores y casos de uso La identificación de actores y casos de uso es la actividad más decisiva para obtener adecuadamente los requisitos y es responsabilidad del analista de sistemas. Para realizar esta actividad, si se dispone de un modelo de negocio, Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 se puede obtener un borrador del modelo de casos de uso en forma bastante directa. Otras veces se puede partir del modelo de dominio o, simplemente, de una especificación de las características que se requieren del sistema. Esta actividad puede descomponerse en cuatro pasos: 1) Encontrar los actores: Hay dos criterios útiles a la hora de elegir los candidatos a actores: - Primero, debe ser posible identificar, al menos, un usuario que pueda representar al actor candidato. - Segundo, debe existir una coincidencia mínima entre los roles que desempeñan las instancias de los diferentes actores. No debemos tener dos o más actores que cumplan los mismos roles: o son el mismo actor o se realiza una generalización abstrayendo el comportamiento común. Para encontrar actores, resulta útil preguntarnos, por ejemplo, quién va a utilizar cierta información, quién va a usar una determinada funcionalidad, quién actualizará algún dato en el sistema, con qué otros sistemas van a interactuar el sistema que estamos modelando. El analista de sistemas da nombre a los actores y describe brevemente los papeles de cada actor. La descripción de cada actor debe esbozar sus necesidades y responsabilidades. 2) Encontrar los casos de uso: El analista de sistemas identificará los casos de uso a través de los talleres con los clientes y los usuarios. El analista de sistemas va repasando los actores de a uno y piensa en qué forma pueden utilizar el sistema o qué necesitan del sistema, proponiendo así casos de uso, que se consideran, en primera instancia, “candidatos”. Algunos de los candidatos no llegarán a ser casos de uso por sí mismos, sino que serán partes de otro. habrá casos de uso a los que llamamos “esenciales” porque involucran actividades que constituyen el núcleo del negocio y suelen ser los primeros en ser descubiertos; y otros casos de uso a los que llamamos “secundarios” o “de soporte”, que permiten realizar tareas tales como actualizar todas las clases que aparecieron en el dominio del problema y las que irán apareciendo; más adelante (en las últimas iteraciones), pueden aparecer casos de uso para administrar usuarios, sesión de usuario, entre otros. 3) Describir brevemente cada caso de uso: A medida que se van descubriendo los casos de uso se suele ir registrando algunas palabras explicándolos. Luego se procede a describir más formalmente el caso de uso, en primera instancia con unas pocas frases, y más adelante se hará una descripción detallada. 4) Describir el modelo de casos de uso completo: Esta tarea consiste en elaborar diagramas y descripciones para explicar el modelo de casos de uso en totalidad Priorizar casos de uso Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 El propósito de esta actividad es determinar cuáles casos de uso son necesarios para el desarrollo en las primeras iteraciones y cuáles pueden dejarse para más adelante. Los resultados de esta actividad conforman la vista de la arquitectura del modelo de casos de uso, que es revisada por el jefe de proyecto y se utiliza como base para la planificación de una iteración. Detallar casos de uso El objetivo de esta actividad es detallar el flujo de sucesos en detalle, incluyendo cómo comienza, termina e interactúan con los actores Con el modelo de casos de uso como punto de partida, el especificador de un caso de uso individual puede comenzar a describir cada caso de uso en detalle, especificando la secuencia precisa de acciones. Hay varias formas y herramientas con las que se puede realizar la descripción de un caso de uso. Independientemente de la forma elegida para describir el caso de uso, debe verificarse que la descripción siempre incluya lo siguiente:  el estado inicial, como precondición  cómo y cuándo comienza el caso de uso (es decir, la primera acción a ejecutar)  el orden requerido en el que las acciones se deben ejecutar (determinado en forma de secuencia numerada)  cómo y cuándo terminan los casos de uso  los posibles estados finales, como postcondiciones  los caminos de ejecución que no están permitidos  las descripciones de caminos alternativos que están incluidos junto con la descripción del camino básico  las descripciones de caminos alternativos que han sido extraídos de la descripción del camino básico  la interacción del sistema con los actores y qué cambios producen  la utilización de objetos, valores y recursos del sistema  la descripción explícita de lo que hace el sistema, separando las responsabilidades del sistema de las acciones de los actores. Otras herramientas que pueden ayudar a mejorar la comprensión de los casos de uso son:  Diagramas de estado: para describir los estados de los casos de uso y las transiciones entre esos estados. Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236  Diagramas de actividad: para describir las transiciones entre estados con más detalle como secuencias de acciones.  Diagramas de interacción: para describir cómo interactúa una instancia de caso de uso con la instancia de un actor. En este caso, el diagrama de interacción muestra solo el caso de uso y el actor o actores participantes. Prototipar la interfaz del usuario Hasta aquí, hemos desarrollado el modelo de casos de uso que especifica qué usuarios hay y para qué necesitan usar el sistema. Ahora, hay que diseñar la interfaz de usuario que le permita llevar a cabo los casos de uso de manera eficiente. Se comienza con los casos de uso, intentando determinar qué se necesita de las interfaces de usuario para habilitar los casos de uso. Esto es hacer un diseño lógico de la interfaz. Luego se realiza un diseño físico y se desarrollan prototipos. Estructurar el modelo de casos de uso El modelo de casos de uso se estructura para:  Extraer descripciones de funcionalidades generales y compartidas que pueden ser utilizadas por descripciones más específicas (casos de uso de inclusión).  Extraer descripciones de funcionalidad adicionales u opcionales que pueden extender descripciones más específicas (casos de uso de extensión).  En esta actividad, el analista de sistemas puede reestructurar el conjunto completo de casos de uso para hacer que el modelo sea más fácil de entender y de trabajar con él.  El analista debe buscar comportamientos compartidos y extensiones. Esto se refleja en la determinación de relaciones de generalización, inclusión y extensión entre casos de uso. Cuando tratamos el tema de “Relaciones entre casos de uso”, se presentaron varios ejemplos de cada una. En la siguiente figura mostramos un ejemplo de un caso de uso cuya funcionalidad fue extraída de los casos de uso base y es llamando “por extensión” o “por inclusión”, según sea el caso de uso base llamador. Prototipos de interfaz Concepto y propósito de los prototipos Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 Un prototipo es una versión inicial de un sistema de software que se utiliza para demostrar los conceptos, probar opciones de diseño y, en general, conocer más acerca del problema y opciones de solución. Tal como lo plantea Ian Sommerville (2002), un prototipo sirve de apoyo a dos actividades dentro del proceso de ingeniería de requerimientos: 1) Obtención de requerimientos: los prototipos permiten a los usuarios experimentar para ver cómo el sistema ayudará a su trabajo. Les permite adquirir nuevas ideas para los requerimientos y proponer nuevos requerimientos 2) Validación de requerimientos: un prototipo puede revelar errores y omisiones en los requerimientos propuestos y especificados. Con el uso de prototipos, los usuarios, a menudo, encuentran que su visión inicial fue incorrecta o incompleta, entonces, la especificación del sistema puede modificarse para reflejar el cambio en la comprensión de los requerimientos. Además de permitir a los usuarios mejorar la especificación de requerimientos, el desarrollo de un prototipo del sistema tiene otras ventajas:  Al demostrar las funciones del sistema se identifican las discrepancias entre los desarrolladores y los usuarios.  Durante el desarrollo del prototipo, el personal de desarrollo puede darse cuenta de que los requerimientos son inconsistentes y/o están incompletos.  Aunque limitado, se dispone rápidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicación a administrar.  El prototipo se utiliza como base para escribir la especificación para la producción de un sistema de calidad. Por lo general, el desarrollo del prototipo conduce a mejorar la especificación del sistema, pero, una vez que el prototipo está disponible, también se utiliza para otros propósitos:  Capacitar al usuario: el prototipo se puede utilizar para capacitar a los usuarios antes de que el sistema final esté terminado.  Probar el sistema: los mismos casos de prueba se introducen al prototipo y al sistema en prueba. Si ambos sistemas dan los mismos resultados, el caso de prueba no detecta una falla Construcción de prototipos de interfaz de usuario En la actualidad, las interfaces gráficas de usuario (GUI, por sus siglas en inglés) se han convertido en las normas para los sistemas interactivos. El Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 esfuerzo comprendido en la especificación, el diseño y la implementación de una interfaz de usuario representa una parte significativa de los costos de desarrollo de un sistema. Desde el punto de vista de la ingeniería de software, la construcción de prototipos es una parte esencial del proceso de diseño de la interfaz de usuario. La construcción de prototipos evolutivos con la participación del usuario final es la única manera sensible para desarrollar interfaces gráficas de usuario para los sistemas de software. Ventajas del uso de interfaz gráfica de usuario (GUI) Aunque las interfaces basadas en texto aún se utilizan, especialmente en los sistemas heredados, los usuarios actuales de sistemas informáticos esperan que las aplicaciones tengan algún tipo de interfaz gráfica de usuario. Este tipo de interfaces se caracterizan por el uso de los siguientes elementos:  Ventanas: Las ventanas múltiples permiten que se despliegue, simultáneamente, información diversa en la pantalla del usuario.  Íconos: Los íconos representan diferentes tipos de información. En algunos sistemas, los íconos representan archivos, y en otros, representan procesos.  Menús: Los comandos se seleccionan de un menú en lugar de teclearse en un lenguaje de órdenes.  Apuntador: Para seleccionar las opciones de un menú, indicar elementos de interés en una ventana o dirigirse a alguna parte de la ventana, se utiliza un dispositivo apuntador, como el mouse (ratón). Gráficos Los elementos gráficos se pueden mezclar con texto en el mismo despliegue. Entre las ventajas del uso de interfaces gráficas de usuario podemos mencionar:  Son fáciles de aprender y utilizar.  Para interactuar con el sistema los usuarios, cuentan con pantallas múltiples (ventanas), por lo tanto, es posible ir de una tarea a otra sin perder de vista la información generada durante la primera tarea.  Es posible interactuar rápidamente y tener acceso inmediato a cualquier punto de la pantalla. Elementos de una interfaz gráfica de usuario Los diseñadores de interfaces de usuario deben tener en cuenta las capacidades físicas y mentales de la gente que utilizará el software. Las Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 personas olvidan fácilmente y cometen varios errores cuando tienen que manejar demasiada información o están bajo presión, pero poseen un amplio rango de capacidades físicas. Las habilidades humanas son la base para los principios de diseño que se enuncian a continuación y que consisten en una serie de principios generales que se pueden aplicar a todos los diseños de interfaces de usuario: Familiaridad del usuario: La interfaz debe utilizar términos y conceptos que se toman de la experiencia de las personas que más utilizan el sistema. Por ejemplo, si en la organización utilizan el término “afiliado” para referirse a los clientes, hay que mantener esta denominación en las interfaces. Consistencia: La interfaz debe ser consistente en el sentido de que las operaciones comparables se activan de la misma forma. Por ejemplo, todas las ventanas de registro de datos son similares (ventana para registrar nuevo disco, nuevo sello, nuevo género). Mínima sorpresa: El comportamiento del sistema no debe provocar sorpresa a los usuarios. Utilizar recursos como, por ejemplo, mostrar una barra de avance para indicar al usuario que el sistema está procesando algo para que no piense que se ha clavado el sistema. Recuperabilidad: La interfaz debe incluir mecanismos para permitir a los usuarios recuperarse de los errores, como confirmación de acciones destructivas (siempre solicitar confirmación ante una acción “eliminar”), proveer un recurso para deshacer (incluir la opción “cancelar” en todas las ventanas), etc. Guía al usuario: Cuando los errores ocurren, la interfaz debe proveer retroalimentación significativa y características de ayuda sensible al contexto. Mostrar mensaje de error significativo para el usuario que le dé indicación sobre cuál es el error y cómo subsanarlo o cómo continuar correctamente con la aplicación. Diversidad de usuarios: La interfaz debe proveer características de interacción apropiada para los diferentes tipos de usuarios del sistema. Hay usuarios que tienen buena memoria y son ágiles con el teclado numérico, de modo que prefieren ingresar por este medio los datos en vez de tener que trasladar la mano al mouse para hacer la selección desde un combo o lista, lo cual se traduce en más tiempo empleado en la operación si hay que hacer muchos cambios de movimiento de la mano (del teclado al mouse y de este al teclado sucesivamente). De modo que la interfaz debería permitir ambos tipos de acciones: ingreso de datos o selección de estos. Interacción del usuario: Los diseñadores de interfaces de usuario deben decidir cómo se va a introducir la información del usuario a la computadora y cómo se presentará al usuario la información del sistema. La interacción del Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 usuario implica emitir comandos y datos asociados al sistema de software. En las primeras computadoras, la única forma de hacer esto era a través de una interna línea de comandos en la que se utilizaba un lenguaje de propósito específico. Sin embargo, este enfoque solo lo utilizaban los expertos, por lo que fueron surgiendo otras posibilidades que les facilitaban las tareas. las diversas formas de interacción del usuario con la computadora (es decir, con la interfaz de usuario) en estos cinco estilos primarios:  Manipulación directa: cómo “arrastrar” para mover o eliminar un archivo. Es una interacción rápida e intuitiva, además de fácil de aprender, pero puede ser difícil de implementar si no hay una representación visual clara para las tareas y objetos.  Selección de menús: seleccionar el archivo y luego seleccionar la acción “mover” o “eliminar” desde un menú. Evita errores del usuario y requiere teclear poco, pero puede parecer lenta a usuarios experimentados.  Llenado de formularios: el usuario llena campos de un formulario (ventana de carga de datos), puede tener menús asociados, botones, íconos, entre otros elementos gráficos. Implica una forma de introducción de datos sencilla y fácil de aprender, pero ocupa mucho espacio en pantalla.  Lenguaje de comandos: el usuario indica un comando especial y parámetros necesarios (DEL nota.txt). Es una forma de interacción poderosa y flexible, pero puede resultar difícil de aprender.  Lenguaje natural: emitir un comando en lenguaje natural (“borrar el archivo nota.txt”). Resulta accesible a usuarios casuales, pero se requiere teclear más, además de que se debería disponer de sistemas de comprensión de lenguaje natural, los cuales no siempre resultan fiables. Respecto de la forma de presentación de la información a los usuarios en la interfaz, podemos mencionar brevemente:  Presentación como texto: utilizada generalmente cuando se requiere información numérica precisa y la información cambia de forma relativamente lenta.  Presentación como gráfico: utilizada generalmente cuando los datos cambian rápidamente o si las relaciones entre los datos son significantes (uso de gráficos de barra, curva, torta, por ejemplo). Uso del color en el diseño de la interfaz de usuario En general, los sistemas interactivos permiten despliegues a color y los diseñadores de interfaces de usuario utilizan el color de diferentes formas. El Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 uso del color en las interfaces puede resultar de utilidad, ayudando a los usuarios a comprender y manejar la complejidad. Sin embargo, si el color es utilizado de manera errónea, puede conducir a interfaces poco atractivas, fatigosas para la vista y propensas a errores. Soporte al usuario Las interfaces de usuario siempre deben proveer alguna forma de sistema de ayuda en línea, como mencionamos al enunciar los principios de diseño de interfaces de usuario. Los sistemas de ayuda en línea son una faceta de una parte general del diseño de interfaces de usuario. El soporte al usuario cubre tres áreas: - los mensajes producidos por el sistema en respuesta a las acciones del usuario; - ayuda en línea; - la documentación suministrada con el sistema. Mensajes de error Los mensajes de error del sistema son la primera marca que reciben los usuarios de un sistema de software. Al hacer su trabajo, los usuarios inexpertos pueden cometer errores y, de manera inmediata, debería poder comprender el mensaje de error resultante. Los mensajes de error deben tomar en cuenta el conocimiento y la experiencia de los usuarios. Podemos tener:  Mensaje orientado al sistema: como, por ejemplo, “Error # 32 en línea 410” Es un mensaje negativo, no se ajusta a las habilidades y nivel de experiencia del usuario; tampoco sugiere cómo rectificar la situación.  Mensaje orientado al usuario: como, por ejemplo, “Cliente no registrado – utilice la opción: Registrar Nuevo Cliente”. Este tipo de mensajes son los que se deben utilizar. Deben ser amables, concisos, consistentes y constructivos. Diseño del sistema de ayuda Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 En el caso de que el mensaje de error no sea suficiente para el usuario, este se dirigirá inmediatamente al sistema de ayuda en busca de más información para solucionar el inconveniente o duda que se le presenta. Hay algunos aspectos interesantes a considerar al momento de diseñar la ayuda en línea:  Niveles de entrada: los sistemas de ayuda proveen varios puntos diferentes de entrada a los usuarios.  Navegación de la ayuda: los usuarios pueden ingresar al sistema de ayuda en el punto de la jerarquía correspondiente al mensaje y luego navegar por la estructura de red del sistema de ayuda. Puede pasar que el usuario comience a navegar por la ayuda y al poco tiempo se encuentre “perdido”; desplegar la información de ayuda en múltiples ventanas puede aliviar esta situación.  Contenido: el texto de un sistema de ayuda se prepara con la ayuda de especialistas en la aplicación. La ayuda en línea no debe ser simplemente una reproducción del manual del usuario, ya que las personas leen en papel y en pantalla de forma diferente. El texto, su exposición y estilo tienen que diseñarse cuidadosamente para permitir su despliegue legible en una ventana, generalmente, pequeña.  Herramientas: respecto de las herramientas que se pueden utilizar para confeccionar un sistema de ayuda en línea tenemos, Documentación del usuario La documentación del usuario no es estrictamente parte del diseño de la interfaz de usuario, pero es recomendable diseñar el apoyo de ayuda en línea junto con la documentación en papel. Los manuales del sistema proveen información más detallada de la ayuda en línea y se diseña de tal forma que puedan ser utilizados por diferentes tipos de usuarios del sistema. Se nos recomienda al menos cinco documentos para entregar junto con el producto de software:  Descripción funcional: describe brevemente los servicios que provee el sistema.  Documento de instalación: provee los detalles de cómo instalar el sistema, los discos que se entregan con el sistema, los archivos de estos discos y la configuración de hardware mínima requerida para que funcione correctamente el sistema.  Manual introductorio: presenta una introducción un tanto informal del sistema, describiendo su utilización normal. Describe cómo iniciar, cerrar sesión de usuarios y cómo utilizar los recursos comunes del sistema.  Manual de referencia: describe todos los recursos del sistema; provee una lista de los mensajes de error, posibles causas y cómo recuperarse de ellos.  Guía del administrador: describe los mensajes que se generan por la interacción del sistema con otros sistemas y cómo reaccionar en estas situaciones; también cuando el problema puede estar relacionado con algún Descargado por Nicolas Obredor ([email protected])  lOMoARcPSD|13420236 elemento de hardware, indicando cómo reconocer y reparar el problema, de ser posible para el usuario Evaluación de la interfaz La evaluación de la interfaz es el proceso de valorar la forma en que es utilizada una interfaz y verificar que cumple sus requerimientos. Idealmente, una evaluación se compara con la especificación de la usabilidad que se basa en los siguientes atributos:  Aprendizaje: se evalúa cuánto tiempo tarda un usuario nuevo en ser productivo con el sistema.  Velocidad de operación: se considera qué tan bien responde el sistema a las operaciones de trabajo del usuario.  Robustez: se evalúa qué tan tolerante es el sistema a los errores del usuario.  Recuperación: se observa qué tan bien se recupera el usuario de los errores del usuario.  Adaptación: se evalúa qué tan atado está el sistema a