Sis 2

TECNOLOGIA ORIENTADA A OBJETOS La Tecnología Orientada a Objetos es parte de la evolución de la tecnología de información (IT: Information Technology). Es uno de los mayores logros en el modelamiento de sistemas en la última década. Permite: - Construir aplicaciones más rápidamente. - Incrementar la calidad del producto resultado. - Soportar el cambio de requerimientos mas facilmente. - Soportar la migración a plataformas distribuidas. - Permite una relación entre un modelo de negocio orientado a objetos y los componentes de un software desarrollado en un lenguaje orientado a objetos.

Beneficios - Es una vía de modelado muy intuitiva porque esta refleja la forma en que nosotros pensamos en el mundo real (utiliza nuestro vocabulario). - Facilidad en el mantenimiento de sistemas que reflejen cambios en sus requerimientos, debido a que los componentes desarrollados pueden cambiar y modificarse sin efectos sobre otros componentes. - Un mismo modelo es usado a lo largo de todo el ciclo de vida de desarrollo, desde la fase de análisis hasta la fase de implementación (usando los mismos conceptos, simplificando la extensión del problema y refinándolo). - Mantiene una clara separación entre la interfaz (¿QUÉ es lo que hace un objeto?) y su implementación (¿CÓMO lo hace?). Esta separación permite que los objetos sean más flexibles debido a que se puede cambiar la implementación de las clases sin afectar el resto del sistema. Ejm. Metodo Factorial. ¿ “Que hace este me todo?: Calcular el factorial de un numero entregado como parámetro. ¿ “Como lo hace?: En caso el parámetro sea 1 entrega 1. En caso contrario multiplica este por la invocación del factorial del mismo numero menos 1. En el ejemplo, se puede cambiar la forma de cálculo recursivo por un método iterativo.

Cliente versus Equipo de Desarrollo

Hay un numero de retos a enfrentar en la relación existente entre los clientes (o usuarios) y los Desarrolladores, debido a las diferentes perspectivas existentes. Clientes: Conocen su negocio y sus propias necesidades. Desarrolladores: Están enfrentados con las siempre cambiantes tecnologías y las reglas del negocio.

Características del desarrollo Orientado a Objetos El desarrollo Orientado a Objetos se enfoca en los objetos como unidades de abstracción.

“Que es un Objeto? - Un objeto es definido como una abstracción de software que modela los aspectos relevantes de una entidad tangible o conceptual dentro de una solución (modela alguna parte de la realidad). - Un objeto es un "paquete" de software que contiene una colección de datos relacionados (atributos) y procedimientos (métodos) que controlan dichos datos. -La estructura y comportamiento de objetos similares están definidos en una clase común para especificación y simplificación. Las clases son como plantillas a partir de las cuales se pueden crear objetos con las mismas características (Un objeto es una instancia de una clase).

- Los objetos se comunican entre ellos enviando mensajes de una a otro, los cuales producen que se ejecute una operación (también conocido como método) en el objeto que lo recibe, logrando así que el sistema responda.

Un objeto es la instancia de una clase (o categoría), que cuenta con una estructura: atributos (propiedades) y operaciones (metodos). Las operaciones son todas las actividades que el objeto es capaz de realizar. Los atributos y operaciones, en conjunto, se conocen como características o razgos. - La Tecnología Orientada a Objetos descompone todo un sistema en objetos los cuales interactúan entre ellos, haciendo cosas por el sistema. Para cada objeto que se defina se debe pensar que hará este objeto por el sistema (“que servicios hará para otros objetos?). - Lo importante es entender como el objeto será usado en el sistema especificando solo las operaciones relevantes.

Atributos de un Objeto

-Los Objetos tienen todo el conocimiento del sistema. Cada pieza de conocimiento es llamada atributo, el cuál tiene un nombre y un valor. El estado de un objeto esta definido por el valor de sus atributos. - Los atributos son normalmente deducidos después de que se haya decidido las operaciones que este va a brindar. El número de atributos depende de las operaciones que el objeto ejecuta. -Los objetos pueden necesitar acceder a los datos almacenados en otros objeto.

-Cuenta Bancaria:

Operaciones principales:

¿ Atributos principales:

-Retirar Efectivo. -Depositar Efectivo. -Depositar Cheque. -Pagar Servicio.

-Numero de la Cuenta. -Saldo de la Cuenta. -Tipo de Cuenta. -Moneda de la Cuenta.

Como decidir que operaciones y atributos son relevantes en el modelado de un sistema. En primer lugar se debe entender como un objeto será usado por otros objetos del mismo sistema. - Se puede definir un numero casi infinito de atributos sin embargo se debe decidir cuales son los relevantes de tal forma que todas las operaciones tengan algo que ejecutar con estas características almacenadas. Por ejemplo se puede tener como atributo de un objeto el numero de átomos que lo conforma, pero “es esta información útil para alguno de las operaciones del objeto?

Abstracción La abstracción se refiere a quitar las características de un objeto para dejar sólo aquellas que sean necesarias. Diferentes tipos de problemas requieren distintas cantidades de información, aún si estos problemas pertenecen a un área común.

Encapsulacion “ocultamiento de información” Es un principio de estado que agrupa datos y procesos permitiendo ocultar a los usuarios de un objeto los

detalles de implementación, ofreciéndoles una interfaz externa mediante la cual poder interaccionar con el objeto.

Es decir se esconde los atributos del objetos para otros objetos, permitiéndose el acceso a estos mediante sus propios métodos. Con esto se protege los datos en el objeto, evitando que otros objetos manipulen sus valores, ya que los pueden corromper o dañar. Asimismo, al ocultar sus atributos, centraliza el acceso a ellos a través de los métodos, evitando recargar a otros objetos con tareas de interpretación y consulta directa de ellos. En un sistema que consta de objetos, éstos dependen unos de otros en diversas formas. Si uno de ellos falla y los desarrolladores tienen que modificarlo, el ocultar sus operaciones de otros objetos significará que tal vez no será necesario modificar los demás objetos.

Beneficios Interno: - Evita que se ”corrompan„ los datos. - La implementación de una operación puede cambiar sin imposibilitar que los demás usuarios la puedan seguir usando de la misma manera.

Externo: - Evita que otros objetos se ”compliquen„ con el uso del objeto.

Relaciones entre Objetos: Relación de: Clasificación (Es Miembro de) -> software Microsoft : Word, Excel Generalización (Es un) -> Vehiculo : ciclomotor, camion, auto Agregación (Es parte de)-> Automovil ruedas, motor, volante

Asociaciones - Los Objetos necesitan comunicarse con otros objetos. Para ello los Objetos se asocian con otros objetos a través de enlaces (Asociaciones). Un objeto puede pasar mensajes a otro objeto utilizando estas Asociaciones. Las asociaciones son bidireccionales. Cada objeto puede enviar mensajes al otro.

Agregación

Es un tipo de asociación mediante el cual un objeto se conforma de otros sub-objetos (una combinación de diversos tipos de objetos). ¿ Por ejemplo un objeto Computadora esta compuesto por los subobjetos Monitor, Teclado, CPU, Mouse, etc.

El uso de Agregación facilita el reúso de componentes desarrollados para otros objetos. Los subobjetos desarrollados para un sistema pueden ser utilizados para otros.

Multiplicidad

La Multiplicidad describe el número de objetos que son parte de una asociación o enlace en un momento en el tiempo. Es necesario identificar la multiplicidad para entender las limitaciones y habilidades del sistema que se está modelando. Es usualmente expresado de las siguientes maneras. -

Solo 1 0o1 0 o mas De 1 a Muchos

Mensajes

En un sistema los objetos trabajan en conjunto interactuando a través del envió de mensajes. Éstos mensajes indican la necesidad de un servicio del objeto que envía el mensaje (precisando que método ejecutar) y el otro receptor ejecutará la operación. “Una comunicación entre objetos que transmite información con la expectativa de desatar una acción. La recepción de un mensaje es, normalmente, considerado como un evento”

Partes de un mensaje: - Objeto receptor - Metodo a activar - Parametro (opcional)

En los mensajes existe el requerimiento, del objeto emisor al receptor, y una respuesta del receptor al emisor. La respuesta o valor de retorno de un mensaje puede ser un objeto o un tipo simple de dato. Ejemplo de Asociaciones y Mensajes

Clases Una clase es una categorizacion de objetos que tienen el mismo comportamiento y la misma estructura, de manera que se pueda especificar atributos, operaciones y asociaciones comunes a ellos. Ademas es una plantilla para fabricar objetos con las mismas caracteristicas. - Cuando se crea un objeto particular a partir de una clase, es necesario que se inicialicen los atributos y asociaciones con valores especıficos.

Ejm. Para la clase Persona al momento de crearse un objeto a partir de ella es necesario definir los atributos de este, como son el nombre, el apellido, direccio n, etc.

Clases versus Objetos Las clases son definiciones estáticas que nos permiten entender a todos los objetos de la misma. Los Objetos son entidades dinámicas, que existen en el mundo real o en una simulación de el.

Herencia

Herencia es la relacion existente entre clases donde una clase llama a la otra padre. La clase hijo puede tener atributos adicionales y un comportamiento relevante a e l ası como puede redefinir operaciones especificadas en la clase padre en el caso fuera requerido. Cuando un objeto de una clase hijo es creado, e l hereda todas las propiedades de su clase padre ademas de los definidos en la clase hijo. La herencia puede mejorar la productividad debido a que nuevas clases pueden ser creadas rapidamente basadas en clases ya existentes.

Polimorfismo (”muchas formas") Es la propiedad por la que una operación existe en varias clases y se comporta de forma diferente en c/u de ellas (implementacion distinta). -> pueden haber varios métodos para una misma operacion. Es importante que cada metodo implementado tenga la misma semantica. (Los argumentos pasados como parametro y el valor de retorno deben ser consistentes en todos los me todos polimorficos). * Permite detectar y aprovechar similitudes entre distintas clases de objetos ->Objetos distintos que responden a un mismo mensaje pueden ser tratados de la misma forma por el remitente * La importancia del polimorfismo es que permite sea invocada una operacion en un objeto de cualquier clase.

Ejemplos. ¿ Si para las siguientes clases -Prestamo Largo Plazo -Prestamo a Corto Plazo -Sobregiro -Tarjeta de Credito

¿ Se desea implementar un metodo de calculo de interes, cada modalidad de credito puede tener su propia tasa de interes y su

propia formula de calculo. ¿ La implementacion de cada uno de estos metodos para cada una de estas clases serıa un conjunto de metodos polimo rficos.

En ocasiones una operación tiene el mismo nombre en diferentes clases. Por ejemplo, podrá abrir una puerta, una ventana, un periódico, un regalo o una cuenta de banco, en cada uno de estos casos, realizará una operación diferente. En la OO, cada clase “sabe” cómo realizar tal operación. Esto es el polimorfismo. Caso: Generacio n de cheques para pago a proveedores En una empresa productora de colchones, diariamente llegan insumos y materias primas utilizadas en el proceso de fabricacion provenientes de diferentes proveedores. - Cada embarque de materias primas llega con una factura del proveedor. - En el almacen de la fabrica se ingresan los insumos o materias primas habiendose verificado que lo especificado en la factura del proveedor sea exactamente lo que se esta recibiendo. (En ocasiones parte de la mercaderıa no llega completa o se rechaza parte de ella por no cumplir con ciertas especificaciones de la empresa en cuyo caso so lo se registra en el sistema lo que se ingresa.) - Una vez ingresada la mercaderıa se genera la nota de ingreso de mercaderıa de almacen, que junto con la factura del proveedor es enviada al area de contabilidad, para que esta registre en el sistema la factura del proveedor (Indicandose la fecha de vencimiento, forma de pago, moneda, ademas de otros datos.)

Caso: Generacio n de cheques para pago a proveedores Semanalmente se obtiene un listado de las facturas vencidas o por vencer en la semana para que pase por aprobacion del gerente financiero, el cual indica que facturas deberan ser canceladas. De la relacio n de facturas aprobadas por el gerente financiero la persona de contabilidad procedera a generar los cheques correspondientes (Pudiendo un mismo cheque cancelar 2 o mas facturas de un mismo proveedor.) Definir las clases requeridas para el siguiente caso. Adicionalmente dar ejemplos de objetos de las principales clases.

Resumen Un objeto es una instancia de una clase. Una clase es una categoría genérica de objetos que tienen los mismos atributos y operaciones. Cuando crea un objeto, el área del problema en que trabaje determinará cuántos de los atributos y operaciones debe tomar en cuenta. Un objeto hereda los atributos y operaciones de su clase. Una clase también puede heredar atributos y operaciones de otra. El polimorfismo esquecifica que una operación puede tener el mismo nombre en diferentes clases y cada clase ejecutará tal operación de forma distinta. Los objetos ocultan su funcionalidad de otros objetos y del mundo exterior. Cada objeto presenta una interfaz para que otros objetos (y personas) puedan aprovechar su funcionalidad. Los objetos funcionan en conjunto mediante el envío de mensajes entre ellos. Los mensajes son peticiones para realizar operaciones. Por lo general, los objetos se asocian entre sí y esta asociación puede ser de diversos tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase. La agregación es un tipo de asociación. Un objeto agregado consta de un conjunto de objetos que lo componen y una composición es un tipo especial de agregación. En un objeto compuesto, los componentes sólo existen como parte del objeto compuesto.

Clase 2

Ciclo de Desarrollo Fases de un Proyecto

– Toma de Requerimientos: Identificar las necesidades explıcitas o implıcitas del negocio.

Se identifican las necesidades o problemas (requerimientos) que debe proporcionar el sistema. Estos requerimientos pueden ser funcionales (Que es lo que debe proveer el sistema) o no funcionales (restricciones que el sistema debe cumplir como rendimiento o confiabilidad). – Analisis: Entendimiento de ¿Que debe hacer el sistema?

En esta etapa se especifica que debe hacer el sistema. Para ello: – Conocer acerca de las reglas del negocio y los terminos especıficos de este (Vocabulario de la empresa), para ello se capturan todas las entidades del negocio, sus interrelaciones y su comportamiento. – Se desarrolla un armazon de clases usando la clasificacion natural y sus relaciones. – Diseno:

Definir como el sistema trabaja internamente, para que los requerimientos puedan ser entregados. – Se profundiza en el modelo obtenido del analisis, identificando en mayor detalle los objetos que lo conforman y sus interrelaciones en una mayor profundidad. – Implementacion:

Construccion del modelo disenado en el paso anterior. – Soporte y Mantenimiento:

Puesta en marcha del sistema. Correccion de errores cometidos durante la etapa de implementacion.

Ciclo de Vida en Cascada

(Ciclo Secuencial de Actividades) El mas conocido ciclo de vida de un sistema. – Cada etapa del desarrollo de un sistema tiene que estar completada para iniciar con la siguiente etapa. – Este enfoque se asegura que el sistema este bien estructurado y bien definidos sus requerimientos, permitiendo flexibilidad y modularidad al sistema por desarrollar. – Su principal debilidad es la cantidad de tiempo que se requiere para entregar un producto al cliente, ademas que no se consideran los casos en que existen malas interpretaciones iniciales de los requerimientos.

Fases secuenciales Comienzo de una fase con el término de la anterior Paso de fase al conseguir los objetivos Obtención de documentos como criterio de finalización de fase El final de una fase puede suponer un punto de revisión  

Inconvenientes

Exige al usuario que exponga explícitamente todos los requisitos al principio, presentando problemas para gestionar la incertidumbre natural propia del comienzo de la mayoría de los proyectos

Hasta llegar a las etapas finales del desarrollo no habrá una versión operativa del programa, lo que influye negativamente en el descubrimiento a tiempo de errores o incongruencias en los requisitos

Ciclo de Vida Iterativo sistema completo; funcionalidad parcial Como respuesta a los tiempos extensos necesarios para el desarrollo de un sistema se desarrollo el ciclo iterativo. – En este ciclo de vida el desarrollo esta dividido en un numero de incrementos, en donde varias etapas del desarrollo pueden hacerse en paralelo sin esperar que la etapa previa haya concluido. – De esta forma se pueden entregar muchas versiones parciales de un sistema, cada una con algunas funcionalidades incrementadas. – Cada fase en sı, es un pequeno desarrollo de un proyecto de sistemas. Un proceso iterativo permite una comprensión creciente de los requerimientos, a la vez que se va haciendo crecer el sistema. Así se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente. Este modelo se basa en la evolución de prototipos ejecutables, mensurables y evaluables, en los cuales se van incorporando mejoras funcionales en cada iteración (versiones). Cada iteración reproduce el ciclo de vida en cascada, pero a una escala menor. Los objetivos de cada iteración se establecen en función de la evaluación de las iteraciones precedentes RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero.

Beneficios Se alienta el feedback del usuario Focalización en los temas más críticos, sin distracciones Testing continuo e iterativo: evaluación objetiva Inconsistencias entre requerimientos, diseños e implementaciones se detectan tempranamente Carga de trabajo mejor repartida en el tiempo Integración progresiva en lugar de Big Bang Evidencias concretas a los sponsors Se facilita la reutilización Arquitectura más robusta

Análisis Orientado a Objetos

La fase del Análisis Orientado a Objetos se puede dividir en las siguientes etapas: 1) Identificar el alcance del sistema

– Investigar y documentar las decisiones acerca de cuales son los alcances que tendra el sistema y cuales requerimientos estaran fuera de este. Estaes quizas la etapa mas crıtica de todo el proyecto. debido a que en ella el usuario (cliente) define que es lo que tendra y no tendra en el sistema final.

2) Identificar los principales Conceptos del sistema – Se debe investigar y documentar acerca del vocabulario de negocios de la empresa.

– Esto ayuda a clarificar los terminos usados por el usuario (cliente) de tal forma que se asegura que todos tienen un comun entendimiento de que es lo que cada termino significa.

3) Especificacion detallada de Requerimientos. – Se investiga y documenta como el usuario interactua con el sistema y como esto afecta al mismo.

4) Examinar el comportamiento de los Objetos. – Investiga y documenta el dinamico comportamiento de objetos especıficos del negocio en el sistema. – Solo los objetos mas importantes del negocio deben ser considerados en esta etapa.

Diseno Orientado a Objetos La fase de Diseno Orientado a Objetos se puede dividir en las siguientes etapas. 1) Diseno de la Arquitectura – La mayorıa de sistemas son demasiado complejos como para entenderse como una unidad. – Es por esto que es necesario partirlos en un conjunto de subsistemas mas simples y faciles de manejar. – Estos subsistemas forman la arquitectura del sistema. – Cuando se disena esta arquitectura se definen los componentes de hardware que forman parte de la infraestructura (PC, Servidores) y los componentes de software que son necesarios construir (Aplicaciones, librerıas).

2) Diseno de Requerimientos – Se adiciona mas informacio n al modelo con el fin de especificar como los objetos se comunican entre sı utilizando mensajes.

3) Diseno de Clases – En esta etapa se tiene un razonable detalle y descripcion de las principales clases en el sistema.. – Se debe revisar cada clase definiendoles los atributos y operaciones.

4) Diseno de Asociaciones – En el Analisis Orientado a Objetos (OOA) se asume que todas las asociaciones son bidireccionales. - En esta etapa se revisa cada asociacion y se identifica la mas eficiente implementacion para los fines buscados.

Implementacion La fase de Implementacion se puede dividir en las siguientes etapas: 1) Definir las Clases en Codigo – Para cualquier lenguaje de programacio n utilizado, como primer pasose debe definir cada clase en el lenguaje escogido. – En la definicio n de la clase se debe especificar: nombre de la clase, nombre de los atributos (especificando los tipos) y nombres de las operaciones indicando el nu mero y tipo de sus argumentos.

2) Implementar las Clases – Cada operacio n definida en una clase debe ser implementada como una funcio n separada en el programa. – Las clases simples pueden ser implementadas por un simple programador mientras que las clases complejas tienen que ser desarrolladas por un equipo de programadores debido a que pueden tener cientos de operaciones relacionadas.

3) Prueba Unitaria – Cada clase antes de poder ser considerada segura para ser reusada por otros programadores en otros proyectos deberaser probada Debidamente – Esta prueba deberaser realizada de forma separada para cada clase.

4) Prueba de Integracio n – Una vez se tengan todas las clases operando apropiadamente de forma independiente se debera verificar que ademas trabajan correctamente una vez que todas hayan sido reunidas.

5) Prueba de Aceptacion

– El sistema es probado por el cliente (usuario) con la finalidad que lo valide y verifique que cumple con los requerimientos especificados.

Unified Modeling Language (UML) ¿ Que es UML? UML aparecio a trave s de un proceso de estandarizacio n con la OMG (Object Management Group) del cual actualmente es un estandar. – UML es un Modeling Language (Lenguaje de Modelado). Es una notacio n principalmente grafica de me todos usados para expresar disenos y desarrollar software UML no es una metodologıa. Es una sintaxis visual que puede ser usada para crear modelos metodolo gicos como es el caso del Proceso Unificado (Unified Process, UP) base de RUP (Rational Unified Process). UML logra unificar los siguientes puntos: í Ciclo de vida del Desarrollo: Debido a que provee una sintaxis visual para todas las etapas del desarrollo de software. Desde la

toma de requerimientos hasta la implementacio n. í Tipos de Aplicacio n: Es usado para modelar casi cualquier tipo de sistema, como sistemas en tiempo real, sistemas de informaci o n,sistemas de soporte para toma de decisiones, etc. í Lenguajes y Plataformas: UML puede ser usado sobre cualquier plataforma y lenguaje de programacio n aunque se obtienen mucho mejores resultados sobre lenguajes y plataformas orientadas a objetos. í Metodologıas de desarrollo: Aunque UP es probablemente la metodologıa preferida para el uso de UML, el puede soportar muchos otras metodologıas de ingenierıa de software. í Sus propios Conceptos: UML es consistente y uniforme en la aplicacio n de todos sus conceptos. – Los diagramas definidos en UML se utilizan para modelar cada etapa del ciclo de desarrollo. – Para manejar casos particulares, UML provee las herramientas para construir diagramas adicionales o modificar los existentes.

Esto se debe a que permite a los analistas y diseñadores de sistemas crear diagramas que capturen los requerimientos de los usuarios y las soluciones de los analistas en una forma sencilla y fácil de comprender por todo el equipo de desarrollo, así como por los usuarios convencionales.

1) Provee a los desarrolladores un lenguaje de modelamiento visual listo para utilizar. 2) 3) 4) 5) 6) 7)

Consolida un conjunto de conceptos generalmente aceptados por muchos métodos y herramientas. Proporciona mecanismos de extensión y de especialización para ampliar los conceptos básicos. Es independiente de los lenguajes de programación y de métodologías de desarrollo de software. Proporciona una base formal para entender el lenguaje de modelado. Anima el crecimiento del mercado de las herramientas OO. Utiliza conceptos de alto nivel de desarrollo tales como colaboraciones, armazones, modelos y componentes. Integra las mejores prácticas de desarrollo de software.

Diagramas UML UML dispone de los siguientes diagramas:

Etapas

Objetivos funcionales del sistema.

Diagrama a usar: Diagramas Use Case Diagramas de Actividades

í Definir claramente el propo sito del sistema. í Comprender las caracterısticas, relaciones y comportamiento de todos los elementos involucrados en el sistema.

Diagramas Use Case. Diagramas de Clases. Diagramas de Actividades.

Toma Requerimientos Identificar los requerimientos, tanto funcionales como no Análisis

í Delimitar el alcance (requerimientos) y las restricciones del sistema. í Entender las reglas del negocio. Diseño

í Refinar el modelo desarrollado en el analisis. í Detallar el comportamiento a ser implementado. í Definir la forma de implementacio n de los requerimientos identificados. í Delimitar el alcance del sistema en funcio n a las condiciones de hardware y software.

Implementacion

í í í í í

Desarrollar los me todos definidos en las clases funcionales. Desarrollar la interfaz grafica de usuario. Llevar a cabo las pruebas del sistema. Capacitar a los usuarios. Instalar el sistema.

Diagramas Use Case. Diagramas de Clases. Diagramas de Actividades. Diagramas de Estados. Diagramas de Interaccio n. Diagramas de Componentes. Diagramas de Despliegue.

í Diagramas de Casos de Uso. í Diagramas de Interaccio n. í Diagrama de Despliegue.