METODOLOGÍA ORIENTADA A OBJETOS.
RESUMEN DEL PRIMER PARCIAL
UNIDAD I Antecedentes 1.1 Historia del desarrollo del software.
PRIMERA ERA
Durante los primeros años de la era de la computadora, el software se contemplaba como un añadido. Desde entonces el campo se ha desarrollado tremendamente. La programación de computadoras era un “arte de andar por casa” para el que existían pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin ninguna planificación,
SEGUNDA ERA
La segunda era en la evolución de los sistemas de computadora se extienden desde la mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre - máquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del hardware y del software.
La segunda era se caracterizó también por el establecimiento del software ya se desarrollaba para tener una amplia distribución en un mercado multidisciplinario.
TERCERA ERA
La tercera era en la evolución de los sistemas de computadora comenzó a mediados de los años setenta y continuó más allá de una década. El sistema distribuido, múltiples computadoras, cada una ejecutando funciones concurrentemente y comunicándose con alguna otra, incrementó notablemente la complejidad de los sistemas informáticos.
CUARTA ERA
La cuarta era de la evolución de sistemas informáticos se aleja de los programas de control y de gestion, dirigiéndose al impacto colectivo de las computadoras individuales y del software. Potentes máquinas personales controladas por sistemas operativos sofisticados, en redes globales y locales, acompañadas por aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas informáticas están cambiando de entornos centralizados de grandes computadoras a entornos descentralizados cliente/servidor.
Es de suma relevancia el mencionar algunas de los lenguajes de programación que fueron utilizados en sus respectivas eras. Esto nos ayudará a comprender mejor el objetivo que se perseguía en cada una de ellas.
ERA
LENGUAJES
CARACTERÍSTICAS
1ª
Fortran
Basic
Logo
Cobol
Fue el primer y principal lenguaje Científico.
Diseñado por IBM.
Utilizado también para aplicaciones comerciales.
Desarrollado como lenguaje de tiempo compartido.
Traza elementos gráficos estableciendo la geometría de lápiz.
Ampliamente usado en programación en minicomputadores.
2ª
Pascal
Prolog
Mumps
Lisp
Lenguaje Académico.
Sus características son copiadas por otros lenguajes.
Éxito comercial a través de Borland.
Desarrollado en Francia, 1973.
Aplicaciones en Inteligencia Artificial (IA).
Sistema de Multiprogramación.
Incluye su propia base de datos.
Utilizado en aplicaciones médicas.
Sintaxis muy diferente de los demás lenguajes.
Programa aplicaciones en IA.
3ª
C, C++
Modula-2
dBase
Desarrollado en los ochentas.
Se utiliza en aplicaciones comerciales.
C++, se utiliza para la tecnología orientada a objetos.
Versión mejorada de Pascal.
Desarrollada en 1979.
Lenguaje estándar para aplicaciones comerciales.
Ramas colaterales: Clipper, FoxBase.
4ª
Visual C++
Visual Basic
JAVA
Desarrollado por Microsoft.
Principalmente orientado a la tecnología de objetos.
Se utiliza para aplicaciones comerciales.
Principalmente para aplicaciones comerciales.
Versión cotizada, ya que permite interactuar con tablas de manejadores de bases de datos y lenguaje SQL.
Acontinuación se presenta una lista de algunas personas que hicieron contribuciones significativas en la creación y crecimiento de la industria de productos de software.
Charles Bachman. Inventó la tecnología del banco de datos en los inicios de los sesentas.
John Backus. FORTRAN desarrollado para IBM (1954)
Bob Bemer. Uno de los diseñadores de COBOL y el ASCII normal para IBM (años sesenta); inventor de la sucesión del Escape, el mecanismo universal para toda la computadora.
Larry Constantine. Inventa los datos que fluyen en los diagramas, presentan primero en papel, los conceptos de un plan estructurado en 1968.
Peter Cunningham. Funda una de las primeras empresas de investigación de mercado para enfocar el software y comienza a comercializar los productos del software en 1974.
Tom DeMarco. El pionero en utilizar una metodología de caso, el autor, y consultor en los años setenta.
Wilfred J. Dixon. Empezó distribuyendo el software estadístico en 1962.
Frank Dodge. Co - fundó McCormack & el Regate qué vendió el primer software de contabilidad en 1969.
Larry Ellison. Dejó camino abierto para los DBMS.
Dave Ferguson. Logró vender el primer producto de software con éxito contra un programa de IBM.
Ken Orr. Crea la metodología de caso desarrollada en los años setenta.
1.2 La descomposición funcional vs. La descomposición en objetos.
Varios métodos han sido propuestos para sistematizar el proceso de vida del software.
Y muchas metodologías de desarrollo de software
han sido propuestas, y éstas pueden clasificarse en tres categorías:
Descomposición funcional.
·Énfasis en datos, más que en funciones.
Descomposición objeto
·Énfasis en objetos más que en datos.
Clasificación de los métodos.
Descomposición funcional:
·Diseño Estructural, Refinamiento por Pasos.
Énfasis en datos, más que en funciones:
·Análisis Estructural, Análisis de Sistemas Estructurados.
·Análisis de Sistemas Estructurados y Metodología de Diseño por bloques módulos.
1.3 Ingeniería de software.
La Ingeniería de Software.
Según la definición del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo". Según el mismo autor, "un producto de software es un producto diseñado para un usuario".
El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad" [Jacobson 1998].
1.4 Modelado y sus beneficios.
Principios de Modelado
En cualquier proyecto de ingeniería como la construcción de un gran edificio, un avión, una represa hidroeléctrica, la construcción de un procesador de textos o un software de comunicaciones para Internet, requieren de etapas de modelamiento que permitan experimentar y visualizar el sistema que se construirá. De la experiencia en ingeniería se extractan los siguientes principios de modelado:
a) La forma como vemos el problema tiene una profunda influencia en forma como acometemos el problema y le damos solución al mismo.
b) Para modelar un sistema complejo no es suficiente un único modelo se requieren múltiples modelos donde cada uno representa una vista (aspecto) del sistema; estos modelos se complementan entre si.
c) Cualquier modelo puede ser representado con diferentes grados de precisión.
d) Los mejores Modelos están ligados a la realidad.
UNIDAD II Introducción al paradigma orientado a objetos
2.1 La complejidad del software.
Al observar sistemas complejos sociales como una gran empresa, los naturales como el universo y los sistemas creados por el hombre como el computador, se observa que exhiben una jerarquía de clases (conceptos) y otra de objetos (instancias). En una empresa donde conjuntos de personas forman un departamento y un conjunto de departamentos forman divisiones se describe la forma canónica de un sistema complejo que exhibe dos jerarquías: Una jerarquía de clases y otra jerarquía de objetos, donde cada objeto es una instancia de la una clase. Este es el modelo del cual se apropia el análisis y diseño orientado a objetos para desarrollar sistemas donde hay gran cantidad de software.
Causas de la complejidad del software
Facilidad de uso.
Exigencia de alto rendimiento y bajo costo.
Capacidad de supervivencia.
Requisitos que cambian durante el desarrollo
Simplicidad para el usuario.
Tamaño (líneas de código).
Modularización.
Comunicación entre los integrantes del equipo.
Director del equipo (persona clave).
Problemas de caracterizar sistemas discretos
Los sistemas complejos son jerárquicos y cada nivel de la jerarquía, constituye un nivel de abstracción diferente.
2.2 Abstracción.
La abstracción encarada desde el punto de vista de la programación orientada a objetos expresa las características esenciales de un objeto, las cuales distinguen al objeto de los demás. Además de distinguir entre los objetos provee límites conceptuales. Entonces se puede decir que la encapsulación separa las características esenciales de las no esenciales dentro de un objeto. Si un objeto tiene más características de las necesarias los mismos resultarán difíciles de usar, modificar, construir y comprender.
La misma genera una ilusión de simplicidad dado a que minimiza la cantidad de características que definen a un objeto.
Pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real. Una analogía sería modelizar un coche en un esquema de POO. Diríamos que el coche es el elemento principal que tiene una serie de características, como podrían ser el color, el modelo o la marca. Además tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar. En un esquema POO el coche sería el objeto, las propiedades serían las características como el color o el modelo y los métodos serían las funcionalidades asociadas como ponerse en marcha o parar.
2.3 Modularidad.
Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
2.4 Encapsulamiento.
Esta característica es la que denota la capacidad del objeto de responder a peticiones a través de sus métodos sin la necesidad de exponer los medios utilizados para llegar a brindar estos resultados. O sea, el método MostrarSaldo() del objeto “cliente” antes mencionado, siempre nos va a dar el saldo de la cuenta de un cliente, sin necesidad de tener conocimiento de cuáles son los recursos que ejecuta para llegar a brindar este resultado.
2.5 Jerarquía.
Es el orden de las abstracciones organizado por niveles.
2.6 Polimorfismo.
Polimorfismo.
El polimorfismo indica que una variable pasada
o esperada puede adoptar múltiples formas.
Cuando se habla de polimorfismo en
programación orientada a objetos se suelen
entender dos cosas:
EJEMPLO:
class disco{
protected:
int capacidad;
char * fabricante;
int num_serie;
public:
disco (int c, char * f, int n){
capacidad = c; strcpy(fabricante, f);
num_serie=n;}
2.7 Persistencia.
Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).
2.8 Concurrencia.
Es la propiedad que distingue un objeto que está activo de uno que no lo está.
UNIDAD III Clases y objetos
3.1 Atributos y métodos de instancia.
Una instancia de un programa es creada típicamente por el click de usuario en un icono de una interfaz Gráfica para usuarios GUI o por la entrada de un comando en una interfaz de línea de comandos CLI y presionando la tecla ENTER. Instancias de programas pueden ser creadas por otros programas.
Atributos de instancia:
determina el estado de los objetos
cada objeto reserva memoria para todas las variables de instancia
Declaración:
[acceso][static][final] tipo nombreAtributo [= valor_inicial];
Atributos
Los atributos son las características individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades. Los atributos se guardan en variables denominadas de instancia, y cada objeto particular puede tener valores distintos para estas variables.
Las variables de instancia también denominados miembros dato, son declaradas en la clase pero sus valores son fijados y cambiados en el objeto.
Además de las variables de instancia hay variables de clase, las cuales se aplican a la clase y a todas sus instancias. Por ejemplo, el número de ruedas de un automóvil es el mismo cuatro, para todos los automóviles.
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.
La definición de una clase se realiza en la siguiente forma:
[public] class Classname {
// definición de variables y métodos
...
}
donde la palabra public es opcional: si no se pone, la clase tiene la visibilidad por defecto, esto es,
sólo es visible para las demás clases del package. Todos los métodos y variables deben ser definidos
dentro del bloque {...} de la clase.
Un objeto (en inglés, instance) es un ejemplar concreto de una clase. Las clases son como
tipos de variables, mientras que los objetos son como variables concretas de un tipo determinado.
Classname unObjeto;
Classname otroObjeto;
3.3 Relaciones entre clases.
Asociacion
Las asociaciones son conexiones conceptuales entre clases. Por ejemplo la asociación, entre trabajador y empresa.
“Un trabajador labora en una empresa” la asociación conectara con una línea a trabajador y empresa, si vemos los roles de cada uno podemos decir que el trabajador es un empleado y la empresa es la empleadora.
“Labora en” es el nombre de la asociación y la colocamos sobre la linea, mientras que los roles (empleado, empleador) los colocamos bajo la línea a cada lado según corresponda. Así nuestra relación “Un trabajador labora en una empresa” en UML se vería así.
3.4 Relaciones entre objetos.
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:
Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte.
Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización.
Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica (véase la fig. 4). La relación es, evidentemente, semántica, pués no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del significado de ambos objetos.
La existencia de esta relación nos permitirá responder a preguntas como:
¿Quién trabajó en óptica?
¿En qué trabajó Newton?
¿Quien trabajó en Física?
Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la tercera observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó en Física, por ser óptica una rama de la Física (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relación entre NEWTON y FISICA, apoyandonos sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de información que tendremos que definir para todo el diccionario será mínima.
UNIDAD IV Proceso de desarrollo del software
4.1 Ciclo de vida del desarrollo del software.
El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define le alcance del proyecto y desarrolla un caso de negocio. La elaboración define un plan del proyecto, especifica las características y fundamenta la arquitectura. La construcción crea el producto y la transición transfiere el producto a los usuarios.
Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información.
Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.
4.3 Análisis.
Definición de un Modelo de Ciclo de Vida
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software.Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
4.4 Diseño.
Principios básicos de diseño
•El diseñador debe considerar enfoques alternativosjuzgando a cada uno en base a los requisitos del problema, los resultados disponibles y los criterios de calidad interna
•Se deberían poder seguir los pasos de diseño hasta el modelo de análisis
•El diseño no va a reinventar nada que ya esté inventado
•El diseño debería presentar uniformidade integración
•Debe estructurarse para admitir cambios
•El diseño no es escribir código y escribir código no es diseñar
•Se debería valorar la calidad del diseño mientras se crea, no después de terminado
•Diseño de datos:
–Modelo de información a estructuras de datos.
•Diseño arquitectónico:
–Define las relaciones entre los elementos estructurales de nuestro programa.
•Diseño procedimental:
–Se transforman los elementos estructurales de nuestro programa en una descripción procedimental del software.
•Diseño de interfaz:
–Describe cómo se comunica el software consigo mismo y con su entorno.
Directrices para un buen diseño
•El diseño debe implementar todos los requisitos explícitoscontenidos en el modelo de análisis y debe acomodar todos los requisitos implícitosque desee el cliente
•El diseño debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software
•El diseño debería proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación.
4.5 Evolución.
Un entorno de desarrollo integrado o IDE (acrónimo en inglés de integrated development environment), es un programa informático compuesto por un conjunto de herramientas de programación.
Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones existentes. El lenguaje Visual Basic, por ejemplo, puede ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word.
Ejemplos de IDE:
El eclipse y el EMF plantilla-basaron el sistema para la generación del fuente-código de modelos de UML.
NetBeans : con el paquete de la empresa de NetBeans IDE 5.5
IDEs de Java por Sunmicrosystems.
JCEE
JCSE
JCME
JCLE
UNIDAD V El lenguaje de modelado unificado
5.1 Antecedentes.
UML (Unified Modeling Language) es un lenguaje para especificar, visualizar, construir y documentar las diferentes etapas del desarrollo de software, así como para modelado de procesos de negocio u otros sistemas no-software. UML reúne una colección de las mejores prácticas en la ingeniería que han sido utilizadas con éxito para modelar sistemas grandes y complejos, ya que cubre tanto objetos conceptuales como los procesos de negocio y funciones del sistema, como también objetos concretos como clases en un lenguaje de programación, esquemas de base de datos y componentes reusables de software.
La técnica central en el UML es el Modelamiento en Objetos que es un lenguaje que permite la especificación de clases, sus datos o atributos (privados) y métodos (públicos), herencia y otras relaciones entre las clases.
Etapas y actividades en el desarrollo OO basado en UML
En la versión definitiva de la metodología publicada por Booch, Rumbaugh y Jacobson se pueden tener en cuenta las siguientes etapas:
· Análisis de Requerimientos
· Diseño del sistema
· Diseño detallado
· Implementación y pruebas
Cada etapa consta de actividades que le dan cuerpo y los documentos que se esperan al final de cada una de ellas.
Elementos Notacionales de UML
Los elementos notacionales que presenta el UML pretenden ser un lenguaje común para el modelamiento de cualquier sistema y se agrupan en tipos de diagrama:
1. Diagrama de Clases
2. Diagrama de Objetos
3. Diagrama de Casos de Uso
4. Diagrama de Secuencia
5. Diagrama de Colaboración
6. Diagrama de Estados
7. Diagrama de Actividades
8. Diagrama de Componentes
9. Diagrama de Ejecución
5.2 Vista estática.
La vista estática nos permite visualizar el comportamiento externo del programa; de esta forma conseguimos conocer qué es lo que debe hacer el programa independientemente de cómo lo haga y sabremos los elementos que interactúan con el sistema. Los elementos implicados en un diagrama de casos de uso son los casos de uso, las relaciones y los actores. Las relaciones y los casos de uso ya han sido explicados anteriormente y el papel del actor también ha sido comentado pero merece la pena detallarlo más: Un actor es un rol que interactúa con el sistema. Lo definimos como rol porque un actor puede ser tanto un usuario de la aplicación como otro sistema o dispositivos externos.
5.3 Vista dinámica.
5.4 Diagramas HASTA AQUI PRIMER PARCIAL.
Tipos de Diagramas en UML
Grandes clásicos conocidos por todos, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación de los diagramas.
La siguiente figura UML muestra los tipos de diagramas:
Fig. 1 – Tipos de diagramas en UML2
Análisis del código fuente de un programa
Clase Ejemplo1
A continuación se muestra el programa principal, contenido en el fichero Ejemplo1.java. En
realidad, este programa principal lo único que hace es utilizar la clase Geometría y sus clases
derivadas. Es pues un programa puramente “usuario”, a pesar de lo cual hay que definirlo dentro de
una clase, como todos los programas en Java.
1. // fichero Ejemplo1.java
2. import java.util.ArrayList;
3. import java.awt.*;
Capítulo 1: Introducción a Java página 5
4. class Ejemplo1 {
5. public static void main(String arg[]) throws InterruptedException
