Capitulo 5: modelado de objetos

Esquema De los casos de uso de los diagramas de clases Modelo y la realidad Un pequeño discurso de filosofía Las actividades durante el modelado de objetos Identificación de objetos Los tipos de objetos entidad, los límites y el control de los objetos Nombre de Objetos La técnica de Abbott ayuda en la identificación de objetos Los usuarios de los diagramas de clases Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

De los casos de uso a los objetos Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 1 Caso de Uso Nivel 2 Caso de Uso Objetos Participantes Operaciones Caso de Uso Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

De los casos de uso a los objetos: ¿Por qué la descomposición funcional no es suficiente? Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 1 Caso de Uso Nivel 2 Caso de Uso Caso de Uso Operaciones Objetos Participantes Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Realidad y Modelo Realidad R: Modelo M: Cosas Reales. Personas. Procesos que ocurren durante algún tiempo. Relación entre las cosas. Modelo M: Abstracciones de (realmente existente o sólo pensaba en) las cosas. Procesos y relaciones entre estas abstracciones. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿por qué los Modelos? Utilizamos modelos: Para abstraer los detalles en la realidad, para que podamos sacar conclusiones complicadas en la realidad con simples pasos en el modelo. Para obtener ideas sobre el pasado o la presencia. Para hacer predicciones sobre el futuro. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Qué es un "buen" modelo? Las relaciones, que son válidas en la realidad R, también son válidas en el modelo M. I: Mapeo de las cosas reales en la realidad R a la abstracción en el modelo M abbildet (interpretación). fM: relación entre las abstracciones en M. fR: la relación entre cosas reales en R. En un buen modelo el siguiente diagrama es conmutativo: fM fR M R I Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Los modelos son falsificables En la Edad Media la gente creía en la verdad. Los modelos de la realidad no puede ser verdad. Un modelo es siempre una aproximación Hay que decir ", de acuerdo a nuestro conocimiento", o "con el conocimiento de hoy”. Popper ("conocimiento objetivo): Sólo podemos construir modelos de la realidad, que son "verdaderas", hasta que hemos encontrado un ejemplo de lo contrario (principio de falsificación) Y aun así podríamos seguir con el modelo ("porque funciona muy bien en la mayoría de los ajustes"). El principio de la falsificación es la base del desarrollo de software El objetivo de prototipos, críticas y pruebas del sistema es falsificar el sistema de software. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modelos de modelos de modelos… El modelado es relativo. Podemos pensar en un modelo como una realidad y se puede construir otro modelo de la misma (con abstracciones adicionales). El desarrollo de sistemas de software es una transformación de los modelos: Análisis, diseño, implementación, pruebas del sistema fM1 fR M1 R Obtención Requerimientos I1 M2 Análisis I2 fM2 …. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Un pequeño discurso en Filosofía La filosofía trabaja en 3 grandes problemas Metafísica: ¿Cuál es la realidad?. Epistemología: ¿Qué es el conocimiento? ¿Cómo podemos almacenar el conocimiento en nuestro cerebro? ¿Hasta qué punto puedo describir la realidad con el conocimiento?. Ética: ¿Qué es bueno, lo que es malo?. La metafísica y la epistemología dependen unos de otros: Las afirmaciones acerca de la realidad dependen estrechamente de las afirmaciones sobre el conocimiento y viceversa. Relación con la ingeniería de software Metafísica: <=> Modelado. Epistemología: <=> Adquisición de los conocimientos de gestión del conocimiento. Ética: <=> Buenas y malas prácticas durante el desarrollo de software. La informática tiene que lidiar con problemas similares a los de la metafísica y la epistemología Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Las cuatro preguntas básicas de la metafísica ¿La realidad es real o no es real? ¿Tiene la realidad sólo existen en nuestro cerebro o existe independientemente de nuestra existencia? ¿Qué se hizo realidad de? ¿Cuántas Realidades existen (1,2, muchas)? ¿La realidad es constante o cambia? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

1. Realidad: ¿real o ideal? El realismo metafísico supone, que la realidad es real La realidad existe fuera de nuestro cerebro. Se trata de "realidad" real. Los subtipos de realismo: Realismo Ingenuo: las cosas son reales, eso es un hecho!. Realismo Crítico (realismo trascendental): las cosas son reales, pero sólo veo lo que quiero ver. Realismo Pragmático: Obras de Realismo, es por eso que la realidad es real. El idealismo metafísico asume que la realidad es una ilusión. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Categorización de los distintos tipos de realismo Ejemplo de una categorización (Taxonomía, ontología) Realismo Metafísico Ingenuo Crítico Pragmático Realismo Metafísico Realismo Ingenuo Realismo Crítico Realismo Pragmático Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

2. ¿Qué es la realidad de? Materialismo: Antimaterialismo: La realidad se compone de cosas reales. Sócrates: Todo está hecho de agua. Antimaterialismo: La realidad se compone de cosas reales, así como de las ideas. Platón: La forma, la belleza, por ejemplo, es tan real como las cosas reales, por ejemplo, Este pequeño tren (de hecho, las formas son más reales, porque son cosas permanentes, reales vivir sólo por un corto tiempo). El materialismo científico: La realidad consiste solamente en cosas que no tienen la energía y/o la masa. La ciencia moderna: la capacidad de leer la mente no es real. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modelo Antimaterialismo de Platón Forma (Esencia, Idea) Realidad Cosa Material * taxonomías, Ontologías, árboles de herencia Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modelado de animales Ottobrunn: Realidad Reino Animal :Realidad Tigre 5 Mamífero Reino Animal :Realidad Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

3. ¿Cuántas Realidades existen? Monismo: Sólo hay una cosa, que es a la vez la fuente y la esencia de la realidad (Thales von Milet: Todo está hecho de agua). Dualismo: Hay 2 diferentes fuentes de las cosas en la realidad. Platón: las formas y las cosas materiales son de 2 tipos de realidad. Descartes: la mente y el cuerpo son cosas separadas. Tao: Cada cosa se ​​compone de dos principios complementarios: Ying y Yang. Pluralismo: Ingeniería del Software: Hay muchas realidades, las necesidades de los clientes son la realidad. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

4. ¿La realidad es constante o cambia? Parménides (600 A.D): Hay una diferencia entre la apariencia y la realidad subyacente. El cambio es una ilusión, la realidad es constante. Heraklit (540-475 D.C): Todo fluye, no hay ninguna sustancia sólida "Ojo de Júpiter" es en realidad un huracán. La física moderna: la realidad es un campo de vibraciones. Ingeniería del Software: La interfaz gráfica de usuario cambia, pero el proceso de negocio subyacente es constante. WIMP: ventanas, iconos, ratón y dispositivo señalador. Los cambios en los procesos de negocio como resultado de instrumentos tecnológicos: "El cambio es la única constante" (Hammer y Champy, Reengineering). Parménides: Ya me estoy comunicando con el teclado o el reconocimiento de voz, detrás de él sigue siendo el mismo sistema Mi sistema tiene que ser continuamente adaptado, porque la realidad cambia dauuerd. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Las 4 preguntas básicas de la epistemología ¿Cómo adquirimos el conocimiento, a través de nuestros sentidos o por medio de nuestra inteligencia? ¿Hasta dónde podemos describir o crear la realidad con el conocimiento? Qué es el conocimiento de los hechos? ¿Cuáles son las actividades durante la adquisición de conocimiento? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Cómo adquirimos el conocimiento? Empirismo: El conocimiento se adquiere por la experimentación y por medio de nuestros sentidos. Nuestro cerebro está inicialmente vacío (“tabula rasa”). Racionalismo: El conocimiento es adquirido por nuestra mente El cerebro es ya en el nacimiento equipado con las ideas (“a priori”). Voluntariado: El conocimiento sólo se adquiere si se quiere lograr algo. El intuicionismo: El conocimiento se adquiere por la intuición. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Taxonomía de los métodos de adquisición de conocimiento Empirismo Intuicionismo Voluntarismo Realismo Adquisición del conocimiento Realismo: Conceptos – De hecho así como conceptos a priori - no son simples copias o ampliaciones de la experiencia sensual Los conceptos se construye en nuestra mente: Los conceptos son "recuerdo" de las formas. Pueden ser desencadenados por los sentidos, sino que ya están en nuestra mente, sólo se despertó. (Platón) Los conceptos son categorías de nuestra mente. Son estructuras mentales que nos permiten hacer un seguimiento de los objetos sensuales. Los conceptos no se derivan de los datos del sensor, pero se utilizan para dar sentido a partir de datos del sensor (Kant) Empirismo: Conceptos ("Verdades") sólo puede ser producida empíricamente. La mente humana puede producir conceptos, pero estos conceptos no producen nuevos conocimientos sobre la realidad. Ejemplo: Se trata de una verdad matemática, que los ángulos de un triángulo suman 180 grados. Pero no se puede deducir de ello que hay triángulos en realidad o - en caso de que existan - que podemos encontrar. En el documento original la diapositiva tiene un diagrama pero hay dos cuadros grandes de texto que lo tapan, entonces no se como hacer esa parte. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Podemos describir la realidad con el conocimiento? Idealismo Epistemológico: ¿Qué sabe usted acerca de un objeto, sólo existe en tu mente?. Los modelos sólo pueden describir las partes de la realidad, nunca la realidad. Realismo Epistemológico: El conocimiento acerca de un objeto es independiente de nuestra mente. Los modelos pueden describir la realidad. Idealistas epistemológicos son pesimistas: Siempre hay conclusiones, que no se puede dibujar en el modelo, ya que dependen de los componentes de la realidad que no se describen en el modelo. Realistas Epistemológicos son optimistas: Todas las conclusiones del modelo de describir las cosas en la realidad. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

La combinación de la metafísica y la epistemología Realista Metafísico, Realista Epistemológico : Hay una realidad fuera de mi mente, yo puedo adquirir conocimientos sobre esta realidad y puedo representar la realidad con mi modelo. (Ingeniería de Software: reingeniería). Realista Metafísico, Idealista Epistemológico: Hay una realidad fuera de mi mente, el conocimiento de esta realidad se ve limitada por las estructuras y actividades de mi mente (Kant). Idealista Metafísico, Idealista Epistemológico: La realidad depende de la mente (otro), mi conocimiento acerca de esta realidad se ve limitado por mi mente. Idealista Metafísico, Realista Epistemológico: La realidad depende de la mente (otro), mi mente puede comprender los conceptos de esta otra mente, y yo puedo representar esta externamente con los modelos (Ingeniería de Software: El cliente especifica el sistema). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

La combinación de la metafísica y la epistemología Realismo Metafísico Idealismo Metafísico Realismo Epistemológico Idealismo Epistemológico Kant Reingeniería Ingeniería de Software (interfaz e Greenfield) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Realidades de los ingenieros de software Algunas personas dicen: "El científico de la computación puede jugar a ser Dios, porque puede crear realidades". Tonterías. Pero: El científico de la computación puede modelar diferentes tipos de realidades y construir con ellas: Un sistema existente (sistema físico, técnico del sistema, sistema social, sistema de software). Un caso especial importante es aquí cuando el sistema actual es un sistema de software. A continuación, se llama "Sistema Legado”. Una idea sin contrapartida en la realidad: Un escenario de visionario o un requisito del cliente. La realidad construida en realidad podría ser sólo parte de las ideas, es decir, aquellos que eran realizables en el software. Ejemplo: Un escenario de visión de futuro resulta ser un sueño, una exigencia del cliente resulta ser muy caro de realizar. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Conocimiento sobre Causalidad Conocimiento sobre Funcionalidad ¿Cómo podemos modelar sistemas complejos sistemas naturales, sistemas sociales, sistemas artificiales)? Epistemología Describe nuestro conocimiento sobre el sistema Conocimiento sobre Causalidad (Modelo Dinámico) Conocimiento sobre Relaciones (Modelo de objetos) Conocimiento sobre Funcionalidad (Modelo Funcional) Diagramas de Estado (Harel) Conjuntos difusos de conocimiento incierto(Zadeh) Diagramas De secuencia (Lamport) Marcos de Herencia Redes semánticas (Minsky) Relacion de Datos (Modelado E/R, Chen) Modelo de base De datos Jerárquica (IMS) Petri Nets(Petri) Diagramas de actividad (“flujogramas bien viejos”) Especificaciones Formales (Liskov) Escenarios/Casos de uso (Jacobsen) Diagrama de flujo de datos (SA/SD) Redes Neuronales Diagrama de Clase (“E/R + Herencia”, Rumbaugh) Marcos Difusos (Graham) Modelo de Base de datos De red (CODASYL) Modelo de base de Datos relacionales (Codd) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Actividades durante el modelado de objetos Principal objetivo: Encontrar las abstracciones importantes. ¿Qué sucede si nos encontramos con las abstracciones equivocadas?. Iterar y corregir el modelo. Pasos durante el modelado de objetos 1. Identificación de clases. Basado en la premisa fundamental de que podemos encontrar abstracciones. 2. Encontrar los atributos. 3. Encontrar los métodos. 4. Encuentra las asociaciones entre clases. Orden de pasos Objetivo: obtener las abstracciones deseados. Orden de pasos secundarios, sólo un heurístico. La iteración es importante. Comenzar revisando: ¿Qué es un modelo? ¿Qué es una abstracción? Se utilizan como sinónimos y significan que proporcionan una visión simplificada de un sistema complejo que no podemos entender al ver todos sus componentes al mismo tiempo. Modelos de la definición abstracta de distancia características importantes de un sistema, haciendo hincapié en otros aspectos. Ejemplo: modelo de arcilla se concentra en la forma del coche, nadie puede sentarse en ella. Los prototipos son modelos. Iterar y corregir el modelo: un modelo científico es siempre como una hipótesis. La parte importante de un modelo científico es que es falsificable. Este es un aspecto importante de creación de prototipos. Ellos son inmediatamente comprensibles y pueden ser falsificados (que es nuestra teoría de cómo la aplicación debería funcionar!). Esta es una de las principales fortalezas de prototipado: falsabilidad usuario final. Rediseño (principio de falsificación en la ciencia: el trabajo con el modelo hasta que se demuestre que es falsa) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Identificación de clases Identificar los límites del sistema. Identificar las entidades importantes en el sistema. Identificación de clases es fundamental para modelado orientado a objetos. Supuesto básico: 1. Podemos encontrar las clases de un nuevo sistema de software (ingeniería). 2. Podemos identificar las clases en un sistema existente (ingeniería inversa). ¿Por qué hacemos esto?. La filosofía, la ciencia, la evidencia experimental. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Identificación de clases es un problema antiguo Los objetos no se encuentran sólo por tomar una foto de una escena o de dominio El dominio de aplicación tiene que ser analizado. Dependiendo del propósito de los objetos del sistema se podría encontrar diferentes ¿Cómo podemos identificar el propósito de un sistema? Los escenarios y casos de uso Otro problema importante: Definir los límites del sistema. ¿Qué objeto está dentro, ¿qué objeto se encuentra fuera? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Qué es esto? Cara Ojo 1..2 Pregunta: ¿Cuál es el showin dibujo en la diapositiva? Los estudiantes, en general, la primera respuesta: Dos caras, una feliz y seria. O un serio y triste. Explique que no hay dos objetos: Si se decide por una cara seria, cubra el rostro serio y mostrar lo que sobra. Está claro ahora que los restos no son una cara completa, ya que un ojo es usado en exceso (contención de recursos!) Y el modelador de objetos tiene que decidir si es parte de lo serio o la cara triste. ¿Lo que hace esto se traduce en la actividad de modelado del objeto real? Significa que han descubierto un modelo de objetos incompletos y debe pedir al cliente que nos proporcione más información para completar la información faltante o para definir los objetos para nosotros (después de todo lo que podría estar buscando en hermanos siameses!). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modelado en acción cara máscara triste feliz ¿Es una cara o dos? ¿Quién lo está utilizando? ¿Persona en el Carnaval? ¿Ladrón de Bancos? ¿Coleccionista de Pintura? ¿Cómo se utiliza? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Piezas de un modelo de objetos Clases. Asociaciones (relaciones). Asociaciones genéricas. Asociaciones canónicas. Parte de la jerarquía (Agregación). Tipo de Jerarquía (Generalización). Atributos. Detección de atributos. Aplicación específica. Los atributos de un sistema de clases puede ser en otro sistema. En cuanto a los atributos de las clases. Operaciones. Detección de operaciones. Operaciones genéricas: Get/Set, el conocimiento general del mundo, los patrones de diseño. Operaciones de dominio: modelo dinámico, modelo funcional. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Objeto vs clase Objeto (instancia): Exactamente una cosa. Esta clase de Ingeniería de Software del 19 de marzo de 9 a 10.. Una clase describe un grupo de objetos con propiedades similares. Juego, Torneo, el mecánico, el coche, la base de datos. Diagrama de objetos: una notación gráfica para el modelado de objetos, clases y sus relaciones ("asociaciones"): Diagrama de clases: Plantilla para la descripción de muchos casos de datos. Útil para la taxonomía, características de, esquemas. Diagrama ejemplo: un conjunto particular de objetos relacionados entre sí. Útil para la discusión de los escenarios, casos de prueba y ejemplos. Herramientas CASE (Computer-Aided Software Engineering) Herramienta para la creación de diagramas de objetos, en los diagramas de clases particulares Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Identificación de clases Búsqueda de objetos es la meta central en el modelado de objetos. Enfoques: Aplicación de enfoque de dominio del problema : Preguntar a expertos del dominio de aplicación para identificar las abstracciones relevantes. Enfoque sintáctico: Comience con los casos de uso. Extraer los objetos que participan en el flujo de los acontecimientos. Utilice el análisis de sustantivos y verbos (técnica Abad) para identificar los componentes del modelo de objetos. Patrones de diseño de enfoque: Usar patrones reutilizables de diseño. Componente enfoque basado en dominio de la solución: Identificar las clases existentes de solución. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Cómo encontrar las clases? Conocer el dominio del problema: observa al cliente Aplicar el conocimiento general del mundo y de la intuición Tomar el flujo de eventos y encontrar objetos que participan en casos de uso Trate de establecer una taxonomía Haga un análisis sintáctico de la exposición del problema, hipótesis o flujo de los acontecimientos Análisis Textual Abbott (1983), también llamado análisis sustantivo-verbo Los sustantivos son buenos candidatos para las clases Los verbos son buenos candidatos para las operaciones Aplicar los conocimientos de diseño: Distinguir los diferentes tipos de objetos Aplicar patrones de diseño P: ¿Qué ideas clave que han cubierto hasta ahora? R: patrones, análisis de documentación estándar, la herencia y herencia múltiple. En la última parte de esta conferencia me gustaría volver al problema de la identificación de objetos y una herramienta que le ayuda en la búsqueda de objetos. Patrones: Una manera de poner sus conocimientos sobre modelado de objetos en cajones. Estándar de documentación de análisis: la forma “oficial” de dibujar modelos de objetos. Los elementos principales son: Herramientas CASE de entrada: Resumen ejecutivo y un subsistema por hoja. Clases 7+-2 por hoja. Documentación: cada subsistema tiene texto de navegación. Diferencia entre la agregación y sucesiones Identificación del objeto: Utilizando el análisis textual Herencia múltiple: ¿Por qué no se puede evitar?, ¿cómo se puede lidiar con eso? La ingeniería de software como un caso especial de la epistemología: Ingeniería de Software es una clase de combinación de materialismo (presupuesto y plazo de influir en su modelado (Se puede limitar lo que se puede lograr) Idealismo:. Algunas de las clases no reflejan la realidad (es decir, el cliente no sabe nada de ellos) y dialectismo (iteración y análisis incremental con la decisión usuario participativo de toma de capacidades). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Cómo encontrar las clases? Búsqueda de objetos es la pieza central en el modelado de objetos Conocer el dominio del problema: Observe a su cliente. Aplicar el conocimiento general del mundo y de la intuición. Tomar el flujo de eventos y encontrar los objetos que participan en los casos de uso. Trate de establecer una taxonomía. Aplicar los conocimientos de diseño: Distinguir los diferentes tipos de objetos Aplicar patrones de diseño (Conferencia sobre los patrones de diseño). Hacer un análisis sintáctico de la declaración del problema, situación o flujo de los acontecimientos. Análisis textual Abbott, 1983, también llamado análisis sustantivo-verbo: Los sustantivos son buenos candidatos para las clases. Los verbos son buenos candidatos para las operaciones. P: ¿Qué ideas clave que han cubierto hasta ahora? R: patrones, análisis de documentación estándar, la herencia y herencia múltiple. En la última parte de esta conferencia me gustaría volver al problema de la identificación de objetos y una herramienta que le ayuda en la búsqueda de objetos. Patrones: Una manera de poner sus conocimientos sobre modelado de objetos en cajones. Estándar de documentación de análisis: la forma “oficial” de dibujar modelos de objetos. Los elementos principales son: Herramientas CASE de entrada: Resumen ejecutivo y un subsistema por hoja. Clases 7+-2 por hoja. Documentación: cada subsistema tiene texto de navegación. Diferencia entre la agregación y sucesiones Identificación del objeto: Utilizando el análisis textual Herencia múltiple: ¿Por qué no se puede evitar?, ¿cómo se puede lidiar con eso? La ingeniería de software como un caso especial de la epistemología: Ingeniería de Software es una clase de combinación de materialismo (presupuesto y plazo de influir en su modelado (Se puede limitar lo que se puede lograr) Idealismo:. Algunas de las clases no reflejan la realidad (es decir, el cliente no sabe nada de ellos) y dialectismo (iteración y análisis incremental con la decisión usuario participativo de toma de capacidades). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Encontrar objetos que participan en los casos de uso Elija un caso de uso y revise su flujo de los acontecimientos Buscar términos que los desarrolladores o usuarios necesitan aclarar para entender el flujo de eventos Buscar los nombres recurrentes (por ejemplo, incidente) Identificar las entidades del mundo real que el sistema necesita para no perder de vista (por ejemplo, Oficial de Campo, Recursos) Identificar los procedimientos del mundo real que el sistema necesita para no perder de vista (por ejemplo, Plan de Emergencia de Operaciones) Identificar las fuentes o sumideros de datos (por ejemplo, la impresora) Identificar los objetos de la interfaz (por ejemplo, la comisaría de policía) Modele el flujo de los acontecimientos con un diagrama de secuencia Utilice siempre los términos de los usuarios Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Tipos de Objetos Objetos de Entidad: Representar a la información persistente rastreada por el sistema (objetos de dominio de aplicación, "Business Objects"). Objetos de interfaz o de frontera: Representa la interacción entre el usuario y el sistema. Objetos de Control: Representar a las tareas de control realizadas por el sistema. Tener tres tipos de objetos da lugar a modelos que son más resistentes al cambio. La interfaz de un sistema cambia más que el control. El control del sistema de cambio más que el dominio de aplicación. Los tipos de objetos se originó en Smalltalk: Modelo, Vista, Controlador (MVC). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Ejemplo: Objetos Reloj2B Año Mes Día CambioFecha Botón PantallaLCD Objetos de Entidad Objetos de Control Objetos de Intefaz Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Nombres de tipos de objetos en UML UML ofrece varios mecanismos para ampliar el lenguaje. UML ofrece el mecanismo de estereotipos para presentar nuevos elementos de modelado. <<Entidad>> año Mes Día <<Control>> ControlCambioFecha <<Frontera>> FronteraBotón FronteraPantallaLCD Objetos de Entidad Objetos de Control Objetos de Límites Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Recomendaciones convención de nomenclatura para los tipos de objetos Para distinguir los tipos de objetos diferentes sobre una base sintáctica, se recomienda sufijos: Los objetos que terminan con la ”_Límite” sufijo son objetos de contorno. Los objetos que terminan con la “_Control” sufijo son objetos de control. Objetos de entidad no tiene ningún sufijo añadido a su nombre. Año Mes Día CambioFecha_ Control Botón_Frontera PantallaLCD_Frontera Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Ejemplo: Flujo de Eventos El cliente entra en una tienda con la intención de comprar un juguete para su hijo con edad n. Ayuda debe estar disponible en menos de un minuto. El propietario de la tienda da consejos al cliente. El consejo depende el rango de edad del niño y los atributos del juguete. El cliente selecciona un juguete peligroso que es algo inadecuado para el niño. El propietario de la tienda recomienda una muñeca más amarilla. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Asignación de partes de la oración a los componentes del modelo de objeto [Abbott, 1983] Parte de la oración Componente del Modelo Ejemplo Sustantivo propio Objeto Jim Smith Sustantivo Impropio Clase Juguete, Muñeca Verbo Hacer metodo Comprar, recomendar Verbo Ser Herencia Es-un (tipo-de) Verbo Tener Agregación Tiene un Verbo Modal Restricción Debe ser Adjetivo Atributo 3 años de edad Verbo Transitivo Método entrar Verbo Intransitivo Método (evento) Depende Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Otro Ejemplo Flujo de Eventos: Un asistente le ayuda. El cliente entra en la tienda para comprar un juguete. Tiene que ser un juguete que le guste a su hija y debe costar menos de 50 euros. Se trata de un videojuego, que utiliza un guante de datos y una pantalla montada en la cabeza. A él le gusta. ¿Esto es un buen caso de uso? Un asistente le ayuda. La idoneidad del juego depende de la edad del niño. Su hija tiene solo 3 años de edad. El asistente recomienda otro tipo de juguete, a saber, el juego de mes “Monopolio”. No exactamente! “Monopolio” es probablemente un sobrante de la situación. El caso de uso debe terminar con el cliente dejando la tienda Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Análisis textual utilizando la técnica de Abad Construcción gramatical Componente UML Persona concreta, cosa Objeto Sustantivo clase verbo Operación Verbo de Clasificación Herencia Verbo posesivo Agregación Verbo Modal Restricción Adjetivo Atributo Verbo Intransitivo Operación (Evento) Ejemplo “Monopolio" “Juguete" “Entrar" “Es un" ,“Ya sea.. o", “Algo así…" “Tiene un ", “Consiste en" “Debe ser", “Menos de…" "3 años de edad" “Depende…." Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Generación de un diagrama de clases a partir de un flujo de eventos Cliente ? enter() tienda Flujo de Eventos: El cliente entra en la tienda para comprar un juguete. Tiene que ser un juguete que le guste a su hija y debe costar menos de 50 euros. Se trata de un videojuego, que utiliza un guante de datos y una pantalla montada en la cabeza. A él le gusta. cliente entra tienda comprar juguete hija menos de 50 euros videojuego Hija edad adecuado * Un asistente le ayuda. La idoneidad del juego depende de la edad del niño. Su hija tiene solo 3 años de edad. El asistente recomienda otro tipo de juguete, a saber, un juego de mesa. El cliente compra el juego y sale de la tienda. depende edad tipo de juguete juguete juego de mesa Precio Gustar() Comprar() videojuego Juego de mesa Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Orden de actividades en el modelado Formular una serie de escenarios con la ayuda del usuario final y/o experto en el dominio de aplicación. Extracto de los casos de uso de los escenarios, con la ayuda de expertos del dominio de aplicación. Analizar el flujo de eventos, por ejemplo, con el análisis textual de Abbott. Generar los diagramas de clases, que incluye los siguientes pasos: Identificación de clase (análisis textual, expertos de dominio). Identificación de los atributos y operaciones (a veces antes de que las clases se encuentran!). Identificación de las asociaciones entre las clases. Identificación de las multiplicidades. La identificación de los roles. Identificación de restricciones. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Algunas cuestiones en el modelado de objetos La mejora de la legibilidad de los diagramas de clases. Gestión de modelado de objetos. Los diferentes usuarios de los diagramas de clases. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Evite los modelos Ravioli Cliente Nombre ClienteID Cuenta Monto Deposito() Retirar() Balance() CuentaID Banco tiene * Cuenta de ahorros cheques hipotecaria No poner demasiadas clases en el mismo paquete: 7+-2 (o incluso 5+-2) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Poner las taxonomías en un diagrama separado Cuenta Monto Deposito() Retirar() Balance() CuentaID Cuenta de ahorros Cuenta de cheques Cuenta hipotecaria Retirar() Retirar() Retirar() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Gestión de proyectos heurísticos Explícitamente programar las reuniones para la identificación de objetos. Primero sólo encontrar objetos. A continuación, tratar de diferenciar entre objetos entidad, interfaz y control. Buscar asociaciones y su multiplicidad. Multiplicidades inusuales suelen dar lugar a nuevos objetos o categorías. Identificar la herencia: Busque una taxonomía, categorizar Identificar la agregación. Deje tiempo para lluvia de ideas, iterar, iterar. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Quién utiliza los diagramas de clase? Propósito de diagramas de clases: La descripción de las propiedades estáticas de un sistema (objetivo principal). ¿Quién usa los diagramas de clases? El cliente y el usuario final no se han interesado también por los diagramas de clases. Por lo general, se centran más en la funcionalidad del sistema. El experto dominio de la aplicación utiliza los diagramas de clases para modelar el dominio de aplicación El desarrollador utiliza diagramas de clases durante el desarrollo de un sistema, es decir, durante el análisis, diseño de objetos de diseño del sistema, y la aplicación. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Clase de diagramas de diferentes tipos de "usuarios" De acuerdo con la actividad de desarrollo, el desarrollador desempeña diversos papeles. Analista. Diseñador de sistema. Diseñador detallado. Implementador. En los sistemas pequeños algunos de los papeles no existen o son interpretados por la misma persona. Cada uno de estos roles tiene una visión diferente acerca de los modelos. Antes de describir estos diferentes puntos de vista, quiero distinguir los tipos de clases que aparecen en los diagramas de clases. Clases de aplicaciones de dominio Clases de soluciones de dominio Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Dominio de Aplicación vs Solución de Dominio Aplicación de dominio: El dominio del problema (servicios financieros, meteorología, gestión de accidentes, arquitectura, ...). Solicitud de la clase de dominio: Una abstracción en el dominio de aplicación. Si nosotros, las aplicaciones de modelos de negocio, estas clases también se denominan objetos de negocio. Ejemplo: juego de mesa, torneo Solución de dominio: Dominios que ayudan en la solución de los problemas de (tele comunicación, bases de datos, construcción de compiladores, sistemas de Otorgamiento, ....) Solución de la clase de dominio: Una abstracción, que se introduce por razones técnicas, ya que ayuda en la solución de un problema. Ejemplos: árboles, Agenda. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

El papel del analista El analista está interesado En las clases de aplicación: Las asociaciones entre las clases son las relaciones entre las abstracciones en el dominio de aplicación. Si el uso de herencia en el modelo reflejan las taxonomías en el dominio de aplicación. Definición Taxonomía: una jerarquía de abstracciones El analista no está interesado En la firma exacta de las operaciones. En las clases de la solución. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Diseñador El diseñador se centra en la solución del problema, que es el dominio de la solución. Diseño consta de muchas de las tareas (la descomposición del subsistema, la selección de la plataforma de hardware, sistema de gestión de datos, etc.) Un problema importante del diseño es la especificación de las interfaces: El diseñador describe la interfaz de las clases (el diseño de objetos) y subsistemas (el diseño del sistema). El objetivo del diseñador es la facilidad de uso y la reutilización de la interfaz Diseño y Usabilidad: las interfaces se pueden utilizar de tantas clases como sea posible dentro del sistema. Diseño y Reutilización: Definición de las interfaces, de tal manera que también se puede utilizar en otros sistemas de software (futuro). => bibliotecas de clases. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Tres tipos de implementadores Clase implementador: Implementa la clase. El implementador decide estructuras apropiadas de datos (para los atributos) y algoritmos (para las operaciones), y se da cuenta de la interfaz del lenguaje de programación de clase INA. Clase de extensión: Extiende la clase por una subclase, que se necesita para un problema nuevo o un nuevo dominio de aplicación. Clase de usuario (cliente): El programador, que quiere usar una clase existente (por ejemplo, una clase de una biblioteca de clase o una clase de otro subsistema). El usuario de la clase sólo está interesado en las firmas de las operaciones de la clase y las condiciones previas, en virtud de la cual pueden ser invocados. El usuario de la clase no está tan interesado en la implementación de la clase. Lenguaje de programación de clase INA?? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

¿Por qué distinguimos estos diferentes usuarios de los diagramas de clases? Los modelos a menudo no distinguen entre clases de la aplicación ("libreta de direcciones") y la solución de clase (”matriz", "árbol"). Razón: lenguajes de modelado UML permiten el uso de ambos tipos de clases en el mismo modelo. Preferido: No hay clases de soluciones en el modelo de análisis. Muchos sistemas no distinguen entre la especificación y la implementación de una clase. Razón: lenguajes orientados a objetos de programación permiten el uso simultáneo de especificación y la implementación de una clase. Preferido: El modelo de diseño de objetos no contiene las implementaciones. La clave para la creación de sistemas de alta calidad del software es la distinción exacta entre Aplicación y solución de las clases de dominio Especificación de la interfaz y la especificación de la implementación Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Ejemplos de TRAMP, ARENA: El objetivo de estas conferencias de ingeniería de software que son capaces de distinguir los roles y algunos de ellos puede ejecutar usted mismo. Ejemplos de TRAMP, ARENA: ¿Quién es el experto en el dominio de aplicación? ¿Quiénes son los usuarios de clase? ¿Quién es el implementador de la clase? ¿Quién es el usuario final? ¿Necesitamos un extensor de la clase? La diapositiva del documento original no tiene título…. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Los diagramas de clases son siempre parte de los modelos Modelo de análisis: el modelo de aplicaciones de dominio. Sistema de diseño y modelos de objetos de diseño: el modelo de solución de dominio. Dependiendo de nuestro papel, nos fijamos en los objetos y los modelos desde una perspectiva diferente. A menudo, sólo estamos interesados ​​en aspectos limitados de un modelo: => 3 tipos de interfaces en el modelo de diseño de objetos. Dependiendo de nuestro papel y el modelo que tenemos interpretaciones diferentes para las diferentes construcciones de UML: Diferentes interpretaciones de las asociaciones. Diferentes interpretaciones de los atributos. Diferentes interpretaciones de la herencia. Echemos un vistazo a estas diferentes interpretaciones. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modelo de análisis El modelo de análisis se construye durante la fase de análisis. Los principales interesados: usuarios finales, analistas, clientes. El esquema contiene sólo las clases del dominio de aplicación. El modelo de análisis es la base para la comunicación entre los analistas, los expertos en el dominio de aplicación y los usuarios finales del sistema. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Modelo de diseño de objetos El modelo de diseño de objetos (a veces también llamado modelo de pliego de condiciones) se crea durante la fase de diseño de objetos Los principales interesados ​​son los especificadores de clase, implementadores de clase y usuarios de la clase Los diagramas de clases contienen las clases de aplicación y la solución de dominio. El modelo de diseño de objetos es la base de la comunicación entre los diseñadores y programadores. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Resumen Modelado vs Realidad. Sistema de modelado: modelo de objeto. modelo dinámico. modelo funcional. El modelado de objetos es la actividad central. Identificación de clase es una actividad importante de modelado de objetos. Hay algunas reglas sintácticas sencillas para encontrar clases y objetos. Los diferentes roles durante el desarrollo de software. Análisis de Requerimientos Estructura del documento. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java

Maneras de encontrar objetos Investigación sintáctica con la técnica de Abbott: En el enunciado del problema (propuesto originalmente, pero rara vez funciona si el enunciado del problema es grande (más de 5 páginas) En el curso de los acontecimientos de casos de uso => Análisis del texto con Abbott El uso de fuentes de conocimiento diferentes: Conocimiento de aplicación: Las entrevistas de los usuarios finales y expertos, para determinar las abstracciones del dominio de aplicación. Conocimiento de diseño: abstracciones reutilizables en el dominio de la solución. Conocimiento general del mundo: También puede utilizar su conocimiento genérico e intuición. Formulación de hipótesis (en lenguaje natural): Descripción de la utilización concreta del sistema. Formulación de casos de uso (en lenguaje natural y UML): Descripción de las funciones con los actores y el flujo de los acontecimientos Objetivo: Llegar a: un modelo de dominio (objetos de dominio específico) una taxonomía (jerarquía de clases) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java