• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Curso Uml   1 Introduccion
 

Curso Uml 1 Introduccion

on

  • 2,914 views

Primer capítulo 1- Introducción del workshop de UML y proceso Unificado

Primer capítulo 1- Introducción del workshop de UML y proceso Unificado

Statistics

Views

Total Views
2,914
Views on SlideShare
2,911
Embed Views
3

Actions

Likes
6
Downloads
0
Comments
1

2 Embeds 3

http://www.slideshare.net 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Curso Uml   1 Introduccion Curso Uml 1 Introduccion Presentation Transcript

    • 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
    • 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
    • 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.
    • 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.
    • 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)
    • 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...
    • 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...
    • 1.1 – Introducción
      • ¿Por qué un proyecto falla?
    • 1.1 – Introducción a UML
      • ¿Cuántos Proyectos fallan?
    • 1.1 – Introducción
      • Curva de Fallos a lo largo del tiempo
    • 1.1 – Introducción
      • 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.
    • 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.
    • 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
    • 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
    • 1.1 – Introducción
      • Definiciones de ISW
    • 1.1 – Introducción
      • 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.
    • 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 .
    • 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.
    • 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.
    • 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.
    • 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.
    • 1.1 – Introducción al UML
      • Lenguaje UNIFICADO modelado
    • 1.1 – Introducción al UML
      • Participantes en UML
    • 1.1 – Introducción al 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
    • 1.1 – Introducción al UML
      • Modelo conceptual de UML
    • 1.1 – Introducción al 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.
    • 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.
    • 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).
    • 1.1 – Introducción al UML
      • 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.
    • 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.
    • 1.1 – Introducción al 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
    • 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.
    • 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
    • 1.3 – Notación y Modelado
      • 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
    • 1.3 – Notación y Modelado
      • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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:
    • 1.3 – Notación y Modelado
      • 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).
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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 )
    • 1.3 – Notación y Modelado
      • 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.
    • 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.
    • 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.
    • 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.
    • 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 )
    • 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
    • Referencias
      • Guía básica Curso UML.pdf
      • Orientación a Objetos (POO).pdf