B03-T09 Diseño orientado a objetos Flashcards
Diferencias principales entre programación estructurada y OO
- Módulos construidos alrededor de operaciones | al rededor declases
- Datos gloabales y distribuidos entre los módulos | Clases débilmente acopladas y sin datosglobales
- Entreda-proceso-salida| Encapsulación-mensajes
- Diagramas de flujos de datos | Diagramas jerárquicosdeclases
¿Qué es una clase?
Coleccción de propiedades y métodos que operan con las propiedades o datos.
El estado de un objeto viene determinado por sus datos.
¿Conceptos básicos de la herencia?
- Superclase - (clase padre de la que heredan las subclases)
- Subclase - la clase que hereda
- Herencia múltiple - una subclase puede heredar de varias clases al mismo tiempo. C++ sí, Java no
Estructura de un módulo en la programación estructurada o imperativa
- Interfaz: datos de entrada, datos de salida y descripción de la funcionalidad
- Implementación: datos locales y secuencial de instrucciones
Ventajas de la programación estructurada o imperativa
- Facilita el desarrollo. Evita repetición del trabajo, compartimentado en módulos, Diseño topdown: descomposición en subprogramas
- Facilita el mantenimiento: claridad de código, independencia de los módulos
- Favorece la reutilización
En la programación estructurada o imperativa, qué son los TAD
Tipos abstractos de datos,que permite abstraer datos y operaciones. Por ejemplo: pila, cola, lista árboles…
Estructura de datos que almacena información para representar un determinado concepto.
La funcionalidad del TAD obtenida por un conjunto de operaciones que se pueden realizar sobreel TAD
Ventajas de los TAD
- Concepto del dominio de los datos reflejada en el código
- Encapsulamiento
- Especificación versus implementación
- Mayor modularidad
- Mayor facilidad de mantenimiento
Características de la POO
- Da soporte sintáctico explícito para la abstracción de datos: definición de clases, métodos, creación objetos, acceso a atributos e innovación métodos
- Cambia el punto de vista
- Aparecen nuevos conceptos: Objeto, Herencia de estructura y de funcinoalidad, polimorfismo
Ventajas de la POO
- Abstración + disciplina programación: Reutilización código, Facilita mantenimiento y extensión, Encapsulación y modularidad
- Potencia del lenguaje. Definición de clases, herencia, polimorfismo
- Reflejar conceptos de la realidad.
- Más sencillo de aprender
- Acoplamiento bajo y cohesión alta.
- Extensibilidad
Qué se entiende por acoplamiento
La interdependencia entre elementos
Qué se entiende por cohesión
La relación entre los diferentes componentes de un elemento.
Alta cohesión: realiza una tarea concreta y sencilla
Incovenientes de la POO
- No evita los malos análisis o diseños
- Preparación específica
- Curva de aprendizaje alta. Múltiples librerías.
- Los OO son poco eficientes, necesitan una arquitecturas relativamente potentes
- Reusabilidad está comprometida por la calidad de los paquetes
- Librerías de componentes deben tener una configuración estricta
Hitos históricos imporantes en las decadas de 1960 y 1970
- Primera aplicación bajora paradigma OO: Scketchpad (63)
- Primer lenguaje OO: Simula 67 (67)
- Refina nociones asociadas a clases y registros (75)
- Smaltalk
Hitos históricos imporantes en las decadas de 1980 y 1990
- Effiel (1985). Mejora Smalltalk
- Módula-2 (Niklaus With). Incluyó conceptos como la abstracción de datos y la programación modular
- Módula-3 (1990’s). DEV y Olivetti lo desarrollaron
- C++.
- VisualBasic. Microsoft
- Borland. Delphi
- Python. Lenguaje scripting, disponen características OO Relativament nuevo, sintaxis y semántica basada en Módula 3
C++
- Creado en la decada de los ochenta.
- Evolución de C
- POO
- Compilado y muy portable.
- Tipado fuerte.
- No hace limpieza dinámica de memoria
- Permite el tratamiento de excepciones
Hitos históricos imporantes en las decadas de 1990 y XXI
- Java
- .Net (Microsoft)
Características principales de Java
- Apareción en 1995
- Lenguaje intrepretado semicomplidao
- Genera byte-code interpretado para máquina virtual (JVM)
- No permite herencia multiple
- Dispone de garbage coelctor
POO - Objeto
instanciación de una clase.
Datos más lógica para tratarlos
POO - Mensaje
Solicitud para que el objeto se comporte de una manera determinada -> llamara un método
Protocolo: Conjunto de mensajes al que puede responder un objeto
POO - Clases
Propiedades más métodos
POO - Clase abstracta
Clase que no puede ser instanciada
POO - Biblioteca de clases
Conjunto de clases para una determinada tarea de programación
POO - Biblioteca de componentes
Grupo de clases que implementan una interfaz determinada
POO - Interfaz
Conjunto de métodos públicos que soporta una clase, y los mensajes que es capaz de tratar
POO - Tipos de operaciones en POO
- Constructor
- Destrucutor
- Selector (get)
- Modificador (set)
- Copiador 8copu, clone)
- Iterador
- Visualizador
POO - tipos de visibilidad
- Público
- Protect
- Private
POO - Normas generales para aplicrar visibilidad
- El estado de la clase debe ser privado
- Las operaciones que definen la funcionalidad deben ser públicas
- Funcionalidades que ayudan a implementar la funcionalidad principal deben ser privadas o protegidas
Propiedades fundamentales de la OO
- Identidad
- Clasificación
- Herencia
- Polifmorfismo
- Encapsulación
- Persistencia
- Extensibilidad
- Reusabilidad
- Composición/agregación
POO - Qué es Identidad
Los objetos tienen su identidad inherente.
Identificador único denominado handle (puntero, valor,etc)
POO - Qué es Clasificación
Misma estructura de datos y mismo comportamiento
POO - Tipos de herencia
- De implementación: herencia de los métodos del padre implementados
- De interfaz: hereda la interfaz pero no la implementación de operaciones (permite el polimorfismo)
- De clase: hereda atributos y métodos
POO - Qué es el polimorfismo
Una misma interfaz puede tener distintos comportamientos.
Tipos de polimorfismo:
- En tiempo de compilación o estático. Elcomportamiento varía en función del tipo de datos que recibe el método.
- En tiempo de ejecución (dinámico). Dada por la implementación de una misma interfaz, o por la herencia del método. Mismo método con lógicas distintas.
POO - Qué es la encapsulación
Solo se permite acceso externo mediante propiedades o métodos públicos, el resto es transparente.
POO - Qué es Persistencia
Un objeto software ocupa un espacio determinado de memoria
POO - Qué es extensibilidad
Puede ser fácilemente extendido
POO - Qué es reusabilidad
Componentesreutilizables
POO - Qué es la composición
“Todo/parte”: La parte no puede existir sin el todo. Por ejemplo, el motor y un coche,. El motor ha de existir dentro de un coche.
Relación fuerte, si se destruye al padre se destruye al hijo
Cuáles son las fases de desarrollo en la POO
- OOA: anállisis orientada a objetos
- OOD: diseño orientado a objetos
- OOP: Programaciónorientada a objetos
POO - Qué es laagregación
Relación todo-parte pero dénil. Laparte puedeexistir sin el todo. Por ejemplo, profesor y departamento.
Los objetos pueden compartirse entre muchos agregados.
La vida del objeto no depende del objeto contenedor.
Diferencia principal entre el análisis OO y la tradicional.
La tradicional se centra en el flujo de datos. La OO en la construcción de modelos basados en el mundo real
Etapas del Análisis Orientada a objetos
- Descripción o especificación del problema. No debe ser inmutable sino evolutiva.
- Modelización del análisis. Las características esenciales deben abstraerse de un módelo.
En OOA aspectos de la descripción o especificación del problema
- Establecer el ámbito del problema
- Describir necesidades y requisitos
- Describir el contexto de la aplicación
- Definir los supuestos
- Definir las necesidades de rendimiento del sistema
En OOA cuáles son los elementos utilizados en la modelización del análisis?
- Clases y objetos del dominio del problema (estructura estática)
- Interacciones entre objetos y su secuenciamiento (estrcutura dinámica)
- Acciones a realizar por el sistema que producen un resultado observables y valioso para los usuarios (estructura funcional)
¿Cuál es el objetivo del Diseño Orientado a Objetos?
Transformar modelos conceptuales (del análisis) en modelos técnicos listos para ser programados.
Tareas que se ejecutan el Diseño Orientado a Objetos
- Decidir la arquitectura del sistema. Se definen los subsistemas
que lo compondrá. Paquete de clases, asociaciones, operaciones y restricciones que están relacionados. Debe tener una interfaz bien definida con el exterior para poder interaccionar con otros subsistemas - Identificar las situacioines de concurrencia inherentes al sistema
- Asignar los subsistemas a los recursos de proceso con lo que cuentan. Cada subsistema debe ser asignado a una unidad de hardware
- Elegir una aproximación para la gestión del almacenamiento de datos (estructura de datos, ficheros,bases de datos)
- ¿cuándo para con el diseño? Cuando los elementos sean tan sencillos que no puedan ser descompuestos
Esiterativo el ciclo de desarrollo de software orientado a objetos
Sí es iterativo. No es un proceso linial.
¿Cuáles son las metodologías que implementan o incluyen el ciclo de desarrollo orientado a objetos?
- Métrica versión 3
- Proceso unificado de desarrollo de Software
¿Cuáles son los objetivos de Métrica3?
- Proporcionar o definir SI que ayuden a conseguir los beneficios de la orgnaización.
- Dotar a la organización de Software que satisfaga las necesidades de los usuarios (toma requisitos usuario)
- Mejora de la productividad de los departamentos TIC
- Facilitar la comunicación y el entendimiento entre los distintos participantesen la producción del software
-Facilitar la operación, mantenimiento y uso de los productos de software
Ideas generals sobre M3 y OO
- Propone técnicas y actividades en OO
- Utilización de UML
- Propone 4 interfaces:
- Gestión del proyecto
- Seguridad
- Gestión de la configuración
- Aseguramiento calidad
M3 - OO. Actividades en el proceso de análisis
- ASI 1. Definición del sistema. Se identifican los límites del sistema, su alcance funcional, y la interacción con usuarios y otros sistemas.
- ASI 2. Establecimiento de requisitos. Se recogen y documentan los requisitos funcionales y no funcionales del sistema con el usuario.
- ASI 3. Descomposición del sistema en subsistemas. Se divide el sistema en partes más manejables (subsistemas) para facilitar el análisis y posterior desarrollo.
- ASI 4. Análisis de los casos de uso. Se modelan los requisitos funcionales como interacciones entre actores y el sistema mediante casos de uso.
- ASI 5. Analisis de clases. Se identifican y definen las clases del dominio, sus atributos, métodos y relaciones, reflejando la estructura interna del sistema.
M3 - OO. Cuáles son los inputs y las técnicas utilizadas en ASI 1.1 Determinación del alcance del sistema
- Inputs: modelo de negocio, modelo de cominio
- Técnicas: casos de uso, diagrama de clases
M3 - OO. Inputs y tareas en ASI 2 establecimiento de requisitos
- Catálogo de requisitos que se completarán.
- Se realiza la definifión, análisis y validación de requisitos
- ASI 2.1 Obtención de requisitos
- ASI 2.2 Especificaciones de casos de uso
M3 - OO Cuáles son las técnicas aplicadas en ASI 2.1 Obtención de requisitos
Casos deuso -> se detallan actores, casos de usos y breve descripción de los casos de uso
M3 - OO Qué se hace en ASI 2.2 Especificaciones de casos de uso
- Desarrollará el escenario de cada caso de uso identificado anterioremente. En casos complejos se realizarán diagramas de transición de estado.
Tareas:
- Descripción del escenario: cómo un actor interactúa con el sistema y cuál es la respuesta obtenida
- Precondiciones y poscondiciones
- Identificación de interfaces de usuario
- Condiciones de fallo que afectan al escenario así como la respuesta del sistema
M· - OO. Tareas y técnicas en ASI 3 Descomposición del sistema en subsistemas
- ASI 3.1 determinación de subsistemas de análisis => diagrama de paquetes
- ASI 3.2 integración de subsistemas de análisis => diagrama de paquetes
M3 - OO Cuál es el objetivo de ASI 4 Análisis de los casos de uso
Identificar las clases cuyos objetos son necesarios para la realización del caso de uso mediante la interacción de sus objetos
M3 - OO Cuáles son las tareas que comprenden el ASI 4 Análisis de los casos de uso
- ASI 4.1 Identificación de clases asociadas a un caso de uso
- ASI 4.2 Interacción de objetos
M3 - OO Cual es la técnica aplicada en ASI 4.1 Identificación de clases asociadas a un caso de uso
Diagrama de clases
M3 - OO Cuáles son las clases que se identifican en ASI 4.1 Identificación de clases asociadas a un caso de uso
- Clase de entidad. Representan la información manipulada en cada caso de uso
- Clases de interfaz de usuario. Interacción entre el sistemay actores (ventanas, formularios, menús…)
- Clases de control Responsables coordinación, secuencia transacciones, control objetos relacionados
M3 - OO Cuál es la técnica empleada en ASI 4.2 Interacción de objetos
Diagramas de interacción
M3 - OO Cuál es el objetivo del ASI 5 Análisis de clases
Describir cada una de las clases que han surgido, identificando las responsabilidades que tienen asociadas, sus atributos y las relaciones entre ellas
M3 - OO Tareas en ASI 5 Análisis de clases
- ASI 5.1Identificación de responsabilidades y atributos
- ASI 5.2 Identificación de asociaciones y agregaciones
- ASI 5.3 Identificación de generalizaciones
M3 - OO Técnicas en ASI 5 Análisis de clases
- Diagrama de clases
- Diagrama de transición de estados
M3 - OO Cuál es el objetivo de ASI 9 Análisis de consistencia y
especificación de requisitos
Asegurar la calidad de los distintos modelados.
Y que los usuarios y analistas tienen el mismo concepto del sistema
M3 - OO Qué acciones se realizan en ASI 9 Análisis de consistencia y
- Verificación de la calidad técnica
- Aseguramiento de la coherencia entre los distintos modelos
- Validación del cumplimiento de requisitos
M3 - OO Cuáles son las actividades en el proceso de diseño
- DSI 2 Diseño de la arquitectura desoporte
- DSI 3 Diseño de casos de usos reales
- DSI 4 Diseño de clases
- DSI 6 Diseño físico de datos. Estructura física de los datos
- DSI 7 Verificación y aceptación de la arquitectura del sistema
M3 - OO Durante la fase de diseño, el diseño de persistencia se hace en paralelo al diseño de arquitectura
SÍ
M3 - OO Cuáles son las tareas que se realizan en DSI 2 Diseño de la
arquitectura desoporte
- Diseño detallado de los subsistemas de soporte
- Establecimiento de las normas y requisitos propios del diseñoy construcción
- Identificación y definición de los mecanismos genéricos de diseño y construcción
M3 - OO Cuáles son las tareas que se realizan en DSI 3 Diseño de casos de usos reales
- Diseño detallado comportamiento del sistema
- Diseño interfaz de usuario
- Validación de la división de subsistemas
M3 - OO Cuáles son los objetivos de DSI 4 Diseño de clases
- Diseño detallado de cada una de las clases
- Definición de un plan de migración y carga inicial de datos
M3 - OO Cuáles son los objetivos de DSI 7 Verificación y aceptación
de la arquitectura del sistema?
Se garantiza la calidad de las especificaciones del sieño y viabilidad
M3 - OO Enumera todos las técnicas utilizadas
- Casos de uso
- Diagrama de clases
- Diagrama de componentes
- Diagrama de despliegue
- Diagrama de transición de estados
- Diagramas de interacción: secuencia y colaboración
- Diagrama de paquetes
- Técnicas de gestión de proyecots (staffing size)
PROCESO UNIFICADO DESARROLLO - OO
Cuáles son sus principios
- Dirigido por casos de uso
- Centrado en la arquitectura
- Proceso iterativo e incremental
PROCESO UNIFICADO DESARROLLO - OO
Utiliza UML
Sí
PROCESO UNIFICADO DESARROLLO - OO
¿Está basado en compoentes?
Basado en componentes.Uso de intarfaces para conectar los diferentes componentes
PROCESO UNIFICADO DESARROLLO - OO
Principio principal
Para el desarrollo del producto se necesitan todas las representaciones
del producto
PROCESO UNIFICADO DESARROLLO - OO
Enumera los diferentes modelos que se generan
- Modelo de casos de uso
- Modelo de análisis
- Modelo de diseño
- Modelo de implementación (componentes y correspondencia entre clases)
- Modelo de despliegue (definición de nodos físicos)
- Modelo de prueba (criterios de aceptación)
- Representación de la arquitectura
- Modelo de dominio y modelo de negocio
PROCESO UNIFICADO DESARROLLO - OO
Cuáles son los propósitos del Modelo de análisis
- Refinar los casos de uso
- Asignación inicial de funcionalidad
PROCESO UNIFICADO DESARROLLO - OO
Actividades o tareas
- Captura de los casos de uso
- Análisis y diseño de casos de uso
PROCESO UNIFICADO DESARROLLO - OO
En el modelo análisis, ¿cómo se representa cada tipo de clase?
- Clase entidad -> círculo con dos rayas abajo
- Clase de interfaz de usuario -> círculo con T tumbada a la izquierda
- Clase de control -> círculo con flecha
PROCESO UNIFICADO DESARROLLO - OO
Cuál es el objetivo del diseño?
Sirve de esquema para la implementación y define clases, subsistemas, interfaces, relaciones y colaboraciones. El diseño es más físico
¿Qué es el modelo CORBA?
Common Object Request Broker Architecture.
Arquitectura OMA: (Object Managment Architecture).
Es un modelo obsoleto sustituido por arquitecturas SOA, REST, microservicios
Sistemas distribuidos. Facilitar interoperabilidad
¿Qué es la programación orientada al aspecto?
La Programación Orientada a Aspectos (POA) o Aspect-Oriented Programming (AOP) es un paradigma que busca separar las funcionalidades transversales del resto de la lógica de negocio.
La POA permite encapsular esas funcionalidades transversales en módulos separados llamados aspectos, y aplicarlos de forma automática y no intrusiva allí donde se necesiten.
Qué es el Diseño por contrato
Es un poco como el diseño utilizando interfaces fuertemente tipado. Saber que se espera recibir, saber que se espera dar
¿Qué es un patrón de diseño?
Descripción de clases y objetos comunicándose entre sí para resolver un problema de diseño general en un contexto particular.
Es decir, es una solución a un problema determinado que se da habitualmente
Enumera las diferentes categorías de patrones de disños
- Patrones de arquitectura
- Patrones de diseño
- Patrones de idioma o dialectos
- Interacciones
- Antipatrón
Lista de patrones creacionales
- Abstract factory
- Builder
- Factory method
- Prototype
- Singleton
Lista de patrones estructurales
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flywight
- Proxy
Lista de patrones de comportamiento
- Command
- Chain of responsability
- Interpreter
- Iterator
- Mediador
- Memento
- Observer
- State
- Strategy
- Template method
- Visitor
Enumeración de otros patrones
- Patrones de interacción
- CORE J2EE
- J2EE DESIGN
- PATRONES GRASP (General Responsability Assigment Software Patterns)
Patrones fundamentales
- Delegation
- Interface
- Maker interface
