Unidad 1 Mad IntroduccióN

1,693 views
1,471 views

Published on

Curso Metodologías de Análisis y Diseño - Usando UML - Capt. 1

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,693
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
116
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Unidad 1 Mad IntroduccióN

  1. 1. Metodologías de Análisis y Diseño Unidad I Introducción a la Orientación a Objetos y el Modelado Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
  2. 2. ¿Por qué la Orientación a Objetos? Principalmente porque la mayoría de los sistemas que se están desarrollando hoy en día están adoptando algunas o todas las nociones que involucra la orientación a objetos. Un poco de Historia. AÑOS 80: no se soluciona la “crisis del software” - poca capacidad de estimación - baja calidad de los programas - elevados costes de mantenimiento - duplicación de esfuerzos (ausencia de reutilización) ENFOQUE DE OBJETOS COMO ALTERNATIVA SIMULA (Noruega, 1967): lenguaje de simulación de sucesos SMALLTALK (PARC, años 70): combina el concepto de clase de SIMULA con la capacidad de abstracción funcional del LISP. Años 80 : Interés por las IGU (interfaces gráficas de usuario): su elevada complejidad se compensa con un alto grado de reutilización. Finales 80 y principios 90: interés por los métodos O.O. (diseño, especificación,...) ENFOQUE ESTRUCTURADO
  3. 3. ¿Qué es la Orientación a Objetos? Es un enfoque de desarrollo de software que organiza tanto el problema como su solución como una colección de objetos discretos, tanto la estructura de datos como el comportamiento están incluidos en la representación. Una representación orientada a objetos (OO) puede reconocerse por sus siete características: Abstracción, Identidad, Clasificación, Encapsulamiento, Herencia, Polimorfismo y Persistencia. Algunas representaciones solo se basan en un subconjunto de estas características. A estas les llamaremos basadas en objetos.
  4. 4. Características - Identidad Se refiere al hecho de que los datos son organizados en entidades discretas y distinguibles. Denominadas objetos. ¿Qué es un objeto? Conceptualmente, un objeto es una cosa con la que se puede interactuar: se le pueden enviar varios mensajes y éste reacciona ante ellos. De está forma , un objeto simple tiene estados y comportamientos asociados. (Grady Booch).
  5. 5. Características - Identidad ¿Qué es un objeto? Ejemplo: Sistema para el manejo del dique de un río El Dique es un objeto Cada Objeto posee un nombre, el que lo distingue de otros objetos. ¿Qué es el estado de un objeto? El estado de un objeto lo constituyen todos los datos que encapsula en un momento determinado. Un objeto normalmente tiene un número de lo que se conoce como atributos cada uno de los cuales tiene un valor. En la mayoría de los lenguajes orientados a objetos (LOO), hoy en día el conjunto de atributos de un objeto no puede cambiar durante su vida, pero si sus valores.
  6. 6. Características - Identidad ¿Qué es el estado de un objeto? Ejemplo: <ul><li>Estados del Dique </li></ul><ul><li>Dique Completamente Cerrado </li></ul><ul><li>-Dique Completamente Abierto </li></ul>¿Qué es el comportamiento de un objeto? Es la manera como actúa y reacciona un objeto, en función de sus cambios de estado y el paso de mensajes. Un objeto comprende ciertos mensajes, lo que quiere decir que puede recibir mensajes y actuar sobre ellos. El conjunto de mensajes que entiende un objeto, al igual que el conjunto de atributos que tiene, normalmente está fijado.
  7. 7. Características - Identidad ¿Qué es el comportamiento de un objeto? Ejemplo: Comportamientos del Dique Alarma sonora: Avisa a los cercanos que un dique cambia de estado cerrado a abierto. (Para que se alejen) ¿Qué son los mensajes? Los mensajes son el medio a través del cual los objetos interactúan Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operación. 
  8. 8. Características - Abstracción Está característica es importante para crear cualquier sistema sea orientado a objetos o no. Ayuda a representar los diferentes puntos de vista incorporados en el sistema que se desarrolla.
  9. 9. Características - Clasificación Se permite agrupar objetos que tienen atributos y comportamientos en común (Concepto de clases). GRUPO DE AVIONES GRUPO DE AUTOS
  10. 10. Características - Clasificación ¿Qué es una Clase? Una clase describe un conjunto de objetos que tiene un rol o roles equivalentes en el sistema. En los lenguajes O.O basados en clases, cada objeto pertenece a una clase, y la clase de un objeto es quien determina su interfaz. Los atributos que tiene un objeto vienen determinados por su clase, aunque, por supuesto, los valores que toman dichos atributos no están determinados por la clase, pudiendo variar. Los objetos de una misma clase tienen las mismas interfaces.
  11. 11. Características - Clasificación ¿Qué es una Clase? Una clase se puede representar usando una caja. Es importante mencionar que la clasificación refleja la perspectiva de la persona o grupo de trabajo que la realizo. Ej.: Se podrían a ver colocado bicicletas y aviones en la clase vehículos de transporte.
  12. 12. Características - Clasificación ¿Qué es una Clase? Se dice que un “objeto” es una instancia de una clase. Cada instancia tiene sus propios atributos (es decir, tiene sus propio estado en cualquier instante de tiempo), pero comparte nombre y comportamiento con las otras instancias de la clase. Por lo tanto una clase describe un conjunto de objetos que comparten una estructura común y tienen comportamientos comunes, pero los valores de los atributos nos ayudan a distinguir cada objeto particular.
  13. 13. Características - Encapsulamiento Las clases encapsulan los atributos y comportamientos de un objeto, ocultando los detalles de implementación. Es un complemento de la abstracción. ABSTRACCION ENCAPSULAMIENTO Empleado Empleado DNI Nombre Categoría Contratar Pagar Despedir
  14. 14. Características - Encapsulamiento La encapsulación no es lo mismo que el ocultamiento de información. El encapsulamiento es una técnica para empaquetar la información de tal forma que se oculte lo que debe ser ocultado y se haga visible lo que está pensando que sea visible.
  15. 15. Características - Herencia Las clases pueden ser organizadas jerárquicamente de acuerdo con las semejanzas y diferencias entre ellas. Para construir las jerarquías se comienza definiendo ampliamente una clase para refinarla luego en subclases más especializadas. Una subclase puede heredar la estructura así como el comportamiento y atributos de su superclase. Clase Abstracta, es una clase que no tiene instancias solo subclases.
  16. 16. Características - Polimorfismo Cuando el comportamiento se manifiesta de maneras diferentes en diferentes clases o subclases, estamos hablando de polimorfismo. Ej.: Una implementación especifica de una operación para una cierta clase se denomina “método”. En un sistema con polimorfismo, una operación puede tener más de un método que la implemente.
  17. 17. Características - Persistencia La capacidad del nombre, estados y comportamientos de un objeto para trascender el espacio o el tiempo. En otras palabras, el nombre, estado y comportamiento de un objeto se conservan cuando el objeto es transformado.
  18. 18. Proceso de Desarrollo OO <ul><li>Una ventaja del desarrollo OO es su consistencia de lenguaje, ya que tanto el problema como la solución pueden describirse en los mismos términos: clases, objetos, métodos, atributos y comportamientos. </li></ul><ul><li>La representación orientada a OO requiere tres perspectivas: </li></ul><ul><ul><li>Vistas Estáticas: incluyen descripciones de los objetos, atributos, comportamientos, y relaciones. </li></ul></ul><ul><ul><li>Vistas Dinámicas: describen comunicación, control / temporización, estados y cambios de estado. </li></ul></ul><ul><ul><li>Restricciones: describen las limitaciones en la estructura (como valores de atributos o cardinalidad) y en el comportamiento dinámico. </li></ul></ul>
  19. 19. Proceso de Desarrollo OO La consistencia a través del proceso es una diferencia clave entre los procedimientos de desarrollo más tradicionales y el proceso de desarrollo OO. Un proceso OO utiliza el encapsulamiento de datos y el comportamiento para formar unidades independientes (objetos). Y estas mismas estructuras semánticas representan el sistema desde los requerimientos a la implementación y prueba de la aplicación. Por lo tanto, la OO es una filosofía de representación de problema solución, y no una representación del ciclo de vida en sí. De está forma, la OO puede aplicarse en cualquiera de los ciclos de vida, desde el modelo en cascada al espiral.
  20. 20. Proceso de Desarrollo OO Requerimientos en OO El análisis OO de requerimientos usualmente se realiza en el lenguaje del usuario y discute los conceptos y escenarios probablemente en el dominio de la aplicación. Los conceptos incluyen información, servicio y responsabilidades. El conocimiento del dominio habilita a los desarrolladores para entender el contexto en el cual se usará el sistema y para describir requerimientos de una forma tal que los usuarios los entenderán. Hay que tener claro ,por su puesto, que la definición de requerimientos puede ser independiente de sus representaciones como objetos.
  21. 21. Proceso de Desarrollo OO Diseño OO <ul><li>Hay dos pautas que se aplican para representar el diseño de un sistema en una forma orientada a objetos. </li></ul><ul><ul><li>Es importante identificar y definir clases y objetos. Se deben conocer no sólo los objetos del mundo real (el dominio del problema – similar a la especificación de requerimientos) sino también los detalles de cada objeto, sus atributos y comportamientos. </li></ul></ul><ul><ul><li>Se deben identificar las interacciones y relaciones entre objetos y clases; sus asociaciones , composiciones, agregaciones y relaciones de herencia. </li></ul></ul>
  22. 22. Proceso de Desarrollo OO Diseño OO Se considera que el diseño del sistema es una abstracción de alto nivel de lo que será en el futuro el diseño del programa.
  23. 23. Proceso de Desarrollo OO Codificación y Prueba OO Una vez hecho el diseño, se describe el sistema a un nivel muy bajo, usando modelos de objetos, atributos y comportamientos. La codificación procede traduciendo los modelos a un lenguaje de programación OO. Este proceso no es trivial, por lo general a los implementadores les resulta necesario refinar las estructuras jerárquicas y efectuar ajustes a medida que los requerimientos crecen y maduran. Las pruebas del sistema siguen el mismo curso (Prueba Unitaria, Integración y del sistema).
  24. 24. Proceso de Desarrollo OO Codificación y Prueba OO Acá se muestran los diferentes niveles de abstracción, y su relación con las pruebas. Sistema Subsistema Jerarquía de Clases Clase Niveles de abstracción Prueba del Sistema Prueba Unitaria Prueba de Integración Prueba de Sistema
  25. 25. Modelado del Sistema <ul><li>¿Por qué modelamos? </li></ul><ul><ul><li>Actividad y productos complejos. </li></ul></ul><ul><ul><li>Modelo: simplificación de la realidad. </li></ul></ul><ul><ul><li>Se construyen modelos para comprender mejor el sistema que se está desarrollando. </li></ul></ul>
  26. 26. Modelado del Sistema <ul><li>Objetivos de la utilización de modelos </li></ul><ul><ul><li>Ayudan a visualizar cómo es o queremos que sea un sistema. </li></ul></ul><ul><ul><li>Especificar la estructura y/o el comportamiento. </li></ul></ul><ul><ul><li>Proporcionar plantillas que guíen en la construcción. </li></ul></ul><ul><ul><li>Documentar las decisiones adoptadas. </li></ul></ul>
  27. 27. Modelado del Sistema <ul><li>Principios Modelado </li></ul><ul><ul><li>La elección de qué modelos crear tiene gran influencia sobre cómo se acomete un problema y cómo se da forma a una solución. </li></ul></ul><ul><ul><li>Todo modelo puede ser expresado a diferentes niveles de precisión. </li></ul></ul><ul><ul><li>Los mejores modelos están ligados a la realidad. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  28. 29. UML: ¿ Qué es UML? <ul><li>UML = U nified M odeling L anguage </li></ul><ul><li>Un lenguaje de propósito general para el modelado orientado a objetos. </li></ul><ul><li>Documento “OMG Unified Modeling Language Specification” </li></ul><ul><li>UML combina notaciones provenientes desde: </li></ul><ul><ul><li>Modelado Orientado a Objetos </li></ul></ul><ul><ul><li>Modelado de Datos </li></ul></ul><ul><ul><li>Modelado de Componentes </li></ul></ul><ul><ul><li>Modelado de Flujos de Trabajo (Workflows) </li></ul></ul>
  29. 30. UML: Situación de Partida <ul><li>Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones. </li></ul><ul><li>Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc. </li></ul><ul><li>Pugna entre distintos enfoques (y correspondientes gurús) </li></ul><ul><li> </li></ul><ul><li>Establecer u na notación estándar </li></ul>
  30. 31. UML: Historia <ul><li>Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. </li></ul><ul><li>El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose. </li></ul>
  31. 32. UML: Historia Nov ‘97 UML aprobado por el OMG 1998 1999 2000 UML 1.2 UML 1.3 UML 1.4 2001-2003 UML 2.0 Revisiones menores
  32. 33. UML: Participantes en UML 1.0 <ul><li>Rational Software </li></ul><ul><li>(Grady Booch, Jim Rumbaugh y Ivar Jacobson) </li></ul><ul><li>Digital Equipment </li></ul><ul><li>Hewlett-Packard </li></ul><ul><li>i-Logix (David Harel) </li></ul><ul><li>IBM </li></ul><ul><li>ICON Computing </li></ul><ul><li>(Desmond D’Souza) </li></ul><ul><li>Intellicorp and James Martin & co. (James Odell) </li></ul><ul><li>MCI Systemhouse </li></ul><ul><li>Microsoft </li></ul><ul><li>ObjecTime </li></ul><ul><li>Oracle Corp. </li></ul><ul><li>Platinium Technology </li></ul><ul><li>Sterling Software </li></ul><ul><li>Taskon </li></ul><ul><li>Texas Instruments </li></ul><ul><li>Unisys </li></ul>
  33. 34. UML: Aglutinamiento de enfoques UML Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion Embly Gamma et. al. Shlaer-Mellor Odell Booch Pre- and Post-conditions State Charts Responsabilities Operation descriptions, message numbering Singleton classes Frameworks, patterns, notes Object life cycles
  34. 35. UML: Inconvenientes <ul><li>Definición del proceso de desarrollo usando UML. UML no es una metodología. </li></ul><ul><li>Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc. </li></ul><ul><li>Ejemplos aislados. </li></ul><ul><li>“ Monopolio de conceptos, técnicas y métodos en torno a UML”. </li></ul>
  35. 36. UML: Perspectivas <ul><li>UML será el lenguaje de model ado orientado a objetos estándar predominante los próximos años. </li></ul><ul><li>Razones: </li></ul><ul><ul><li>Participación de metodólogos influyentes. </li></ul></ul><ul><ul><li>Participación de importantes empresas. </li></ul></ul><ul><ul><li>Aceptación del OMG como notación estándar. </li></ul></ul><ul><li>Evidencias: </li></ul><ul><ul><li>Herramientas que proveen la notación UML. </li></ul></ul><ul><ul><li>“ Edición ” de libros. </li></ul></ul><ul><ul><li>Congresos, cursos, “ camisetas” , etc. </li></ul></ul>
  36. 37. UML: Modelo Conceptual <ul><li>Bloques de construcción de UML: </li></ul><ul><ul><li>Elementos </li></ul></ul><ul><ul><ul><li>Estructurales (clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y nodos) </li></ul></ul></ul><ul><ul><ul><li>Comportamiento (interacción, máquina de estados) </li></ul></ul></ul><ul><ul><ul><li>Agrupación (paquetes) </li></ul></ul></ul><ul><ul><ul><li>Anotación (notas) </li></ul></ul></ul><ul><ul><li>Relaciones </li></ul></ul><ul><ul><ul><li>Dependencia </li></ul></ul></ul><ul><ul><ul><li>Asociación </li></ul></ul></ul><ul><ul><ul><li>Generalización </li></ul></ul></ul><ul><ul><ul><li>Realización </li></ul></ul></ul><ul><ul><li>Diagramas </li></ul></ul>
  37. 38. UML: Modelo Conceptual <ul><li>Modelo Estático </li></ul><ul><ul><li>Construye y documenta los aspectos estáticos de un sistema. </li></ul></ul><ul><ul><li>Refleja la estructura básica y estable de un sistema software. </li></ul></ul><ul><ul><li>Crea una representación de los principales elementos del dominio del problema </li></ul></ul><ul><ul><li>Se compone de: </li></ul></ul><ul><ul><ul><li>Diagramas de Casos de Uso </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Clases </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Objetos </li></ul></ul></ul><ul><ul><ul><li>Diagramas de componentes </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Despliegue </li></ul></ul></ul><ul><li>Modelo Dinámico </li></ul><ul><ul><li>Crea los diagramas que muestran el comportamiento de un sistema </li></ul></ul><ul><ul><li>Se compone de los siguientes diagramas: </li></ul></ul><ul><ul><ul><li>Diagramas de Secuencia </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Colaboración </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Transición de Estados </li></ul></ul></ul><ul><ul><ul><li>Diagramas de Actividad </li></ul></ul></ul>
  38. 39. UML: Arquitectura Vista de diseño Vista de procesos Vista de despliegue Vista de implementación Vista de casos de uso Comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solución. Aspectos estáticos : diagramas de clases y objetos. Aspectos dinámicos : diagramas de interacción, de estados y de actividades Comprende los casos de uso que describen el comportamiento del sistema, tal y como es percibido por los usuarios finales, analistas y encargados de pruebas. Aspectos estáticos : diagramas de casos de uso. Aspectos dinámicos : diagramas de interacción, de estados y de actividades Comprende los hilos (threads) y procesos que forman los mecanismos de sincronización y concurrencia del sistema Aspectos estáticos y dinámicos : los mismos que la vista de diseño, pero con énfasis en las clases activas Comprende los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico. Aspectos estáticos : diagramas de componentes. Aspectos dinámicos : diagramas de interacción, de estados y de actividades Contiene los nodos que forman la topología hardware. Aspectos estáticos : diagramas de despliegue. Aspectos dinámicos : diagramas de interacción, de estados y de actividades
  39. 40. Bibliografía <ul><li>Guía del Tópico: </li></ul><ul><li>Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap. 6) </li></ul><ul><li>Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002. </li></ul><ul><li>Utilización de UML en ingeniería del software con objetos y componentes – Perdita Stevens & Rob Pooley – Addison Wesley – 2002. </li></ul><ul><li>UML y Patrones una introducción al análisis y diseño orientados a objeto y al proceso unificado – Craig Larman – Prentice Hall - 2002. </li></ul>

×