Si buscas hosting web, dominios web, correos empresariales o crear páginas web gratis, ingresa a PaginaMX
Por otro lado, si buscas crear códigos qr online ingresa al Creador de Códigos QR más potente que existe

I.- INTRODUCCION

COMPLEJIDAD

Entre más complejo es el sistema que se desea crear más beneficios presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves :

El primero se debe a que mediante un plano/visión global resulta más fácil detectar las dependencias y dificultades implícitas del sistema, y la segunda razón radica en que los cambios en una etapa inicial (Análisis) resultan más fáciles de realizar que en una etapa final de un sistema como lo seria la fase intensiva de codificación.

Puesto que UML es empleado en el análisis para sistemas de mediana-alta complejidad, era de esperarse que su base radica en otro paradigma empleado en diseños de sistemas de alto nivel que es la orientación a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos.

Hoy en día, entre los lenguajes orientados a objetos más utilizados se encuentran Java y C#, además de otros más antiguos como C++ y SmallTalk, aunque el programar en todos estos lenguajes requiere experiencia previa sobre la sintaxis y bloques específicos, el paradigma empleado en todos ellos es el mismo : Objetos.

Lo anterior permite que un análisis en UML sea realizado independiente del lenguaje en el que finalmente sea implementando el Sistema (Java,C#,C++,SmallTalk), misma característica que permite a personal no familiarizado en lenguajes de programación participen en el análisis y diseño de un sistema.

MODELO DE OBJETOS

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).

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.

Los métodos (comportamiento) y atributos (estado)

Están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

CLASES Y OBJETOS

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos.
Entre ellos destacan los siguientes:

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 ellas.
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. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de POO.

Objeto:

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

Método:

Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". 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 (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). 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, la acción que genera.

Atributos:

Características que tiene la clase

Mensaje:

Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

Propiedad o atributo:

Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

Estado interno:

Es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.

Componentes de un objeto:

Atributos, identidad, relaciones y métodos.

Identificación de un objeto:

Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

CLASIFICACION

METODOLOGIA:

LA NOTACION

Los diagramas entidad-relación ayudan a modelar el componente de representación de datos de un sistema software. La representación de datos, sin embargo, sólo forma parte de un diseño completo de un sistema. Otros componentes son modelos de interacción del usuario con el sistema, especificación de módulos funcionales del sistema y su interacción, etc. El lenguaje de modelado unificado (UML, Unified Modeling Language) es un estándar propuesto para la creación de especificaciones de varios componentes de un sistema software. Algunas de las partes de UML son:

1.-Diagrama de clase.
Un diagrama de clase es similar a un diagrama E-R. Más adelante en este apartado se mostrarán algunas características de los diagramas de clase y cómo se corresponden con los diagramas E-R.

2.-Diagrama de caso de uso.
Los diagramas de caso de uso muestran la interacción entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario (tales como prestar dinero o matricularse de una asignatura).

3.-Diagrama de actividad.
Los diagramas de actividad describen el flujo de tareas entre varios componentes de un sistema.

4.-Diagrama de implementación.
Los diagramas de implementación muestran los componentes del sistema y sus interconexiones tanto en el nivel del componente software como el hardware.

DIAGRAMA DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. 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.

CLASES:

La clase es la unidad básica que encapsula toda la información de un objeto a través de la cual podemos modelar el entorno en estudio. En UML, una clase es representada por un rectángulo que posee tres divisiones:

DIAGRAMA DE TRANSICION DE ESTADOS

El diagrama de transición de estados o DTE, enfatiza el comportamiento dependiente del tiempo del sistema.
Hasta hace un tiempo, los modelos del comportamiento dependiente del tiempo del sistema importaban solo para una categoría especial de sistemas conocidos como sistemas de tiempo real, por ejemplo sistemas de conmutación telefónica.

Para sistemas enfocados a los negocios no se veían demasiado importante, sin embargo en sistemas grandes y complejos enfocados a negocios que si tienen aspectos de comportamiento de tiempo real.

Por ejemplo si el sistema maneja entradas de miles de terminales y entradas de alta velocidad de otros sistemas, pueden entonces surgir aspectos de comportamiento dependientes del tiempo, del tipo que surgen en un sistema típico de tiempo real. Por esto aunque no se apliquen en todos los sistemas es conveniente estar familiarizado con herramientas de modelado para el comportamiento dependiente del tiempo.

Los principales componentes del diagrama son los estados y las flechas, que representan los cambios de estado. Existe una variada notación pero lo más común es representar a los estados mediante rectángulos o mediante círculos, esta última forma puede llegar a parecerse con los DFD; por lo tanto aconsejo y usaré en todos los ejemplos la representación mediante rectángulos.

Cada rectángulo representa un estado en el que se puede encontrar el sistema. Se lo puede encontrar definido como un conjunto de circunstancias y atributos que caracterizan a una persona o cosa en un tiempo dado; forma de ser; condición.

Los estados típicos de un sistema pueden ser:

1.-Esperar a que el usuario dé su contraseña.

2.-Mezclar los ingredientes

3.-Llenar el tanque.

4.-Esperar la siguiente orden.

DIAGRAMA DE OBJETOS

Representan un único ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicación. Cuando cree un objeto nuevo, llamado especificación de instancia, UModel le permite asignar una clase ya existente representada por la instancia. UModel ofrece automáticamente al objeto instancias de las propiedades pertinentes desde la clase y el usuario puede insertar valores de muestras para el objeto.

Los diagramas de objetos UML utilizan una notación similar a los diagramas de clases y se utilizan para ilustrar una instancia de una clase en un momento dado. Imagine que desea dibujar un diagrama de objetos para ilustrar un ejemplo real de una clase y de sus relaciones.

Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante el proceso de planificación de clases o para ayudar a partes interesadas para quienes los diagramas de clases sean demasiado abstractos.

Puesto que los diagramas de objetos utilizan notaciones muy similares a los diagramas de clases, la barra de herramientas de diagramas de objetos usan algunos de los iconos de la barra de herramientas de diagramas de clases. Para editar los atributos y valores de un objeto puede utilizar la barra de herramientas, el diálogo de propiedades o editarlos directamente en el diagrama.

DIAGRAMA DE INTERACCION

Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos.
Son importantes para modelar los aspectos dinámicos de un sistema y para construir sistemas ejecutables a través de ingeniería hacia adelante e ingeniería inversa.
Comúnmente contienen:

Objetos
Enlaces
Mensajes

Pueden servir para visualizar, especificar, construir y documentar los aspectos dinámicos de una sociedad particular de objetos, o pueden ser usados para modelar un flujo particular de control de un caso de uso.
Los diagramas de interacción están conformados por los diagramas de secuencia y los diagramas de colaboración.

ciclo robot uml.

DIAGRAMA DE MODULOS

El diagrama de módulos muestra la asignación de clases y objetos o módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias.

Programa principal:

1.-Identifica al archivo que contiene la raíz del programa.

Especificación y cuerpo:

2.-Identifican los archivos que contienen la declaración y la definición de los objetos o bien procedimientos o funciones necesarias para el correcto funcionamiento de la aplicación.

DIAGRAMA DE PROCESOS

El diagrama de proceso es una forma gráfica de presentar las actividades involucradas en la elaboración de un bien y/o servicio terminado.
En la práctica, cuando se tiene un proceso productivo y se busca obtener mayor productividad, se estudian las diversas operaciones para encontrar potenciales o reales “cuellos de botella” y dar soluciones utilizando técnicas de ingeniería de métodos.
La simbología utilizada en la elaboración de un diagrama de proceso es la siguiente:

APLICACIÓN DE LA NOTACION

PROCESO

El proceso de desarrollo de un sistema informático implica a mucha gente, el principal es el cliente que es la persona que tiene el problema que ha de ser solucionado.

El Analista documenta el problema del cliente y lo trasmite a los desarrolladores, los programadores construyen el software, lo prueban y lo instalan sobre el hardware del cliente. Hoy en día los sistemas se han hecho tan complejos que una sola persona no puede conocer todas las facetas de las necesidades de un negocio, entender estas necesidades, diseñar una solución para ellas, escribir el programa e instalarlo asegurándose de que todos los componentes trabajen correctamente.

3.- UML (LENGUAJE UNIFICADO DE MODELADO)

INTRODUCCION

UML (Unified Modeling Languaje)
Es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos.
Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado.

Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión.

ORIENTACION A OBJETOS

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana:
Antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo.

La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores.

APLICACION ALA ORIENTACION DE OBJETOS

USO DE RALACIONES

AGREGACION, COMPOSICION, INTERFACES Y REALIZACION

Agregación:
Es una relación que se derivó de la asociación, por ser igualmente estructural, es decir que contiene un atributo, que en todos los casos, será una colección, es decir un Array, Vector, Collections, etc. y además de ello la clase que contiene la colección debe tener un método que agregue los elementos a la colección. También se puede leer como que un medio de transporte tiene varios pasajeros.

Asociación:
Es una Clase que surge de una multiplicidad de muchos a muchos, y fue incorporada en UML para dar soporte a este caso. Se sacan los atributos de las clases involucradas y se los incorpora a una clase a parte.

Composición:
Al igual que en la agregación, es una relación estructural pero se le suma, que tiene un método de destrucción de los objetos. Y a diferencia de la asociación, el ciclo de vida del objeto área está relacionado con el del objeto ruta.

Realización:
Es una relación de contrato con otra clase. Se la utiliza para implementar una interfaz. En lenguajes como java o php utilizamos la palabra reservada “implements”.

INTRODUCCION A CASOS Y USOS

DIAGRAMAS DE CASOS DE USOS

Los diagramas de caso de uso son uno de los cinco tipos de diagramas en UML para modelar aspectos dinámicos de sistemas (diagramas de actividad, diagramas de estados, diagramas de secuencia y diagramas de colaboración son otros cuatro tipos de diagramas en UML para modelar los aspectos dinámicos de un sistema). Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso, actores y sus relaciones.

Se aplican los diagramas de casos de uso para modelar las vistas de casos de uso de un sistema. Para la mayor parte, esto involucra el modelado el contexto de un sistema, subsistema, o clase, o modelar las necesidades del comportamiento de esos elementos.

Los diagramas de casos de uso son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas, subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos pueden ser usados dentro del contexto. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa.

DIAGRAMAS DE ESTADOS

Muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen:

Estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

http://jms32.eresmas.net/tacticos/UML/UML08/Fig0801.gif

DIAGRAMAS DE SECUENCIA

Es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso.

Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.

Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales.
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.

DIAGRAMA DE COLABORACIONES

Presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.

Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas.

El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.

DIAGRAMA DE ACTIVIDADES

Es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema.

Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.

Parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes.

Ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad.

DIAGRAMA DE COMPONENTES

Se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de software, los componentes de código binario, y los componentes ejecutables. En el Diagrama de Componentes modelas componentes del sistema, a veces agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes).

DIAGRAMAS DE DISTRIBUCION

Se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment', empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos.

Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente.

Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma).



Inicio Info Servicios Productos Libro de Visitas Contáctanos
Menú INTELIGENCIA ARTIFICIAL SISTEMAS DE INFORMACION REDES DE ÁREA AMPLIA (WAN) TEORIA DE LENGUAJES Y COMPILADORES TEORIA DE LENGUAJES Y COMPILADORES LENGUAJE DE MODELADO DE SISTEMAS ARQUITECTURA EMPRESARIAL DE LA TECNOLOGIA DE LA INFORMACION TEORIA DE LENGUAJES Y COMPILADORES CONTINUACION 2 TEORIA DE LENGUAJES Y COMPILADORES CONTINUACION 1 TEORIA DE LENGUAJES Y COMPILADORES CONTINUACION 3 DESISTALAR WINDOWS 8 E INSTALAR WINDOWS 7 PRESENTACION Lista Anime \| Más	Si buscas hosting web, dominios web, correos empresariales o crear páginas web gratis, ingresa a PaginaMX Por otro lado, si buscas crear códigos qr online ingresa al Creador de Códigos QR más potente que existe Tweet I.- INTRODUCCION COMPLEJIDAD Entre más complejo es el sistema que se desea crear más beneficios presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves : El primero se debe a que mediante un plano/visión global resulta más fácil detectar las dependencias y dificultades implícitas del sistema, y la segunda razón radica en que los cambios en una etapa inicial (Análisis) resultan más fáciles de realizar que en una etapa final de un sistema como lo seria la fase intensiva de codificación. Puesto que UML es empleado en el análisis para sistemas de mediana-alta complejidad, era de esperarse que su base radica en otro paradigma empleado en diseños de sistemas de alto nivel que es la orientación a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos. Hoy en día, entre los lenguajes orientados a objetos más utilizados se encuentran Java y C#, además de otros más antiguos como C++ y SmallTalk, aunque el programar en todos estos lenguajes requiere experiencia previa sobre la sintaxis y bloques específicos, el paradigma empleado en todos ellos es el mismo : Objetos. Lo anterior permite que un análisis en UML sea realizado independiente del lenguaje en el que finalmente sea implementando el Sistema (Java,C#,C++,SmallTalk), misma característica que permite a personal no familiarizado en lenguajes de programación participen en el análisis y diseño de un sistema. MODELO DE OBJETOS 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). 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. Los métodos (comportamiento) y atributos (estado) Están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos. La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos. CLASES Y OBJETOS La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes: 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 ellas. 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. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de POO. Objeto: Instancia de una clase. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que consecuentemente reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o con objetos internos del sistema (del programa). Es una instancia a una clase. Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". 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 (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). 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, la acción que genera. Atributos: Características que tiene la clase Mensaje: Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. Propiedad o atributo: Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método. Estado interno: Es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Componentes de un objeto: Atributos, identidad, relaciones y métodos. Identificación de un objeto: Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes. En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto. CLASIFICACION METODOLOGIA: LA NOTACION Los diagramas entidad-relación ayudan a modelar el componente de representación de datos de un sistema software. La representación de datos, sin embargo, sólo forma parte de un diseño completo de un sistema. Otros componentes son modelos de interacción del usuario con el sistema, especificación de módulos funcionales del sistema y su interacción, etc. El lenguaje de modelado unificado (UML, Unified Modeling Language) es un estándar propuesto para la creación de especificaciones de varios componentes de un sistema software. Algunas de las partes de UML son: 1.-Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R. Más adelante en este apartado se mostrarán algunas características de los diagramas de clase y cómo se corresponden con los diagramas E-R. 2.-Diagrama de caso de uso. Los diagramas de caso de uso muestran la interacción entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario (tales como prestar dinero o matricularse de una asignatura). 3.-Diagrama de actividad. Los diagramas de actividad describen el flujo de tareas entre varios componentes de un sistema. 4.-Diagrama de implementación. Los diagramas de implementación muestran los componentes del sistema y sus interconexiones tanto en el nivel del componente software como el hardware. DIAGRAMA DE CLASES Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. 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. CLASES: La clase es la unidad básica que encapsula toda la información de un objeto a través de la cual podemos modelar el entorno en estudio. En UML, una clase es representada por un rectángulo que posee tres divisiones: DIAGRAMA DE TRANSICION DE ESTADOS El diagrama de transición de estados o DTE, enfatiza el comportamiento dependiente del tiempo del sistema. Hasta hace un tiempo, los modelos del comportamiento dependiente del tiempo del sistema importaban solo para una categoría especial de sistemas conocidos como sistemas de tiempo real, por ejemplo sistemas de conmutación telefónica. Para sistemas enfocados a los negocios no se veían demasiado importante, sin embargo en sistemas grandes y complejos enfocados a negocios que si tienen aspectos de comportamiento de tiempo real. Por ejemplo si el sistema maneja entradas de miles de terminales y entradas de alta velocidad de otros sistemas, pueden entonces surgir aspectos de comportamiento dependientes del tiempo, del tipo que surgen en un sistema típico de tiempo real. Por esto aunque no se apliquen en todos los sistemas es conveniente estar familiarizado con herramientas de modelado para el comportamiento dependiente del tiempo. Los principales componentes del diagrama son los estados y las flechas, que representan los cambios de estado. Existe una variada notación pero lo más común es representar a los estados mediante rectángulos o mediante círculos, esta última forma puede llegar a parecerse con los DFD; por lo tanto aconsejo y usaré en todos los ejemplos la representación mediante rectángulos. Cada rectángulo representa un estado en el que se puede encontrar el sistema. Se lo puede encontrar definido como un conjunto de circunstancias y atributos que caracterizan a una persona o cosa en un tiempo dado; forma de ser; condición. Los estados típicos de un sistema pueden ser: 1.-Esperar a que el usuario dé su contraseña. 2.-Mezclar los ingredientes 3.-Llenar el tanque. 4.-Esperar la siguiente orden. DIAGRAMA DE OBJETOS Representan un único ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicación. Cuando cree un objeto nuevo, llamado especificación de instancia, UModel le permite asignar una clase ya existente representada por la instancia. UModel ofrece automáticamente al objeto instancias de las propiedades pertinentes desde la clase y el usuario puede insertar valores de muestras para el objeto. Los diagramas de objetos UML utilizan una notación similar a los diagramas de clases y se utilizan para ilustrar una instancia de una clase en un momento dado. Imagine que desea dibujar un diagrama de objetos para ilustrar un ejemplo real de una clase y de sus relaciones. Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante el proceso de planificación de clases o para ayudar a partes interesadas para quienes los diagramas de clases sean demasiado abstractos. Puesto que los diagramas de objetos utilizan notaciones muy similares a los diagramas de clases, la barra de herramientas de diagramas de objetos usan algunos de los iconos de la barra de herramientas de diagramas de clases. Para editar los atributos y valores de un objeto puede utilizar la barra de herramientas, el diálogo de propiedades o editarlos directamente en el diagrama. DIAGRAMA DE INTERACCION Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos. Son importantes para modelar los aspectos dinámicos de un sistema y para construir sistemas ejecutables a través de ingeniería hacia adelante e ingeniería inversa. Comúnmente contienen: Objetos Enlaces Mensajes Pueden servir para visualizar, especificar, construir y documentar los aspectos dinámicos de una sociedad particular de objetos, o pueden ser usados para modelar un flujo particular de control de un caso de uso. Los diagramas de interacción están conformados por los diagramas de secuencia y los diagramas de colaboración. DIAGRAMA DE MODULOS El diagrama de módulos muestra la asignación de clases y objetos o módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias. Programa principal: 1.-Identifica al archivo que contiene la raíz del programa. Especificación y cuerpo: 2.-Identifican los archivos que contienen la declaración y la definición de los objetos o bien procedimientos o funciones necesarias para el correcto funcionamiento de la aplicación. DIAGRAMA DE PROCESOS El diagrama de proceso es una forma gráfica de presentar las actividades involucradas en la elaboración de un bien y/o servicio terminado. En la práctica, cuando se tiene un proceso productivo y se busca obtener mayor productividad, se estudian las diversas operaciones para encontrar potenciales o reales “cuellos de botella” y dar soluciones utilizando técnicas de ingeniería de métodos. La simbología utilizada en la elaboración de un diagrama de proceso es la siguiente: APLICACIÓN DE LA NOTACION PROCESO El proceso de desarrollo de un sistema informático implica a mucha gente, el principal es el cliente que es la persona que tiene el problema que ha de ser solucionado. El Analista documenta el problema del cliente y lo trasmite a los desarrolladores, los programadores construyen el software, lo prueban y lo instalan sobre el hardware del cliente. Hoy en día los sistemas se han hecho tan complejos que una sola persona no puede conocer todas las facetas de las necesidades de un negocio, entender estas necesidades, diseñar una solución para ellas, escribir el programa e instalarlo asegurándose de que todos los componentes trabajen correctamente. 3.- UML (LENGUAJE UNIFICADO DE MODELADO) INTRODUCCION UML (Unified Modeling Languaje) Es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos. Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión. ORIENTACION A OBJETOS El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación. Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de la vida humana: Antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. APLICACION ALA ORIENTACION DE OBJETOS USO DE RALACIONES AGREGACION, COMPOSICION, INTERFACES Y REALIZACION Agregación: Es una relación que se derivó de la asociación, por ser igualmente estructural, es decir que contiene un atributo, que en todos los casos, será una colección, es decir un Array, Vector, Collections, etc. y además de ello la clase que contiene la colección debe tener un método que agregue los elementos a la colección. También se puede leer como que un medio de transporte tiene varios pasajeros. Asociación: Es una Clase que surge de una multiplicidad de muchos a muchos, y fue incorporada en UML para dar soporte a este caso. Se sacan los atributos de las clases involucradas y se los incorpora a una clase a parte. Composición: Al igual que en la agregación, es una relación estructural pero se le suma, que tiene un método de destrucción de los objetos. Y a diferencia de la asociación, el ciclo de vida del objeto área está relacionado con el del objeto ruta. Realización: Es una relación de contrato con otra clase. Se la utiliza para implementar una interfaz. En lenguajes como java o php utilizamos la palabra reservada “implements”. INTRODUCCION A CASOS Y USOS DIAGRAMAS DE CASOS DE USOS Los diagramas de caso de uso son uno de los cinco tipos de diagramas en UML para modelar aspectos dinámicos de sistemas (diagramas de actividad, diagramas de estados, diagramas de secuencia y diagramas de colaboración son otros cuatro tipos de diagramas en UML para modelar los aspectos dinámicos de un sistema). Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso, actores y sus relaciones. Se aplican los diagramas de casos de uso para modelar las vistas de casos de uso de un sistema. Para la mayor parte, esto involucra el modelado el contexto de un sistema, subsistema, o clase, o modelar las necesidades del comportamiento de esos elementos. Los diagramas de casos de uso son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas, subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos pueden ser usados dentro del contexto. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa. DIAGRAMAS DE ESTADOS Muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: Estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones. DIAGRAMAS DE SECUENCIA Es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. DIAGRAMA DE COLABORACIONES Presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros. DIAGRAMA DE ACTIVIDADES Es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado. Parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes. Ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad. DIAGRAMA DE COMPONENTES Se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de software, los componentes de código binario, y los componentes ejecutables. En el Diagrama de Componentes modelas componentes del sistema, a veces agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes). DIAGRAMAS DE DISTRIBUCION Se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment', empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente. Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma).
Tu Sitio Web Gratis © 2025

Menú