Este documento presenta los conceptos fundamentales del diseño de objetos. Explica que el diseño de objetos determina cómo la aplicación interactuará con los usuarios de acuerdo con los casos de uso definidos. También describe las herramientas como diagramas de clases, diagramas de interacción y diagramas de estados que se utilizan en el diseño de objetos. Finalmente, introduce el patrón de diseño de estados que separa la implementación de los comportamientos de un objeto según su estado.
Este documento describe las herramientas CASE (Computer-Aided Software Engineering), que son herramientas que ayudan al ingeniero de software a desarrollar y mantener software de manera más eficiente. Explica los componentes clave de las herramientas CASE, como el repositorio integrado y la interfaz de usuario, y cómo han evolucionado a través de los años para incluir funciones como generación automática de código. También incluye ejemplos de componentes comunes de herramientas CASE como editores, diccionarios de datos y herramientas de verificación
El documento describe los conceptos clave del modelo de análisis, incluyendo documentos de visión, asociaciones, diagramas de casos de uso, clases de análisis como interfaz, control y entidad, realizaciones de casos de uso y diagramas de interacción como secuencia y colaboración. Explica cómo estos elementos se usan para modelar y comprender los requisitos del sistema.
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.
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.
Este documento presenta una introducción al Unified Process (UP) y al Lenguaje Unificado de Modelado (UML). Explica brevemente el origen y desarrollo de UP y UML, sus características principales, y los diferentes tipos de diagramas que provee UML para modelar sistemas orientados a objetos.
El documento presenta una introducción a los patrones de diseño, describiendo que su objetivo es promover la reutilización mediante la solución de problemas comunes de software de manera probada. Explica que existen diferentes tipos de patrones clasificados según su propósito, ámbito y elementos. Finalmente, brinda recomendaciones sobre cómo seleccionar y aplicar los patrones de diseño en los proyectos de software.
Este documento describe los conceptos básicos de la metodología orientada a objetos y el lenguaje unificado de modelado (UML). Explica que la orientación a objetos une datos y procesos en objetos, y describe conceptos como clases, atributos, métodos, herencia y polimorfismo. También introduce UML como un lenguaje estándar para modelar sistemas de software que puede usarse en todas las fases del desarrollo.
El documento describe el modelo conceptual de una base de datos utilizando el modelo entidad-relación (E/R). El modelo E/R representa los datos como entidades y relaciones entre entidades, y fue desarrollado originalmente por Peter Chen en 1976-1977. El documento explica los elementos clave del modelo E/R, incluyendo entidades, atributos, relaciones, cardinalidades y cómo representarlos gráficamente.
Este documento describe las herramientas CASE (Computer-Aided Software Engineering), que son herramientas que ayudan al ingeniero de software a desarrollar y mantener software de manera más eficiente. Explica los componentes clave de las herramientas CASE, como el repositorio integrado y la interfaz de usuario, y cómo han evolucionado a través de los años para incluir funciones como generación automática de código. También incluye ejemplos de componentes comunes de herramientas CASE como editores, diccionarios de datos y herramientas de verificación
El documento describe los conceptos clave del modelo de análisis, incluyendo documentos de visión, asociaciones, diagramas de casos de uso, clases de análisis como interfaz, control y entidad, realizaciones de casos de uso y diagramas de interacción como secuencia y colaboración. Explica cómo estos elementos se usan para modelar y comprender los requisitos del sistema.
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.
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.
Este documento presenta una introducción al Unified Process (UP) y al Lenguaje Unificado de Modelado (UML). Explica brevemente el origen y desarrollo de UP y UML, sus características principales, y los diferentes tipos de diagramas que provee UML para modelar sistemas orientados a objetos.
El documento presenta una introducción a los patrones de diseño, describiendo que su objetivo es promover la reutilización mediante la solución de problemas comunes de software de manera probada. Explica que existen diferentes tipos de patrones clasificados según su propósito, ámbito y elementos. Finalmente, brinda recomendaciones sobre cómo seleccionar y aplicar los patrones de diseño en los proyectos de software.
Este documento describe los conceptos básicos de la metodología orientada a objetos y el lenguaje unificado de modelado (UML). Explica que la orientación a objetos une datos y procesos en objetos, y describe conceptos como clases, atributos, métodos, herencia y polimorfismo. También introduce UML como un lenguaje estándar para modelar sistemas de software que puede usarse en todas las fases del desarrollo.
El documento describe el modelo conceptual de una base de datos utilizando el modelo entidad-relación (E/R). El modelo E/R representa los datos como entidades y relaciones entre entidades, y fue desarrollado originalmente por Peter Chen en 1976-1977. El documento explica los elementos clave del modelo E/R, incluyendo entidades, atributos, relaciones, cardinalidades y cómo representarlos gráficamente.
Este documento provee una introducción a los patrones de diseño. Explica que los patrones de diseño son soluciones estándar a problemas comunes de programación que ayudan a flexibilizar el código. Cubre las categorías principales de patrones creacionales, estructurales y de comportamiento, así como ejemplos de cada categoría. También discute las ventajas de los patrones de diseño como la promoción de la reutilización y la facilitación de la documentación.
Analisis y Diseño de Sistemas II Orientado a objetosGloria Gonzales
El documento describe el lenguaje de modelado UML (Unified Modeling Language). UML es un lenguaje estándar para visualizar, especificar, construir y documentar los componentes de sistemas de software. Proporciona elementos, relaciones y diagramas para modelar la estructura y el comportamiento de sistemas. Algunos diagramas de UML incluyen diagramas de clases, casos de uso, secuencia y componentes.
Este documento presenta información sobre análisis orientado a objetos y UML. En la primera sección, se define el análisis orientado a objetos y se describen los elementos que debe contener un documento de análisis orientado a objetos, como documentos de análisis, especificación de requisitos, diagramas de casos de uso, escenarios y prototipos. La segunda sección explica los objetivos de la ingeniería de software, las ventajas del análisis orientado a objetos, la evolución de la metodología orientada a objetos y
Este documento presenta el tema del análisis en la ingeniería de software. Explica qué es el análisis, el análisis orientado a objetos y los artefactos de análisis. También describe las actividades del análisis orientado a objetos como la identificación de paquetes, clases y requisitos especiales. Finalmente, cubre los roles de los trabajadores en el análisis como el arquitecto y el ingeniero de casos de uso.
El documento describe diferentes enfoques para el modelado del análisis de requisitos en ingeniería de software, incluyendo el análisis estructurado, orientado a objetos, de dominio, basado en escenarios, orientado a flujos, basado en clases y el modelo de clase-responsabilidad-colaborador. El objetivo del modelado de análisis es describir los requisitos del cliente, establecer una base para el diseño de software y definir requisitos que puedan validarse una vez construido el software.
UML es un lenguaje gráfico estandarizado para modelar sistemas de software. Se compone de elementos, relaciones y diagramas. Los elementos incluyen clases, casos de uso y máquinas de estado. Las relaciones describen cómo se conectan los elementos. Los diagramas como el diagrama de clases y el diagrama de estados representan gráficamente los modelos. UML permite modelar tanto aspectos estructurales como de comportamiento de los sistemas de software.
El documento compara el modelo de casos de uso y el modelo de análisis. Explica que el modelo de casos de uso se describe desde la perspectiva del cliente y se estructura por casos de uso, mientras que el modelo de análisis se describe desde la perspectiva del desarrollador y se estructura por clases y paquetes. También describe los principales artefactos del modelo de análisis como las clases de análisis, las realizaciones de casos de uso y los diagramas de interacción y clases de análisis.
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.
El documento describe los conceptos clave de la Vista Lógica en el análisis y diseño orientado a objetos con UML, incluyendo clases, atributos, operaciones, relaciones, agregación, herencia y diagramas de clases. Explica cómo modelar el sistema mediante la identificación de clases y especificación de sus características y cómo representar la interacción entre clases a través de diferentes tipos de relaciones.
Introducción a los Patrones de diseño de softwareYazmin RuBo
Este documento introduce los conceptos básicos de la reutilización de software y los patrones de diseño. Explica que la reutilización reduce costos y mejora la calidad al permitir el uso repetido de artefactos de software. También cubre los pros y contras de la reutilización, así como su evolución entre los siglos XX y XXI. Finalmente, presenta el caso de una cafetería que mejora su sistema de pedidos aplicando el patrón Decorator para agregar condimentos adicionales a las bebidas.
El documento discute diferentes técnicas de modelado de requerimientos como diagramas de flujo de datos, diagramas de estado, y modelos orientados al comportamiento. También cubre el análisis de requerimientos para aplicaciones web, señalando que depende del tamaño y complejidad del proyecto la cantidad de análisis necesario. Los modelos comunes para aplicaciones web incluyen modelos de contenido, interacción, funcionalidad, navegación y configuración.
El documento describe diferentes técnicas para modelar requerimientos, incluyendo modelos basados en escenarios, casos de uso, diagramas de actividades, clases y atributos. Explica que el objetivo del modelado de requerimientos es describir lo que necesita el cliente y definir requerimientos validables. Los modelos de escenarios ilustran los requerimientos desde la perspectiva del usuario, mientras que los modelos de clases representan los objetos, operaciones y relaciones del sistema.
Patrones de diseño - Daniel E. Jaramillo2008PA2Info3
El documento describe los patrones de diseño, sus tipos y elementos. Explica que un patrón es una solución efectiva y reusable a un problema de diseño recurrente. Los patrones capturan experiencia para hacerla accesible, ayudan a comprender sistemas y facilitan la reutilización. Se describen patrones de creación, estructurales y de comportamiento como el Abstract Factory, Observer y otros.
Este documento proporciona una introducción al modelado visual y al lenguaje UML. Explica que el modelado visual y UML son ampliamente utilizados por empresas líderes para mejorar la comunicación, reducir riesgos y costos, y aumentar la calidad. Describe los principales diagramas de UML como casos de uso, clases, secuencias, estados y componentes y cómo se usan para modelar diferentes aspectos de un sistema. Finalmente, concluye que UML es un estándar reconocido para el modelado de sistemas de software.
Este documento presenta una crítica al uso de colaboraciones parametrizadas de UML para especificar patrones de diseño, debido a que UML no es suficientemente expresivo. Propone el uso de perfiles UML como una solución, ya que permiten extender UML para modelar dominios específicos como los patrones. Revisa trabajos previos sobre el tema y concluye que los perfiles UML pueden ser útiles para definir, documentar y visualizar patrones de diseño.
El documento presenta los contenidos de la unidad 3 de diseño orientado a objetos, incluyendo casos de uso, diagramas de interacción y secuencia, patrones de diseño como creacionales, estructurales y de comportamiento, y patrones GRASP. También describe ejemplos de diagramas de colaboración para los casos de uso de un video club utilizando los patrones discutidos.
Contenido:
1- Casos de Uso
2- Modelado de Dominio
3- Diagrama de Clases
4- Diagrama de Actividades
5- Diagrama de Estados
6- Diagrama e Despliegue
7- Diagrama de Secuencia
Este documento presenta una introducción al modelado de software orientado a objetos usando UML. Explica brevemente los conceptos clave de UML como diagramas, clases, relaciones, comportamientos y componentes. También describe el proceso de desarrollo de software basado en UML.
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Juan Pablo Bustos Thames
El documento describe diferentes tipos de visibilidad entre objetos en diseño orientado a objetos. Estos incluyen visibilidad de atributos, visibilidad de parámetros, visibilidad declarada localmente y visibilidad global. También describe una arquitectura común de tres capas para sistemas de información que incluye una capa de presentación, una capa de lógica de aplicaciones y una capa de almacenamiento.
Sesion 6 2 diseño análisis arquitecturalJulio Pari
El documento describe el análisis arquitectural y el proceso de particionamiento. El análisis arquitectural empareja los requisitos con una solución tecnológica óptima. El particionamiento divide el problema en unidades discretas para crear un sistema de software exitoso mediante el particionamiento de dominio y tecnológico. El objetivo del particionamiento es proporcionar una matriz de problemas únicos para la fase de diseño.
Este documento resume los fundamentos de la programación orientada a objetos. Explica conceptos clave como clases, objetos, abstracción, encapsulamiento, modularidad, herencia y polimorfismo. También describe las etapas del ciclo de vida del desarrollo de software como especificación de requisitos, análisis, diseño y programación, enfocándose en el enfoque orientado a objetos para cada una.
Este documento provee una introducción a los patrones de diseño. Explica que los patrones de diseño son soluciones estándar a problemas comunes de programación que ayudan a flexibilizar el código. Cubre las categorías principales de patrones creacionales, estructurales y de comportamiento, así como ejemplos de cada categoría. También discute las ventajas de los patrones de diseño como la promoción de la reutilización y la facilitación de la documentación.
Analisis y Diseño de Sistemas II Orientado a objetosGloria Gonzales
El documento describe el lenguaje de modelado UML (Unified Modeling Language). UML es un lenguaje estándar para visualizar, especificar, construir y documentar los componentes de sistemas de software. Proporciona elementos, relaciones y diagramas para modelar la estructura y el comportamiento de sistemas. Algunos diagramas de UML incluyen diagramas de clases, casos de uso, secuencia y componentes.
Este documento presenta información sobre análisis orientado a objetos y UML. En la primera sección, se define el análisis orientado a objetos y se describen los elementos que debe contener un documento de análisis orientado a objetos, como documentos de análisis, especificación de requisitos, diagramas de casos de uso, escenarios y prototipos. La segunda sección explica los objetivos de la ingeniería de software, las ventajas del análisis orientado a objetos, la evolución de la metodología orientada a objetos y
Este documento presenta el tema del análisis en la ingeniería de software. Explica qué es el análisis, el análisis orientado a objetos y los artefactos de análisis. También describe las actividades del análisis orientado a objetos como la identificación de paquetes, clases y requisitos especiales. Finalmente, cubre los roles de los trabajadores en el análisis como el arquitecto y el ingeniero de casos de uso.
El documento describe diferentes enfoques para el modelado del análisis de requisitos en ingeniería de software, incluyendo el análisis estructurado, orientado a objetos, de dominio, basado en escenarios, orientado a flujos, basado en clases y el modelo de clase-responsabilidad-colaborador. El objetivo del modelado de análisis es describir los requisitos del cliente, establecer una base para el diseño de software y definir requisitos que puedan validarse una vez construido el software.
UML es un lenguaje gráfico estandarizado para modelar sistemas de software. Se compone de elementos, relaciones y diagramas. Los elementos incluyen clases, casos de uso y máquinas de estado. Las relaciones describen cómo se conectan los elementos. Los diagramas como el diagrama de clases y el diagrama de estados representan gráficamente los modelos. UML permite modelar tanto aspectos estructurales como de comportamiento de los sistemas de software.
El documento compara el modelo de casos de uso y el modelo de análisis. Explica que el modelo de casos de uso se describe desde la perspectiva del cliente y se estructura por casos de uso, mientras que el modelo de análisis se describe desde la perspectiva del desarrollador y se estructura por clases y paquetes. También describe los principales artefactos del modelo de análisis como las clases de análisis, las realizaciones de casos de uso y los diagramas de interacción y clases de análisis.
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.
El documento describe los conceptos clave de la Vista Lógica en el análisis y diseño orientado a objetos con UML, incluyendo clases, atributos, operaciones, relaciones, agregación, herencia y diagramas de clases. Explica cómo modelar el sistema mediante la identificación de clases y especificación de sus características y cómo representar la interacción entre clases a través de diferentes tipos de relaciones.
Introducción a los Patrones de diseño de softwareYazmin RuBo
Este documento introduce los conceptos básicos de la reutilización de software y los patrones de diseño. Explica que la reutilización reduce costos y mejora la calidad al permitir el uso repetido de artefactos de software. También cubre los pros y contras de la reutilización, así como su evolución entre los siglos XX y XXI. Finalmente, presenta el caso de una cafetería que mejora su sistema de pedidos aplicando el patrón Decorator para agregar condimentos adicionales a las bebidas.
El documento discute diferentes técnicas de modelado de requerimientos como diagramas de flujo de datos, diagramas de estado, y modelos orientados al comportamiento. También cubre el análisis de requerimientos para aplicaciones web, señalando que depende del tamaño y complejidad del proyecto la cantidad de análisis necesario. Los modelos comunes para aplicaciones web incluyen modelos de contenido, interacción, funcionalidad, navegación y configuración.
El documento describe diferentes técnicas para modelar requerimientos, incluyendo modelos basados en escenarios, casos de uso, diagramas de actividades, clases y atributos. Explica que el objetivo del modelado de requerimientos es describir lo que necesita el cliente y definir requerimientos validables. Los modelos de escenarios ilustran los requerimientos desde la perspectiva del usuario, mientras que los modelos de clases representan los objetos, operaciones y relaciones del sistema.
Patrones de diseño - Daniel E. Jaramillo2008PA2Info3
El documento describe los patrones de diseño, sus tipos y elementos. Explica que un patrón es una solución efectiva y reusable a un problema de diseño recurrente. Los patrones capturan experiencia para hacerla accesible, ayudan a comprender sistemas y facilitan la reutilización. Se describen patrones de creación, estructurales y de comportamiento como el Abstract Factory, Observer y otros.
Este documento proporciona una introducción al modelado visual y al lenguaje UML. Explica que el modelado visual y UML son ampliamente utilizados por empresas líderes para mejorar la comunicación, reducir riesgos y costos, y aumentar la calidad. Describe los principales diagramas de UML como casos de uso, clases, secuencias, estados y componentes y cómo se usan para modelar diferentes aspectos de un sistema. Finalmente, concluye que UML es un estándar reconocido para el modelado de sistemas de software.
Este documento presenta una crítica al uso de colaboraciones parametrizadas de UML para especificar patrones de diseño, debido a que UML no es suficientemente expresivo. Propone el uso de perfiles UML como una solución, ya que permiten extender UML para modelar dominios específicos como los patrones. Revisa trabajos previos sobre el tema y concluye que los perfiles UML pueden ser útiles para definir, documentar y visualizar patrones de diseño.
El documento presenta los contenidos de la unidad 3 de diseño orientado a objetos, incluyendo casos de uso, diagramas de interacción y secuencia, patrones de diseño como creacionales, estructurales y de comportamiento, y patrones GRASP. También describe ejemplos de diagramas de colaboración para los casos de uso de un video club utilizando los patrones discutidos.
Contenido:
1- Casos de Uso
2- Modelado de Dominio
3- Diagrama de Clases
4- Diagrama de Actividades
5- Diagrama de Estados
6- Diagrama e Despliegue
7- Diagrama de Secuencia
Este documento presenta una introducción al modelado de software orientado a objetos usando UML. Explica brevemente los conceptos clave de UML como diagramas, clases, relaciones, comportamientos y componentes. También describe el proceso de desarrollo de software basado en UML.
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Juan Pablo Bustos Thames
El documento describe diferentes tipos de visibilidad entre objetos en diseño orientado a objetos. Estos incluyen visibilidad de atributos, visibilidad de parámetros, visibilidad declarada localmente y visibilidad global. También describe una arquitectura común de tres capas para sistemas de información que incluye una capa de presentación, una capa de lógica de aplicaciones y una capa de almacenamiento.
Sesion 6 2 diseño análisis arquitecturalJulio Pari
El documento describe el análisis arquitectural y el proceso de particionamiento. El análisis arquitectural empareja los requisitos con una solución tecnológica óptima. El particionamiento divide el problema en unidades discretas para crear un sistema de software exitoso mediante el particionamiento de dominio y tecnológico. El objetivo del particionamiento es proporcionar una matriz de problemas únicos para la fase de diseño.
Este documento resume los fundamentos de la programación orientada a objetos. Explica conceptos clave como clases, objetos, abstracción, encapsulamiento, modularidad, herencia y polimorfismo. También describe las etapas del ciclo de vida del desarrollo de software como especificación de requisitos, análisis, diseño y programación, enfocándose en el enfoque orientado a objetos para cada una.
Sesion 6 3 diseño particionamiento de dominioJulio Pari
Este documento describe el proceso de particionamiento del dominio. Explica que particionar el dominio implica dividir el dominio del problema en unidades cohesivas antes del diseño detallado. Describe cómo los modelos de casos de uso, objetos y dinámicos revelan información sobre el dominio que puede usarse para particionarlo. Luego, explica el proceso de particionar los casos de uso, objetos y dependencias entre particiones.
El documento compara diferentes tipos de modelos orientados a objetos como el modelo de objetos, modelo dinámico y modelo funcional. También compara metodologías como OOHDM, SOHDM, RUP y UML. Finalmente, incluye referencias electrónicas sobre estos temas.
El documento describe la transición entre el análisis y el diseño en el desarrollo de software. Explica que el análisis se centra en modelar el dominio del problema sin considerar la tecnología, mientras que el diseño añade una "capa" de funcionalidad tecnológica sobre los modelos de análisis. También destaca la importancia de comprender cómo los productos de trabajo evolucionan entre las fases para facilitar el proceso general de desarrollo.
Este documento describe los conceptos clave del diseño orientado a objetos. Explica que el diseño orientado a objetos transforma el modelo de análisis en un modelo de diseño que sirve como anteproyecto para la construcción de software. También describe los pasos clave del proceso de diseño orientado a objetos como la partición del modelo en subsistemas, la asignación de subsistemas a procesadores y tareas, y el diseño de objetos, mensajes y la interfaz de usuario.
UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO. Jaqueline Luna
investigación complementaria sobre los 13 diagramas UML, la metodología de desarrollo ágil de software y las actividades específicas de la etapa de análisis de sistemas
Este documento presenta los fundamentos de la programación orientada a objetos. Explica conceptos clave como clases, objetos, abstracción, encapsulamiento, jerarquía y herencia. También describe las etapas del ciclo de vida del desarrollo de software como especificación de requisitos, análisis, diseño y programación. Resalta cómo la POO permite manejar mejor la complejidad del software a través de la modularidad y agrupación de elementos en clases y objetos.
Este documento presenta el temario de la asignatura de Ingeniería de Software II de la carrera de Ingeniería en Sistemas de la Facultad de Sistemas Mercantiles. Incluye videos tutoriales, cuestionarios, casos de estudio y evaluaciones parciales sobre temas como diagramas de clases, herramientas CASE, análisis y diseño orientados a objetos.
El artículo discute el diseño de un sistema manejador de bases de datos orientado a objetos. Estos sistemas aprovechan la orientación a objetos para elaborar esquemas de bases de datos más robustos y completos que facilitan la construcción de software complejo. Actualmente existen estándares y herramientas que pueden ser utilizados para solucionar problemas como la persistencia de objetos y la comunicación cliente-servidor. El artículo se enfoca en diseñar e implementar un lenguaje de manipulación y definición de datos, y la transformación semántica entre
El documento describe el Proceso Unificado para el desarrollo de software. Este proceso es simple, basado en componentes de software interconectados a través de interfaces. Utiliza UML para los diagramas y es iterativo e incremental, dividiendo el proyecto en pequeñas iteraciones. Cada iteración identifica casos de uso clave y desarrolla la arquitectura correspondiente a través de distintas fases hasta entregar una versión del producto.
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiRaimonKoudsi
En esta presentacion se tratará de: FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS, asi como los FUNDAMENTOS BASICOS DEL DISEÑO ORIENTADO A OBJETOS
Iconix es una metodología iterativa e incremental para el desarrollo de software que utiliza UML. Ofrece trazabilidad entre los requisitos y los artefactos producidos. Se basa en el uso de casos de uso, diagramas de secuencia y prototipado para iterar entre el análisis, diseño e implementación. El proceso es simplificado en comparación con otros más tradicionales y se enfoca en la participación activa de los usuarios.
Este documento presenta el modelo de "4+1 vistas" para describir la arquitectura de sistemas de software. El modelo describe la arquitectura usando cinco vistas concurrentes: la vista lógica, la vista de procesos, la vista física, la vista de desarrollo y una quinta vista de casos de uso. Cada vista se enfoca en los intereses de diferentes partes interesadas y permite abordar requisitos funcionales y no funcionales por separado.
Este documento presenta el modelo de "4+1 vistas" para describir la arquitectura de sistemas de software. El modelo describe la arquitectura usando cinco vistas concurrentes: la vista lógica, la vista de procesos, la vista física, la vista de desarrollo y una quinta vista de casos de uso. Cada vista se enfoca en los intereses de diferentes partes interesadas y usa su propia notación. Juntas, las cinco vistas proveen una descripción completa de la arquitectura del sistema.
Introduccion a la programacion orientada a objetosFabian Dorado
Este documento presenta conceptos clave de la programación orientada a objetos. Explica que un objeto representa un concepto del mundo real y contiene datos y operaciones. También define clases, atributos, métodos, encapsulamiento y otros pilares de la POO. Resalta las ventajas de este paradigma como la reusabilidad, el modelado del mundo real y la facilidad de mantenimiento del software.
Los patrones de diseño brindan soluciones probadas a problemas comunes de desarrollo de software. Existen patrones de creación, estructurales y de comportamiento para diferentes tipos de problemas. Un patrón común es el patrón MVC que divide una aplicación en modelo, vista y controlador, donde el modelo contiene la lógica del dominio, la vista muestra la interfaz y el controlador gestiona las peticiones y actualizaciones.
El diseño de software es el proceso de visionado y definición de soluciones software a uno o más conjuntos de problemas. Uno de los componentes principales del diseño de software es el análisis de requisitos del software (ARS, del inglés SRA). Se trata de una parte del proceso de desarrollo de software que enumera especificaciones empleadas en ingeniería de software. Si el software está "semiautomatizado" o centrado en el usuario, el diseño de software puede implicar también el diseño de experiencia de usuario que utiliza un storyboard o guión gráfico para ayudar determinar esas especificaciones.
Este documento explica qué es UML y sus principales características. UML es un lenguaje visual para modelar sistemas que facilita la comunicación entre los involucrados en un proyecto. Incluye diagramas para modelar la estructura y dinámica de un sistema. Algunos diagramas comunes son de clases, casos de uso y secuencia.
Este documento presenta una introducción a UML, incluyendo sus objetivos, conceptos clave como diagramas y vistas, y su utilidad para modelar sistemas de software. Explica los diferentes tipos de diagramas UML como casos de uso, colaboración y máquinas de estado y cómo estas vistas permiten modelar diferentes aspectos de un sistema.
Similar a Sesion 13 diseño iii diseño de objetos (20)
Evento - Virtual Lab Despliegue de aplicaciones en Kubernetes #Ibm virtual la...Julio Pari
Este documento introduce los conceptos de contenedores y Kubernetes. Explica que los contenedores aíslan los procesos en lugar de máquinas virtuales completas, lo que hace que sean más livianos y portables. Luego describe cómo Kubernetes organiza contenedores en clústeres y los orquesta a través de un master y nodos trabajadores para implementar aplicaciones de manera escalable. Finalmente, proporciona contactos de especialistas de IBM para obtener más información.
Links kubernetes - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
Este documento anuncia dos talleres virtuales gratuitos sobre despliegue de aplicaciones en Kubernetes y envío de mensajes con Event Streams en IBM Cloud. Los talleres se llevarán a cabo el 28 de julio y el 11 de agosto respectivamente. Los interesados pueden registrarse en un enlace proporcionado para aprender a crear servicios utilizando tecnologías de código abierto en la nube de IBM.
Comandos - Evento - Virtual Lab Despliegue de aplicaciones en KubernetesJulio Pari
This document provides instructions for completing a lab tutorial on getting started with IBM Cloud container services. It includes steps to check version numbers for required tools, clone a GitHub repository, log in to IBM Cloud, build and push a Docker image, configure a Kubernetes cluster, deploy a sample application, and expose it via a service. The lab is split into two parts - the first focuses on building and pushing a container image, while the second covers deploying it on Kubernetes and making the application accessible.
Este documento presenta la estructura propuesta para un trabajo de tesis o proyecto profesional. Detalla los diferentes capítulos que debería contener el documento, como la introducción, marco teórico, objeto de estudio, y capítulos para la propuesta de solución, modelo de negocio, requerimientos, arquitectura y construcción del sistema, calidad y pruebas, y gestión del proyecto. El documento provee una guía general para la organización y contenido de cada capítulo con el fin de abordar un tema de investig
El documento describe la arquitectura tecnológica actual y recomendada para el sitio web de la Facultad de Ingeniería de Sistemas e Informática de la UNMSM. Actualmente se hospeda en un servidor dedicado con CentOS y Joomla, pero se recomienda migrar a una plataforma en la nube Jelastic que ofrece escalabilidad automática, balanceo de carga y alta disponibilidad con Liferay.
Jelastic provides a private cloud platform-as-a-service (PaaS) that allows developers to rapidly deploy scalable applications to the cloud without code changes. It delivers a fully managed private cloud infrastructure with automated scaling, high availability, and comprehensive management tools. Jelastic's per-server subscription model offers significant savings over traditional virtualization solutions or cloud building blocks.
El documento presenta la arquitectura de un sistema de ingeniería de software, incluyendo su nombre, objetivo, diagrama de contexto, diagrama de arquitectura general y las tecnologías a utilizar.
Solucion Examen Parcial Sistemas Digitales UNMSM FISIJulio Pari
El documento presenta las soluciones a un examen parcial de Sistemas Digitales impartido en la UNMSM, Facultad de Física, en julio. Contiene las respuestas a 8 preguntas del examen.
Práctica de Inventarios - Investigación Operativa IIJulio Pari
Este documento presenta una discusión sobre la teoría de inventarios a través de 30 páginas. Aborda temas como los modelos de inventarios, los costos asociados con el mantenimiento de inventarios y la toma de decisiones sobre los niveles óptimos de inventario.
Armas silenciosas para guerras tranquilasJulio Pari
Este documento resume la historia y el desarrollo de las "armas silenciosas" para la "guerra tranquila". En 1954, los poderosos decidieron llevar a cabo una guerra silenciosa contra el público estadounidense utilizando nuevas tecnologías como las computadoras para controlar y manipular la sociedad de manera predecible y mantener el poder en manos de unos pocos. El documento introduce las armas silenciosas como una nueva forma de control social a través de la manipulación de datos e información en lugar de armas convenc
Este documento describe el Lenguaje Unificado de Modelado (UML) y sus diagramas. UML es un lenguaje gráfico para modelar sistemas de software desarrollado inicialmente por Grady Booch, Ivar Jacobson y James Rumbaugh. El documento explica los diagramas de clases, casos de uso, estados, secuencias, actividades y la historia del desarrollo de UML. También incluye ejemplos de cómo generar código Java a partir de diagramas UML usando NetBeans.
Formato de presentación de Proyecto UNMSM FISIJulio Pari
El documento presenta un proyecto realizado por 5 estudiantes de la Facultad de Ingeniería de Sistemas e Informática de la Universidad Nacional Mayor de San Marcos en Lima, Perú, e incluye los nombres, códigos y correos electrónicos de los integrantes, así como el nombre del curso, profesor y fecha.
Este cuento habla sobre una familia que vive en una casa en el bosque. La familia está formada por los padres y sus dos hijos, un niño y una niña. Los niños disfrutan jugando en el bosque mientras sus padres los cuidan desde la casa.
Este documento describe los pasos para crear y consultar una base de datos MySQL. Inicialmente se crea la base de datos y las tablas ejecutando un script SQL. Luego se muestran diferentes consultas como listar las bases de datos existentes, listar las tablas de una base y consultar el contenido de una tabla. Finalmente se explica el uso de archivos comunes como una hoja de estilos y una librería para realizar las conexiones a la base de datos.
El documento describe los pasos para instalar MySQL, phpMyAdmin y configurar la conexión entre PHP y MySQL. Explica cómo instalar MySQL, crear bases de datos y tablas, y ejecutar consultas SQL. Luego, detalla la instalación de phpMyAdmin y su configuración. Finalmente, muestra cómo conectar PHP a MySQL mediante funciones como mysql_connect() y mysql_query(), y cómo manejar los resultados de las consultas.
Este documento describe las funciones de usuario en PHP. Explica la sintaxis básica para definir funciones, cómo pasar parámetros a funciones, devolver valores de funciones e incluir archivos. Las funciones se definen usando la palabra clave function, pueden aceptar parámetros y devolver valores. Los archivos pueden incluirse usando las instrucciones require e include.
2. Términos
Application logic: Software cuya principal
función es controlar las interacciones con el actor
manejando el comportamiento de la interface de
usuario.
Transaction logic: Unidad de trabajo
estandarizada, reusable que puede ser referida por
cualquier número de aplicaciones. Por ejemplo
una transacción de “deposito” puede ser accedida
vía una aplicación ATM, home banking u otra
aplicación de cajero..
CAL/Fundamentos 2
3. Introducción
Su aplicación (sistema) debería hacer lo que el
usuario espera que haga. El diseño de objetos
es la fase en la cual ud. decide como hace su
aplicación para que concuerde con estas
espectativas.
Se han definido estas espectativas en el inicio
del proyecto usando los casos de uso. Ud. ha
definido todos los recursos que el sistema
necesita manejar, durante el análisis del
problema usando el modelo de objetos y los
diagramas de interacción.
CAL/Fundamentos 3
4. Introducción
Durante el análisis arquitectural ud.
particionó el sistema en unidades
basadas en los casos de uso del
dominio del problema (particiones de
dominio) y la arquitectura mas
adecuada para soportar los objetivos
del sistema.
CAL/Fundamentos 4
5. Introducción
Ahora en la fase de diseño de objetos
se trabajará en cada partición para
definir los mecanismos de control
dentro del software y las interfaces
entre estas piezas de software.
CAL/Fundamentos 5
6. Herramientas – Diseño de O.
Ya hemos usado la mayoría de herramientas
del diseño de objetos:
El modelo de objetos
Los diagramas de interacción
Especificacion de CUS (Narrativa - escenarios)
Continuaremos usando estas herramientas.
Pero ahora añadiremos diferentes detalles a los
diagramas. Adicionalmente usaremos el
diagrama de estados para modelar el ciclo de
vida de los objetos y comportamientos
específicos al estado.
CAL/Fundamentos 6
7. Productos Trabajo Del Diseño
5
Modelo de
4 Objetos 6
escenario
s
1 3 7
2 Diagrama
Modelo de Especificacion
10 De Estados
casos de uso CUS
9
Diagrama de
11 Secuencia 8
Colaboración
CAL/Fundamentos 7
8. Productos Trabajo Del Diseño
1. El modelo de casos de uso identifica
la comunicación entre los actores y el
sistema. El díalogo es la base para los
diagramas de interacción. Los recursos
usados para soportar el diálogo vienen
a ser los objetos del modelo de objetos.
CAL/Fundamentos 8
9. Productos Trabajo Del Diseño
2. La descripción de los casos de uso
se pueden modelar usando la
especificación narrativa, modelo de
análisis y diagramas colaboración que
definan la lógica en la interacción entre
los actores y el sistema. La evaluación
de la lógica podría resultar en cambios
al alcance y definiciones de los casos
de uso.
CAL/Fundamentos 9
10. Productos Trabajo Del Diseño
3. La especificación narrativa de CUS
representan la lógica para un caso de uso o
una operación individual.
4. Siempre que una operación requiera lógica
significante,se puede emplear el diagrama de
actividad para ayudar en su diseño. Esto a su
vez puede resultar en el descubrimiento de
otras operaciones mas pequeñas y reusables
que puedan proporcionar soporte para las
mas grandes y complejas. (...)
CAL/Fundamentos 10
11. Productos Trabajo Del Diseño
(...) Cada operación también revela los
atributos que los objetos necesitan para
invocar la operación. Estos atributos
son agregados a la definición de la
clase para los objetos cuyo propósito
se acerca mas a los propósitos del
atributo.
CAL/Fundamentos 11
12. Productos Trabajo Del Diseño
5. Los diagramas de clase
proporcionan la definición de objetos.
Cada operación y cada atributo
descubierto por su uso en otros
diagramas son agregados al diagrama
de clase. El diagrama de clase es el
repositorio definitivo y la fuente de todo
para la generación de código.
CAL/Fundamentos 12
13. Productos Trabajo Del Diseño
6. El diagrama de estados identifica acciones y
actividades que se traducen en operaciones y
lógica de operaciones. Cada operación nueva
se agrega a la clase que define el objeto.
7. El diagrama de estados representa el ciclo de
vida de un objeto único. Cada evento que el
objeto puede responder es representado con un
cambio de estados y comportamientos. Los
comportamientos específicos de estado son
representados como acciones y actividades.
CAL/Fundamentos 13
14. Productos Trabajo Del Diseño
8. Los diagramas de interacción modelan los
eventos entre objetos y al hacer así
identifican las interfaces que los objetos
necesitan para recibir los eventos.
9. Los diagramas de interacción se pueden
usar para derivar los diagramas de estados al
identificar estados candidatos y los eventos
que causan las transiciones entre estados.
CAL/Fundamentos 14
15. Productos Trabajo Del Diseño
10. Las definiciones de clase proporcionan
los objetos que participan en los diagramas
de interacción. Las interfaces, descubiertas
en los diagramas de interacción, se traducen
en operaciones para las clases que definen a
los objetos participantes. Cada operación a
su vez identifica los atributos de la clase en la
forma de parametros de entrada
(argumentos) y valores de retorno.
CAL/Fundamentos 15
16. Productos Trabajo Del Diseño
11. Los escenarios individuales en una
especificación narrativa pueden formar
la base para la comunicación de
objetos en un diagrama de interacción.
Los diagramas de interacción
frecuentemente identifican intefaces
complejas que requieren mayor análisis
usando otros diagramas, entre ellos
diagramas de actividad.
CAL/Fundamentos 16
17. Diagramas de Interacción
Para beneficiarse de los diagramas,
necesitamos comprender la relación
entre los diagramas.
Los diagramas:
Presentan una descripción consisa de lo
que ud. conoce y decide acerca del
sistema
Representan diferentes vistas de sistema.
CAL/Fundamentos 17
18. Diagramas de Interacción
Juntos, sin embargo, los diferentes
diagramas representan un cuadro
completo de cómo está estructurado
el sistema y como trabajan los
objetos. Al comparar las diferentes
vistas, se pueden identificar
inconsistencias y mejorar el modelo
general.
CAL/Fundamentos 18
19. Diagrama De Estados
En muchos sistemas, existen al menos
unas pocas clases de objeto clave que
sufren cambios sustanciales durante su
tiempo de vida. Para estos objetos, un
único evento puede resultar en muchas
respuestas diferentes basadas en las
condiciones actuales del objeto. La
condición del objeto es referida como el
estado del objeto.
CAL/Fundamentos 19
20. Diagrama De Estados
Estado del objeto: El estado se define
por los valores de los atributos y las
relaciones del objeto. Por ejemplo,
cuando se abre una cuenta de crédito,
un intento de comprar un artículo
resultaría en una comparación del monto
comprado y el crédito disponible. Cuando
la cuenta de crédito es cerrada, un
intento de comprar artículos resultaría en
un error.
CAL/Fundamentos 20
21. Diagrama De Estados
Igualmente, una relación puede
provocar una respuesta diferente. Por
ejemplo, cuando en el sistema de
boletaje un AsientoPresentación no
está asociada con un NivelDePrecio, no
puede venderse. Una vez que se
establezca el enlace con el
NivelDePrecio, el AsientoPresentación
se puede vender.
CAL/Fundamentos 21
22. Diagrama De Estados
El diagrama de estados no se usará
para todas las clases del modelo. El
diagrama de estados es una
herramienta de propósito especial que
se emplea solo para objetos que
poseen substancial comportamiento de
estados específico. ¿cómo reconocer
esos objetos? ...
CAL/Fundamentos 22
23. Diagrama De Estados
Una técnica es revisar los diagramas
de interacción e identificar aquellos
objetos que participan en muchos, o
mas aún en todos, los escenarios.
Específicamente, busque aquellos
objetos que tengan mas flechas de
evento entrantes, pues cada evento
entrante tiene el potencial de cambiar el
estado actual del objeto.
CAL/Fundamentos 23
24. Diagrama De Estados
El objeto permanece en una condición o estado hasta que algo
le ocurra al objeto que active un cambio en el estado llamado
“transición”.
A B C
CAL/Fundamentos 24
25. Revisión D. Estados Notación
Revisar la notación del diagrama de estados en la
presentación:
UML – Diagrama de Estados.
En el siguiente ejemplo se ayuda a empezar la
construcción de un diagrama de estados usando
un diagrama de secuencia como fuente. Los
ejemplos son muy pequeños de modo que se
puede enfocar en los mecanismos mas que en la
complejidad del dominio del problema. Pero la
misma estrategia se puede emplear a medida que
la complejidad del dominio se incrementa.
CAL/Fundamentos 25
26. Revisión D. Estados Notación
Identifique los estados.
aGestionFacilidad aPresentación aAsientoPresentación
CrearPresentación
CrearAsientoPresentación El objeto no existe hasta
que el el evento lo crea. El
Hecho
objeto comienza en un
Hecho estado inicial: “sin precio,
no seleccionado, y no
vendido”
Caso de Uso: Planear Presentación
Escenario: Programar Presentación con éxito
CAL/Fundamentos 26
27. Revisión D. Estados Notación
Identifique los eventos que activan la
transición entre estados.
aGestionFacilidad aPresentación aAsientoPresentación
CrearPresentación
CrearAsientoPresentación
Transición eventos
Hecho
Hecho
Caso de Uso: Planear Presentación
Escenario: Programar Presentación con éxito
CAL/Fundamentos 27
28. Revisión D. Estados Notación
Dibuje el diagrama de estados
aGestionFacilidad aPresentación aAsientoPresentación
CrearPresentación
CrearAsientoPresentación
Hecho
Hecho
Sin precio
No separado
No vendido
Caso de Uso: Planear Presentación
Escenario: Programar Presentación con éxito
CAL/Fundamentos 28
29. Revisión D. Estados Notación
Mezcle el nuevo diagrama con el diagrama
previo para formar un único diagrama de
estados para el AsientoPresentación.
aGestionFacilidad aAsientoPresentación
Sin precio
Precio(NivelDePrecio) No separado
No vendido
Hecho
Precio(NivelDePrecio
Sin precio
No separado
Caso de Uso: Planear Presentación
No vendido
Escenario: Programar Presentación con éxito
CAL/Fundamentos 29
30. Construir Un D. De Estados
Ejercicio:
Ver documento Word.
Diseño III – Construir Diagrama de Estados
CAL/Fundamentos 30
31. Patron Diseño de Estado
Cuando un objeto exhibe un conjunto de
comportamientos específicos de estado, el
código puede ser muy grande, complejo y dificil
de seguir. Para cada comportamiento que el
objeto pueda manifestar, la implementación
puede ser diferente por cada estado del objeto.
Por ejemplo, un objeto relativamente simple con
seis estados y seis comportamientos podría
necesitar 36 bloques de código de
implementación – un bloque por cada
comportamiento para cada estado.
CAL/Fundamentos 31
33. Patron Diseño de Estado
Una técnica para para cubrir la
complejidad de comportamientos de
estados específico es el patrón diseño
de estados. Este patrón usa el
concepto de delegación para separar la
implementación de un comportamiento
del objeto que es responsable por el
comportamiento.
CAL/Fundamentos 33
34. Patron Diseño de Estado
Por ejemplo, muchos de nosotros somos
responsables de declarar impuestos. Sin
embargo, para algunos de nosotros, el
proceso es extremadamente complejo y
requiere asistencia de un experto.
Retenemos la responsabilidad final de
declarar impuestos, pero delegamos el
proceso a un especialista que lo hace
por nosotros.
CAL/Fundamentos 34
35. Patron Diseño de Estado
Cuando el especialista en impuestos termina
el nos entrega resultados. La delegación
también se puede aplicar a objetos, por
ejemplo, una póliza de seguros proporciona
interfaces para enviar reclamos y cancelar la
póliza. Pero la implementación de estas
interfaces depende del estado (condición) de
la póliza. En la siguiente imagen se muestran
los componentes del patrón diseño de
estados usado para delegar la
implementación de estas interfaces.
CAL/Fundamentos 35
37. Patron Diseño de Estado
Cuando los comportamientos de un objeto
difieren dependiendo de un estado de objeto,
ud. puede definir nuevos objetos que
represente el estado del objeto. Cada unico
tipo de estado de objeto tiene su propia
implementación para cada comportamiento.
Cuando el objeto necesita un comportamiento
este “delega” el comportamiento a un objeto
de estado apropiado. Una vez que el
comportamiento está completo, el objeto
estado regresa el control al objeto original.
CAL/Fundamentos 37
38. Patron Diseño de Estado
Veamos el ejemplo Java:
Void SubmitClaim(Claim)
{ state.SubmitClaim(Claim) }
Note como la operación simplemente
invoca otra operación del mismo nombre
sobre el objeto referido por el atributo
estado. La interface no tiene realmente
una implementación de su propiedad.
CAL/Fundamentos 38
39. Patron Diseño de Estado
Transformar el diagrama de estados en
el patron de estados: El diagrama de
estados proporciona una descripción
explícita de los estados de un objeto.
Para crear el patrón de estados en su
diagrama de clases vea los siguientes
cuadros y siga los pasos.
CAL/Fundamentos 39
40. Patron Diseño de Estado
El patrón de estados no es adecuado
para todas las aplicaciones de
comportamiento específico de estado.
Sin embargo, cuando uno encara un
numero grande de estados y una
variedad de comportamientos, el patrón
puede pagar buenos dividendos en
facilidad de mantenimiento y
comprensión.
CAL/Fundamentos 40
41. Patron Diseño de Estado
Crear un atributo sobre la clase
Base llamado estado o estatus o AsientoPresentación
estado
algo similar que convenga al
propósito.
CAL/Fundamentos 41
42. Patron Diseño de Estado
Sin precio No Disponible
No separado
No vendido
Para cada estado en el diagrama Precio(NivelPrecio)
de estados, crear su RemoverPrecio()
Con precio
No separado
correspondiente definición de No vendido
Disponible
clase. Cancel() Select()
con precio Reembolsar()
separado
Separado No vendido
AsientoPresentación
Compra(TipoPrecio)
estado
con precio
Vendido No separado
vendido
NoDisponible Disponible Separado Vendido
CAL/Fundamentos 42
43. Patron Diseño de Estado
Dibuje una relacion de
generalización desde cada objeto
estado hacia la única superclase.
AsientoPresentación EstadoAsientoPresentación
estado
NoDisponible Disponible Separado Vendido
CAL/Fundamentos 43
44. Patron Diseño de Estado
AsientoPresentación
EstadoAsientoPresentación
estado : EstadoAsientoPresentacion
0..* 1
NoDisponible Disponible Separado Vendido
El tipo de dato del atributo de Estado/Estatus de la clase base debería
referirse a la nueva superclase (esto permitirá que la clase base se
refiera a cualquier subclase estado a través de este atributo). El
símbolo de agregación se usa comunmente para indicar que la
generalizacion de estado es “parte de” el maquillaje de la clase base.
CAL/Fundamentos 44
45. Patron Diseño de Estado
Para cada evento en el diagrama de transición de Sin precio
estados: a) agregue una interface correspondiente al No separado
objeto base. B) agregue una interface correspondiente No vendido
(identica) a la superclase estado (esto provocará que Precio(NivelPrecio)
RemoverPrecio()
cada subclase estado herede las interfaces). Con precio
No separado
No vendido
AsientoPresentación Cancel() Select()
EstadoAsientoPresentación
estado : EstadoAsientoPresentacion Reembolsar()
con precio
Select()
Select()
Cancel()
separado
Cancel()
0..* 1 Reembolsar() No vendido
Reembolsar()
Comprar() Compra(TipoPrecio)
Comprar(TipoPrecio)
Precio()
Precio(NivelPrecio)
RemoverPrecio()
RemoverPrecio() con precio
No separado
vendido
NoDisponible Disponible Separado Vendido
CAL/Fundamentos 45
46. Patron Diseño de Estado
Un ejemplo Java para delegar comportamiento:
Void Compra(TipoPrecio) {Estado.Compra(TipoPrecio)}
AsientoPresentación
EstadoAsientoPresentación
estado : EstadoAsientoPresentacion
Select()
Select()
Cancel()
Cancel()
0..* 1 Reembolsar()
Reembolsar()
Comprar()
Comprar(TipoPrecio)
Precio()
Precio(NivelPrecio)
RemoverPrecio()
RemoverPrecio()
Para implementar las interfaces del
objeto base, invoque la interface
correspondiente sobre el atributo que
NoDisponible Disponible Separado Vendido
retiene la referencia a la subclase
estado.
CAL/Fundamentos 46
47. Resúmen
Los estados y los comportamientos
específicos de estado son elementos
importantes de cualquier diseño final de
aplicación. El diagrama de estados es
una herramienta especificamente
diseñada para representar el estado del
objeto, los eventos de transición de
estados y el comportamiento específico
de estado en la forma de acciones y
actividades.
CAL/Fundamentos 47
48. Resúmen
Los estados son representados por los
valores de los atributos del objetos. Las
acciones activadas por eventos
representan la implementación de los
eventos que causan el cambio actual
en el estado. Las actividades
representan comportamientos internos
al estado del objeto.
CAL/Fundamentos 48
49. Resúmen
Aplicando patrones para simplificar el modelo:
El patrón diseño de estados es una forma de
manejar la complejidad del comportamiento
específico de estado y evitar codificación
complicada. El patrón de diseño de estado está
diseñado específicamente para distribuir y
aislar el comportamiento específico de estado.
Este arreglo hace que la solución sea visible a
nivel de modelo.
CAL/Fundamentos 49
50. Resúmen
(...) En cualquier momento un
problema puede resolverse a nivel de
modelo en vez de con el código, el
tiempo y costos de mantenimiento se
reducen considerablemente.
CAL/Fundamentos 50
51. Resúmen
Actualizar los productos del trabajo. Cada
vez que se agrega una nueva clase al
modelo debe reconciliar el producto del
trabajo nuevamente. La comprensión de la
relación entre los productos del trabajo
proporciona un conjunto de herramientas
que le ayudan a entender completamente y
describir el rol de cada nuevo recurso y su
relación con los otros elementos del
modelo.
CAL/Fundamentos 51
52. Resúmen
Una forma que ud. conozca si su modelo está
bien diseñado es si es capaz de añadir nuevas
características con poco o ningún cambio al
modelo. Los cambios debería ser aislados en
pequeños subconjuntos de componentes del
modelo. En contraste, un pobre diseño
rápidamente crecerá en tamaño y complejidad
con cada comportamiento adicional. Un simple
cambio puede resultar en múltiples y
frecuentemente cambios redundantes en
muchas partes del modelo.
CAL/Fundamentos 52