CAPÍTULO 1: INTRODUCCIÓN
¿POR QUÉ MODELAMOS?
Un modelo es una representación de algo en el mismo u otro medio. El modelo capta los aspectos importantes de lo que estamos modelando y simplifica el resto.
LA IMPORTANCIA DE MODELAR
Los modelos se usan para:
-Capturar y enumerar los requisitos y el dominio del conocimiento.
-Pensar del diseño de un sistema.
-Capturar decisiones del diseño en una forma mutables a partir de los requisitos.
-Generar productos aprovechables para el trabajo.
-Organizar, encontrar, filtrar, recuperar, examinar y corregir la información en grandes sistemas.
-Explorar económicamente múltiples soluciones.
-Domesticar los sistemas complejos.
NIVELES DE LOS MODELOS
La cantidad de detalle del modelo debe adaptarse a los siguientes propósitos:
-Guías al proceso de pensamiento.
-Especificaciones abstractas de la estructura esencial de un sistema.
-Especificaciones completa de un sistema final.
-Ejemplos de sistemas típicos o posibles.
-Descripciones completas o parciales de un sistema.
¿QUÉ HAY EN UN MODELO?
El aspecto semántico y el aspecto visual.
El aspecto semántico capta el significado de una aplicación. Los elementos semánticos llevan el significado del modelo.
El aspecto visual muestra la información semántica de modo que pueda ser considerada, hojeada y corregida por lose seres humanos.
¿CUÁL ES EL SIGNIFICADO DE UN MODELO?
Es un generador de potenciales configuraciones de sistemas, también es una descripción de la estructura genérica y del significado de un sistema.
En los modelos hay que considerar los siguientes aspectos:
-Abstracción frente a detalle.
-Especificación frente a implementación.
-Descripción frente a instancia.
-Variaciones en la interpretación.
PRINCIPIOS DEL MODELADO
-La elección de que modelos crear tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución.
-Todo modelo puede ser expresado a diferentes niveles de precisión.
-Los mejores modelos están ligados a la realidad.
-Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.
MODELO ORIENTADO A OBJETOS
La visión actual del desarrollo de software toma una perspectiva orientada a objetos. En este enfoque, el principal bloque de construcción es el objeto o clase.
Actualmente, el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de software, simplemente porque ha demostrado ser válido en la construcción de sistemas en toda clase de dominio de problemas, abarcando todo el abanico de tamaños y complejidades.
SECCIÓN 2: PERSPECTIVA GENERAL DE UML
UML es un lenguaje para visualizar. Detrás de cada símbolo de la notación de UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso otra herramienta puede interpretar esa herramienta sin ambigüedad.
Bloques de construcción de UML
Existen tres bloques de construcción:
-Elementos
-Relaciones
-Diagramas
Hay cuatro tipos de elementos
-Elementos estructurales
-Elementos de comportamiento
-Elementos de agrupación
-Elementos de notación
Hay cuatro tipos de relaciones.
-Dependencia
-Asociación
-Generalización
-Realización
UML incluye nueve diagramas:
-Diagrama de clases
-Diagrama de objetos
-Diagrama de casos de usos.
-Diagrama de secuencias
-Diagrama de colaboración
-Diagrama de estados
-Diagrama de actividades
-Diagrama de componentes
-Diagrama de despliegue
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
-Dirigido por los casos de uso significa que los casos de uso se utilizan como un artefacto básico para establecer el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.
-Centrado en la arquitectura significa que la arquitectura del sistema se utiliza como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema en desarrollo.
-Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.
HIDTORIA DE UML
LOS MÉTODOS DE DESARROLLO ORIENTADO A OBJETOS
Emergieron en los años 70 y fueron difundidos en los 80. Alcanzaron cierta penetración en le área de los grandes sistemas.
El primer lenguaje que es generalmente reconocido como orientado a objetos es Simula 67, desarrollado en 1967. El movimiento de orientación de objetos se hizo popular en los 80’s.
Aparecieron muchos libros cuyos temas estaban enfocados en el modelaje orientado a objetos.
ESFUERZOS DE UNIFICACIÓN
El primer intento exitoso se dio en 1995 cuando se creo el Lenguaje Unificado de Modelado (UML)
ESTANDARIZACIÓN
El Lenguaje Unificado de Modelado fue adoptado unánimemente por los miembros de OMG como estándar en noviembre de 1997.
¿QUÉ SIGNIFICA UNIFICADO?
-A través de los métodos históricos y notaciones.
-A través de los dominios de aplicación.
-A través de los lenguajes de implementación y plataformas.
-A través de procesos de desarrollo.
-A través de los conceptos internos.
OBJETIVOS DE UML
-UML es un lenguaje de propósito general que pueden utilizar todos los programadores.
-basado en el común acuerdo.
-Pretende abordar los problemas actuales de desarrollo de software.
-UML pretende trabajar correctamente con todos.
-UML incluye todos los conceptos que consideramos necesarios para utilizar un proceso moderno iterativo.
-Ser tan simple como fuera posible.
AREAS CONCEPTUALES
-Estructura estática
-Comportamiento dinámico.
-Construcciones de implementación.
-Organización del modelo.
-Mecanismos de extensión.
CAPÍTULO 2: CONCEPTOS DE UML
CLASES Y OBJETOS
Una clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento. Un objeto es el valor de una variable.
DIAGRAMAS DE UML
Es una representación gráfica de un conjunto de elementos, se utilizan para visualizar un sistema desde diferentes perspectivas.
DIAGRAMAS ESTRUCTURALES
-Diagramas de clases.
-Diagramas de objetos.
-Diagramas de componentes.
-Diagramas de despliegue.
DIAGRAMAS DE COMPORTAMIENTO
-Diagramas de casos de uso
-Diagramas de secuencia.
-Diagramas de colaboración.
-Diagramas de estados.
-Diagramas de actividades.
VISTAS DE UML
Es un subconjunto de UML que modela construcciones que representan un aspecto del sistema.
VISTA ESTÁTICA
Modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación.
VISTA DE LOS CASOS DE USO
Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores.
VISTA DE INTERACCIÓN
Describe secuencias de intercambio de mensajes entre los roles que implementan los comportamientos de un sistema. Se exhibe en dos programas.
-Diagrama de secuencia: muestra un conjunto de mensajes, dispuestos en una secuencia temporal.
-Diagrama de colaboración: modela los objetos y los enlaces significativos dentro de una interacción.
VISTA DE LA MÁQUINA DE ESTADOS
Modela las posibles historias de vida de un objeto de una clase.
VISTA DE ACTIVIDADES
Es una variante de una máquina de estados, que muestra las actividades implicadas en la ejecución de un cálculo.
VISTA DE IMPLEMENTACIÓN
Proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos.
VISTA DE GESTIÓN DEL MODELO
Modela la organización del modelo en sí mismo.
RELACIONES
Se da entre los objetos.
DEPENDENCIA
Relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.
GENERALIZACIÓN
Relación entre un elemento general y un caso más específico de ese elemento.
ASOCIACIÓN
Relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.
CAPÍTULO 3: CASOS DE USO
TÉRMINOS Y CONCEPTOS
Un caso de uso es una descripción de una secuencia de acciones que ejecuta un sistema para producir un resultado observable de valor para un actor.
NOMBRES
Cada caso debe tener un nombre que lo distinga de otros casos de uso. Es una cadena de texto.
CASOS DE USO Y ACTORES
Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con éstos.
CASOS DE USO Y FLUJO DE EVENTOS
El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo atienda fácilmente.
CASOS DE USO Y COLABORACIONES
Un casos de uso debe implementarse al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos que colaborarán para llevar a cabo el comportamiento del caso de uso.
ORGANIZACIÓN DE CASOS DE USO
Pueden organizarse agrupándolos en paquetes. También pueden agruparse especificando relaciones de generalización, inclusión y extensión entre ellos.
OTRAS CARACTERÍSTICAS
Los casos de uso son también clasificadores, de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases.
PROPIEDADES COMUNES
Un diagrama de casos de uso es u tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas.
CONTENIDOS
Un diagrama de casos de uso contiene.
-Casos de uso.
-Actores.
-Relaciones de dependencia, generalización y asociación.
USOS COMUNES
-Para modelar el contexto de un sistema.
-Para modelar los requisitos de un sistema.
OBJETIVOS DEL USUARIO E INTERACIONES CON EL SISTEMA
Los verdaderos objetivos del usuario se describirán con términos como “garantizar el formateo consistente de un documento” y “hacer que el formato de un documento sea igual que el de otro”. Las interacciones con el sistema permiten decir que los casos de uso incluirán cosas como: “define estilo”, “cambia estilo” y “mueva un estilo de un documento a otro”.
CUANDO EMPLEAR CASOS DE USO
La captura de los casos de uso es una de las tareas principales durante la fase de elaboración; de hecho es lo primero que se debe hacer, aunque ese usa en otras fases también.
MODELADO DE CASOS DE USO
MODELADO DEL COMPORTAMIENTO DE UN ELEMENTO
-Identificar los actores que interactúan con el elemento.
-Organizar los actores.
-Considerar las formas más importantes que tiene cada actor de interactuar con el elemento.
-Considerar las formas excepcionales en las que cada actor puede interactuar con el elemento.
-Organizar estos comportamientos como casos de uso, utilizando las relaciones de inclusión y extensión.
MODELADO DEL CONTEXTP DE UN SISTEMA
-Identificar los actores en torno al sistema.
-Organizar los actores similares en jerarquías de generalización/especialización.
-Introducir esos actores en un diagrama de casos de uso y especificar las vías de comunicación de cada actor con los casos de uso del sistema.
MODELADO DE LOS REQUISISTOS DE UN SISTEMA
-Establecer el contexto del sistema.
-Considerar el comportamiento de cada actor.
-Nombrar esos comportamientos comunes como casos de uso.
-Factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros.
-Modelar los casos de uso, actores y relaciones en un diagrama de casos de uso.
-Adornar esos casos de uso con notas que enuncien los requisitos no funcionales.
INGENIERÍA DIRECTA E INVERSA
La ingeniería directa es el proceso de transformar un modelo en código a través de una correspondencia con un lenguaje de implementación.
La ingeniería inversa es el proceso de transformar código en un modelo a través de una correspondencia a partir de un lenguaje de implementación específico.
¿POR QUÉ MODELAMOS?
Un modelo es una representación de algo en el mismo u otro medio. El modelo capta los aspectos importantes de lo que estamos modelando y simplifica el resto.
LA IMPORTANCIA DE MODELAR
Los modelos se usan para:
-Capturar y enumerar los requisitos y el dominio del conocimiento.
-Pensar del diseño de un sistema.
-Capturar decisiones del diseño en una forma mutables a partir de los requisitos.
-Generar productos aprovechables para el trabajo.
-Organizar, encontrar, filtrar, recuperar, examinar y corregir la información en grandes sistemas.
-Explorar económicamente múltiples soluciones.
-Domesticar los sistemas complejos.
NIVELES DE LOS MODELOS
La cantidad de detalle del modelo debe adaptarse a los siguientes propósitos:
-Guías al proceso de pensamiento.
-Especificaciones abstractas de la estructura esencial de un sistema.
-Especificaciones completa de un sistema final.
-Ejemplos de sistemas típicos o posibles.
-Descripciones completas o parciales de un sistema.
¿QUÉ HAY EN UN MODELO?
El aspecto semántico y el aspecto visual.
El aspecto semántico capta el significado de una aplicación. Los elementos semánticos llevan el significado del modelo.
El aspecto visual muestra la información semántica de modo que pueda ser considerada, hojeada y corregida por lose seres humanos.
¿CUÁL ES EL SIGNIFICADO DE UN MODELO?
Es un generador de potenciales configuraciones de sistemas, también es una descripción de la estructura genérica y del significado de un sistema.
En los modelos hay que considerar los siguientes aspectos:
-Abstracción frente a detalle.
-Especificación frente a implementación.
-Descripción frente a instancia.
-Variaciones en la interpretación.
PRINCIPIOS DEL MODELADO
-La elección de que modelos crear tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución.
-Todo modelo puede ser expresado a diferentes niveles de precisión.
-Los mejores modelos están ligados a la realidad.
-Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.
MODELO ORIENTADO A OBJETOS
La visión actual del desarrollo de software toma una perspectiva orientada a objetos. En este enfoque, el principal bloque de construcción es el objeto o clase.
Actualmente, el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo de software, simplemente porque ha demostrado ser válido en la construcción de sistemas en toda clase de dominio de problemas, abarcando todo el abanico de tamaños y complejidades.
SECCIÓN 2: PERSPECTIVA GENERAL DE UML
UML es un lenguaje para visualizar. Detrás de cada símbolo de la notación de UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso otra herramienta puede interpretar esa herramienta sin ambigüedad.
Bloques de construcción de UML
Existen tres bloques de construcción:
-Elementos
-Relaciones
-Diagramas
Hay cuatro tipos de elementos
-Elementos estructurales
-Elementos de comportamiento
-Elementos de agrupación
-Elementos de notación
Hay cuatro tipos de relaciones.
-Dependencia
-Asociación
-Generalización
-Realización
UML incluye nueve diagramas:
-Diagrama de clases
-Diagrama de objetos
-Diagrama de casos de usos.
-Diagrama de secuencias
-Diagrama de colaboración
-Diagrama de estados
-Diagrama de actividades
-Diagrama de componentes
-Diagrama de despliegue
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE
-Dirigido por los casos de uso significa que los casos de uso se utilizan como un artefacto básico para establecer el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.
-Centrado en la arquitectura significa que la arquitectura del sistema se utiliza como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema en desarrollo.
-Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.
HIDTORIA DE UML
LOS MÉTODOS DE DESARROLLO ORIENTADO A OBJETOS
Emergieron en los años 70 y fueron difundidos en los 80. Alcanzaron cierta penetración en le área de los grandes sistemas.
El primer lenguaje que es generalmente reconocido como orientado a objetos es Simula 67, desarrollado en 1967. El movimiento de orientación de objetos se hizo popular en los 80’s.
Aparecieron muchos libros cuyos temas estaban enfocados en el modelaje orientado a objetos.
ESFUERZOS DE UNIFICACIÓN
El primer intento exitoso se dio en 1995 cuando se creo el Lenguaje Unificado de Modelado (UML)
ESTANDARIZACIÓN
El Lenguaje Unificado de Modelado fue adoptado unánimemente por los miembros de OMG como estándar en noviembre de 1997.
¿QUÉ SIGNIFICA UNIFICADO?
-A través de los métodos históricos y notaciones.
-A través de los dominios de aplicación.
-A través de los lenguajes de implementación y plataformas.
-A través de procesos de desarrollo.
-A través de los conceptos internos.
OBJETIVOS DE UML
-UML es un lenguaje de propósito general que pueden utilizar todos los programadores.
-basado en el común acuerdo.
-Pretende abordar los problemas actuales de desarrollo de software.
-UML pretende trabajar correctamente con todos.
-UML incluye todos los conceptos que consideramos necesarios para utilizar un proceso moderno iterativo.
-Ser tan simple como fuera posible.
AREAS CONCEPTUALES
-Estructura estática
-Comportamiento dinámico.
-Construcciones de implementación.
-Organización del modelo.
-Mecanismos de extensión.
CAPÍTULO 2: CONCEPTOS DE UML
CLASES Y OBJETOS
Una clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento. Un objeto es el valor de una variable.
DIAGRAMAS DE UML
Es una representación gráfica de un conjunto de elementos, se utilizan para visualizar un sistema desde diferentes perspectivas.
DIAGRAMAS ESTRUCTURALES
-Diagramas de clases.
-Diagramas de objetos.
-Diagramas de componentes.
-Diagramas de despliegue.
DIAGRAMAS DE COMPORTAMIENTO
-Diagramas de casos de uso
-Diagramas de secuencia.
-Diagramas de colaboración.
-Diagramas de estados.
-Diagramas de actividades.
VISTAS DE UML
Es un subconjunto de UML que modela construcciones que representan un aspecto del sistema.
VISTA ESTÁTICA
Modela los conceptos del dominio de la aplicación, así como los conceptos internos inventados como parte de la implementación.
VISTA DE LOS CASOS DE USO
Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores.
VISTA DE INTERACCIÓN
Describe secuencias de intercambio de mensajes entre los roles que implementan los comportamientos de un sistema. Se exhibe en dos programas.
-Diagrama de secuencia: muestra un conjunto de mensajes, dispuestos en una secuencia temporal.
-Diagrama de colaboración: modela los objetos y los enlaces significativos dentro de una interacción.
VISTA DE LA MÁQUINA DE ESTADOS
Modela las posibles historias de vida de un objeto de una clase.
VISTA DE ACTIVIDADES
Es una variante de una máquina de estados, que muestra las actividades implicadas en la ejecución de un cálculo.
VISTA DE IMPLEMENTACIÓN
Proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos.
VISTA DE GESTIÓN DEL MODELO
Modela la organización del modelo en sí mismo.
RELACIONES
Se da entre los objetos.
DEPENDENCIA
Relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.
GENERALIZACIÓN
Relación entre un elemento general y un caso más específico de ese elemento.
ASOCIACIÓN
Relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.
CAPÍTULO 3: CASOS DE USO
TÉRMINOS Y CONCEPTOS
Un caso de uso es una descripción de una secuencia de acciones que ejecuta un sistema para producir un resultado observable de valor para un actor.
NOMBRES
Cada caso debe tener un nombre que lo distinga de otros casos de uso. Es una cadena de texto.
CASOS DE USO Y ACTORES
Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con éstos.
CASOS DE USO Y FLUJO DE EVENTOS
El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo atienda fácilmente.
CASOS DE USO Y COLABORACIONES
Un casos de uso debe implementarse al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos que colaborarán para llevar a cabo el comportamiento del caso de uso.
ORGANIZACIÓN DE CASOS DE USO
Pueden organizarse agrupándolos en paquetes. También pueden agruparse especificando relaciones de generalización, inclusión y extensión entre ellos.
OTRAS CARACTERÍSTICAS
Los casos de uso son también clasificadores, de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases.
PROPIEDADES COMUNES
Un diagrama de casos de uso es u tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas.
CONTENIDOS
Un diagrama de casos de uso contiene.
-Casos de uso.
-Actores.
-Relaciones de dependencia, generalización y asociación.
USOS COMUNES
-Para modelar el contexto de un sistema.
-Para modelar los requisitos de un sistema.
OBJETIVOS DEL USUARIO E INTERACIONES CON EL SISTEMA
Los verdaderos objetivos del usuario se describirán con términos como “garantizar el formateo consistente de un documento” y “hacer que el formato de un documento sea igual que el de otro”. Las interacciones con el sistema permiten decir que los casos de uso incluirán cosas como: “define estilo”, “cambia estilo” y “mueva un estilo de un documento a otro”.
CUANDO EMPLEAR CASOS DE USO
La captura de los casos de uso es una de las tareas principales durante la fase de elaboración; de hecho es lo primero que se debe hacer, aunque ese usa en otras fases también.
MODELADO DE CASOS DE USO
MODELADO DEL COMPORTAMIENTO DE UN ELEMENTO
-Identificar los actores que interactúan con el elemento.
-Organizar los actores.
-Considerar las formas más importantes que tiene cada actor de interactuar con el elemento.
-Considerar las formas excepcionales en las que cada actor puede interactuar con el elemento.
-Organizar estos comportamientos como casos de uso, utilizando las relaciones de inclusión y extensión.
MODELADO DEL CONTEXTP DE UN SISTEMA
-Identificar los actores en torno al sistema.
-Organizar los actores similares en jerarquías de generalización/especialización.
-Introducir esos actores en un diagrama de casos de uso y especificar las vías de comunicación de cada actor con los casos de uso del sistema.
MODELADO DE LOS REQUISISTOS DE UN SISTEMA
-Establecer el contexto del sistema.
-Considerar el comportamiento de cada actor.
-Nombrar esos comportamientos comunes como casos de uso.
-Factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros.
-Modelar los casos de uso, actores y relaciones en un diagrama de casos de uso.
-Adornar esos casos de uso con notas que enuncien los requisitos no funcionales.
INGENIERÍA DIRECTA E INVERSA
La ingeniería directa es el proceso de transformar un modelo en código a través de una correspondencia con un lenguaje de implementación.
La ingeniería inversa es el proceso de transformar código en un modelo a través de una correspondencia a partir de un lenguaje de implementación específico.
No hay comentarios:
Publicar un comentario