¡Descarga UML - LARMAN 2da Edicion y más Apuntes en PDF de Análisis de Sistemas de Ingeniería solo en Docsity!
Metodología Larman.
¿Qué es el análisis y el diseño?
El análisis pone énfasis en una investigación del problema y los requisitos en vez de ponerlo en una solución. Se puede clasificar como análisis de requisitos (un estudio de los requisitos) o análisis de objetos (un estudio del objeto del dominio).
El diseño pone énfasis en una solución conceptual que satisface los requisitos, en vez de ponerlo en la implementación.
¿Qué son el análisis y el diseño orientado a objetos?
Durante el análisis orientado a objetos, se presta especial atención a encontrar y describir los los objetos – o conceptos – en el dominio del problema.
Durante el diseño orientado a objetos, se presta especial atención a la definición de los objetos de software y en como colaboran para satisfacer los requisitos.
Desarrollo iterativo y proceso unificado.
El desarrollo iterativo es un enfoque para el desarrollo de software y juega un papel central en el modo en que se presenta el A/DOO.
Un proceso de desarrollo de software describe un enfoque para la construcción, desarrollo y, posiblemente mantenimiento del software.
El proceso unificado es un ejemplo de proceso iterativo para proyectos que utilizan el A/DOO, y se ha convertido en un proceso de desarrollo de software de gran éxito para construcción de sistemas orientados a objeto.
El UP combina las practicas comúnmente aceptadas, tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, es una descripción consistente y bien documentada; proporciona una estructura organizada de ejemplo para discutir sobre hacer – y como aprender
o La idea más importante del UP: el desarrollo iterativo.
El UP fomenta el desarrollo iterativo, en este enfoque, el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija llamado iteraciones; el resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. Cada iteración incluye sus propias actividades de análisis de requisitos, diseño, implementación y pruebas.
El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema mediante múltiple iteraciones, con retroalimentación cíclica y adaptación como elementos principales que dirigen para converger hacia un sistema adecuado. El sistema
crece incrementalmente a lo largo del tiempo, es por esto, que este enfoque también se conoce como desarrollo iterativo e incremental.
o Las fases del UP y términos orientados a la planificación.
Un proyecto UP organiza el trabajo y las iteraciones en cuatro fases fundamentales:
Inicio: visión aproximada, análisis del negocio, alcance, estimulaciones imprecisas. Elaboración: visión refinada, implementación iterativa del núcleo central de la arquitectura, resolución de los riesgos altos, identificación de más requisitos y alcance, estimaciones más realistas. Construcción: implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles, preparación para el despliegue. Transición: prueba beta, despliegue.
Esto no se corresponde con el antiguo ciclo de vida en “cascada” o secuencial, en el que primero se definían todos los requisitos y, después, se realizaba todo, o la mayoría, del diseño.
La fase de inicio no es una fase de requisitos; sino una especie de fase de viabilidad, donde se lleva a cabo solo el estudio suficiente para decidir si continuar o no.
De igual modo, la fase de elaboración no es la fase de requisitos o de diseño, sino que es una fase donde se implementa, de manera iterativa, la arquitectura que constituye el núcleo central y se mitigan las cuestiones de alto riesgo.
o Las disciplinas del UP (eran flujos de trabajo).
El UP describe actividades de trabajo, como escribir casos de uso, en disciplina. Informalmente, una disciplina es un conjunto de actividades (y artefactos relacionados) en un área determinada, como las actividades en el análisis de requisitos. En el UP, un artefacto es el término general para cualquier producto del trabajo: código, gráficos web, esquema de DD.BB.
UP Agil: optar por un conjunto pequeño de actividades y artefactos; se base en retroalimentaciones debido a que el UP es iterativo; hay un plan de alto nivel denominado – denominado el plan de fase – que estima la fecha de terminación del proyecto y otros hitos importantes.
o El ciclo de vida en “cascada” secuencial: a diferencia del ciclo de vida iterativo del UP, una antigua alternativa era el ciclo de vida “en cascada”, lineal o secuencial. En su acepción habitual, definía los pasos más o menos de la siguiente forma.
1. Determinar, registrar y acordar un conjunto de requisitos completo y fijo. 2. Diseñar un sistema basado en estos requisitos. 3. Implementar en base al diseño.
Fase de Inicio: su propósito es establecer una visión común inicial de los objetivos del proyecto, determinar si es viable y decidir si merece la pena llevar a cabo algunas investigaciones serias en la fase de elaboración. Si se ha decidido de antemano que el proyecto se hará sin ninguna duda, y es claramente viable, entonces la fase de inicio será especialmente breve. Podrá incluir los primeros talleres de requisitos, planificación de la primera iteración y, entonces, rápidamente, cambiar a la elaboración.
o Artefactos que se pueden crear en la fase de inicio.
Comprensión de los requisitos: son capacidades y funciones con las cuales debe ser conforme el sistema – y más ampliamente, el proyecto –. El primer reto del trabajo de los requisitos es encontrar, comunicar y recordar (que normalmente significa registrar) lo que se necesita realmente, de manera que tenga un significado claro para el cliente y los miembros del equipo de desarrollo. o Tipos de requisitos: estos se clasifican de acuerdo con el modelo FURPS+. Funcional (Fuctional): características, capacidades y seguridad. Facilidad de uso (Usability): factores humanos, ayuda, documentación. Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperación de un fallo y grado de previsión. Rendimiento (Performance): tiempos de respuesta, productividad, precisión, disponibilidad, uso de los recursos. Soporte (Supportability): adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad. o El „+‟ en FURPS+ indica requisitos adicionales, tales como: Implementación: limitación de recursos, lenguajes y herramientas, hardware… Interfaz: restricciones impuestas para la interacción con sistemas externos. Operaciones: gestión del sistema en su puesta en marcha. Empaquetamiento. Legales: licencias, etc. Algunos de estos requisitos se denominan colectivamente atributos de calidad, requisitos de calidad. Lo normal es dividir los requisitos en funcionales (comportamiento) y no funcionales (todo lo demás). Los requisitos funcionales se estudian y recogen en el modelo de casos de uso. El glosario en el UP también comprende el concepto de diccionario de datos , que reúne los requisitos relacionados con los datos, como reglas de validación, valores aceptables, etc.
Modelos de caso de uso: son utilizados para descubrir y registrar los requisitos (especialmente los funcionales). La escritura de casos de uso – historias del uso de un sistema – es una técnica excelente para entender y descubrir los requisitos. El UP define el modelo de casos de uso en la disciplina requisitos. Básicamente, es el conjunto de todos los casos de uso; es un modelo de la funcionalidad y entorno del sistema. Hay que recordar que los casos de uso no son orientados a objeto, de este modo podemos utilizar esta herramienta en análisis que no sean orientados a objeto. o Casos de uso: es una colección de escenario con existo y fallo relacionados, que describen a los actores utilizando un sistema para satisfacer un objetivo. Escenario: es una secuencia especifica de acciones e interacciones entre los actores y el sistema, objeto de estudio; también se denomina instancia de caso de uso. Actor: es algo con comportamiento, como una persona (identificada por un roll), sistemas informatizados u organización.
Escenario (flujo básico): describe el camino de éxito típico que satisface los intereses del personal involucrado. El escenario recoge los pasos, que pueden ser de tres tipos: Una interacción entre actores. Una validación (normalmente a cargo del sistema). Un cambio de estado realizado por el sistema (por ejemplo, registrando o modificando algo). Extensiones: indican todos los otros escenarios o bifurcaciones, tanto de éxito como de fracaso; posee dos partes: la condición y el manejo. Requisitos especiales: si un requisito no funcional, atributo de calidad, o restricción se relaciona de manera específica con un caso de uso, se recoge en el caso de uso. Esto incluye cualidades tales como rendimiento, fiabilidad, factibilidad de uso, y restricciones de diseño que son obligados o se consideran probables. Lista de tecnología y variaciones de datos: a menudo, encontramos variaciones técnicas en cómo se debe hacer algo, pero no en que, y es importante registrarlo en el caso de uso.
o Actores: es cualquier cosa con comportamiento, incluyendo el propio sistema que se está estudiando, cuando solicita los servicios de otro sistema. Los actores no son solamente roles que juegan personas, sino también organizaciones, software y maquinas. Actor principal: tiene objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema que se está estudiando. Se lo identifica para encontrar los objetivos de usuario, los cuales dirigen los casos de uso. Actor de apoyo: proporciona un servicio (por ejemplo, información) al sistema que se está estudiando. Normalmente se trata de un sistema informático, pero podría ser una organización o una persona. Se lo identifica para clasificar las interfaces externas y los protocolos. Actor pasivo: está interesado en el comportamiento del caso de uso, pero no es principal ni de apoyo; por ejemplo, la agencia tributaria del gobierno. Se lo identifica, para asegurar que todos los intereses necesarios sean identificados y satisfechos.
o Diagramas de caso de uso: es una excelente representación del contexto del sistema; conforma un buen diagrama de contexto, esto es, muestra los límites de un sistema, lo que permanece fuera de él, y como se utiliza. Sirve como herramienta de comunicación que resume el comportamiento de un sistema y sus actores. El actor principal se coloca en la parte izquierda del diagrama de casos de uso, mientras que los actores de apoyo se colocan en la parte derecha; si el actor es un sistema informático se lo representa de la siguiente manera: dentro de un rectángulo, se coloca << actor >> y el nombre del sistema.
De la fase de inicio, a la fase de elaboración: antes de empezar la fase de elaboración, debemos revisar qué fue lo que sucedió en el inicio; tengamos en cuenta, que los artefactos creados deberían ser breves e incompletos, una etapa rápida y de investigación ligera. Esta etapa no es la fase de requisitos del proyecto, sino una etapa breve para determinar la viabilidad, riesgo y alcances básicos, y decidir si merece la pena más investigación seria en el proyecto, que tendrá lugar durante la fase de elaboración. La elaboración es una fase de construcción del núcleo central de la arquitectura, resolución de los elementos de alto riesgo, definición de la mayoría de los requisitos, y estimación de la planificación y recursos globales. Es la seria inicial de las iteraciones. o ¿Qué artefactos podrían crearse en la elaboración? Modelo de dominio: es una visualización de los conceptos del dominio; es similar al modelo de información estático de las entidades del dominio. Modelo de diseño: es el conjunto que describen el diseño lógico. Comprende los diagramas de clases software, diagramas de interacción, diagramas de paquetes, etc. Documento de la arquitectura de software: una ayuda de aprendizaje que resume las cuestiones claves de la arquitectura y como se resuelven en el diseño. Es un resumen de las ideas destacadas del diseño y su motivación en el sistema. Modelo de datos: incluye los esquemas de bases de datos, y las estrategias de transformación entre representaciones de objetos y no objetuales. Modelo de pruebas: una descripción de lo que se probara y como. Modelo de implementación: se corresponde con la implementación real – el código fuente, ejecutables, base de datos, etc. –. Guiones de caso de uso, prototipos UI: descripción de la interfaz de usuario, caminos de navegación, modelos de facilidad de uso, etc.
Modelo de casos de uso: representación de los Diagramas de Secuencia del Sistema: es un dibujo que muestra, para un escenario especifico de un caso de uso, los eventos que generan los actores externos, el orden y los eventos entre los sistemas. Todos los sistemas se tratan como cajas negras; los diagramas destacan los eventos que cruzan los límites del sistema desde los actores a los sistemas. o Asignación de nombres a los eventos y operaciones: los eventos del sistema ( y sus operaciones del sistema asociadas) deberían expresarse al nivel de intenciones en lugar de en términos del medio de entrada físico o a nivel de elementos de la interfaz de usuario. También se mejora la calidad, el comenzar el nombre de un evento del sistema con un verbo, puesto que resalta la orientación de orden de estos eventos. De esto modo, “introducirArticulo” es mejor que “escanear” (esto es, escanear con láser) porque captura la intención de la operación, al mismo tiempo que permanece abstracta y sin compromiso respecto a las elecciones de diseño sobre que interfaz utilizar para capturar el evento del sistema.
Enlaces: es un camino de conexión entre dos objetos; indica que es posible alguna forma de navegación y visibilidad entre los objetos. De manera mas formal, un enlace es una instancia de una asociación. Recordemos que, a lo largo de un mismo enlace, pueden influir multiples mensajes y mensajes en ambas direcciones. Mensajes: cada mensaje entre objetos se representa con una expresión de mensaje y una pequeña flecha que indica la dirección del mensaje. Pueden fluir muchos mensajes a lo largo de este enlace. Se añade un numero de secuencia, para mostrar el orden secuencial, de los mensajes en los hilos de control actual (no se numera el primer mensaje). Se puede enviar un mensaje a si mismo, esto se representa mediante un autolazo, con mensajes que fluyen a lo largo de este enlace.
o Diagrama de secuencia: ilustran las interacciones en un tipo de formato con el aspecto de una valla, en el que cada objeto nuevo se añade a la derecha.
Fortalezas: muestra claramente la secuencia u ordenación en el tiempo de los mensajes; notación simple. Debilidades: fuerza a extender por la derecha cuando se añaden nuevos objetos; consume espacio horizontal. Enlaces: a diferencia de los diagramas de colaboración, los diagramas de secuencia no muestran enlaces. Mensajes: cada mensaje entre objetos se representa con una expresión de mensaje sobre una línea con punta de flecha entre los objetos. El orden en el tiempo se organiza de arriba a abajo. Se pueden representar un auto mensaje utilizando una caja de activación anidada. Focos de control y cajas de activación: los diagramas de secuencia podrían también mostrar los focos de control (esto es, una llamada de rutina ordinaria, la operación se encuentra en la pila de llamadas) utilizando caja de activación. La caja es opcional, pero la utilizan habitualmente los modeladores de UML. Representación de retornos: un diagrama de secuencia podría opcionalmente mostrar el retorno de un mensaje mediante una línea punteada con la punta de flecha abierta, al final de una caja de activación. Lo normal es que se excluya por quienes utilizan UML. Algunos anotan la línea de retorno para describir lo que se está devolviendo (si es el caso) a partir del mensaje.
GRASP: diseño de objetos con responsabilidad.
GRASP es un acrónimo de General Responsibility Assignment Software Patterns (Patrones generales de software para asignar responsabilidades). El nombre se eligió para sugerir la importancia de aprehender estos principios para diseñar con éxito el software orientado a objeto.
o Responsabilidades y métodos. UML define una responsabilidad como “un contrato y obligación de un clasificador”. Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento. Existen dos tipos: Hacer: Hacer algo él mismo, como crear un objeto o hacer un cálculo. Iniciar una acción en otros objetos. Controlar y coordinar actividades en otros objetos. Conocer: Conocer los datos privados encapsulados. Conocer los objetos relacionados. Conocer las cosas que puede derivar o calcular Las responsabilidades se asignan a las clases de los objetos durante el diseño de objetos. Las responsabilidades relevantes relacionadas con “conocer” a menudo se pueden inferir a partir del modelo del dominio, debido a los atributos y asociaciones que describe. Una responsabilidad, no es lo mismo que un método, pero los métodos se implementan para llevar a cabo responsabilidades. Las responsabilidades se implementan utilizando métodos que actúan solos, o colaboran con otros métodos u objetos.
o Responsabilidades y los diagramas de interacción: los diagramas de interacción muestran elecciones en la asignación de responsabilidades a los objetos. Cuando se crean, se han tomado las decisiones acerca de la asignación de responsabilidades, lo que se refleja en los mensajes que se envían a diferentes clases de objeto. Estas elecciones se reflejan en los diagramas de interacción.
o ¿Qué son los patrones GRASP?: describen los principios fundamentales del diseño de objetos y la asignación de responsabilidades, expresados como patrones.
o Patrones: 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 nuevos situaciones y discusiones sobre sus compromisos.
Es un principio evaluativo que aplica un diseñador mientras evalúa todas las decisiones de diseño. Impulsa la asignación de responsabilidades de manera que su localización no incremente el acoplamiento hasta un nivel que nos lleven a resultados negativos que puede producir un acoplamiento alto. Beneficios: no afectan los cambios en otros componentes; fácil de entender de manera aislada; conveniente para reutilizar. Patrones relacionados: variaciones protegidas.
o Alta cohesión: en cuanto al diseño de objeto, la cohesión es una medida de la fuerza con la que se relacionan y de grado de focalización de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas, y que no hace una gran cantidad de trabajo, tienen alta cohesión. Estos elementos pueden ser clases, subsistemas, etc. Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado trabajo. Tales clases no son convenientes, ya que padecen dificultades de entendimiento, de reutilización, mantenimiento, y son muy delicadas, pues constantemente son afectadas por los cambios. En la práctica, el nivel de cohesión no se puede considerar de manera aislada a otras responsabilidades y otros principios como los patrones experto y bajo acoplamiento. Al igual que el bajo acoplamiento, el patrón de alta cohesión es un principio a tener en mente durante todas las decisiones de diseño; es un objetivo subyacente a tener en cuenta continuamente. Es un principio evaluativo que aplica un diseñador mientras evalúa todas las decisiones de diseño. Diferentes grados de cohesión: Muy baja cohesión: una única clase es responsable de muchas cosas en áreas funcionales muy diferentes. Baja cohesión: una única clase tiene la responsabilidad de una tarea compleja en un área funcional. Alta cohesión: una clase tiene una responsabilidad moderada en un área funcional y colabora con otras clases para llevar a cabo las tareas. Moderada cohesión: una clase tiene responsabilidades ligeras y únicas en unas pocas áreas diferentes que están lógicamente relacionadas con el concepto de la clase, pero no entre ellas. Beneficios: se incrementan la claridad y facilitan la comprensión del diseño; se simplifican el mantenimiento y las mejorar; se soportan a menudo bajo acoplamiento; el grado fino de funcionalidad altamente relacionada incrementa la reutilización porque una clase cohesiva se puede utilizar para un propósito muy específico.
o Controlador: un evento del sistema de entrada es un evento generado por un actor externo, se asocian con operaciones del sistema, tal como se relacionan los mensajes y los métodos. Un controlador es un objeto que no pertenece a la interfaz de usuario, responsables de recibir o manejar un evento del sistema. Un controlador define el método para la operación del sistema. Normalmente, un controlador debería delegar en otros objetos el trabajo que se necesita hacer; coordina o controla la actividad. No realiza mucho trabajo por si mismo. El patrón controlador proporciona guías acerca de las opciones generalmente aceptadas y adecuadas. El controlador es una especie de fachada en la capa del dominio para la capa de la interfaz. A menudo, es conveniente utilizar la misma clase controlador para todos los eventos del sistema de un caso de uso, de manera que es posible mantener la información acerca del estado del caso de uso en el controlador. Un error típico del diseño de los controladores es otorgarles demasiada responsabilidad. Beneficios: aumenta el potencial para reutilizar y las interfaces conectables; razonamiento sobre el estado de casos de uso.
