La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

© 2007 Microsoft Corporation.. Objeto. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos).

Presentaciones similares


Presentación del tema: "© 2007 Microsoft Corporation.. Objeto. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos)."— Transcripción de la presentación:

1 © 2007 Microsoft Corporation.

2 Objeto. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Clase: Es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Términos orientados a objetos

3

4

5

6

7

8

9

10 Método: algoritmo asociado a un objeto ( o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un mensaje. Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviado el mensaje adecuado al objeto pertinente. Términos orientados a objetos

11 Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera de un objeto, y cuyo valor puede ser alterado por la ejecución de algún método. Términos orientados a objetos

12 Ejemplo de una clase Foco Encender () Apagar()

13 Encapsulamiento: también llamado ocultación de la información.cada objeto esta aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. Características de TOO

14

15 Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. Herencia: los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Características de TOO

16 Ejemplo de polimorfismo operaciones suma (int x, int y) Suma (double x, double y) Suma (char x, char y)

17 Ejemplo de herencia Forma Dibujar () Borrar () Obtienecolor () Poncolor () CirculoRectánguloCuadrado

18

19 Para el siguiente ejercicio, hacer la jerarquía de clases, agregando métodos y atributos a las siguientes clases. Práctica Cursos Escuela Estudiante

20 Proceso.- es una secuencia de pasos para alcanzar un propósito específico. Ingeniería de software PersonasProcedimientos Herramientas Proceso.- es lo que las personas hacen, usando procedimientos, métodos, herramientas, y equipo para transformar un material en un producto.

21 Proceso de desarrollo de SW es un conjunto de actividades, métodos, prácticas y transformaciones que las personas emplean para desarrollar y mantener software y productos asociados tales como planes de proyecto, documentos de diseño, código, casos de prueba, manuales de usuarios, etc.. Ingeniería de software

22 Línea Secuencial (Cascada) Modelos de desarrollo de SW Análisis de requerimientos Diseño Implementación Pruebas y mantenimiento Modelo en espiral Comunicación con el cliente Planificación Análisis de riesgos Diseño Construcción y adaptación Evaluación

23 Ejemplos de otros procesos de desarrollo de SW RUP eXtreme Programming (XP) Microsoft Solution Framework

24 Rational Unified Process (RUP) Consta de 4 fases Inicio Elaboración Construcción Transmisión

25 Esta metodología se basa en: Extreme Programing (XP) Pruebas Unitarias Refabricación Programación de pares Propuestas de XP Empieza en pequeño y añade funcionalidad con retroalimentación continua. El manejo del cambio se convierte en parte sustantiva del proceso El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias El cliente o el usuario se convierte en miembro del equipo

26 XP Extreme Programming La metodología XP (Extreme programing) tiene el propósito de desarrollar un software en un corto tiempo, utilizando las etapas que se cree son las mas importantes, empezando con los requerimientos y posteriormente la diagramación, utilizando la metodología UML. Al momento de utilizar la diagramación UML puedes realizar solo algunos de los diagramas como lo son los diagramas de casos de uso, diagrama de clases y diagrama de implementación.

27 Tiene las siguientes características: Microsoft Solution Framework (MSF) Adaptable Escalable Flexible Tecnología agnóstica Se compone de varios modelos: Modelo de Arquitectura del Proyecto Modelo de Equipo Modelo de Proceso Modelo de Gestión del Riesgo Modelo de Diseño del Proceso Modelo de Aplicación

28 Modelo Visual Modelar.- Es una manera efectiva de administrar la complejidad del desarrollo de SW. Un modelo sirve como una abstracción, una representación aproximadamente del mundo real que se quiere construir.

29 Porque modelar El dominio del problema es bien conocido La solución es relativamente fácil de construir Muy pocas personas colaboran en la construcción de la solución La solución requiere mantenimiento mínimo Es poco probable que haya requerimientos posteriores

30 En que casos modelar Complejidad Riesgos Los participantes iniciales en la solución de la construcción no siempre completan la tarea

31 Modelar un Sistema Provee a los arquitectos e involucrados en el proyecto: La habilidad de visualizar el sistema completo Evaluar diferentes opciones Comunicar el diseño de una manera más clara antes de iniciar con el proyecto Evaluar riesgos técnicos, financieros y de construcción

32 Permite que los desarrolladores: Tengan un mejor entendimiento de lo que van a construir Puedan crear y comunicar los diseños de SW antes de comprometer recursos adicionales Puedan agregar requerimientos al sistema Asegurar que los que están construyendo es lo que el usuario espera Modelar un Sistema

33 Arquitectura basada en modelos Nuevo enfoque originado por Object Management Group para el desarrollo de SW Separar el diseño de la arquitectura y de las tecnologías de construcción Diseño: Requerimientos funcionales Tecnologías de construcción: Requerimientos no funcionales Especificar la arquitectura a un nivel de mayor detalle incluyendo tecnologías de la capa de presentación, de la capa de negocio, de persistencia o tecnología de mapeo o de persistencia

34 Los métodos de análisis y diseño Un método define un sistema reproducible para obtener resultados fiables. Todos los ámbitos del conocimiento utilizan métodos mas o menos sofisticados y mas o menos formalizados. Los cocineros hablan de recetas de cocina, los pilotos realizan check- list antes de despegar. Los arquitectos dibujan planos y los músicos siguen reglas de composición. Asimismo, un método de elaboración de programas describe cómo modelar y construir sistemas de programas de manera fiable y reproducible. ¿Qué es un método?

35 Los métodos de análisis y diseño De manera general, los métodos permiten construir modelos a partir de elementos de modelado que constituyen los conceptos fundamentales para la representación de sistemas o fenómenos. Las notas escritas sobre las partituras son elementos de modelado para la música. La aproximación orientada a objetos propone el equivalente de las notas – los objetos – para la representación de los programas. ¿Qué es un método?

36 Los métodos de análisis y diseño Los métodos definen también una representación – a menudo gráfica – que permite, por una parte, manipular fácilmente los modelos y, por otra, comunicar e intercambiar la información entre los diferentes interlocutores. Una buena representación busca el equilibrio entre la densidad de información y la legibilidad Además de los elementos de modelado y de sus representaciones gráficas, un método define reglas de implementación que describen la articulación de los diferentes puntos de vista, el encadenamiento de las acciones, la ordenación de las tareas y el reparto de las responsabilidades. ¿Qué es un método?

37 Principales etapas de la definición de UML En desarrollo 2004…) Adaptación oficial 2003 Estandarización por el OMG Sumisión al OMG- enero 97 Versión Beta OOPSLA 96 www – junio 96 OOPSLA 95 Comentarios Otros métodos UML 2.0 UML 1.5 UML 1.0 UML 0.9 Método unificado 0.8 Booch 91 Booch 93 OMT -1 OMT-2 OOSE Colaboradores Especificación disponible en Internet Especificación disponible en Internet Juego de documentación

38

39

40 Modelo de casos de uso Flujos de evento

41 Actores Un actor representa una persona, hardware o sistema externo que interactúa con el sistema. En UML un actor es representado de la siguiente manera: actor Cliente comercial Cliente Generalización Ejemplo:

42 Casos de uso Un caso de usos especifica el comportamiento de un sistema o una parte de un sistema y es una descripción de una secuencia de acciones incluyendo las variantes que un sistema desarrolla para ofrecer un resultado observable a un actor. El objetivo de un caso de uso es definir el comportamiento de un sistema. Un caso de uso es representado de la siguiente manera: Nombre

43 Casos de uso (continuación) Los casos de uso deben de tener un nombre que permita distinguir entre un caso de uso y otro. Se recomienda que los casos de uso sean cortos, verbos y que indiquen el comportamiento del sistema que se está modelando. Registra pedido Valida usuario Nombre simple

44 Diagramas de Casos de uso Un diagrama de casos de uso es uno de los diagramas en UML para modelar la funcionalidad del sistema Muestra un conjunto de casos de uso, actores y sus relaciones. Son utilizados para modelar la vista del sistema. Modelando el contexto del sistema Modelando los requerimientos del sistema.

45 Diagramas de Casos de uso (Modelando el contexto del sistema) Cliente individual Cliente corporativo Cliente Administra cuenta Ejecuta transacción Institución de autoservicio Institución financiera Sistema de validación de tarjetas de crédito

46 Paquetes de Casos de uso En UML el paquete es un mecanismo de propósito general para organizar los elementos del modelado de grupos. Reglas de negocio

47 Flujos de eventos Documentación de un caso de uso Flujos primarios y alternos Análisis de casos de uso

48 Flujos primarios y alternos El flujo de eventos se utiliza para especificar el comportamiento de un caso de uso, indicando como y cuando inicia y termina. Registra pedido Administración de pedidos Realización

49 > y > generalización. > y > generalización. El primero indica que el Caso de Uso requiere de usar otro caso de uso para poder ser llevado a cabo. Esta es una forma muy adecuada de sacar factor común entre Casos de Uso, o incluso de fraccionar Casos de Uso muy grandes. El segundo indica que un Caso de Uso es una variación de otro caso de uso. Observamos también que Comer pan y Beber cafe son una generalización de Alimentarse.

50 Ejemplo ( Generalización, Include, Extend) Registra pedido Registra pedido especial Seguimiento de pedidos Valida usuario Valida contraseña Escanea retina >

51 Ejemplo (Diagrama de Casos de uso) Teléfono celular Usuario Red de teléfonos celulares Registra llamada Recibe llamada Agenda de usuario Registra conferencia Recibe Llamadas adicionales

52 Análisis de casos de uso Identificar los actores Organizar los actores Para cada actor, considerar la forma principal en que interactúa con el elemento Considerar excepciones Organizar el comportamiento en casos de uso (aplicando include y extend)

53 Ejemplo Registra pedido Cobros Seguimiento de pedidos Entrega pedido Valida cliente Entrega pedido especial >

54 Documentación de caso de uso La documentación de los casos de uso puede ser realizada de la siguiente manera Documentando los escenarios a través de texto Mediante colaboración y organizando los casos de uso

55 Casos de uso Caso de uso: Reporte Numero del caso de uso: 3 Actores : Propósito: Resumen: Tipo: Primario y esencial Referencias cruzadas: Curso normal de los eventos Acción del actor Respuesta del sistema Documentación de caso de uso

56 Requerimientos Caso de estudio: punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de código de barra) y software (el sistema que se ejecuta en la terminal)

57 Requerimientos a) a)Panorama general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizara en las ventas de un supermercado. b) Metas En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar soporte a servicios mas rápidos, mas baratos y mejores. Concretamente, la meta incluye: Pago rápido de los clientes. Análisis rápido y exacto de las ventas. Control automático del inventario.

58 Requerimientos c) Funciones del sistema Las funciones del sistema son lo que este deberá de hacer: Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben de realizarse, y el usuario debe de saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras funciones.

59 Estas son algunas de las funciones del sistema de punto de venta: Ref.FunciónCategoría R1.1 Registra la venta en proceso (actual): los productos comprados. R1.2 Calcula el total de la venta actual, se incluye el impuesto. R1.3 Captura la información sobre el objeto comprado usando su código de barras, o usando una captura manual del código de producto. R1.4 Reduce las cantidades del inventario cuando se realiza una venta. R1.5 Se registran las ventas efectuadas. R1.6 El cajero debe de introducir una identificación y una contraseña para poder utilizar el sistema. R1.7 Ofrece un mecanismo de almacenamiento persistente. R1.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas. R1.9 Muestra la descripción y el precio del producto registrado. Requerimientos

60 Casos de uso Diagrama UML de casos de uso para el sistema de punto de venta: Cliente Entrega el cambio de los productos comprados Compra productos Punto de venta Registra los datos Cajero Este esquema tiene por objeto ofrecer un diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que estos lo utilizan.

61 Casos de uso Un diagrama de casos de uso más refinado seria el siguiente: Cliente Entrega el cambio de los productos comprados Compra productos Punto de venta Registra los datos Cajero Administra a los usuarios Inicia termina Gerente Adm. Del sistema

62 Práctica Sistema de control escolar. Inscripción Alta de materias Lista de profesores Sistema de inscripciones Reportes Reporte de calificaciones Cardex Boletas de calificaciones

63 7. Diagrama de clases

64 Clases Clases Operaciones Operaciones Relaciones de herencia, agregación y dependencia Relaciones de herencia, agregación y dependencia Multiplicidad Multiplicidad Diagrama de clases

65 Es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Describe un conjunto de objetos que tienen características y comportamiento idéntico. Describe un conjunto de objetos que tienen características y comportamiento idéntico. Clases

66 Atributos Es un componente de información que el objeto conoce de si mismo. Es un componente de información que el objeto conoce de si mismo. Elementos de un atributo. Elementos de un atributo. Visibilidad Visibilidad Nombre del atributo Nombre del atributo Tipo de dato Tipo de dato Valor por defecto Valor por defecto

67 Operaciones Una operación es la implementación de un servicio del cual puede ser solicitado por cualquier objeto de la clase para afectar su comportamiento. Una operación es la implementación de un servicio del cual puede ser solicitado por cualquier objeto de la clase para afectar su comportamiento. Elementos de una operación: Elementos de una operación: Nombre de operación Nombre de operación Argumentos Argumentos Tipo de dato a regresar. Tipo de dato a regresar. Visibilidad Visibilidad

68 Visibilidad Es el adjetivo que se le asigna a las operaciones o atributos de una clase y especifica cuando puede ser usado por otras clases. Es el adjetivo que se le asigna a las operaciones o atributos de una clase y especifica cuando puede ser usado por otras clases. Public.- El método o atributo puede ser utilizado por cualquier clase(+). Public.- El método o atributo puede ser utilizado por cualquier clase(+). Protected.- El método o atributo puede ser utilizado por cualquier descendiente de la clase (#). Protected.- El método o atributo puede ser utilizado por cualquier descendiente de la clase (#). Private.- El método o atributo puede ser utilizado solo por la misma clase(-). Private.- El método o atributo puede ser utilizado solo por la misma clase(-).

69 Ejemplo: Toolbar # CurrentSelection: Tool # ToolCourt: Integer + pickItem (i: integer) + addTool (t: Tool) + removeTool: (i: integer) + getTool () : Tool # checkOrphans () - Compact () Protected Public Private

70 Relaciones de Herencia y asociación La asociación es una relación que indica la comunicación que existe entre dos clases. La asociación es una relación que indica la comunicación que existe entre dos clases. La herencia es representada con una relación de generalización entre clases (una clase base y subclases). La herencia es representada con una relación de generalización entre clases (una clase base y subclases).

71 Ejemplo Window Open()close()move()display() ConsoleWindowDialogBox Control Generalización Asociación

72 Multiplicidad La Multiplicidad se utiliza para indicar cuantos objetos pueden estar conectados a través de una relación de asociación. La Multiplicidad se utiliza para indicar cuantos objetos pueden estar conectados a través de una relación de asociación. Persona Compañía Empleado Multiplicidad Asociación Empleador 1.. *1

73 Tipos de clases Abstracta: Son clases que no tienen instancias de forma directa, en UML es especificada con el nombre en tipo de letra cursiva. Abstracta: Son clases que no tienen instancias de forma directa, en UML es especificada con el nombre en tipo de letra cursiva. Raíz.- Es una clase que no tiene padres, en UML es especificada escribiendo root abajo del nombre de la clase. Raíz.- Es una clase que no tiene padres, en UML es especificada escribiendo root abajo del nombre de la clase. Hoja: Es una clase que no tiene hijos, en UML es especificada escribiendo leaf abajo del nombre de la clase. Hoja: Es una clase que no tiene hijos, en UML es especificada escribiendo leaf abajo del nombre de la clase.

74 Ejemplo Icon(root) Origin: Point Display ( ) Get ID ( ): integer (leaf) RectangularIcon Height: integer Width: integer ArbitraryIcon Edge: LineCollection IsInside (p: Point) : Boolean Button Display ( ) OKButton(leaf) Clase abstracta Clase base Operación abstracta Clase abstracta Clase leaf Clase concreta

75 Agregación y Composición Equipo Jugador Composición Agregación LibroPagina

76 8.- Diagramas de Secuencia

77 Clases y Objetos Una clase es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Un objeto es la instancia de la clase. Un objeto es la instancia de la clase.

78 Diagrama de Secuencia Un diagrama de secuencia es un diagrama de interacción que se utiliza para modelar el aspecto dinámico del sistema. Un diagrama de secuencia es un diagrama de interacción que se utiliza para modelar el aspecto dinámico del sistema. El diagrama de secuencia hace énfasis en el orden de ejecución de los mensajes con respecto al tiempo. El diagrama de secuencia hace énfasis en el orden de ejecución de los mensajes con respecto al tiempo.

79 Línea de vida La línea de vida de un objeto es una línea punteada vertical que representa la existencia de un objeto en un tiempo determinado. La línea de vida de un objeto es una línea punteada vertical que representa la existencia de un objeto en un tiempo determinado. Cliente Línea de vida

80 Foco de control El foco de control de un objeto es un rectángulo que muestra el tiempo durante el cual un objeto está ejecutando una acción de forma directa o a través de un procedimiento subordinado. El foco de control de un objeto es un rectángulo que muestra el tiempo durante el cual un objeto está ejecutando una acción de forma directa o a través de un procedimiento subordinado. Cliente Foco de control

81 Mensajes y Operaciones Un mensaje es la especificación de la comunicación entre objetos. Un mensaje es la especificación de la comunicación entre objetos. Cuando un mensaje es enviado, la acción que resulta es una sentencia ejecutable que forma una abstracción de un procedimiento computacional. Cuando un mensaje es enviado, la acción que resulta es una sentencia ejecutable que forma una abstracción de un procedimiento computacional. Call.- Invoca a una operación a un objeto. Call.- Invoca a una operación a un objeto. Return.- Regresa un valor de regreso a quien lo invoco. Return.- Regresa un valor de regreso a quien lo invoco. Send.- Envía una señal a un objeto. Send.- Envía una señal a un objeto. Create.- Crea un objeto. Create.- Crea un objeto. Destroy.- Destruye un objeto. Destroy.- Destruye un objeto. Operación: Es la implementación de un servicio que puede recibir peticiones de un objeto. Operación: Es la implementación de un servicio que puede recibir peticiones de un objeto.

82 Mensajes y operaciones (ejemplo) c:Client TicketAgent p:Planning Assistance Create Return Destroy Call Send Destroy Route Setltinerary (l) Create Notity() X CalculateRoute()

83 Diagrama de colaboración Un diagrama de colaboración es un diagrama de interacción que se utiliza para modelar el aspecto dinámico del sistema. Un diagrama de colaboración es un diagrama de interacción que se utiliza para modelar el aspecto dinámico del sistema. El diagrama de colaboración hace énfasis en la organización de los objetos que participan en la interacción. El diagrama de colaboración hace énfasis en la organización de los objetos que participan en la interacción.

84 EJEMPLO DIAGRAMA DE COLABORACIÓN


Descargar ppt "© 2007 Microsoft Corporation.. Objeto. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos)."

Presentaciones similares


Anuncios Google