Asignatura: Introducción al análisis y diseño de sistemas Profesor: Cesar Espinoza Jiménez Nombre: Victor Manuel López Orozco Proyecto: Ensayos Fundamentos poo, Diagramas de Caso de Uso y Diagramas de Clase



Descargar 47.12 Kb.
Fecha de conversión06.03.2018
Tamaño47.12 Kb.



Asignatura: Introducción al análisis y diseño de sistemas

Profesor: Cesar Espinoza Jiménez

Nombre: Victor Manuel López Orozco

Proyecto: Ensayos Fundamentos POO,  Diagramas de Caso de Uso y Diagramas de Clase.

Grupo: 2”D”

Fundamentos POO

Introducción:

En el universo de la programación actual, es de amplio consenso que la programación orientada a objetos es el mejor paradigma disponible para enfrentar las cada vez más complejas tareas de la programación. Sin embargo, no todos los programadores tienen claro los fundamentos de este paradigma, y tienden a confundir la programación usando objetos con la programación orientada a objetos.

Programamos orientado a objetos cuando, usando un lenguaje de programación, somos capaces de modelar el problema en términos de objetos y sus relaciones.

Es decir cuando cada entidad en el programa es un objeto que brinda determinados servicios.

En este trabajo se hace una sucinta descripción de los fundamentos de la programación orientada a objetos, necesaria para aquellos que no poseen nociones sobre esta materia, y material de consulta para los que la conocen o dominan.

Desarrollo:

La programación orientada a objetos es la expresión de uno de los más avanzados paradigmas en el campo de la programación, y es, al mismo tiempo, el resultado de la evolución experimentada por los paradigmas anteriores.

A diferencia de otros paradigmas de programación, que intentan, al abordar un problema, representarlo o modelarlo empleando entidades cercanas a la computadora (arreglos, subrutinas, módulos) la programación orientada a objetos se propone emplear entidades lo más cercanas posibles a la realidad.

Un objeto es un ente que posee sus características propias (propiedades) y un conjunto de acciones que es capaz de realizar (métodos).

Una clase es un ente abstracto que permite declarar las propiedades y los métodos de objetos similares.

Un lenguaje de programación orientado a objetos debe permitir al programador realizar definiciones de clases, y construir objetos a partir de esas clases.

Para resolver un problema bajo el paradigma de la programación orientada a objetos basta con determinar y caracterizar los diferentes objetos que intervienen en el problema, definir sus propiedades y métodos y ponerlos a interactuar entre sí.

La POO es una técnica para desarrollar soluciones computacionales utilizando componentes de software (objetos de software).

Objeto: Componente o código de software que contiene en sí mismo tanto sus características (campos) como sus comportamientos (métodos); se accede a través de su interfaz o signatura.

Campo: Es una característica de un objeto, que ayuda a definir su estructura y permite diferenciarlo de otros objetos. Se define con un identificador y un tipo, el cual indica los valores que puede almacenar. El conjunto de valores de los campos definen el estado del objeto.

Método: Es la implementación de un algoritmo que representa una operación o función que un objeto realiza. El conjunto de los métodos de un objeto determinan el comportamiento del objeto.

La POO es un paradigma de la programación de computadores; esto hace referencia al conjunto de teorías, estándares, modelos y métodos que permiten organizar el conocimiento, proporcionando un medio bien definido para visualizar el dominio del problema e implementar en un lenguaje de programación la solución a ese problema.

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.

Conclusiones:

Para entender cómo funciona el paradigma de la programación orientada a objetos es necesario ver un programa como una colección de objetos que interactúan entre sí enviándose mensajes y cambiando su estado durante la ejecución.

Resolver un problema bajo el paradigma de la programación orientada a objetos implica determinar y caracterizar los diferentes objetos que intervienen en el problema, definir sus propiedades y métodos y ponerlos a interactuar.
Diagramas de Caso de Uso

Introducción:

UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.



Desarrollo:

Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes, consistentes promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

Es práctica común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.


Relaciones de Casos de Uso


Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:

Inclusión (include o use)


Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones son importantes, ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor puede usar el sistema. La notación es de una flecha de punta abierta con línea discontinua desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una expansión de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parámetros o valores de retorno. Aqui tambien podemos decir que éste va de padre a hijo.

Extensión (Extend)


Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. Uso extensión puede ser insertada en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."


Generalización


"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.



Conclusión: Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

Diagramas de clase

Introducción

Un diagrama de clases está compuesto por los siguientes elementos:



Clase: atributos, métodos y visibilidad.

Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:



http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/clase1.jpg

En donde:



Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).

Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

Balance


Puede realizar las operaciones de:

Depositar, Girar y Balance

El diseño asociado es:

http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/clase2.jpg

Atributos y Métodos:



Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

Public (+,http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/public.jpg): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-,http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/private.jpg): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

Protected (#,http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/protected.jpg): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

Métodos: Los métodos u operaciones de una clase son la forma en cómo ésta interactúa con su entorno, éstos pueden tener las características:

Public (+,http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/public2.jpg): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

Prívate (-,http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/private2.jpg): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

Protected (#,http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/protected2.jpg): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:



Uno o muchos: 1...* (1...n)

0 o muchos: 0...* (0...n)

Número fijo: m (m denota el número).

Herencia (Especialización/Generalización): http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/herencia1.jpg

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected)



Agregación: http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/agregacion1.jpg

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:



Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Asociación: http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/asociacion1.jpg

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.


Dependencia o Instanciación (uso): http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/dependencia1.jpg

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana está condicionado a la instanciación proveniente desde el objeto Aplicación):

http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/edependencia.jpg

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).



Casos Particulares:

Clase Abstracta:

http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/abstracta.jpg

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.



Clase parametrizada:

http://www.dcc.uchile.cl/~psalinas/uml/img/modelo/parametrizada.jpg

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).

En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependerán exclusivamente de la implementación que se le quiera dar.
REFENCIAS:

*PROGRAMACIÒN ORIENTADA A OBJETOS.

http://msdn.microsoft.com/es-es/library/bb972232.aspx



*DIAGRAMAS DE CASO DE USO.

http://www.clikear.com/manuales/uml/diagramascasouso.aspx

http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

*DIAGRAMAS DE CLASE.

http://www.dcc.uchile.cl/~psalinas/uml/modelo.html

Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal