Ensayos

Alumna: Diana Cortes Ortiz

Docente: Lic. Cesar Espinoza Jiménez

Materia: Introducción al Análisis

y Diseño de Sistemas

3° PARCIAL

FUNDAMENTOS DE LA POO

A partir de los años setenta se trabaja sobre una nueva clase de lenguajes de simulación y sobre la construcción de prototipos tales como Simula-70 y basados en parte de éste, el Smalltalk. En estos lenguajes, la abstracción de datos tiene una gran importancia y los problemas del mundo real se representan mediante objetos de datos a los cuales se les añade el correspondiente conjunto de operaciones asociados a ellos. Términos como Abstracción de datos, objeto, encapsulación entre otros, son conceptos básicos sobre la que se fundamenta la POO.

La POO se basa en el modelo objeto donde el elemento principal es el objeto, el cual es una unidad que contiene todas sus características y comportamientos en sí misma, lo cual lo hace como un todo independiente pero que se interrelaciona con objetos de su misma clase o de otras clase, como sucede en el mundo real.

La reutilización es la principal característica de la POO, la cual se logra mediante:

Encapsulación de información: Ocultamiento de información, datos o funciones especiales a los usuarios.

Herencia: Propiedad que permite a los objetos ser construidos a partir de otros; es recibir de un módulo superior sus características, tales como atributos o funciones (campos y métodos o comportamientos), para usarlos en el módulo actual. Heredar es compartir atributos.

Sobre escritura (override): Posibilidad de heredar un método de un módulo y cambiarle el comportamiento en el heredero, con la opción de poder usar el original, si se desea.

Métodos unidos a los objetos: Los métodos de un objeto son inseparables y siempre formarán parte de su cuerpo, como un todo.

Noción de self : Unicidad de los objetos; son únicos y no se repiten, aunque sean de la misma clase.

Conclusión: La POO nos permite estructurar un sistema con todas sus características de acuerdo a la clasificación además de que nos brinda la facilidad de poder analizar, modelar, diseñar para así poder aplicar las medidas y métodos para poderlo llevar a cabo en el mundo real.

Referencias:Luis Armando Canchala Fernández, Fundamentos de la POO. Obtenido el 24 de Marzo del 2011, de http://msdn.microsoft.com/es-es/library/bb972232.aspxFernando Zacatenco Onofre, Fundamentos de la POO. Obtenido el 24 de marzo del 2011, de http://dis.um.es/~jfernand/0506/dai/poo.pdf

DIAGRAMA DE CLASES

Se ha convertido en el estándar de factor de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh.

Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargarán del funcionamiento y la relación entre uno y otro. En un diagrama de clases se pueden distinguir principalmente dos elementos: clases y sus relaciones.

Las clases son el conjunto de objetos que comparten los mismos atributos, operaciones son las responsabilidades, relaciones y semántica es la relevancia. Este nos sirve para poder realizar la abstracción de un dominio, formalizar el análisis de conceptos, definir una solución de diseño y construir componentes de software. Sus elementos son:

Clase: esta Es la unidad básica que encapsula toda la información de un Objeto. Se representa con un rectángulo que tiene tres divisiones.

Relaciones entre Clases: será necesario explicar cómo podemos interrelacionar dos o más clases con sus respectivas características y objetivos.

Herencia: Indica lo que hereda la subclase además de que posee sus propios métodos y atributos los cuales serán visibles.

Agregación: nos sirve para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres.

Asociación: La relación entre clases conocidas.

Dependencia o Instanciación (uso): es un tipo de relación muy particular en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase).

Conclusión: Nos permite representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre estas. También nos sirve para poder observar las relaciones entre las clases que se involucran el sistema, las cuales pueden ser de herencia, de uso y de convencimiento.

Referencias:Juan José Flores Cueto Carmen Bertolotti Zúñiga, Diagrama de Clases. Obtenido el 24 de Marzo del 2011, de http://es.scribd.com/doc/31096724/Diagrama-de-Clases-en-UMLhttp://www.osmosislatina.com/lenguajes/uml/clasesob.htm

DIAGRAMA DE CASO DE USOEn 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado, creó el concepto de caso de uso. Se han realizado muchas mejoras al concepto que se estableció entonces, pero probablemente la más influyente y significativa.

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.

Los elementos que componen un diagrama Caso de uso son:

Actor: Un actor representa quien o que inicia una acción dentro del sistema. Un Actor es representado por una figura en forma de persona.

Uso-Caso: Es representado por un ovalo que describe la funcionalidad que se requiere por el sistema.

Comunicación: Representa la relación que existe entre un caso-uso y un Actor, este es representado por una línea recta que se extiende de la figura del actor hacia el ovalo del caso-uso.

Limite de Sistema (System Boundry): Empleado para delimitar los límites del sistema, y representado por un rectángulo con color de fondo distintivo.

Generalización: Este elemento es representado por una línea con flecha que se extiende del caso-uso hijo hacia el caso-uso padre.

Inclusión: Indica que un caso-uso depende de otro caso, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una línea punteada con flecha y comentario <<include>> que se extiende del caso-uso hacia el caso-uso de inclusión.

Extensión: Representa una dependencia especifica, mientras una generalización no implica que los casos-usos dependen uno del otro. Este elemento es representado por una línea punteada con flecha y comentario <<extend>> que origina el caso-uso base hacia el caso-uso de extensión.

Conclusión: Nos sirve para poder describir las relaciones que habrá entre los requisitos, usuarios y los componentes. Además de que nos ayudan a validar la arquitectura al mismo tiempo para verificar que nuestro sistema evolucione durante su desarrollo.

Referencias:

María Isabel Sánchez Segura, Desarrollo Orientado a Objetos con UML .Obtenido el 24 de Marzo del 2011, de http://www.clikear.com/manuales/uml/diagramascasouso.aspx

Xavier Ferré Grau,Diagramas de Caso de Uso. Obtenido el 24 de Marzo del 2011, de http://www.osmosislatina.com/lenguajes/uml/casos.htm