Este documento presenta una introducción al análisis y diseño orientado a objetos. Explica brevemente los modelos de ciclo de vida, el análisis orientado a objetos, el diseño orientado a objetos y las notaciones utilizadas. Describe los modelos de ciclo de vida en cascada e iterativo-incremental, y explica conceptos clave del análisis como casos de uso, diagramas de clases y modelos basados en objetos y comportamiento. También cubre temas del diseño orientado a objetos como la separación entre el problema y la
Objetivo: Conocer el dominio del problema para poder comunicarse con clientes y usuarios para entender sus necesidades, tanto explícitas como implícitas y sus expectativas sobre el sistema a desarrollar.
Este documento describe los sistemas distribuidos y sus principales características. Explica que los sistemas distribuidos son redes de computadoras que se comunican a través de mensajes para lograr un objetivo común. También define los sistemas distribuidos como un conjunto de elementos de hardware y software que permiten el enlace entre clientes y servidores. Finalmente, destaca algunas propiedades clave de los sistemas distribuidos como la concurrencia, la falta de un reloj global y la capacidad de los componentes de fallar de forma independiente.
El documento describe los diferentes tipos de requisitos funcionales que deben considerarse para un sistema, incluyendo reglas de negocio, transacciones, funciones administrativas, autenticación, niveles de autorización, seguimiento de auditoría, interfaces externas, requisitos de certificación, requisitos de búsqueda e informes, cumplimiento de requisitos legales, información histórica y archivo. También cubre atributos clave de los requisitos funcionales como eficiencia, efectividad, calidad y otros.
Este documento presenta una introducción a la ingeniería de requerimientos, incluyendo su importancia, los pasos principales del proceso, y los roles involucrados. Explica que la ingeniería de requerimientos es necesaria para evitar fallos en proyectos de software, y que involucra actividades como definir, especificar, validar y hacer evolucionar los requerimientos a lo largo del ciclo de vida del proyecto.
Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.
Este documento describe los diferentes tipos de software, incluyendo software de sistema, tiempo real, gestión, ingeniería y científico, empotrado e inteligencia artificial. También describe la ingeniería de software como una disciplina que incluye análisis, diseño, desarrollo, pruebas e implementación de software. Finalmente, explica que los prototipos son simulaciones interactivas que permiten probar el flujo de interacción antes de comenzar la programación.
La ingeniería de requerimientos es importante para entender claramente lo que necesita el cliente antes de desarrollar el software. Incluye tareas como concepción, indagación, elaboración, negociación, especificación, validación y administración de requerimientos. El objetivo es identificar las necesidades del cliente, analizar la factibilidad y especificar la solución de manera no ambigua a través de la colaboración entre ingenieros, clientes y usuarios.
Este documento describe los requerimientos funcionales y no funcionales para un sistema. Los requerimientos funcionales especifican las funciones que el sistema debe realizar, como la autenticación de usuarios, autorización de acceso y envío de archivos. Los requerimientos no funcionales se refieren a propiedades como el rendimiento, la seguridad y la usabilidad del sistema, en lugar de sus funciones específicas.
Objetivo: Conocer el dominio del problema para poder comunicarse con clientes y usuarios para entender sus necesidades, tanto explícitas como implícitas y sus expectativas sobre el sistema a desarrollar.
Este documento describe los sistemas distribuidos y sus principales características. Explica que los sistemas distribuidos son redes de computadoras que se comunican a través de mensajes para lograr un objetivo común. También define los sistemas distribuidos como un conjunto de elementos de hardware y software que permiten el enlace entre clientes y servidores. Finalmente, destaca algunas propiedades clave de los sistemas distribuidos como la concurrencia, la falta de un reloj global y la capacidad de los componentes de fallar de forma independiente.
El documento describe los diferentes tipos de requisitos funcionales que deben considerarse para un sistema, incluyendo reglas de negocio, transacciones, funciones administrativas, autenticación, niveles de autorización, seguimiento de auditoría, interfaces externas, requisitos de certificación, requisitos de búsqueda e informes, cumplimiento de requisitos legales, información histórica y archivo. También cubre atributos clave de los requisitos funcionales como eficiencia, efectividad, calidad y otros.
Este documento presenta una introducción a la ingeniería de requerimientos, incluyendo su importancia, los pasos principales del proceso, y los roles involucrados. Explica que la ingeniería de requerimientos es necesaria para evitar fallos en proyectos de software, y que involucra actividades como definir, especificar, validar y hacer evolucionar los requerimientos a lo largo del ciclo de vida del proyecto.
Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.
Este documento describe los diferentes tipos de software, incluyendo software de sistema, tiempo real, gestión, ingeniería y científico, empotrado e inteligencia artificial. También describe la ingeniería de software como una disciplina que incluye análisis, diseño, desarrollo, pruebas e implementación de software. Finalmente, explica que los prototipos son simulaciones interactivas que permiten probar el flujo de interacción antes de comenzar la programación.
La ingeniería de requerimientos es importante para entender claramente lo que necesita el cliente antes de desarrollar el software. Incluye tareas como concepción, indagación, elaboración, negociación, especificación, validación y administración de requerimientos. El objetivo es identificar las necesidades del cliente, analizar la factibilidad y especificar la solución de manera no ambigua a través de la colaboración entre ingenieros, clientes y usuarios.
Este documento describe los requerimientos funcionales y no funcionales para un sistema. Los requerimientos funcionales especifican las funciones que el sistema debe realizar, como la autenticación de usuarios, autorización de acceso y envío de archivos. Los requerimientos no funcionales se refieren a propiedades como el rendimiento, la seguridad y la usabilidad del sistema, en lugar de sus funciones específicas.
Este documento describe diferentes tipos de pruebas de software, incluyendo pruebas unitarias, de integración, regresión, del sistema, de estrés, de desempeño, de carga, de volumen, de recuperación y tolerancia a fallas, de múltiples sitios, de compatibilidad y conversión, de integridad de datos y base de datos, de seguridad y control de acceso, del ciclo de negocio, de interfaz gráfica de usuario, de configuración, de estilo, de aceptación, de instalación, de documentación y
Un sistema de gestión de base de datos consta de tres componentes principales: el diccionario de datos, el lenguaje de definición de datos, y el lenguaje de manipulación de datos. El diccionario de datos contiene metadatos sobre los datos almacenados. El lenguaje de definición de datos se usa para crear y modificar objetos de datos. El lenguaje de manipulación de datos permite introducir, eliminar, y consultar datos.
Clasificación de las metodologías de desarrollo de softwareElvisAR
- Las metodologías de análisis y diseño estructurado se utilizan con herramientas CASE para incrementar la productividad en el desarrollo e implementación de sistemas de información, incluyendo metodologías como Kendall & Kendall.
- Las metodologías orientadas a procesos se centran en especificar y descomponer la funcionalidad del sistema utilizando diagramas de flujo de datos y especificaciones de procesos.
- Los diagramas de flujo de datos representan cómo se mueven y transforman los datos e incluyen procesos
Esta metodología para el diseño conceptual de almacenes de datos consta de tres fases: 1) examinar el esquema ER de la base de datos operacional para generar esquemas candidatos multidimensionales, 2) recoger los requisitos de los usuarios mediante entrevistas, y 3) contrastar la información de los usuarios con los esquemas candidatos para generar la mejor solución que satisfaga los requisitos de los usuarios basada en los datos operacionales.
Este documento presenta un enfoque de ingeniería de requisitos para modelar sistemas de información conceptualmente. El enfoque se basa en herramientas para especificar requisitos y en un método gráfico orientado a objetos para modelado conceptual que permite generar código automáticamente. El proceso define cómo construir un modelo de requisitos funcionales y cómo representar esos requisitos en el modelo conceptual.
Requerimientos funcionales y no funcionalesLismirabal
El documento describe los diferentes tipos de requerimientos para el desarrollo de software, incluyendo requerimientos funcionales y no funcionales. Los requerimientos funcionales definen las funciones del sistema y deben incluir verbos, mientras que los no funcionales se refieren a características como el desempeño, la seguridad y la usabilidad. También se mencionan ejemplos de requerimientos funcionales y no funcionales para un sistema bibliotecario.
Outsourcing S.A. presta servicios de TI como mesa de ayuda, mantenimiento de hardware, administración de servidores y entrenamiento en TI. Actualmente tiene tres clientes a los que les provee diferentes servicios con personal asignado. Se solicita asesorar a la empresa en la implementación de ITIL para mejorar la gestión de sus servicios de TI mediante la identificación de procesos clave, un esquema de implementación y documentación mínima requerida, incluyendo herramientas de software útiles.
Este documento presenta el proyecto de análisis y diseño de un sistema para la función bibliotecaria. Incluye casos de uso para dominios como préstamo de libros, registro de libros, y llenado de carnet de usuario. También incluye un diagrama de secuencias. El proyecto fue desarrollado por estudiantes de la carrera de Computación e Informática para el tercer semestre y fue asesorado por el ingeniero Jhonel Iván Flores Apaza.
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASAlcoverify
Este documento resume los conceptos clave de la ingeniería de requerimientos para el desarrollo de sistemas. Explica que los requerimientos definen las necesidades y condiciones que debe cumplir un sistema. Describe los tipos de requerimientos, como los funcionales, no funcionales, de usuario y del sistema. También cubre las características, clasificaciones y métodos de análisis de requerimientos. Concluye destacando la importancia de la ingeniería de requerimientos para el éxito de un proyecto de desar
El documento habla sobre la ingeniería de software. Explica que la ingeniería de software surgió en los años 1960 como resultado de la crisis del software causada por la introducción de la tercera generación de hardware. También define la ingeniería de software como la disciplina que ofrece métodos y técnicas para desarrollar software de calidad de manera efectiva y económica. Luego, describe algunas metodologías clave de la ingeniería de software como los requerimientos, análisis y diseño, codificación y pruebas. Finalmente, discute los
El documento presenta información sobre la calidad de software. Define la calidad de software como el grado en que un producto de software cumple con las expectativas de los clientes. Explica que la calidad implica evaluar tanto el producto final como los procesos de desarrollo, los cuales están estandarizados en modelos como ISO/IEC 9126 e ISO/IEC 25000. Estos modelos definen las características de calidad como funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
El documento describe las diferentes estructuras de los sistemas operativos, incluyendo sistemas monolíticos, de capas, microkernels, cliente-servidor y máquinas virtuales. Explica que los sistemas monolíticos ejecutan todo el código del sistema operativo como un solo programa, mientras que los sistemas de capas y microkernels son más modulares y dividen el sistema operativo en módulos independientes que se comunican entre sí. Los sistemas cliente-servidor usan procesos servidores para proveer servicios a procesos cliente,
Este documento presenta un resumen de un proyecto de desarrollo de software basado en la metodología RUP. El proyecto consiste en desarrollar un sistema de gestión de artículos deportivos para una empresa del sector. Se utilizaron plantillas RUP y se generaron varios artefactos como modelos de negocio, casos de uso y diagramas de clases. El proyecto se desarrolló en varias fases e iteraciones siguiendo el proceso RUP.
Este documento presenta información sobre diagramas de casos de uso de negocio y sistema. Explica que los casos de uso describen las interacciones entre actores y un sistema o negocio. También cubre temas como la identificación y estructuración de casos de uso de negocio, incluyendo actores, procesos, relaciones y diagramas. Finalmente, introduce los casos de uso de sistema y su relación con los casos de uso de negocio.
El documento describe varios modelos de procesos de desarrollo de software. Explica que el desarrollo de software es un proceso de aprendizaje a través de la comunicación entre personas. También define un proceso de software como una estructura para las actividades necesarias para construir software de alta calidad. Además, señala que el software tiende a evolucionar con el tiempo debido a factores como los plazos del mercado y los cambios en los requerimientos.
El documento describe los fundamentos del Aseguramiento de la Calidad del Software (SQA). Explica que la calidad del software puede mejorarse mediante un proceso iterativo de mejora continua que requiere control y retroalimentación de los procesos de ciclo de vida, detección de errores y mejora de calidad. También describe conceptos como la prevención temprana de errores y la mejora continua que son adecuados para la ingeniería de software. Finalmente, señala que la calidad del producto depende de la calidad del proceso utilizado para cre
Este documento presenta un plan de aseguramiento de la calidad (SQA) para un proyecto de desarrollo de software. El plan describe las actividades de calidad que se llevarán a cabo, incluyendo la revisión de productos, el cumplimiento de procesos, revisiones técnicas formales y el seguimiento de desviaciones. También especifica la documentación requerida como especificaciones de requisitos, diseño de software, planes de verificación y validación, y documentación de usuario. El plan cubre las etapas de requisitos, an
El documento describe la estructura y procesos del Rational Unified Process (RUP) y cómo se aplica en el modelo de análisis de requisitos. Explica las fases, iteraciones e iteraciones preliminares del RUP, y describe los elementos clave del modelo de análisis como casos de uso, clases de análisis, diagramas de secuencia y colaboración, y arquitectura del análisis. También incluye ejemplos detallados de cómo se representan y analizan los requisitos funcionales en el modelo de análisis.
El documento resume las características principales de un Documento de Requerimientos. Explica que este documento sirve para comunicar los requerimientos de un software de manera precisa y para servir como base para la planificación, desarrollo y validación de un proyecto. También contrasta este documento con los modelos de requerimientos, y resalta algunas técnicas y limitaciones comunes en la documentación de requerimientos.
Este documento presenta una introducción a los conceptos fundamentales de análisis y diseño orientado a objetos. Explica técnicas como análisis y diseño orientado a objetos, el lenguaje unificado de modelado, técnicas de modelado de objetos, la metodología de Booch, la metodología RUP, diseño de alto y bajo nivel, y comprensión de requerimientos. También incluye referencias históricas clave en el desarrollo de la arquitectura y el diseño de software.
Este documento describe diferentes tipos de pruebas de software, incluyendo pruebas unitarias, de integración, regresión, del sistema, de estrés, de desempeño, de carga, de volumen, de recuperación y tolerancia a fallas, de múltiples sitios, de compatibilidad y conversión, de integridad de datos y base de datos, de seguridad y control de acceso, del ciclo de negocio, de interfaz gráfica de usuario, de configuración, de estilo, de aceptación, de instalación, de documentación y
Un sistema de gestión de base de datos consta de tres componentes principales: el diccionario de datos, el lenguaje de definición de datos, y el lenguaje de manipulación de datos. El diccionario de datos contiene metadatos sobre los datos almacenados. El lenguaje de definición de datos se usa para crear y modificar objetos de datos. El lenguaje de manipulación de datos permite introducir, eliminar, y consultar datos.
Clasificación de las metodologías de desarrollo de softwareElvisAR
- Las metodologías de análisis y diseño estructurado se utilizan con herramientas CASE para incrementar la productividad en el desarrollo e implementación de sistemas de información, incluyendo metodologías como Kendall & Kendall.
- Las metodologías orientadas a procesos se centran en especificar y descomponer la funcionalidad del sistema utilizando diagramas de flujo de datos y especificaciones de procesos.
- Los diagramas de flujo de datos representan cómo se mueven y transforman los datos e incluyen procesos
Esta metodología para el diseño conceptual de almacenes de datos consta de tres fases: 1) examinar el esquema ER de la base de datos operacional para generar esquemas candidatos multidimensionales, 2) recoger los requisitos de los usuarios mediante entrevistas, y 3) contrastar la información de los usuarios con los esquemas candidatos para generar la mejor solución que satisfaga los requisitos de los usuarios basada en los datos operacionales.
Este documento presenta un enfoque de ingeniería de requisitos para modelar sistemas de información conceptualmente. El enfoque se basa en herramientas para especificar requisitos y en un método gráfico orientado a objetos para modelado conceptual que permite generar código automáticamente. El proceso define cómo construir un modelo de requisitos funcionales y cómo representar esos requisitos en el modelo conceptual.
Requerimientos funcionales y no funcionalesLismirabal
El documento describe los diferentes tipos de requerimientos para el desarrollo de software, incluyendo requerimientos funcionales y no funcionales. Los requerimientos funcionales definen las funciones del sistema y deben incluir verbos, mientras que los no funcionales se refieren a características como el desempeño, la seguridad y la usabilidad. También se mencionan ejemplos de requerimientos funcionales y no funcionales para un sistema bibliotecario.
Outsourcing S.A. presta servicios de TI como mesa de ayuda, mantenimiento de hardware, administración de servidores y entrenamiento en TI. Actualmente tiene tres clientes a los que les provee diferentes servicios con personal asignado. Se solicita asesorar a la empresa en la implementación de ITIL para mejorar la gestión de sus servicios de TI mediante la identificación de procesos clave, un esquema de implementación y documentación mínima requerida, incluyendo herramientas de software útiles.
Este documento presenta el proyecto de análisis y diseño de un sistema para la función bibliotecaria. Incluye casos de uso para dominios como préstamo de libros, registro de libros, y llenado de carnet de usuario. También incluye un diagrama de secuencias. El proyecto fue desarrollado por estudiantes de la carrera de Computación e Informática para el tercer semestre y fue asesorado por el ingeniero Jhonel Iván Flores Apaza.
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASAlcoverify
Este documento resume los conceptos clave de la ingeniería de requerimientos para el desarrollo de sistemas. Explica que los requerimientos definen las necesidades y condiciones que debe cumplir un sistema. Describe los tipos de requerimientos, como los funcionales, no funcionales, de usuario y del sistema. También cubre las características, clasificaciones y métodos de análisis de requerimientos. Concluye destacando la importancia de la ingeniería de requerimientos para el éxito de un proyecto de desar
El documento habla sobre la ingeniería de software. Explica que la ingeniería de software surgió en los años 1960 como resultado de la crisis del software causada por la introducción de la tercera generación de hardware. También define la ingeniería de software como la disciplina que ofrece métodos y técnicas para desarrollar software de calidad de manera efectiva y económica. Luego, describe algunas metodologías clave de la ingeniería de software como los requerimientos, análisis y diseño, codificación y pruebas. Finalmente, discute los
El documento presenta información sobre la calidad de software. Define la calidad de software como el grado en que un producto de software cumple con las expectativas de los clientes. Explica que la calidad implica evaluar tanto el producto final como los procesos de desarrollo, los cuales están estandarizados en modelos como ISO/IEC 9126 e ISO/IEC 25000. Estos modelos definen las características de calidad como funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
El documento describe las diferentes estructuras de los sistemas operativos, incluyendo sistemas monolíticos, de capas, microkernels, cliente-servidor y máquinas virtuales. Explica que los sistemas monolíticos ejecutan todo el código del sistema operativo como un solo programa, mientras que los sistemas de capas y microkernels son más modulares y dividen el sistema operativo en módulos independientes que se comunican entre sí. Los sistemas cliente-servidor usan procesos servidores para proveer servicios a procesos cliente,
Este documento presenta un resumen de un proyecto de desarrollo de software basado en la metodología RUP. El proyecto consiste en desarrollar un sistema de gestión de artículos deportivos para una empresa del sector. Se utilizaron plantillas RUP y se generaron varios artefactos como modelos de negocio, casos de uso y diagramas de clases. El proyecto se desarrolló en varias fases e iteraciones siguiendo el proceso RUP.
Este documento presenta información sobre diagramas de casos de uso de negocio y sistema. Explica que los casos de uso describen las interacciones entre actores y un sistema o negocio. También cubre temas como la identificación y estructuración de casos de uso de negocio, incluyendo actores, procesos, relaciones y diagramas. Finalmente, introduce los casos de uso de sistema y su relación con los casos de uso de negocio.
El documento describe varios modelos de procesos de desarrollo de software. Explica que el desarrollo de software es un proceso de aprendizaje a través de la comunicación entre personas. También define un proceso de software como una estructura para las actividades necesarias para construir software de alta calidad. Además, señala que el software tiende a evolucionar con el tiempo debido a factores como los plazos del mercado y los cambios en los requerimientos.
El documento describe los fundamentos del Aseguramiento de la Calidad del Software (SQA). Explica que la calidad del software puede mejorarse mediante un proceso iterativo de mejora continua que requiere control y retroalimentación de los procesos de ciclo de vida, detección de errores y mejora de calidad. También describe conceptos como la prevención temprana de errores y la mejora continua que son adecuados para la ingeniería de software. Finalmente, señala que la calidad del producto depende de la calidad del proceso utilizado para cre
Este documento presenta un plan de aseguramiento de la calidad (SQA) para un proyecto de desarrollo de software. El plan describe las actividades de calidad que se llevarán a cabo, incluyendo la revisión de productos, el cumplimiento de procesos, revisiones técnicas formales y el seguimiento de desviaciones. También especifica la documentación requerida como especificaciones de requisitos, diseño de software, planes de verificación y validación, y documentación de usuario. El plan cubre las etapas de requisitos, an
El documento describe la estructura y procesos del Rational Unified Process (RUP) y cómo se aplica en el modelo de análisis de requisitos. Explica las fases, iteraciones e iteraciones preliminares del RUP, y describe los elementos clave del modelo de análisis como casos de uso, clases de análisis, diagramas de secuencia y colaboración, y arquitectura del análisis. También incluye ejemplos detallados de cómo se representan y analizan los requisitos funcionales en el modelo de análisis.
El documento resume las características principales de un Documento de Requerimientos. Explica que este documento sirve para comunicar los requerimientos de un software de manera precisa y para servir como base para la planificación, desarrollo y validación de un proyecto. También contrasta este documento con los modelos de requerimientos, y resalta algunas técnicas y limitaciones comunes en la documentación de requerimientos.
Este documento presenta una introducción a los conceptos fundamentales de análisis y diseño orientado a objetos. Explica técnicas como análisis y diseño orientado a objetos, el lenguaje unificado de modelado, técnicas de modelado de objetos, la metodología de Booch, la metodología RUP, diseño de alto y bajo nivel, y comprensión de requerimientos. También incluye referencias históricas clave en el desarrollo de la arquitectura y el diseño de software.
Los DBMSs soportan la concurrencia y la recuperación de fallos mediante transacciones ACID (atómicas, consistentes, aisladas y duraderas), registro de operaciones y la búsqueda de horarios equivalentes a la ejecución en serie. El protocolo de bloqueo de dos fases estricto (2PL) garantiza horarios serializables, mientras que el registro de escrituras anticipadas (WAL) permite deshacer operaciones abortadas y recuperar el sistema tras un fallo al estado consistente.
Este documento describe los elementos clave involucrados en el proceso de negociación de transferencia de tecnología en una organización. Explica que la tecnología medular es el conocimiento esencial dominado por los emprendedores que se convierte en el motor de innovación continua, mientras que la negociación tecnológica implica el intercambio de conocimientos a través de mecanismos como licencias, ventas, inversión extranjera y asistencia técnica. También destaca la importancia de la información y el poder de negoci
El documento describe el Modelo CMMi, un conjunto de buenas prácticas para mejorar los procesos de desarrollo de software y sistemas. Explica que el CMMi ofrece una guía para la mejora continua mediante dos representaciones: por etapas, con niveles de madurez, y continua, con niveles de capacidad de las áreas de proceso. También describe las constelaciones, estructura y áreas de proceso del modelo.
Este documento describe los conceptos clave de la ingeniería de requerimientos, incluyendo la identificación de participantes, la indagación de requerimientos, la elaboración de escenarios de usuario y casos de uso, y la validación de requerimientos. Un enfoque colaborativo que involucra a todos los participantes es fundamental para entender las necesidades del proyecto y desarrollar requerimientos claros y consistentes.
El documento describe el proceso de análisis de requisitos, el cual refina y estructura los requisitos capturados para lograr una comprensión más precisa. El análisis utiliza un modelo de objetos conceptual llamado modelo de análisis para describir los requisitos usando el lenguaje de los desarrolladores. El modelo de análisis estructura los requisitos en clases y paquetes para facilitar su mantenimiento.
Este documento presenta información sobre diagramas de caso de uso para el análisis y diseño de sistemas. Explica que los diagramas de caso de uso documentan el comportamiento de un sistema desde la perspectiva del usuario e identifican los requisitos funcionales. Describe los componentes clave de un diagrama de caso de uso, incluidos actores, casos de uso y asociaciones. Además, proporciona un ejemplo de un diagrama de caso de uso y la descripción de un caso de uso específico para la planificación de actividades de mantenimiento.
El documento describe la relación entre ciencia y tecnología, y diferentes clasificaciones de la tecnología. También explica la gestión tecnológica, su relación con la competitividad, y su aplicación en las empresas. Finalmente, discute el rol de las pequeñas y medianas empresas en los países en desarrollo y las políticas públicas dirigidas a apoyarlas.
Este documento presenta información sobre pruebas de sistemas y pruebas de aceptación. Explica que las pruebas de sistemas buscan discrepancias entre el programa y los requerimientos, enfocándose en errores durante la transición al diseño. También describe objetivos, tipos y la implementación de pruebas de sistemas. Luego, explica que las pruebas de aceptación verifican que el producto cumpla los estándares y satisfaga a los usuarios según los requerimientos iniciales. Finalmente, detalla la implementación de ambos
Este documento describe los diagramas de estados, incluyendo sus elementos, funciones y partes. Un diagrama de estados muestra cómo los objetos cambian de estado en respuesta a eventos y cómo los estados, eventos y transiciones representan el comportamiento de un sistema. Se usan para ilustrar los cambios de estado de los objetos de una clase en respuesta a eventos.
Este documento describe los conceptos fundamentales del análisis y diseño orientado a objetos de un sistema de software. Explica brevemente el proceso de desarrollo de software, los casos de uso, el modelo conceptual y otros temas clave del análisis orientado a objetos. Además, utiliza un sistema de punto de venta como caso de estudio para ilustrar estos conceptos.
El proceso de desarrollo de software incluye la asignación disciplinada de tareas y responsabilidades para asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Esto implica definir quién realiza qué tareas, cuándo y cómo. El objetivo es desarrollar software que cumpla con los requisitos del usuario de manera eficiente.
1. El documento describe el método de desarrollo de software conocido como Proceso Unificado, el cual se basa en iteraciones cortas y en la construcción incremental del sistema.
2. Se explican las fases del proceso, los artefactos que deben producirse en la fase de inicio y las disciplinas a las que pertenecen dichos artefactos.
3. Los casos de uso y los requerimientos funcionales se presentan como herramientas importantes para describir las funcionalidades del sistema desde las primeras etapas del desarrollo.
Este documento presenta los conceptos básicos de análisis y diseño orientado a objetos. Explica el proceso de desarrollo de software, incluyendo la definición de requisitos, casos de uso, modelo conceptual, diagramas de secuencia y colaboración. El objetivo es asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles mediante un enfoque disciplinado.
Este documento presenta una evaluación a distancia para el curso de Ingeniería de Software. Consta de dos partes: preguntas objetivas y preguntas de ensayo. La parte objetiva incluye preguntas de verdadero/falso, de elección múltiple y de completado. La parte de ensayo propone dos casos para que el estudiante desarrolle usando el modelado de sistemas. El estudiante debe elegir solo uno de los dos casos presentados.
Este documento presenta una aplicación de subastas en línea como ejemplo para ilustrar técnicas avanzadas de desarrollo de aplicaciones Java. Primero, describe el proceso de determinar los requisitos del proyecto a través de entrevistas con usuarios y la creación de un modelo. Luego, explica los componentes clave de la aplicación de subastas, incluido el registro de compradores y vendedores, la publicación y puja de artículos, y la notificación de resultados de subastas. Finalmente, proporciona un diagrama de
PRIMER EXAMEN PARCIAL DE INTELIGENCIA DE NEGOCIOSRis Fernandez
Este documento presenta un examen parcial de inteligencia de negocios que evalúa competencias relacionadas con el modelado de bases de datos multidimensionales y el diseño e implementación de soluciones de inteligencia de negocios. El examen contiene preguntas sobre conceptos básicos de inteligencia de negocios como modelos estrella, dimensiones, indicadores y jerarquías. También incluye un caso práctico sobre una empresa minorista donde se pide diseñar un datamart respondiendo preguntas sobre indicadores, dimensiones, modelo dimensional y ma
Este documento proporciona información sobre un servicio de asesoría y resolución de ejercicios en ciencias e informática. Incluye la dirección de correo electrónico y sitio web de contacto, así como una lista de tareas y ejercicios que los estudiantes pueden realizar con apoyo del servicio. Algunas de las tareas incluyen investigar metodologías de desarrollo de sistemas, algoritmos para resolver problemas, y aplicar el ciclo de vida del software para desarrollar programas que resuelven problemas específicos.
10 Clase Captura De Los Requisitos Cap.6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan modelos del dominio y del negocio para comprender el contexto del sistema. Los requisitos funcionales se capturan a través de casos de uso, mientras que los no funcionales se especifican por separado. El proceso iterativo permite actualizar los requisitos a lo largo del desarrollo del proyecto.
10 Clase Captura De Los Requisitos Cap[1].6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan artefactos como un modelo de casos de uso, requisitos adicionales, modelos de dominio y de negocio. Los modelos de dominio y negocio ayudan a comprender el contexto mediante la identificación de objetos, procesos y actores. La captura de requisitos funcionales se basa en casos de uso, mientras que los no funcionales especifican propiedades como rendimiento y seguridad. El proceso iterativo permite actualizar los
CURSO DE PROGRAMACION AVANZADA EN JAVA EN ESPAÑOLDarwin Durand
Este documento describe el desarrollo de una aplicación de subastas en línea como ejemplo para mostrar técnicas avanzadas de programación en Java. Explica cómo determinar los requisitos del proyecto, modelar la aplicación, y elegir las APIs de Java apropiadas. Luego, describe el código central de la aplicación de subastas, que se basa en la plataforma Enterprise JavaBeans para crear una aplicación multihilo que permita múltiples usuarios de forma simultánea.
El documento describe el desarrollo de un prototipo de sistema para realizar compras electrónicas mediante subastas inversas en un entorno B2B. El sistema permitirá a las empresas y proveedores interactuar en línea para negociar precios de manera más eficiente y transparente, reduciendo costos en el proceso de compras.
Este documento presenta varias actividades relacionadas con el desarrollo de programas para resolver problemas reales siguiendo el ciclo de vida del software. La primera actividad propone investigar metodologías de desarrollo de sistemas y algoritmos para luego aplicarlos a problemas propuestos. Las actividades siguientes guían al estudiante en la creación de diagramas de flujo, pseudocódigo y programas sencillos en C++ para calcular promedios, realizar ventas y generar reportes, aplicando cada etapa del ciclo de vida del software.
Este documento describe un servicio de asesoría y resolución de ejercicios de ciencias y programación. Proporciona un correo electrónico y sitio web para solicitar cotizaciones y apoyo en ejercicios de fundamentos de programación y otras asignaturas de ciencias.
la simulación es ampliamente
aceptada en el mundo de los negocios
para predecir, explicar y ayudar a
identificar soluciones óptimas. En
particular, aplicaremos la simulación
Monte Carlo a un proyecto de inversión
con el fin de poder estimar el riesgo de
un fracaso, usando para este propósito
la hoja electrónica Excel.
la simulación es ampliamente
aceptada en el mundo de los negocios
para predecir, explicar y ayudar a
identificar soluciones óptimas. En
particular, aplicaremos la simulación
Monte Carlo a un proyecto de inversión
con el fin de poder estimar el riesgo de
un fracaso, usando para este propósito
la hoja electrónica Excel.
Este documento presenta una introducción a la ingeniería de requisitos para un sistema de software. Explica que la captura de requisitos es el proceso de descubrir lo que se debe construir mediante la obtención de una lista de requisitos de cada usuario. Luego, cubre conceptos clave como el modelado de negocio, modelado de dominio, casos de uso y requisitos funcionales y no funcionales. Finalmente, describe las iteraciones típicas del proceso de ingeniería de requisitos usando RUP.
El resumen del documento es:
Ingeniería Eléctrica necesita un sistema de información que integre los resultados financieros de cada proyecto para tomar mejores decisiones. Consideró tres alternativas y seleccionó SAP Business One porque integra todas las áreas de la empresa, proporciona información en tiempo real a cualquier nivel y se adapta a sus procesos empresariales existentes.
para programadores y desarrolladores de inteligencia artificial y machine learning, como se automatiza una cadena de valor o cadena de valor gracias a la teoría por Manuel Diaz @manuelmakemoney
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)AbrahamCastillo42
Power point, diseñado por estudiantes de ciclo 1 arquitectura de plataformas, esta con la finalidad de dar a conocer el componente hardware llamado tarjeta de video..
Catalogo general tarifas 2024 Vaillant. Amado Salvador Distribuidor Oficial e...AMADO SALVADOR
Descarga el Catálogo General de Tarifas 2024 de Vaillant, líder en tecnología para calefacción, ventilación y energía solar térmica y fotovoltaica. En Amado Salvador, como distribuidor oficial de Vaillant, te ofrecemos una amplia gama de productos de alta calidad y diseño innovador para tus proyectos de climatización y energía.
Descubre nuestra selección de productos Vaillant, incluyendo bombas de calor altamente eficientes, fancoils de última generación, sistemas de ventilación de alto rendimiento y soluciones de energía solar fotovoltaica y térmica para un rendimiento óptimo y sostenible. El catálogo de Vaillant 2024 presenta una variedad de opciones en calderas de condensación que garantizan eficiencia energética y durabilidad.
Con Vaillant, obtienes más que productos de climatización: control avanzado y conectividad para una gestión inteligente del sistema, acumuladores de agua caliente de gran capacidad y sistemas de aire acondicionado para un confort total. Confía en la fiabilidad de Amado Salvador como distribuidor oficial de Vaillant, y en la resistencia de los productos Vaillant, respaldados por años de experiencia e innovación en el sector.
En Amado Salvador, distribuidor oficial de Vaillant en Valencia, no solo proporcionamos productos de calidad, sino también servicios especializados para profesionales, asegurando que tus proyectos cuenten con el mejor soporte técnico y asesoramiento. Descarga nuestro catálogo y descubre por qué Vaillant es la elección preferida para proyectos de climatización y energía en Amado Salvador.
La inteligencia artificial sigue evolucionando rápidamente, prometiendo transformar múltiples aspectos de la sociedad mientras plantea importantes cuestiones que requieren una cuidadosa consideración y regulación.
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)codesiret
Los protocolos son conjuntos de
normas para formatos de mensaje y
procedimientos que permiten a las
máquinas y los programas de aplicación
intercambiar información.
2. MotivaciónMotivación
Un proyecto software no consiste sólo en programar.p y p g
Necesitamos saber cuáles son las necesidades del cliente.
Id tifi l i it t l li l lid lIdentificar los requisitos, anotarlos, analizarlos, validarlos.
Necesitamos diseñar una solución, y hacer “los planos” del, y p
software:
Diseño de la arquitectura, detallado, de datos, …
Hay que asegurarse de que el software funciona:
Pruebas de unidad (a nivel de método y clase), de integración, del
sistema de aceptación etcsistema, de aceptación, etc.
Hay que mantener el software.
2
Documentación (de cada una de las fases), coherencia entre los
productos de las distintas fases (ej. código vs. diseños).
3. IndiceIndice
Modelos de Ciclo de Vida.
Análisis y Diseño Orientado a ObjetosAnálisis y Diseño Orientado a Objetos.
Notaciones.
Metodologías.
3
4. Modelos de ciclo de vidaModelos de ciclo de vida
Q é t t i i i l f d¿Qué estrategia seguimos para organizar las fases de
un proyecto?.
Un modelo de ciclo de vida nos guia en las fases que
hay que realizar, sus entradas y salidas, y los criteriosy q y y
de transición.
L l ió d d d d l í iLa elección de uno u otro depende de las características
del proyecto.
Con teconologías orientadas a objetos se tiende a ciclos
de vida iterativos e incrementales.
4
5. Modelos de Ciclo de VidaModelos de Ciclo de Vida
/ Estudio de Viabilidad.
Análisis
Qué
/
Planificación y Estimación.
N it it i
Desventajas:
Diseño
Có
•No permite iteraciones.
• Los requisitos se
congelan al principio del
Codificación
mo
congelan al principio del
proyecto.
• No existe un proyecto
Pruebas
• No existe un proyecto
“enseñable” hasta el final
del proyecto.
e integración
O ó [ ti ]
MCV en
Cascada
5
Operación y
Mantenimiento
[retiro]
6. Modelos de Ciclo de VidaModelos de Ciclo de Vida
Iteración de A & D
Planificación Análisis Diseño
[más iteraciones]
Incremento
Extraer
Eval
Planificación Análisis Diseño clases
reutilizables
Prototipo Pruebas
Eval.
cliente
[más iteraciones]
MCV iterativo e
6
incremental (RUP)
7. IndiceIndice
M d l d Ci l d VidModelos de Ciclo de Vida.
Análisis y Diseño Orientado aAnálisis y Diseño Orientado a
Objetos.
Ventajas e inconvenientesVentajas e inconvenientes.
Análisis.
Diseño.
NotacionesNotaciones.
Metodologías.
7
8. Análisis y Diseño
Problema vs SoluciónProblema vs. Solución
Análisis (qué) Diseño (cómo)
Dominio del problema Dominio de la Solución
Modelo del Dominio del Problema Modelo del Dominio de la Solución
ControlTrafico
VentanaResumen VentanaMapas
Avión Controlador
Trafico
Aeropuerto C t lT fi
BDPlanVuelo
p
8
PlanVuelo
Aeropuerto ControlTrafico
9. Paradigma de Orientación a Objetosg j
Características
Diseños modularesDiseños modulares.
Efectos laterales mínimos(encapsulamiento)( p )
Extensibilidad.
Fácil de modificar.
Orientado a datos.
Explota la herencia (jerárquico).
R ili ió d l
9
Reutilización de clases.
10. VentajasVentajas
Módulos con fuerte cohesión interna y escasoy
acoplamiento externo (sin variables globales, …)
Facilita el funcionamiento en entornoFacilita el funcionamiento en entorno
multiprocesador (objetos distribuidos)
Correspondencia directa con el mundo realCorrespondencia directa con el mundo real
Prototipos rápidos
Herramientas y bibliotecas muy amplias
Aplicaciones construidas enganchando objetosAplicaciones construidas enganchando objetos
Mejor comprensión y mantenimiento
10Apropiado para aplicaciones dirigidas por eventos.
11. InconvenientesInconvenientes
I t d f bl b i ti dImpactos desfavorables sobre espacio y tiempo de
ejecución.
Forma de pensar diferente: curva de aprendizaje lenta.
Herencia y ligadura dinámica dificultan las pruebas.
Difícil seguir el flujo de ejecución (e.j. llamádas implicitas
a constructores, conversiones implícitas, etc.)
Frameworks grandes y complicados (e.j. MFCs).
11
12. Análisis Orientado a ObjetosAnálisis Orientado a Objetos
Centrarse en el “qué”.
Identificar los requisitos: documentos de análisis.
Entrevistas.Entrevistas.
Identificar requisitos funcionales y no funcionales (ej.: rendimiento,
fiabilidad)
Especificar los requisitos: documento de especificación de
requisitos.
D t té i O i ió l ifi ió d l i itDocumento técnico. Organización y clasificación de los requisitos.
Analizar: Modelos de análisisAnalizar: Modelos de análisis.
Estudio de posibles escenarios: casos de uso.
Otras técnicas: fichas CRC, orientados al flujo, etc.
12Validar.
13. Análisis Orientado a ObjetosAnálisis Orientado a Objetos
La especificación de
i it d ib l
Obtención
de requisitos
requisitos describe el
sistema, en lenguaje
natural.de requisitos
Especificación
de requisitos:
Documento
Sirve de comunicación
entre desarrolladores y
Análisis
Modelo de
Análisis:
entre desarrolladores y
clientes, “contrato”.
Diseño del
Sistema
Modelo
Modelo del
El modelo de análisis
usa notación formal (ej.:
Z, Alloy) o semi-formalModelo del
Sistema:
Modelo
, y)
(ej.: UML).
Sirve de comunicación
13
Sirve de comunicación
entre desarrolladores.
14. Análisis Orientado a ObjetosAnálisis Orientado a Objetos
Modelos de Análisis
Modelos basados en Modelos orientados al Flujo
Casos de uso, texto.
Casos de uso, diagramas.
Diagramas de Flujo de Datos
Diagramas de Flujo de Control
Modelos basados en
Escenarios
Modelos orientados al Flujo
Diagramas de actividad.
Diagramas de secuencia.
…
Diagramas de Transición de Estados
…
Modelo de Análisis
Modelos basados en
Modelos basados en
Diagramas de Clases.
Diagramas de Paquete.
Modelos CRC
Clases
Diagramas de Estado.
Diagramas de Secuencia
Modelos basados en
Comportamiento
14
Modelos CRC.
Diagramas de Interacción.
…
Diagramas de Secuencia.
…
15. Análisis Orientado a ObjetosAnálisis Orientado a Objetos
Modelos de Análisis. Basado en Escenarios.
Modelo de
Análisis: Modelo
Modelo Funcional:
Modelo
Modelo de
Objetos: Modelo
Modelo
Dinámico: Modelo
Modelo funcional: casos de uso y escenarios.
Modelo de Objetos: diagramas de clases yModelo de Objetos: diagramas de clases y
objetos.
M d l di á i di d i
15
Modelo dinámico: diagramas de secuencia,…
16. Casos de usoCasos de uso
D ib é h l i t d d l t d i tDescriben qué hace el sistema desde el punto de vista
de un observador externo.
Actores: ¿quién interactúa con el sistema?. También
pueden ser otros sistemas.p
Un escenario es un ejemplo de lo que ocurre cuando
i i ú l iuno o varios actores interactúan con el sistema.
C d j t d i ( i dCaso de uso: conjunto de escenarios (secuencias de
interacción de los actores y el sistema)
16
17. Casos de usoCasos de uso
Pasos:
Identificar los límites (alcance) del sistema.
Identificar los actores principales.
Para cada uno, identificar sus objetivos.
Definir casos de uso que satisfagan sus objetivos.
17
18. Casos de Uso: Ejemplo
CASO DE USO 1: Procesar venta
Casos de Uso: Ejemplo
CASO DE USO 1: Procesar venta
Actor Primario:
C jCajero.
Interesados y objetivos:
Cajero: Quiere anotaciones precisas y rápidas de precios, sin errores.
Cli t Q i l á id l í i f Q iCliente: Quiere que el pago sea rápido con el mínimo esfuerzo. Quiere
una prueba de compra para justificar devoluciones.
Compañía: Quieren almacenar las transacciones y satisfacer los
intereses de los clientes.intereses de los clientes.
Comercial: Quiere que se le actualicen sus comisiones por venta.
Agencias de impuestos gubernamentales: Quieren recolectar impuestos
de cada venta. Puede que haya varias agencias (nacionales, regionales,
t )etc.)
Servicios de Autorización de Pagos (por tarjetas de crédito): Quiere
recibir peticiones digitales de autorizaciones en el formato y protocolo
correcto.
1818
Precondiciones:
El cajero se ha identificado y autentificado.
19. Casos de Uso: Ejemplo
Garantía de éxito (Postcondiciones):
Casos de Uso: Ejemplo
Garantía de éxito (Postcondiciones):
Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se actualizan los sistemas de
inventario y de contabilidad. Se registran las comisiones. Se genera un recibo. Se registran las
aprobaciones de pago por tarjeta.
Escenario principal de Exito:Escenario principal de Exito:
1. Llega un clienta al TPV con bienes o servicios que comprar.
2. El cajero comienza una nueva compra.
3. El cajero introduce un identificador de producto.
4 El i t i t l l t t d i ió d l i i4. El sistema registra el elemento y presenta una descripción del mismo, su precio y
total actual. Se calcula el precio de una lista de reglas.
El cajero repite los pasos 3-4 hasta que no hay más elementos.j p p q y
5. El sistema presenta el total con los impuestos calculados.
6. El cajero le dice el total al cliente, y le pide que pague.
7 El cliente paga y el sistema procesa el pago7. El cliente paga y el sistema procesa el pago.
8. El sistema registra la venta completada y manda la información a los sistemas
externos de inventario y contabilidad.
9. El sistema genera el recibo.
1919
10. El cliente se va.
20. Casos de Uso: Ejemplo
Extensiones (Flujos alternativos):
Casos de Uso: Ejemplo
Extensiones (Flujos alternativos):
a*. En cualquier momento, el sistema falla.
3a. Identificador inválido.
1. El sistema señala un error y rechaza la entrada.
7a. Pago en efectivo.
...
7b Pago con tarjeta7b. Pago con tarjeta.
...
Requisitos especiales:
Pantalla táctil en panel grande y plano. El texto debe ser visible desde un metro.
Respuesta de autorización de crédito en menos de 30 secs, el 90% de las veces.
Recuperación robusta cuando el acceso a sistemas externos (tales como el inventario,
impuestos, etc.) falla.impuestos, etc.) falla.
Posibilidades de internazionalización de texto.
Reglas de negocio insertables en los pasos 3 y 7.
...
2020
21. Casos de Uso: Ejemplo
Lista de variaciones de tecnología y datos:
Casos de Uso: Ejemplo
Lista de variaciones de tecnología y datos:
3a. Se introduce el identificador del elemento mediante escáner de código de barras o
mediante el teclado.
3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU.
7a. La información sobre el pago con tarjeta se puede introducir mediante el teclado o
lector.
7b. Se pide firma en papel. En dos años, creemos que muchos clientes van a querer
captura de firma digital.
Frecuencia de ocurrencia:
Puede ser casi continua.
Temas abiertos:
¿Cuáles son las posibles variaciones en las leyes sobre impuestos?
Explorar el tema de recuperación en caso de fallo de sistemas externos.
¿Qué modificaciones se necesitan para negocios distintos?
¿Debe el cajero extraer el cajón con la recaudación al terminar?
¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lo hace?
2121
¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lo hace?
22. Diagrama de Casos de Uso (UML)Diagrama de Casos de Uso (UML)
TPVTPV
Procesar
Venta
caje o
Servicio
cajero
Procesar
Devoluciones
de Autorización
de Pagos
«actor»
Calculador de
Impuestos
Analizar
Actividad
«actor»
Analizador de
Actividad de pImpuestos
«actor»
Gestionar
Ventas
...
Sistema de
contabilidad
Gestionar
Seguridad
Gestionar
22
Administrador
del sistema
Gestionar
Usuarios
23. Modelos de Análisis Basados en Clases
Identificar las clases
Analizar los documentos de análisis o casos de usoAnalizar los documentos de análisis, o casos de uso.
Clases que pertenecen al espacio de la solución vs.
espacio del problema.p p
Aislar los sustantivos:
Entidades externas: producen o consumen información que usa
el sistema.el sistema.
Cosas (informes, señales, etc.): información que necesita el
sistema.
Sucesos o eventos que ocurren durante la operación delSucesos o eventos que ocurren durante la operación del
sistema.
Papeles que desempeñan los usuarios.
Unidades organizacionales.Unidades organizacionales.
Sitios que establecen el contexto y la función global del sistema.
Estructuras que definen una clase de objetos o clases
relacionadas.
23
relacionadas.
24. Diagrama de clases
C t
Conceptuales
* 1d it
Concepto u
Objeto del
dominio
cantidad
ElementoVenta
1..*
Descripcion
Precio
ID
Especific.Producto
* 1descrito-por
3contiene
1
1..*
registra-ventas-de
1..*
0..1
contenido-en
1.. ID
Catálogo
1
Producto
1..
1 *
3 describe
1..*
1
Venta
1
Tienda
* capturada-en
3 Usado-por 1
*
3 almacena
1
1..*
fecha
hora
por
1
dirección
nombre
1
capturada-en
Atributos
1
Iniciada-por
1
1
P
pagada-p
1
R i t
contiene
1..*
1
Asociación
Cliente
24
cantidad
Pago Registro
1
Cajero
11
registra-ventas-en
25. Clasificación de clasesClasificación de clases
Tipos de clases:
De entidad (a.k.a. de modelo o de negocio). Son clases
i d l li ió Rque persisten durante la aplicación. Representan
información relevante para la aplicación.
De frontera (a.k.a. de contorno). Clases que crean la
interfaz que el usuario ve y con la que interaccionainterfaz que el usuario ve y con la que interacciona.
De control. Realizan una “unidad de trabajo”: crean oDe control. Realizan una unidad de trabajo : crean o
actualizan objetos de entidad, validan datos, etc.
25
26. Diagrama de clases de análisisDiagrama de clases de análisis
Caso de uso Procesar Venta
Cajero TPV GUI
«actor»«actor»«actor»
Registro
Venta
Busqueda
Elemento
Calculo
Precio
Calculador
Impuestos
Servicio
Autorización
Pagos
Sistema
Contabilidad
1..*
26
Venta Elemento
Venta
27. Método de Clase-Responsabilidad-
Clases/Responsabilidades/Colaboradores
Colaborador (CRC)
Clases/Responsabilidades/Colaboradores.
Facilitan la colaboración entre desarrolladores.Facilitan la colaboración entre desarrolladores.
Una ficha por cada clase relevante.
Se identifican sus responsabilidades.
División de responsabilidades, relaciones de
colaboración.
Jerarquías de generalización/especialización.
27
28. Método de Clase-Responsabilidad-
Colaborador (CRC)
Clase: PlanoDePlanta
Descripción:Descripción:
Responsabilidad ColaboradorResponsabilidad Colaborador
Define el nombre/tipo de plano de planta
Maneja la posición del plano de planta
Escala el plano de planta
Incorpora paredes, puertas y ventanas
M t l i ió d l á d íd
Pared
CMuestra la posición de las cámaras de vídeo Camara
28
29. Del Análisis al DiseñoDel Análisis al Diseño
El d l d áli i d ib l i t d dEl modelo de análisis describe el sistema desde
el punto de vista de los actores.
N ti i f ió d l t t i tNo contiene información de la estructura interna
del sistema, esto es del cómo.
Di ñ d l i tDiseño del sistema:
Objetivos de diseño que se deben optimizar (derivados
de los requisitos no funcionales)de los requisitos no funcionales).
Una arquitectura software: descomposición en
subsistemas, dependencias entre ellos, etc.
Diseño detallado (de objetos).
Refinamiento del diseño del sistema.
29
Diseño de las clases de la solución, interfaces.
30. Diseño Orientado a ObjetosDiseño Orientado a Objetos
Conceptos básicos de DOO:
Encapsulamiento.p
Ocultación de información.
HerenciaHerencia.
Interfaces.
P li fiPolimorfismo.
30
31. Diseño Orientado a Objetosj
Encapsulamiento
Desarrollador
Objetivo: crear clase con interfaz clara yj y
comprensible
Manera: ocultar detalles de implementaciónManera: ocultar detalles de implementación
Beneficios: cambio de estructuras/algoritmos
sin afectarsin afectar
Coste: clases reutilizables más caras a corto
plazoplazo
31
32. Diseño Orientado a Objetosj
Encapsulamiento
Usuario de las clases
Objetivo: usar la clase con el mínimo esfuerzoj
Manera: usar sólo las operaciones provistas
Beneficios: interfaz comprensible bajo coste deBeneficios: interfaz comprensible, bajo coste de
programación
Coste: pérdida de eficiencia de ejecuciónCoste: pérdida de eficiencia de ejecución
32
34. OODOOD
Módulos construidos alrededor de las
clases
Clases escasamente acopladas, sin datos
globalesglobales
Encapsulamiento y mensajes
Diagramas jerárquicos de clases
34
35. Definición de una claseDefinición de una clase
Identificar y nombrar la clase
Identificar sus componentesp
Identificar sus atributos
Identificar los erroresIdentificar los errores
Identificar las conexiones funcionales (qué
clases sirve/exige)clases sirve/exige)
Definir conexiones con superclase y subclases
Identificar propiedades especiales (persistencia,
concurrencia)
35Probar la clase en un prototipo
36. Identificar atributosIdentificar atributos
El conjunto de atributos de una clase debe
ser:
Completo (contienen toda la información
pertinente)pertinente)
General (se aplican a todos los objetos de la
clase)clase)
Diferenciado (cada atributo representa un
aspecto diferente de la clase)aspecto diferente de la clase)
36
37. Definir atributosDefinir atributos
Ti d t ib tTipos de atributos
Atómicos predefinidos (entero, real, carácter,
pixel...)
Atómico enumerativo (color, día de la
)semana...)
Colección
Composición (referencias objetos)
Valor del atributo
Común a muchos objetos (variable de clase)
Propio de un objeto (variable de objeto)
37
op o de u objeto ( a ab e de objeto)
38. Identificar MétodosIdentificar Métodos
Método: algoritmo que utiliza y modifica los
atributos de una clase
Un método es desencadenado por un mensaje
Funcionalidad de la clase: conjunto de susFuncionalidad de la clase: conjunto de sus
métodos
El conjunto de métodos debe ser:El conjunto de métodos debe ser:
Completo (realizan toda la funcionalidad de la clase)
General (se aplican a todos los objetos de la clase)General (se aplican a todos los objetos de la clase)
Diferenciado (cada método debe ser simple y realizar
una sola función)
38
una sola función)
39. Definir MétodosDefinir Métodos
Ti d ét dTipos de métodos
Modificador (asigna valor a un atributo)
Selector (devuelve el valor de un atributo)
Aplicable a la clase (constructor)p ( )
Aplicable al objeto
Parámetros del métodoParámetros del método
¿Qué información necesita? (argumentos de
entrada)entrada)
¿Qué debe devolver? (resultado y argumentos
de salida)
39
de sa da)
40. EjemploEjemplo
C tid d E t
ElementoVenta
Descripcion: Text
EspecificacionProducto
1
descrito-por
*
...
getSubTotal()
Cantidad: Entero
1..*
Descripcion: Text
Precio: Dinero
ID: IDElemento
1 *
Venta
contenido-en
1
captura Catalogo
5contiene1
1..*
Busca-en
1
1
catalogo
getEspecificacion(...)
Fecha: Date
hora: Time
completa: Logico
Venta
...
Registro
1
...
g
1
1
1 catalogo
finalizarVenta()
introducirElemento(...)
hacerNuevaCompra(...)
realizarPago(...)
Completar()
crearElementoVenta(..)
crearPago()
getTotal()
1
5usa
1
*
realizarPago(...)g ()
P
pagada-por
1
1
Dirección: Direccion
nombre: Texto
Tienda
1
40
anyadirVenta(...)
Cantidad: Dinero
Pago tiene 1
3Registra-completadas 1
41. Identificar ErroresIdentificar Errores
¿Qué puede salir mal durante la ejecución
de un método?
¿Qué comprobaciones debe hacer cada
método?método?
¿Cómo interceptar y corregir las
condiciones de error?
41
42. Patrones de DiseñoPatrones de Diseño
Catálogo de soluciones que han probado ser buenasCatálogo de soluciones que han probado ser buenas
para ciertos problemas comunes de diseño.
Evita “reinventar la rueda” continuamente.
R tili ió d b á ti ú tReutilización de buenas prácticas, común en otras
ingenierías.
Un patrón es una descripción del problema y la esencia
de su solución, que se puede reutilizar en casos
distintosdistintos.
Los estudiaremos en el Tema 8.
42
44. UMLUML
Unified Modeling Language
http://uml.org
Unified Modeling Language.
Combinar y estandarizar una notación para la descripciónCombinar y estandarizar una notación para la descripción
de sistemas orientados a objetos a partir de los lenguajes
de modelado más conocidos:
Booch OODBooch - OOD.
Rumbaugh - OMT.
Jacobson - OOSE y Objectory.
Combina las mejores propiedades de:
Conceptos de modelos de datos (ERD)Conceptos de modelos de datos (ERD)
Modelos de negocios (workflow)
Modelos de Objetos
Modelos de Componentes
44
Modelos de Componentes
45. UMLUML
Es un lenguaje gráfico para visualizar especificarEs un lenguaje gráfico para visualizar, especificar,
construir y documentar las partes de un sistema de
software desde distintos puntos de vista.
Ofrece una forma estándar de modelar sistemas
software pudiendo utilizarse:software, pudiendo utilizarse:
Con cualquier proceso de desarrollo.
A lo largo de todo el ciclo de vida.
C di ti t t l í d i l t ióCon distintas tecnologías de implementación
Puede usarse también en otras áreas, como la,
ingeniería de negocio, modelado de procesos, etc.
45
46. UML
No es un método ni un proceso ni una metodología
UML
No es un método, ni un proceso ni una metodología.
No establece qué modelos construir.No establece qué modelos construir.
Para un óptimo aprovechamiento, debe ser usado en un
proceso:
guiado por casos de usoguiado por casos de uso,
centrado en la arquitectura,
iterativo e
46
incremental.
47. UMLUML
UML es una familia de notaciones, útiles
para describir distintos aspectos de unp p
sistema:
Estático Describe los elementos del sistema yEstático. Describe los elementos del sistema y
sus relaciones.
Dinámico Describe el comportamiento delDinámico. Describe el comportamiento del
sistema a lo largo del tiempo.
Casos de Uso Desde el punto de vista del usuarioCasos de Uso. Desde el punto de vista del usuario.
47
49. Vistas
Vi t d C d U
Vistas
Vista de Casos de Uso
Funcionalidad externa del sistema
Vi t Ló iVista Lógica
Estructura estática y conducta dinámica del sistema
Vi t d C tVista de Componentes
Organización de las componentes
Vi t d C iVista de Concurrencia
Comunicaciones y sincronización
Vi t d D liVista de Despliegue
Arquitectura física
49
50. Vista de Casos de UsoVista de Casos de Uso
Dirigida al Análisis de Requisitos (lo que quiere hacer elg q ( q q
usuario)
Describe la funcionalidad del sistema, como la perciben
los actores externoslos actores externos
Dirige el desarrollo de las otras vistas
Define los objetivos finales del sistema
Permite validar el sistema
Actor externo:
UsuarioUsuario
Otro sistema
Se plasma en diagramasp g
de Casos de Uso
de Actividad
de Secuencia
50
de Secuencia
51. Vista de Casos de UsoVista de Casos de Uso
TPVTPV
Procesar
Venta
caje o
Servicio
cajero
Procesar
Devoluciones
de Autorización
de Pagos
«actor»
Calculador de
Impuestos
Analizar
Actividad
«actor»
Analizador de
Actividad de pImpuestos
«actor»
Gestionar
Ventas
...
Sistema de
contabilidad
Gestionar
Seguridad
Gestionar
51
Administrador
del sistema
Gestionar
Usuarios
52. Vista LógicaVista Lógica
Describe la funcionalidad interna
Dirigida a diseñadores y desarrolladoresDirigida a diseñadores y desarrolladores
Define la estructura estática
Clases, objetos y relaciones
Define las colaboraciones dinámicasDefine las colaboraciones dinámicas
Mensajes y funciones
P i d d di i lPropiedades adicionales
Persistencia y concurrencia
52Interfaces y estructura interna de las clases
53. Vista LógicaVista Lógica
Se plasma en diagramas
Estáticos
de Clases
de Objetosj
Dinámicos
de Estadode Estado
de Secuencia
de Colaboraciónde Colaboración
de Actividad
53
57. Vista Lógicag
Diagrama de Colaboración (comunicación)
realizarPago(cantidad)
:Registro :Venta
realizarPago(cantidad) 1: realizarPago(cantidad)
1.1: crear(cantidad)
:Pago
57
58. Vista Lógicag
Diagrama de Actividad
Put Coffee
in Filter
Turn on
Put Filter
in Machine
Find
Add Water
to Reservoir
Machine
Brew
[found
coffee] / coffeePot.turnOn
Beverage
Get
Cups
coffee
[no coffee] light goes out
Get cans
of cola
Pour
Coffee
[found cola]
of cola
Drink
[no cola]
58
[no cola]
59. Vista de ComponentesVista de Componentes
Describe los módulos del sistema y sus
dependencias.p
Modelar la arquitectura software.
Di i id d ll dDirigida a desarrolladores.
Se plasma en diagramas.Se p as a e d ag a as
de Componentes
59
61. Vista de ConcurrenciaVista de Concurrencia
Describe la división del sistema en procesos y
procesadores
Dirigida a desarrolladores e integradores
Resuelve problemas deResuelve problemas de
uso eficiente de los recursos
ejecución en paralelo (hilos)ejecución en paralelo (hilos)
comunicación y sincronización de hilos
Se plasma en diagramasSe plasma en diagramas
dinámicos
de Componentes
61
de Componentes
de Despliegue
63. Vista de Despliegue
M t l di t ib ió fí i d l i t
Vista de Despliegue
Muestra la distribución física del sistema
(ordenadores, dispositivos) y sus
conexiones
Dirigida a desarrolladores, integradores yg , g y
probadores
Se plasma enSe plasma en
el diagrama de Despliegue
el mapa de asignación de componentes a lael mapa de asignación de componentes a la
arquitectura física
63
66. Tipos de DiagramasTipos de Diagramas
Análisis Diseño
D. Casos de Uso. D. Clases y Objetos.
D. Secuencia del Sistema.
D Clases Conceptuales
D. Colaboración.
D SecuenciaD. Clases Conceptuales.
D. Clases Análisis.
D. Secuencia.
D. Estados.
66
68. MetodologíasMetodologías
Una notación no es suficiente.
¿Cómo se organiza el proyecto? (MCV)¿Cómo se organiza el proyecto? (MCV)
¿Qué documentación se genera?
¿Qué técnicas se utilizan en cada fase?
¿Quién las realiza?¿Quién las realiza?
¿Herramientas de soporte?
68
69. MetodologíasMetodologías
Booch (OOAD) Jacobson (OOSE)( )
CASEIode (CCM)
Coad-Yourdon-
Ni l (OOA OOD)
Olivetti (OGROUP)
Martin-Odell
(OOIE)Nicola (OOA,OOD)
NE University
(Demeter)
(OOIE)
TASKON
(OORAM)(Demeter)
Object Engin.
(Fresco)
( )
Winter (OSMOSYS)
Rumbaugh (OMT)
Hewlett-Packard
(Fusion)
Graham (SOMA)
LBMS (SE/OT)
Shlaer/Mellor
(OOSA)Graham (SOMA)
Texas Instruments
(IEO)
(OOSA)
CCTA (SSADM)
Wirfs-Brock (RDD)
69
ICL (MTD)
ParcPlace (OBA)
W s oc ( )
Lloyds Register
(Z++)
70. Rational Unified Process (RUP)Rational Unified Process (RUP)
Es un proceso iterativo e incremental.p
Dirigido por los casos de uso.
Centrado en la arquitecturaCentrado en la arquitectura.
Fases:
Comienzo Definir el alcance del proyectoComienzo. Definir el alcance del proyecto.
Elaboración. Plan de proyecto, especificar características,
esbozar la arquitectura.
Construcción. Construir el producto.
Transición. Entrega a los usuarios.
70
Comienzo Elaboración Construcción Transición
tiempo
71. Rational Unified Process (RUP)( )
Hitos e Iteraciones
Comienzo Elaboración Construcción Transición
Visión Esbozo
de arqu.
funcionalidad
inicial
Release
del producto
Comienzo Elaboración Construcción Transición
… … … …
Iteraciones
preliminares
Iteraciones de
arquitectura
Iteraciones de
desarrollo
Iteraciones de
transición
71ReleaseRelease Release Release Rel. Release Release Release ReleaseRel.
73. Rational Unified Process (RUP)
workflows y modelos
Requisitos
Modelo de
Casos de
Uso
Uso de diagramas UML
Análisis
Modelo de
Análisis
Diseño
Modelo
de
Diseño
Modelo de
Despliegue
Implementación
Diseño
g
Modelo de
I l t ió
Implementación Implementación
Modelo de
73
Prueba
Modelo de
Pruebas
74. Modelo de Casos de UsoModelo de Casos de Uso
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Diagramas de
Objetos
Diagramas de
Paquetes
Modelo de
Análisis
Modelo
Diagramas de
Componentes
Di dModelo
De Diseño
Modelo de
D li
Diagramas de
Despliegue
Diagramas de
Despliegue
Modelo de
Implementación
g
Secuencia
Diagramas de
ColaboraciónImplementación
Modelo de
Pruebas
Colaboración
Diagramas de
Estado
74Diagramas de
Actividad
75. Modelo de AnálisisModelo de Análisis
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Diagramas de
Objetos
Diagramas de
Paquetes
Modelo de
Análisis
Modelo
Diagramas de
Componentes
Di dModelo
De Diseño
Modelo de
D li
Diagramas de
Despliegue
Diagramas de
Despliegue
Modelo de
Implementación
g
Secuencia
Diagramas de
ColaboraciónImplementación
Modelo de
Pruebas
Colaboración
Diagramas de
Estado
75Diagramas de
Actividad
76. Modelo de DiseñoModelo de Diseño
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Diagramas de
Objetos
Diagramas de
Paquetes
Modelo de
Análisis
Modelo
Diagramas de
Componentes
Di dModelo
De Diseño
Modelo de
D li
Diagramas de
Despliegue
Diagramas de
Despliegue
Modelo de
Implementación
g
Secuencia
Diagramas de
ColaboraciónImplementación
Modelo de
Pruebas
Colaboración
Diagramas de
Estado
76Diagramas de
Actividad
77. Modelo de DespliegueModelo de Despliegue
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Diagramas de
Objetos
Diagramas de
Paquetes
Modelo de
Análisis
Modelo
Diagramas de
Componentes
Di dModelo
De Diseño
Modelo de
D li
Diagramas de
Despliegue
Diagramas de
Despliegue
Modelo de
Implementación
g
Secuencia
Diagramas de
ColaboraciónImplementación
Modelo de
Pruebas
Colaboración
Diagramas de
Estado
77Diagramas de
Actividad
78. Modelo de ImplementaciónModelo de Implementación
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Diagramas de
Objetos
Diagramas de
Paquetes
Modelo de
Análisis
Modelo
Diagramas de
Componentes
Di dModelo
De Diseño
Modelo de
D li
Diagramas de
Despliegue
Diagramas de
Despliegue
Modelo de
Implementación
g
Secuencia
Diagramas de
ColaboraciónImplementación
Modelo de
Pruebas
Colaboración
Diagramas de
Estado
78Diagramas de
Actividad
79. Proceso dirigido por casos de usoProceso dirigido por casos de uso
workflows
Requisitos Análisis Diseño Implementación Prueba
Los casos de uso dirigen y relacionan estos workflows
Los casos de uso dirigen las iteraciones:
Creación y validación de la arquitectura.
Definición de los casos y procedimientos de prueba.
Planificación de las iteraciones.
Creación de la documentación de usuario.
Entrega del sistema
79
Entrega del sistema
Sincronización del contenido de los distintos modelos
80. Proceso centrado en la arquitecturaProceso centrado en la arquitectura
Los modelos son el medio para visualizar,Los modelos son el medio para visualizar,
especificar, construir, generar y documentar la
arquitectura del sistema.
RUP prescribe el refinamiento sucesivo de la
arquitecturaarquitectura.
C i El b ió C t ió T i ióComienzo Elaboración Construcción Transición
tiempo
Arquitectura
80
81. BibliografíaBibliografía
“A l i UML d P tt 2 d Editi ” C i“Applying UML and Patterns. 2nd Edition ”. Craig
Larman, Prentice Hall, 2002.
“A l i UML i th U ifi d P ” I“Applying UML in the Unified Process”. Ivar
Jacobson, Rational Software.
“I i í d l S ft U f á ti 6ª“Ingeniería del Software. Un enfoque práctico 6ª
Edición”. R.S. Pressman, McGraw Hill. 2005.
“I i í d l S ft O i t d Obj t ”“Ingeniería del Software Orientado a Objetos”,
Bruegge, Dutoit, Prentice Hall. 2002.
“A áli i Di ñ O i t d Obj t UML“Análisis y Diseño Orientado a Objetos con UML
y el Proceso Unificado”. Schach. McGraw Hill.
2005
81
2005.