Curso UML Emilio Avilés Ávila http://www.techmi.es

Workshop (20 horas) Workshop UML y Proceso Unificad para empresas y profesionales

Temario Introducción Introducción Introducción a UML Notación y Modelo Orientación a Objetos Diagramas Proceso Unificado

Introducción

Introducción

Introducción a UML

Notación y Modelo

Orientación a Objetos

Diagramas

Proceso Unificado

Tema 1 Introducción

Objetivos Introducción Introducción Introducción a UML Notación y Modelo Orientación a Objetos Diagramas Proceso Unificado Orígenes y evolución del software. Errores actuales en los proyectos software. Qué es la Ingeniería del Software. Introducción y motivación al modela UML. Elementos de UML. Notación y modelado. Por qué Orientación a Objetos

Introducción

Introducción

Introducción a UML

Notación y Modelo

Orientación a Objetos

Diagramas

Proceso Unificado

Orígenes y evolución del software.

Errores actuales en los proyectos software.

Qué es la Ingeniería del Software.

Introducción y motivación al modela UML.

Elementos de UML.

Notación y modelado.

Por qué Orientación a Objetos

Tema 1.1 Introducción

1.1 – Introducción Evolución del Software Primera era : Software a medida. Distribución limitada. Orientación procesos batch. Segunda era : Surgió la multiprogramación y multiusuario. Primeros sistemas en tiempo real (captura de datos, análisis y respuesta en tiempo establecido). Aparecen las bases de datos. El software como producto.

Evolución del Software

Primera era :

Software a medida.

Distribución limitada.

Orientación procesos batch.

Segunda era :

Surgió la multiprogramación y multiusuario.

Primeros sistemas en tiempo real (captura de datos, análisis y respuesta en tiempo establecido). Aparecen las bases de datos.

El software como producto.

1.1 – Introducción Evolución del Software Tercera era : Potencia de cómputo personal. Surgen los sistemas distribuidos. Distintas máquinas procesando de forma concurrente. Impacto del software en el consumo. Cuarta era : Sistemas personales potentes. Tecnologías orientadas a objetos. Aparición de sistemas expertos. Creación de las grandes redes.

Evolución del Software

Tercera era :

Potencia de cómputo personal.

Surgen los sistemas distribuidos.

Distintas máquinas procesando de forma concurrente.

Impacto del software en el consumo.

Cuarta era :

Sistemas personales potentes.

Tecnologías orientadas a objetos.

Aparición de sistemas expertos.

Creación de las grandes redes.

1.1 – Introducción El Software Definición Conjunto de instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseado, las estructuras de datos que permiten a los programas manipular adecuadamente la información y los documentos que describe la operación y uso de los programas. Características El software se desarrolla , no se fabrica. Ejemplo: En el software es fácil corregir los errores de la fase de diseño, en el hardware en cambio es muy difícil. El software no se estropea o desgasta (pero si pasa de moda). La mayoría del software se construye a la medida , en vez de ensamblar componentes existentes (esto último está cambiando paulatinamente)

El Software

Definición

Conjunto de instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseado, las estructuras de datos que permiten a los programas manipular adecuadamente la información y los documentos que describe la operación y uso de los programas.

Características

El software se desarrolla , no se fabrica. Ejemplo: En el software es fácil corregir los errores de la fase de diseño, en el hardware en cambio es muy difícil.

El software no se estropea o desgasta (pero si pasa de moda).

La mayoría del software se construye a la medida , en vez de ensamblar componentes existentes (esto último está cambiando paulatinamente)

1.1 – Introducción ¿Qué es un proyecto software? Desarrollo de un sistema. Estudio de factibilidad. Consultoría. Análisis. Diseño. Evaluación de aplicaciones. Conversiones. Cursos de entrenamiento. Instalación (equipo, software, redes). Etc...

¿Qué es un proyecto software?

Desarrollo de un sistema.

Estudio de factibilidad.

Consultoría.

Análisis.

Diseño.

Evaluación de aplicaciones.

Conversiones.

Cursos de entrenamiento.

Instalación (equipo, software, redes).

Etc...

1.1 – Introducción Aplicaciones Software Software de sistemas Software de tiempo real. Software de sistemas distribuidos. Software de gestión. Software de ingeniería y cálculo científico. Software empotrado (sistemas de control) Software de cómputo personal. Software de inteligencia artificial. Software basado en web. Etc...

Aplicaciones Software

Software de sistemas

Software de tiempo real.

Software de sistemas distribuidos.

Software de gestión.

Software de ingeniería y cálculo científico.

Software empotrado (sistemas de control)

Software de cómputo personal.

Software de inteligencia artificial.

Software basado en web.

Etc...

1.1 – Introducción ¿Por qué un proyecto falla?

¿Por qué un proyecto falla?

1.1 – Introducción a UML ¿Cuántos Proyectos fallan?

¿Cuántos Proyectos fallan?

1.1 – Introducción Curva de Fallos a lo largo del tiempo

Curva de Fallos a lo largo del tiempo

1.1 – Introducción Utilización del Software ¿Uso?

Utilización del Software ¿Uso?

1.1 – Introducción Evolución de la ISW ISW : Ingeniería del software Inicialmente la programación de las computadoras era un arte que no disponía de métodos sistemáticos en los que poder basarse para la realización de productos software. Se realizaban sin ninguna planificación. De los 60 hasta finales de los 70 se caracterizó: Por el establecimiento del software como producto que se desarrollaba para una distribución general. En esta época nació el mantenimiento del software que se da cuando cambian los requisitos de los usuarios y se hace necesaria la modificación del software.

Evolución de la ISW

ISW : Ingeniería del software

Inicialmente la programación de las computadoras era un arte que no disponía de métodos sistemáticos en los que poder basarse para la realización de productos software. Se realizaban sin ninguna planificación.

De los 60 hasta finales de los 70 se caracterizó:

Por el establecimiento del software como producto que se desarrollaba para una distribución general.

En esta época nació el mantenimiento del software que se da cuando cambian los requisitos de los usuarios y se hace necesaria la modificación del software.

1.1 – Introducción Evolución de la ISW (60’) El esfuerzo requerido para este mantenimiento era en la mayoría de los casos tan elevado que se hacía imposible su mantenimiento. A continuación, surge una etapa que se caracteriza por la aparición de una serie de técnicas como la Programación Estructurada y las Metodologías de Diseño que solucionan los problemas anteriores. A finales de esta etapa aparecen las herramientas CASE , aunque muy rudimentarias.

Evolución de la ISW (60’)

El esfuerzo requerido para este mantenimiento era en la mayoría de los casos tan elevado que se hacía imposible su mantenimiento.

A continuación, surge una etapa que se caracteriza por la aparición de una serie de técnicas como la Programación Estructurada y las Metodologías de Diseño que solucionan los problemas anteriores.

A finales de esta etapa aparecen las herramientas CASE , aunque muy rudimentarias.

1.1 – Introducción Evolución de la ISW (70’) Surgen diversas técnicas y metodologías formales de diseño de sistemas. Cada una introdujo notaciones propias, visiones distintas , sin embargo todas introducían características comunes: Mecanismos de traducción de necesidades a una representación del diseño (Ejemplo: diagramas de contexto) Notación para representar funcionalidad e interfaces Refinamiento y partición (modularidad) Criterios de valoración de la calidad

Evolución de la ISW (70’)

Surgen diversas técnicas y metodologías formales de diseño de sistemas.

Cada una introdujo notaciones propias, visiones distintas , sin embargo todas introducían características comunes:

Mecanismos de traducción de necesidades a una representación del diseño (Ejemplo: diagramas de contexto)

Notación para representar funcionalidad e interfaces

Refinamiento y partición (modularidad)

Criterios de valoración de la calidad

1.1 – Introducción Evolución de la ISW (80’-90’) A finales de los 80’s surgió el diseño orientado a objetos (DOO). En los 90’s: Afianzamiento la tecnología OO Evolución de las herramientas CASE Explosión del fenómeno WWW, Intranets, Java Como producto de lo anterior surge: UML La propuesta de Desarrollo Rápido de Aplicaciones (RAD en ingles) Reutilización

Evolución de la ISW (80’-90’)

A finales de los 80’s surgió el diseño orientado a objetos (DOO).

En los 90’s: Afianzamiento la tecnología OO

Evolución de las herramientas CASE

Explosión del fenómeno WWW, Intranets, Java

Como producto de lo anterior surge:

UML

La propuesta de Desarrollo Rápido de Aplicaciones (RAD en ingles)

Reutilización

1.1 – Introducción Definiciones de ISW

Definiciones de ISW

1.1 – Introducción Punto Vista SW

Punto Vista SW

1.1 – Introducción Mitos del desarrollo Software: Gestión Tenemos un libro que está lleno de estándares y procedimientos para construir software, ¿ya se le ha proporcionado a la gente lo que necesita saber? La gente dispone de las herramientas de desarrollo más avanzadas y los equipos más modernos por eso se espera que desarrollen software de calidad. Si se falla en la planificación, podemos añadir mas programadores y se resuelve.

Mitos del desarrollo Software: Gestión

Tenemos un libro que está lleno de estándares y procedimientos para construir software, ¿ya se le ha proporcionado a la gente lo que necesita saber?

La gente dispone de las herramientas de desarrollo más avanzadas y los equipos más modernos por eso se espera que desarrollen software de calidad.

Si se falla en la planificación, podemos añadir mas programadores y se resuelve.

1.1 – Introducción Mitos del desarrollo Software: Desarrolladores El software es fácil de desarrollar. El software consiste en programas ejecutables . El desarrollo del software es sólo una labor de programación . Es natural que el software contenga errores . Hasta que no tengo el ejecutable no tengo posibilidad de comprobar la calidad .

Mitos del desarrollo Software: Desarrolladores

El software es fácil de desarrollar.

El software consiste en programas ejecutables .

El desarrollo del software es sólo una labor de programación .

Es natural que el software contenga errores .

Hasta que no tengo el ejecutable no tengo posibilidad de comprobar la calidad .

1.1 – Introducción Mitos del desarrollo Software: Cliente Una declaración general de objetivos es suficiente para empezar a hacer el programa, los detalles los podemos dar después. Los requisitos del negocio cambian continuamente pero el software es flexible y estos cambios se pueden acometer fácilmente. Etc.

Mitos del desarrollo Software: Cliente

Una declaración general de objetivos es suficiente para empezar a hacer el programa, los detalles los podemos dar después.

Los requisitos del negocio cambian continuamente pero el software es flexible y estos cambios se pueden acometer fácilmente.

Etc.

Tema 1.2 Introducción al UML

1.1 – Introducción al UML Modelado Motivación : Es difícil comprender un sistema complejo en su totalidad. Los modelos permiten comprender mejor el sistema que se está desarrollando. Objetivos : Permite mostrar el sistema como nos gustaría que fuera. Permite especificar la estructura y/o comportamiento del sistema. Proporciona una plantilla que nos guía durante la construcción. Permite documentar las decisiones.

Modelado

Motivación :

Es difícil comprender un sistema complejo en su totalidad.

Los modelos permiten comprender mejor el sistema que se está desarrollando.

Objetivos :

Permite mostrar el sistema como nos gustaría que fuera.

Permite especificar la estructura y/o comportamiento del sistema.

Proporciona una plantilla que nos guía durante la construcción.

Permite documentar las decisiones.

1.1 – Introducción al UML Modelado (II) Consideraciones: Todo modelo puede ser expresado en diferentes niveles de detalle. Un solo modelo no es suficiente en sistemas no triviales: mejor utilizar un pequeño conjunto de modelos casi independientes. El propósito de UML es visualizar, especificar, construir y documentar sistemas Orientados a Objetos.

Modelado (II)

Consideraciones:

Todo modelo puede ser expresado en diferentes niveles de detalle.

Un solo modelo no es suficiente en sistemas no triviales: mejor utilizar un pequeño conjunto de modelos casi independientes.

El propósito de UML es visualizar, especificar, construir y documentar sistemas Orientados a Objetos.

1.1 – Introducción al UML El Lenguaje Unificado de Modelado Lenguaje estándar para escribir planos o prototipos ( blueprints ) de software. Proporciona un vocabulario (conjunto de símbolos gráficos) y reglas que permiten mejorar la comunicación en un proyecto software. No indica Qué modelos se deberían crear. Cuándo deberían ser creados. Ni quién debería crearlos.

El Lenguaje Unificado de Modelado

Lenguaje estándar para escribir planos o prototipos ( blueprints ) de software.

Proporciona un vocabulario (conjunto de símbolos gráficos) y reglas que permiten mejorar la comunicación en un proyecto software.

No indica

Qué modelos se deberían crear.

Cuándo deberían ser creados.

Ni quién debería crearlos.

1.1 – Introducción al UML Lenguaje UNIFICADO modelado

Lenguaje UNIFICADO modelado

1.1 – Introducción al UML Participantes en UML

Participantes en UML

1.1 – Introducción al UML Evolución de UML

Evolución de UML

1.1 – Introducción al UML Modelo Conceptual UML Permite entender modelos UML y construirlos. Tiene 3 elementos principales: Bloques básicos de construcción Reglas de combinación de bloques Mecanismos comunes

Modelo Conceptual UML

Permite entender modelos UML y construirlos.

Tiene 3 elementos principales:

Bloques básicos de construcción

Reglas de combinación de bloques

Mecanismos comunes

1.1 – Introducción al UML Modelo conceptual de UML

Modelo conceptual de UML

1.1 – Introducción al UML Modelo conceptual de UML

Modelo conceptual de UML

1.1 – Introducción al UML Vistas UML Cada vista es una proyección del sistema completo. Cada vista resalta aspectos específicos del sistema. Las vistas son descritas mediante diagramas. No hay una separación estricta, por lo que un diagrama puede pertenecer a más de una vista.

Vistas UML

Cada vista es una proyección

del sistema completo.

Cada vista resalta aspectos

específicos del sistema.

Las vistas son descritas

mediante diagramas.

No hay una separación

estricta, por lo que un

diagrama puede pertenecer

a más de una vista.

1.1 – Introducción al UML Vistas UML: Vista de Casos de Uso Comportamiento del sistema tal y como lo perciben los usuarios finales, analistas y encargados de las pruebas. Especifica las fuerzas que configuran la arquitectura del sistema.

Vistas UML: Vista de Casos de Uso

Comportamiento del sistema tal y como lo perciben los usuarios finales, analistas y encargados de las pruebas.

Especifica las fuerzas que configuran la arquitectura del sistema.

1.1 – Introducción al UML Vistas UML: Vista de Diseño Comprende clases, interfaces y colaboraciones del problema y la solución. Soporta los requisitos funcionales (servicios proporcionados por el sistema).

Vistas UML: Vista de Diseño

Comprende clases, interfaces y colaboraciones del problema y la solución.

Soporta los requisitos funcionales (servicios proporcionados por el sistema).

1.1 – Introducción al UML Vistas UML: Vista de Procesos Comprende hilos y procesos. Cubre el funcionamiento, capacidad de crecimiento y rendimiento.

Vistas UML: Vista de Procesos

Comprende hilos y procesos.

Cubre el funcionamiento, capacidad de crecimiento y rendimiento.

1.1 – Introducción al UML Vistas UML: Vista de Implementación Comprende los componentes y archivos del sistema físico. Cubre el ensamblado del sistema y la gestión de configuraciones.

Vistas UML: Vista de Implementación

Comprende los componentes y archivos del sistema físico.

Cubre el ensamblado del sistema y la gestión de configuraciones.

1.1 – Introducción al UML Vistas UML: Vista de Despliegue Contiene los nodos que forman la topología hardware del sistema. Cubre la distribución, entrega e instalación.

Vistas UML: Vista de Despliegue

Contiene los nodos que forman la topología hardware del sistema.

Cubre la distribución, entrega e instalación.

1.1 – Introducción al UML Diagramas en UML

Diagramas en UML

Tema 1.3 Notación y Modelado

1.3 – Notación y Modelado Arquitectura : conjunto de decisiones significativas sobre: Organización del sistema Selección de elementos estructurales y sus interfaces Comportamiento del sistema Composición de los elementos estructurales y de comportamiento en subsistemas Estilo arquitectónico que guía la organización

Arquitectura : conjunto de decisiones significativas sobre:

Organización del sistema

Selección de elementos estructurales y sus interfaces

Comportamiento del sistema

Composición de los elementos estructurales y de comportamiento en subsistemas

Estilo arquitectónico que guía la organización

1.3 – Notación y Modelado Arquitectura UML La visualización , especificación , construcción y documentación de un sistema requieren diferentes perspectivas. La arquitectura de un sistema permite manejar los diferentes puntos de vista y controlar el desarrollo del mismo. Aspectos no estructurales de la arquitectura: uso, funcionalidad, rendimiento, capacidad de adaptación, reutilización, etc.

Arquitectura UML

La visualización , especificación , construcción y documentación de un sistema requieren diferentes perspectivas.

La arquitectura de un sistema permite manejar los diferentes puntos de vista y controlar el desarrollo del mismo.

Aspectos no estructurales de la arquitectura: uso, funcionalidad, rendimiento, capacidad de adaptación, reutilización, etc.

1.3 – Notación y Modelado Conexión con el ‘Mundo real’ Sus modelos se pueden conectar a diferentes lenguajes de programación, bases de datos, etc. Ingeniería directa : modelo UML -> código en LPOO Ingeniería inversa : código en LPOO ->modelo UML

Conexión con el ‘Mundo real’

Sus modelos se pueden conectar a diferentes lenguajes de programación, bases de datos, etc.

Ingeniería directa :

modelo UML -> código en LPOO

Ingeniería inversa :

código en LPOO ->modelo UML

1.3 – Notación y Modelado Notación: Bloques de Construcción Compuesto de : Elementos Relaciones Mecanismos comunes

Notación: Bloques de Construcción

Compuesto de :

Elementos

Relaciones

Mecanismos comunes

1.3 – Notación y Modelado Notación: Elementos Elementos estructurales : Son los nombres de modelos en UML. 7 tipos básicos que tienen variantes: Clase Interfaz Colaboración Caso de uso Componente Clase Activa Nodo

Notación: Elementos

Elementos estructurales : Son los nombres de modelos en UML. 7 tipos básicos que tienen variantes:

Clase

Interfaz

Colaboración

Caso de uso

Componente

Clase Activa

Nodo

1.3 – Notación y Modelado Notación: Elementos Clase : Descripción de un conjunto de objetos. Implementa una o mas interfaces

Notación: Elementos

Clase :

Descripción de un conjunto de objetos.

Implementa una o mas interfaces

1.3 – Notación y Modelado Notación: Elementos Interfaz : Colección de operaciones que especifican el servicio de una clase o componente. Describe el comportamiento visible externamente de un elemento. Puede representar comportamiento completo de una clase o componente, o sólo una parte. Normalmente se conecta a una clase o componente.

Notación: Elementos

Interfaz :

Colección de operaciones que especifican el servicio de una clase o componente.

Describe el comportamiento visible externamente de un elemento.

Puede representar comportamiento completo de una clase o componente, o sólo una parte.

Normalmente se conecta a una clase o componente.

1.3 – Notación y Modelado Notación: Elementos Colaboración : Define una interacción. Una clase puede participar en varias colaboraciones Representan patrones de comportamiento.

Notación: Elementos

Colaboración :

Define una interacción.

Una clase puede participar en varias colaboraciones

Representan patrones de comportamiento.

1.3 – Notación y Modelado Notación: Elementos Caso de uso : Descripción de una secuencia de acciones. Es ‘realizado’ por una colaboración.

Notación: Elementos

Caso de uso :

Descripción de una secuencia de acciones.

Es ‘realizado’ por una colaboración.

1.3 – Notación y Modelado Notación: Elementos Componente : Parte física (reemplazable) de un sistema existente en tiempo de ejecución. Formado por un conjunto de interfaces de los que proporciona su implementación. Representa el empaquetamiento físico de diversos elementos lógicos.

Notación: Elementos

Componente :

Parte física (reemplazable) de un sistema existente en tiempo de ejecución.

Formado por un conjunto de interfaces de los que proporciona su implementación.

Representa el empaquetamiento físico de diversos elementos lógicos.

1.3 – Notación y Modelado Notación: Elementos Clase Activa : Clase que tiene uno o más hilos de ejecución. Sus objetos representan elementos con comportamiento concurrente.

Notación: Elementos

Clase Activa :

Clase que tiene uno o más hilos de ejecución.

Sus objetos representan elementos con comportamiento concurrente.

1.3 – Notación y Modelado Notación: Elementos Nodo : Representa un elemento físico con memoria y capacidad de procesamiento. Un conjunto de componentes pueden residir en un nodo o migrar a otro.

Notación: Elementos

Nodo :

Representa un elemento físico con memoria y capacidad de procesamiento.

Un conjunto de componentes pueden residir en un nodo o migrar a otro.

1.3 – Notación y Modelado Notación: Elementos Elementos de comportamiento : Partes dinámicas de los modelos UML. Tipos: Elementos de comportamiento : Partes organizativa de los modelos UML:

Notación: Elementos

Elementos de comportamiento :

Partes dinámicas de los modelos UML. Tipos:

Elementos de comportamiento :

Partes organizativa de los modelos UML:

1.3 – Notación y Modelado Notación: Elementos Elementos de Asociación : Partes explicativas de los modelos

Notación: Elementos

Elementos de Asociación :

Partes explicativas de los modelos

1.3 – Notación y Modelado Notación: Relaciones Dependencia : Relación entre un elemento independiente y otro dependiente de él. Asociación : Conjunto de enlaces o conexiones entre objetos. A gregación un tipo especial de asociación (relación estructural).

Notación: Relaciones

Dependencia : Relación entre un elemento independiente y otro dependiente de él.

Asociación : Conjunto de enlaces o conexiones entre objetos.

A gregación un tipo especial de asociación (relación estructural).

1.3 – Notación y Modelado Notación: Relaciones Generalización : Relación de generalización/especialización. Realización : Relación entre clasificadores, que implica un contrato.

Notación: Relaciones

Generalización : Relación de generalización/especialización.

Realización : Relación entre clasificadores, que implica un contrato.

1.3 – Notación y Modelado Notación: Diagramas (1/3) Representación grafica de elementos Diagrama de clases: Conjunto de clases, interfaces, componentes y relaciones. Cubren la vista de diseño estática. Si incluyen clases activas cubren la vista de procesos estática. Diagrama de objetos: Conjunto de objetos y sus relaciones. Representan casos reales o prototípicos de un diagrama de clases. Diagrama de casos de uso: Conjunto de actores, casos de uso y sus relaciones. Importantes en el modelado y organización del comportamiento del sistema.

Notación: Diagramas (1/3)

Representación grafica de elementos

Diagrama de clases:

Conjunto de clases, interfaces, componentes y relaciones.

Cubren la vista de diseño estática.

Si incluyen clases activas cubren la vista de procesos estática.

Diagrama de objetos:

Conjunto de objetos y sus relaciones.

Representan casos reales o prototípicos de un diagrama de clases.

Diagrama de casos de uso:

Conjunto de actores, casos de uso y sus relaciones.

Importantes en el modelado y organización del comportamiento del sistema.

1.3 – Notación y Modelado Notación: Diagramas (2/3) Diagrama de interacción: Conjunto de objetos con sus relaciones y los mensajes enviados. Cubren la vista dinámica de un sistema. Diagrama de secuencia: Diagrama de interacción que ordena los mensajes en el tiempo. Diagrama de comunicación (anteriormente colaboración): Diagrama de interacción que muestra la organización estructural de los objetos que envían o reciben mensajes. Diagrama de estados: Muestra una máquina de estados. Formado por estados, transiciones, eventos y actividades. Resaltan el comportamiento dirigido por eventos.

Notación: Diagramas (2/3)

Diagrama de interacción:

Conjunto de objetos con sus relaciones y los mensajes enviados.

Cubren la vista dinámica de un sistema.

Diagrama de secuencia:

Diagrama de interacción que ordena los mensajes en el tiempo.

Diagrama de comunicación (anteriormente colaboración):

Diagrama de interacción que muestra la organización estructural de los objetos que envían o reciben mensajes.

Diagrama de estados:

Muestra una máquina de estados.

Formado por estados, transiciones, eventos y actividades.

Resaltan el comportamiento dirigido por eventos.

1.3 – Notación y Modelado Notación: Diagramas (3/3) Diagrama de actividades: Diagrama de estados que muestra el flujo de unas actividades a otras. Resaltan el flujo de control entre objetos. Diagrama de componentes: Muestra la organización y dependencias entre componentes. Cubre la vista de implementación estática de un sistema. Se relacionan con los de clases en que un componente se corresponde con una o más clases, interfaces y colaboraciones. Diagramas de despliegue ( deployment ): Muestran la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Cubre la vista de despliegue estática de una arquitectura.

Notación: Diagramas (3/3)

Diagrama de actividades:

Diagrama de estados que muestra el flujo de unas actividades a otras.

Resaltan el flujo de control entre objetos.

Diagrama de componentes:

Muestra la organización y dependencias entre componentes.

Cubre la vista de implementación estática de un sistema.

Se relacionan con los de clases en que un componente se corresponde con una o más clases, interfaces y colaboraciones.

Diagramas de despliegue ( deployment ):

Muestran la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.

Cubre la vista de despliegue estática de una arquitectura.

1.3 – Notación y Modelado Notación: Reglas Especifican cómo se construye un modelo bien formado a partir de los bloques de construcción. Reglas para: Nombres : cómo denominar elementos, relaciones y diagramas. Alcance : contexto que proporciona significado a un nombre. Visibilidad : cómo se ven y utilizan los nombres entre sí. Integridad : modelado apropiado y consistente de elementos. No siempre se construyen modelos bien formados: Abreviados : se ocultan algunos elementos para simplificar Incompletos : se omiten algunos elementos Inconsistentes : no se garantiza la integridad del modelo

Notación: Reglas

Especifican cómo se construye un modelo bien formado a partir de los bloques de construcción.

Reglas para:

Nombres : cómo denominar elementos, relaciones y diagramas.

Alcance : contexto que proporciona significado a un nombre.

Visibilidad : cómo se ven y utilizan los nombres entre sí.

Integridad : modelado apropiado y consistente de elementos.

No siempre se construyen modelos bien formados:

Abreviados : se ocultan algunos elementos para simplificar

Incompletos : se omiten algunos elementos

Inconsistentes : no se garantiza la integridad del modelo

1.3 – Notación y Modelado Notación: Mecanismo comunes Se aplican durante todo el lenguaje. Tipos: Especificaciones : Cada elemento de la notación gráfica tiene una especificación que describe su semántica y su sintaxis . Se utilizan para enunciar detalles del sistema. Adornos : Permiten representar detalles de especificación . Pueden ser textuales o gráficos. Divisiones comunes: Casi todos los elementos del lenguaje pueden ser entendidos de dos formas ( Clase/objeto , Interfaz/implementación )

Notación: Mecanismo comunes

Se aplican durante todo el lenguaje. Tipos:

Especificaciones :

Cada elemento de la notación gráfica tiene una especificación que describe su semántica y su sintaxis .

Se utilizan para enunciar detalles del sistema.

Adornos :

Permiten representar detalles de especificación .

Pueden ser textuales o gráficos.

Divisiones comunes:

Casi todos los elementos del lenguaje pueden ser entendidos de dos formas ( Clase/objeto , Interfaz/implementación )

1.3 – Notación y Modelado Notación: Mecanismo comunes II Mecanismos de extensión: UML sigue el principio abierto-cerrado. Tipos

Notación: Mecanismo comunes II

Mecanismos de extensión: UML sigue el principio abierto-cerrado. Tipos

1.3 – Notación y Modelado Modelo Un modelo es una simplificación de la realidad. Un buen modelo incluye únicamente los elementos que tienen importancia en el sistema y omite los elementos menores. Tipos Estructural : organización del sistema. Comportamiento : indicando como actúa.

Modelo

Un modelo es una simplificación de la realidad.

Un buen modelo incluye únicamente los elementos que tienen importancia en el sistema y omite los elementos menores.

Tipos

Estructural : organización del sistema.

Comportamiento : indicando como actúa.

1.3 – Notación y Modelado Objetivos del Modelado Visualizar como es ó queremos que sea un sistema. Especificar la estructura o comportamiento del un sistema. Conseguir plantillas para construir un sistema. Documentar las decisiones que tomemos.

Objetivos del Modelado

Visualizar como es ó queremos que sea un sistema.

Especificar la estructura o comportamiento del un sistema.

Conseguir plantillas para construir un sistema.

Documentar las decisiones que tomemos.

1.3 – Notación y Modelado Pasos a seguir.. Enfoque con Orientación a objetos La base fundamental es la clase y el objeto. Objetos que tienen atributos y realizan acciones. Expresaremos diferentes tipos de precisión Debe servir a cliente, analista y desarrollador. Cuanto más ligado a la realidad mejor Permitirá desarrollar correctamente un sistema Usar varios modelos de un mismo sistema Diversas perspectivas del sistema a desarrollar Cada modelo por separado nos dará un tipo de información, pero estarán interrelacionados.

Pasos a seguir..

Enfoque con Orientación a objetos

La base fundamental es la clase y el objeto.

Objetos que tienen atributos y realizan acciones.

Expresaremos diferentes tipos de precisión

Debe servir a cliente, analista y desarrollador.

Cuanto más ligado a la realidad mejor

Permitirá desarrollar correctamente un sistema

Usar varios modelos de un mismo sistema

Diversas perspectivas del sistema a desarrollar

Cada modelo por separado nos dará un tipo de información, pero estarán interrelacionados.

Tema 1.4 Orientación a Objetos

1.4 – Orientación a Objetos Introducción Orientación a Objetos Todo en el mundo que nos rodea son objetos. El desarrollo de software actualmente tiende a imitar al mundo real. Ventajas Producción de sistemas escalables . Fácil mantenimiento . Reutilización de Objetos.

Introducción Orientación a Objetos

Todo en el mundo que nos rodea son objetos.

El desarrollo de software actualmente tiende a imitar al mundo real.

Ventajas

Producción de sistemas escalables .

Fácil mantenimiento .

Reutilización de Objetos.

1.4 – Orientación a Objetos Introducción Orientación a Objetos Generaremos sistemas mediante el uso de objetos Los cuales por sí mismos proporcionan una funcionalidad . La suma de todas las funcionalidades de los objetos de un sistema nos darán el resultado deseado. La supresión de un objeto no afectará Podremos añadir más objetos ( escalabilidad ) Muchos objetos se repetirán ( reutilizar )

Introducción Orientación a Objetos

Generaremos sistemas mediante el uso de objetos

Los cuales por sí mismos proporcionan una funcionalidad .

La suma de todas las funcionalidades de los objetos de un sistema nos darán el resultado deseado.

La supresión de un objeto no afectará

Podremos añadir más objetos ( escalabilidad )

Muchos objetos se repetirán ( reutilizar )

Conclusiones Introducción Introducción Introducción a UML Notación y Modelo Orientación a Objetos Diagramas Proceso Unificado Orígenes y evolución del software. Errores actuales en los proyectos software. Qué es la Ingeniería del Software. Introducción y motivación al modela UML. Elementos de UML. Notación y modelado. Por qué Orientación a Objetos

Introducción

Introducción

Introducción a UML

Notación y Modelo

Orientación a Objetos

Diagramas

Proceso Unificado

Orígenes y evolución del software.

Errores actuales en los proyectos software.

Qué es la Ingeniería del Software.

Introducción y motivación al modela UML.

Elementos de UML.

Notación y modelado.

Por qué Orientación a Objetos

Referencias Guía básica Curso UML.pdf Orientación a Objetos (POO).pdf

Guía básica Curso UML.pdf

Orientación a Objetos (POO).pdf