The Internet belongs to everyone. Let’s keep it that way.

Protect Net Neutrality
Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

1.1 Conceptualización de Tecnología Orientada a Objetos

No description
by

Jaime Ávila

on 25 March 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 1.1 Conceptualización de Tecnología Orientada a Objetos

C#
Modelado con UML
El Lenguaje Unificado de Modelado (UML) es un lenguaje gráfico para visualizar, especificar, construir y documentar software. UML ofrece un estándar para describir aspectos conceptuales tales como procesos de negocios y funciones del sistema y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.
Conclusión
La ingeniería de software orientada a objetos, es relativamente joven, y sin embargo, como hemos visto puede llegar a ser muy útil e importante, sobre todo en la "globalización" de software y logrando hacer más eficiente, organizado y fiable el desarrollo de sistemas.
DESARROLLO DE SISTEMAS
DISEÑO
Es Fundamental
Más eficiente y fiable
DISEÑO
1.1 Conceptualización de Tecnología Orientada a Objetos
THANK YOU!
Reutilización
Otros patrones:
De notación y diagramas
De análisis
Patrones
Marcos de Aplicaciones
Define las grandes líneas del modelo del diseño.
Arquitectura
Modalidades:
Clases
Componentes
Patrones
Marcos
Ideas de diseño extraídas de la experiencia, que constituyen un esbozo de solución para problemas parecidos.
Componentes:
Nombre
Contexto
Problema
Solución
Pueden utilizar o complementar otros patrones:
SISTEMAS DE PATRONES
Marcos de caja blanca
Marcos de caja negra
Conjunto de clases que constituyen una aplicación incompleta y genérica.
Reducen el trabajo
Otras compañías pueden suministrar complementos
Diferencias con Patrones
Los patrones son soluciones más pequeñas.
Los patrones son más abstractos.
Los patrones son menos especializados.
Limitan la flexibilidad
Aprendizaje difícil
Reducen creatividad de desarrolladores
Actividades
Establecimiento de la configuración de la red
Nodos, conexiones, ancho de banda, etc.
Establecimiento de los subsistemas
Interfaz
Sólida
Rápida
Fiable
Consistente
Capta la información y la forma en la que será enviada una vez que se procese.
Lista de objetos con los que el usuario interactúa y las acciones que hace sobre ellos.
Navegar por la información e interactuar gráficamente.
Modelo Conceptual de la Interfaz de Usuario
Interfaz Gráfica de Usuario
Preguntas
Conceptos de modelado
Un
sistema
es un conjunto organizado de partes que se comunican, diseñado para un propósito especIfico. Por ejemplo un automóvil, está compuesto por cuatro ruedas, un chasis, una carroceria y un motor, está diseñado para transportar personas.

Partes de un sistema pueden, a su vez, considerarse como sistemas más simples Ilamados
subsistemas
. Por ejemplo el motor de un automóvil, compuesto por cilindros, pistones, un módulo de inyección y muchas otras partes, es un subsistema del automóvil.Esta descomposición en subsistemas puede aplicarse en forma repetida a los subsistemas. Los objetos representan el final de esta repetición, cuando cada parte es lo suficientemente simple para que podamos comprenderla por completo sin mayor descomposición.

Sistemas,modelos y vistas
Se originó de la unificación de un conjunto de lenguajes de modelado gráficos orientados a objetos a finales de la década del 80. Conformando un conjunto de notaciones gráficas que ayudan a describir y diseñar sistemas, particularmente sistemas desarrollados siguiendo el estilo de orientación a objetos.
UML
El
modelado
nos permite manejar la complejidad mediante un enfoque de dividir y conquistar o de dividir y vencer: para cada tipo de problema que queremos resolver construimos un modelo que solo se centra en las cuestiones relevantes del problema.

Por lo general, el modelado se enfoca en la construcción de un modelo que sea lo suficientemente simple para que una persona lo comprenda en forma plena.
Una
vista
se enfoca en un subconjunto de un modelo para hacerlo comprensible.Por ejemplo, todos los pianos necesarios parala construcción de un aeropiano constituyen un modelo. Los extractos necesarios para expiicar el funcionamiento del sistema de combustible constituyen ia vista del sistema de combustible.

Las vistas pueden traslaparse: una vista del aeroplano que representa el alambrado eléctrico también incluye el alambrado para el sistema de combustible.Las
notaciones
son reglas gráficas o textuales para la representación de vistas.
Modelado orientado a objetos
Dominio de aplicación
El dominio de aplicación a veces se divide adicionalmente en:

El dominio de cliente incluye los asuntos relevantes para el cliente, como el costo de operación del sistema, el impacto del sistema en el resto de Ia organización.
El dominio de usuario incluye los asuntos relevantes para el usuario final, como funcionalidad, facilidad de aprendizaje y de uso.
Representa todos los aspectos del problema del usuario. Esto incluye el ambiente fIsico, los usuarios y otras personas, sus procesos de trabajo, etc.

Es crItico que los analistas y desarrolladores comprendan el dominio de aplicación de un sistema para realizar con efectividad la tarea que pretenden.
Dominio de solución
Es el espacio de todos los sistemas posibles. El dominio de solución es mucho más rico y volátil que el dominio de aplicación.

Esto se debe a las tecnologÍas emergentes (también liamadas facilitadores de tecnología), a cambios conforme madura la tecnología de implementación o a una mejor comprensión de la tecnologIa de implementación por parte de los desarrolladores cuando construyen el sistema.

El modelado del dominio de solución representa las actividades de diseño del sistema y diseño de objetos del proceso de desarrollo.

Implementación de los casos de uso
Éste diseño parte del diagrama de colaboración resumido que se ha hecho en la etapa de análisis, y se consideran por separado las clases de frontera, de entidades y de control.

Punto de partida del diseño de la interfaz de usuario.
CLASES DE FRONTERA
Sirven para implementar la funcionalidad de los casos de uso.
CLASES DE CONTROL Y DE ENTIDADES
Éste proceso comienza con el estudio de la implementación de las operaciones ya identificadas en el análisis, una por una.
Los objetos son entidades que tienen un determinado "estado", "comportamiento (método)" e "identidad":

El estado está compuesto de datos o informaciones; serán uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.
La identidad es una propiedad de un objeto que lo diferencia del resto; dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).
PROGRAMACION ORIENTADA A OBJETOS
DISEÑO DE CLASES DE CONTROL
Nuevas operaciones de clases.
Nuevas clases.
¿Que se necesitará?
Diagrama estático de diseño
OBJETIVOS


Esta actividad es contraria a todas las demás actividades que describimos en los capItulos anteriores: análisis, diseflo, implementación, comunicación y negociación son actividades constructivas.
Sin embargo, las pruebas están orientadas al quebrantamiento del sistema. En consecuencia, Las pruebas las realizan, por lo general, desarrolladores que no estuvieron involucrados en Ia construcción del sistema.
PANORAMA DE LAS PRUEBAS
La falla es cualquier desviación del comportamiento
observado con respecto al especificado
Un error significa que el sistema está en un estado tal
que el procesamiento adicional del sistema conducirá a una falla, lo cual causa que el sistema se
desvie del comportarniento pretendido
Un defecto es la causa mecánica o algoritmica de un error
FALLA
ERROR
DEFECTO
El objetivo es diseñar pruebas que manifiesten los
defectos que hay en el sistema y que revelen los problemas.
El objetivo de las pruebas es maximizar la cantidad de defectos descubiertos, lo cual luego permite que los desarrolladores los corrijan e incrementen la confiabilidad del sistema.
La revisión del diagrama obtenido se basa en:
Normalización de los nombres
Es bueno utilizar la misma terminología del diagrama estático del análisis.
Es probable que debamos cambiar algunos nombres:
Podemos vulnerar alguna norma aplicable al proyecto.
Para respetar una terminología ya establecida en proyecto anteriores
O porque el lenguaje de programación no lo soporta.
Las actividades de las pruebas se documentan en cuatro tipos de documentos, Plan de pruebas, Especificaciones de casos de prueba, Reportes de incidentes de pruebas y Reporte de resurnen de pruebas.
DOCUMENTACION
Este documento lista todas las fallas que se descubrieron durante las pruebas y que necesitan investigarse.
Cada ejecución de cada prueba se documenta en un
Reporte de incidentes de la prueba. Se registran los resultados reales de las pruebas y las diferencias con respecto a la salida esperada
Cada prueba se documenta con una especificación de caso de prueba.
Este documento contiene las entradas, manejadores, stubs y salidas esperadas de las pruebas.
Este documento también contiene las tareas a realizar.
El plan de pruebas se enfoca en los aspectos administrativos de las pruebas.
Documenta el alcance, enfoque, recursos y calendarización de las actividades de pruebas.
En este documento se identifican los requerimientos y componentes a probar.
Es realizar una revisión sistemática en busca de clases que pueden ser reutilizadas por otras ya existentes.
Un caso de prueba es un conjunto de datos de entrada y resultados esperados que ejercitan a un componente con el propósito de causar fallas y detectar defectos. Un caso de prueba tiene cinco atributos: nombre, ubicación, entrada, oráculo y bitácora
CASOS DE PRUEBAS
Reutilización de las clases
• Las pruebas unitarias tratan de encontrar defectos en los objetos participantes o en los subsistemas, o en ambos, con respecto a los casos de uso del modelo de casos de uso.

• Las pruebas de integración son las actividades relacionadas con la localización de defectos cuando se prueban juntos componentes que se han probado de manera individual; por ejemplo, los subsistemas descritos en la descomposición en subsistemas, mientras se ejecutan los casos de uso y escenarios del RAD.

• Las pruebas de estructura del sistema son la culminación de las pruebas de integración que involucran a todos los componentes del sistema. Las pruebas de integración y de estructura explotan el conocimiento del SDD usando una estrategia descrita en el Plan de pruebas (TP, por sus siglas en inglés).

• Las pruebas de sistema prueban todos los componentes juntos, vistos como un solo sistema, para identificar errores con respecto a los escenarios del enunciado del problema y a los objetivos de los requerimientos y del diseño identificados en el análisis y el diseño del sistema, respectivamente:

• Las pruebas funcionales prueban los requerimientos del RAD y, si se tiene disponible, del manual de usuario.

• Las pruebas del desempeño revisan los requerimientos no funcionales y objetivos de diseño adicionales del SDD. Observe que los desarrolladores realizan las pruebas funcionales y de desempeño.

• Las pruebas de aceptación y de instalación revisan los requerimientos contra el acuerdo del proyecto y deben ser realizadas por el cliente, con apoyo de los desarrolladores si es necesario.
TECNICAS PARA LA DETECCION DE DEFECTOS
La herencia múltiple no suele ser soportada por todos los lenguajes.
Adaptación de la herencia en el nivel soportado por el lenguaje de programación
Por ello existen varias formas de deshacerla:
Por duplicación .
Por delegación.
Por interfaces.
Por agregación.
Si el lenguaje de programación no soporta las interfaces, las sustituiremos por clases abstractas.
Ahora en el diseño nos debemos preocupar por cuestiones de eficiencia que en el diseño no nos preocupaban.
Sustitución de las interfaces
Cambios para la mejora del rendimiento
Aquí mando yo
CAJA BLANCA
¿Qué significa OMG?

¿Cuáles son las cuatro modalidades de la reutilización?

¿Cuáles son las clases persistentes?

-En modelado ,¿Que son la notaciones?

Menciona los cinco atributos de un caso de uso de pruebas
Los atributos deben ser sustituidos con 1 valor por clases múltimples aparte que comparta con la primera una asociación de 1 a n, ya que así no hay que enviar un mensaje de una clase a otra.
Agrupación de clases para reducir el tránsito de mensajes
CAJA NEGRA
Las pruebas de caja negra se enfocan en el
comportamiento de entrada/salida del componente. Las pruebas de caja negra no manejan los
aspectos internos del componente ni el comportamiento o estructura de los componentes.
Las pruebas de caja blanca se enfocan en Ia estructura interna del componente. Una prueba de caja
blanca se asegura que, sin importar el comportamiento de entrada/salida particular, se pruebe
cada estado del modelo dinámico del objeto y cada interacción entre los objetos.
Para toda clase debe haber una operación que:
Sustituir las operaciones de las clases de frontera por operaciones en elementos de la interfaz de usuario.
Especificación de las operaciones implícitas
La instancia.
Destruya objetos.
Lean y pongan los valores de todos los atributos.
PLAN DE PRUEBAS
ESPECIFICACIONES DE CASOS DE PRUEBA
REPORTES DE INCIDENTE DE PRUEBAS
REPORTE DE RESUMEN DE PRUEBA
Referencias a las clases frontera
Cohesión y acoplamiento
Los atributos y operaciones de cada clase deben tener mucha relación entre sí.
DEBE SER COHERENTE
Los conceptos de la POO tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard, del Centro de Cómputo Noruego en Oslo.
ORIGEN
Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ella.

Herencia: Por ejemplo, herencia de la clase C a la clase D, es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C.

Objeto: Instancia de una clase. Entidad provista de un conjunto de propiedades o atributos y de comportamiento o funcionalidad, los mismos que consecuentemente reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o con objetos internos del sistema (de. Es una instancia a una clase.

Método: Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

Evento: Es un suceso en el sistema. El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento la reacción que puede desencadenar un objeto; es decir, l acción que genera.

Atributos: Característica que tiene la clase.
CONCEPTOS
Poco coherentes = Más difíciles de entender.
INTRODUCCION
La programación orientada a objetos (POO) es un paradigma de programación que usa objetos en sus interacciones, para diseñar aplicaciones y programas informáticos.
El acoplamiento expresa el grado en el que éstos dependen de otras clases y objetos para llevar a cabo su responsabilidad.
Mayor acoplamiento =
Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.
Clase afectada por cambios en otras.
Por tanto, se deberá modificar más a menudo.
La POO se fue convirtiendo en el estilo de programación dominante a mediados de los años 1980, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las interfaces gráficas de usuario, para las cuales la POO está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.
Clases persistentes
Existen tres tipos principales de sistemas de almacenamiento: bases de datos orientadas a objetos, bases de datos relacionales y ficheros clásicos; y base de datos object-relacional.
Se llama clases persistentes a las que pueden tener objetos persistentes, y clases temporales a las no persistentes.
Un objeto persistente es aquel que tiene una vida más larga que el proceso que lo crea, por lo que hay que grabarlo en un sistema de almacenamiento permanente y también lógicamente debe poder ser leído.
Es el caso más sencillo de todos, ya que no hay que transformar los objetos para hacerlos persistentes.
Bases de datos orientadas a objetos
En la definición de la clase con objetos persistentes, se indica cuales de sus atributos lo son y qué política de lectura de objetos se requiere.
A un objeto le corresponde una fila de una tabla de base de datos relacional o un registro de un fichero; y a los atributos le corresponden columnas de la tabla correspondiente.
Bases de datos relacionales y ficheros clásicos
Se hace necesario realizar la gestión de la persistencia, la cual se puede hacer de 3 maneras:
Cada clase persistente tiene operaciones para que los objetos se graben, borren, etc, por sí mismos.
Desventaja: Dependerá de cada gestión de base de datos concreta.
Ventaja: Requiere menos llamadas a objetos
Este gestor accede directamente en cada clase a la base de datos, así la clase de entidades se desacopla del sistema de gestión de base de datos y además el gestor puede servir de memoria caché intermedia.
Gestor de disco para cada clase persistente
Se crean gestores de disco y se añaden operación de grabación, lectura en cada clase de dominio.

Diferencia: Puede ser más portable.
Mezcla de las dos anteriores
Bases de datos object-relational
Puede tener atributos de tipo compuesto, por tanto, no será necesario crear gestores de disco para todas las clases persistentes, sino sólo para aquellas a las cuales se accederá directamente.
Fases para definir la estructura de base de datos relacional o con ficheros clásicos
Se convierte cada clase con un atributo con valores múltiples en dos clases unidas por una asociación, y después le hacemos corresponder un tipo de entidad a cada clase no asociativa. Después se añade una relación para cada asociación con cardinalidades.
1. Transformamos el modelo estático en un modelo entidad-relación
2. Supresión de la herencia
Definiendo una tabla para cada clase que contendrá los atributos propios de la clase y los heredados.
Es una solución sencilla pero tiene tantas tablas como subclases, hay que crear un gestor de disco para cada subclase.
Se puede crear una tabla para la superclase en la que se graba a todos los clientes; a la vez se crea una tabla complementaria para cada subclase con el identificador del objeto y los atributos específicos.
Se crea una única tabla para todas las jerarquías de herencia con todos los campos, tanto de la superclase como de todas sus subclases y se le añade un campo que nos diga qué subclase del objeto corresponde a cada fila.
Es buena solución si sólo una pequeña fracción de los objetos de la clase pertenecen a la subclase y además si los valores de los atributos son de longitud fija.
La eficiencia en tiempo es muy elevada en esta solución, pero menos en ocupación de disco.

LENGUAJES
JAVA
HISTORIA
OMG
OMT
UML
RUBY
PYTHON
VISUAL BASIC
Organización no lucrativa, consituida por más de 800 empresas para:

• Fomentar el uso de la tecnología orientada a objetos.
• Dedicado al cuidado y el establecimiento de diversos estándares de tecnologías.
• Impulsar la generación de este tipo de software.

1989
1991
C++
1996
¿Qué debemos hacer?
Aprovechar la oportunidad de reutilizar componentes
Aplicar patrones y marcos siempre que sea posible.
Enfoque de modelado de objetos para el diseño de software. Método de desarrollar sistemas orientados a objetos.
Modelo para la construcción de software orientado a objetos, que ha sido propuesto como estándar de ISO por el OMG. Con él se ha llegado a un modelo orientado a objetos único de forma oficial.
Object Management Group
Unified Modeling Language
Object-Modeling Technique
Modelo Dinámico:

Describe el comportamiento interno del sistema.
ANÁLISIS
Paquetes UML
1. Traducir los requisitos a un lenguaje más formal.
2. Identificar las clases fundamentales para la implementación del software.
3. Expresar los casos de uso en términos de clases.


Cada paquete debe ser
coherente
y
poco dependiente
. A su vez este paquete de análisis se divide en paquetes de servicio, y cada paquete de servicio sólo puede estar en un paquete de análisis a la vez.
Modelo Funcional:

Describe la funcionalidad del sistema desde el punto de vista del usuario.
Modelo de Objetos:
Describe Ia estructura de un sistema desde el punto de vista de objetos, atributos, asociaciones y operaciones.
Las pruebas son el proceso de encontrar diferencias entre el comportamiento esperado, especificado
por los modelos del sistema, y el comportamiento observado del sistema.

Cuando se encuentran diferencias, los desarrolladores identifican el defecto que causa Ia falla observada y modifican el sistema para corregirlo. En otros casos se identifica a! modelo como causa de Ia diferencia y se actualiza éste para que refleje el estado del sistema.

Definimos las pruebas como el intento sistemático de localizar errores en forma planeada
en el software implementado.
Esta definición contrasta con otra usada por lo comün que dice
que "las pruebas son el proceso de demostrar que no hay errores presentes".
Clases de frontera
: Representan la interfaz de usuario por pantalla. Debe haber al menos una para cada papel de cada actor y representan objetos gráficos complejos como ventanas, diálogos de pantalla, menús…
Clases de entidades
: Corresponden a los objetos del dominio que

serán
persistentes.
Clases de control
: Corresponde a objetos internos del software, no modelan nada del mundo real y sus operaciones suelen contener la parte principal de los algoritmos de aplicación. Si en el futuro tenemos que variar los algoritmos de proceso sin cambiar nada en los datos, solo será necesario modificar las clases de control.
Paquetes de análisis
Paquetes de servicios
Comprenden casos de uso relacionados y tienen que ver con un único actor; son indivisibles (o un cliente tiene un paquete de servicios completo, o no lo tiene).
División de la documentación
Tipos de clases de análisis
Análisis y diseño orientado a objetos


El análisis orientado a objetos está interesado en el modelado del dominio de aplicación.
El diseño orientado a objetos está interesado en el modelado del dominio de solución. Ambas
actividades de modelado usan las mismas representaciones (es decir, clases y objetos). En el
análisis y diseño orientados a objetos, el modelo del dominio de aplicación también es parte del
modelo del sistema.


Por ejemplo, un sisterna de control de tráfico aéreo tiene una clase ControladorTráfico para representar a los usuarios individuales, sus preferencias e información de bitácora.

El sistema también tiene una clase Aeronave para representar la información asociada con la aeronave a la que se le está dando seguimiento. ControladorTráfico y Aeronave son conceptos del dominio de aplicación que están codificados dentro del sistema.
Cada uno de estos corresponde a subsistemas enteros y pueden servir para repartir el trabajo del análisis entre varias personas o equipos.
Diagrama de caso de uso
Diagramas de clase
Diagramas de secuencia, gráfica de estado o de actividad
Análisis y Modelado de Sistemas de Información
Competencia:
Analizar y modelar proyectos de sistemas de información aplicando el paradigma orientado a objetos.
Tema 1: El Modelo del Proceso de Software
Competencia:
Conocer el modelo de proceso de software.
Temario y Actividades:
Full transcript