jueves, 1 de octubre de 2015

PORTADA


ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ 
“MANUEL FÉLIX LÓPEZ”
                                                                                               
                                
CARRERA INFORMÁTICA


SEMESTRE SÉPTIMO                       PERIODO MAR – AGO/2015


PORTAFOLIO DE INGENIERÍA DEL SOFTWARE


AUTORA:
MARÍA PAOLA MENDOZA MENDIETA


FACILITADORA:
 ING. HIRAIDA SANTANA CEDEÑO


MISIÓN
Formación de profesionales integros que conjuguen ciencia, tecnología y valores en su accionar, comprometidos con la sociedad en el manejo adecuado de programas y herrmientas computacionales de última generación

VISIÓN
Ser referentes en la formación de profesionales de prestigio en el desarrollo de aplicaciones informáticas y soluciones de hardware


CALCETA, 2015

miércoles, 8 de julio de 2015

DIAGRAMA DE SECUENCIA Y PAQUETE

Fecha de Clase: 6- 10 julio del 2015
INTRODUCCIÓN
Los diagramas UML, son de gran importancia en el desarrollo de proyecto de software ya que permiten al cliente y  al desarrollador visualizar o construir los requisitos y la funcionalidad de los sistemas. Es por esto que los diagramas de secuencia y de paquete son fundamentales y básicos en el desarrollo de sistemas.
El diagrama de secuencia permite mostrar de forma gráfica  como los objetos actúan entre sí, mientas que el diagrama de paquete es utilizado en sistemas grandes permitiendo agrupar las partes del sistema en paquetes para comprender de manera adecuada el funcionamiento de un software y estos diagramas también sirven para la documentación de un proyecto de software.

OBJETIVO
Recolectar información de los diagramas de paquetes y de secuencia  para conocer mejor su funcionamiento.
MARCO TEÓRICO
DIAGRAMA DE SECUENCIA
Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el escenario. En aplicaciones grandes además de los objetos se muestran también los componentes y casos de uso. El mostrar los componentes tiene sentido ya que se trata de objetos reutilizables, en cuanto a los casos de uso hay que recordar que se implementan como objetos cuyo rol es encapsular lo definido en el caso de uso. Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interacción de objetos, se utilizan con frecuencia para validar los casos de uso. Documentan el diseño desde el punto de vista de los casos de uso, observando qué mensajes se envían a los objetos, componentes o casos de uso y viendo a grosso modo cuánto tiempo consume el método invocado, los diagramas de secuencia nos ayudan a comprender los cuellos de botella potenciales, para así poder eliminarlos. (____, 2009)
  
 ELEMENTOS DE UN DIAGRAMA DE SECUENCIA
Según Parada (2010), los elementos de un estado de secuencia son:

OBJETOS
Los objetos se colocan cerca de la parte superior del diagrama, de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama. La extensión que esta debajo y en forma descendente será una línea discontinua conocida como la línea de vida del objeto. Junto con la línea de vida del objeto se encuentra un pequeño rectángulo conocido como activación, el cual representa la ejecución de una operación que realiza el objeto. La longitud del rectángulo se interpreta como la duración de la activación.

ESTIMULOS
Un estímulo que va de un objeto a otro pasa de la línea de vida de un objeto a la de otro. Un objeto puede enviarse un mensaje a si mismo (es decir desde su línea de vida hacia su propia línea de vida). Un estímulo puede ser simple, síncrono o asíncrono. Un mensaje simple es la transferencia del control de un objeto a otro. Si un mensaje envía un mensaje síncrono, esperara la respuesta a tal mensaje antes de continuar. En el diagrama de secuencias, los símbolos de mensajes varia, por ejemplo, la punta de flecha de flecha de un mensaje simple esta formada por dos líneas, la punta de flecha de un mensaje sincrónico esta rellena y la de un asíncrono tiene una sola línea.
TIEMPO
El diagrama representa el tiempo en dirección vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que este más cerca de la parte superior ocurrirá antes de uno que esté más cerca de la parte inferior. Con ello el diagrama de secuencias tiene dos dimensiones. La dimensión horizontal es la disposición de los objetos y la dimensión vertical muestra el paso del tiempo.

EJEMPLO DE DIAGRAMA DE SECUENCIA
Proceso de envió de documentos, en un sistema web.

DIAGRAMA DE PAQUETE
Un paquete es un mecanismo utilizado para agrupar elementos de UML,  es una parte de un modelo. Contiene elementos del modelo al más alto nivel, tales como clases y sus relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones: cualquier elemento que no esté contenido en otro. Los paquetes pueden contener otros paquetes.
Muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido. (Franco, 2011)
DEPENDENCIA
Las dependencias entre paquetes resumen dependencias entre los elementos internos a ellos, es decir, las dependencias del paquete se derivan a partir de las dependencias entre los elementos individuales.
Indica que un elemento de un paquete requiere a otro de un paquete distinto. Se representa mediante una flecha discontinua con inicio en el paquete que depende del otro.

Según Sparx Systems (2007), las propiedas o los elementos que se deben tener en cuenta al momento de realizar los diagramas de paquetes son los siguientes:
Combinación de paquetes
Cuando un conector «merge» se usa en un paquete, la fuente de la combinación importa los contenidos importados y anidados del destino. Si existe un elemento dentro del origen y el destino, las definiciones del elemento origen se expandirán para incluir las definiciones del elemento contenidas en el destino. Todos los elementos agregados o actualizados por una combinación se notan por una relación de generalización desde el origen hasta el destino.
Importación de Paquetes
El conector «import» indica que los elementos dentro del paquete destino, que en este ejemplo es una sola clase, se importarán al paquete origen. El espacio de nombre del paquete origen ganará acceso a la Clase/s de Destino; el espacio de nombre del destino no está afectado.
Conectores Anidados
El conector anidado entre el paquete destino y los paquetes de origen reflejan lo que muestran los contenidos del paquete.

EJEMPLO DE DIAGRAMA DE PAQUETE
Diagram de Paquete del sistema FILESYST

CONCLUSIÓN
Puedo concluir que estos dos diagramas de UML, que se describieron en este documento, son indispensable en el desarrollo de un proyecto de software. Puesto  que cada uno de los diagramas tienen característica que los hace únicos e importantes. El diagrama de secuencia permite dar a conocer la interacción entre  los objetos pudiendo determinar el tiempo que se va a llevar a cabo una acción o una tarea. Mientras que los diagramas de paquetes son utilizados en sistemas grandes, ya que este diagrama permitirá subdividir el sistema en paquetes para  tener sistemas organizados. Estos diagramas son importantes para la realización de sistemas de alta calidad, ya que permite determinar con exactitud los requerimientos y las funcionalidades del software.
BIBLIOGRAFÍA

_______. 2009. ESTÁNDAR DIAGRAMA DE SECUENCIA. Formato. PDF

Booch, G; Rumbaugh, J; Jacobson, I. 2004. El lenguaje unificado de modelado UML. Formato PDF.

Ferre, X y Sanchez, M. 2010?. Desarrollo orientado a objetos con UML. UPM.

Franco, A. 2011. Diagrama paquetes, colaboracion y componetes.

Parada, R. 2010. Diagrama de Secuencia. El Salvador. Formato PDF.

Rosales, A y Cruz, J. 2013. Diagrama de Paquetes. Formato PDF.


Sparx Systems. 2007?. Diagrama de Paquete. Formato HTML.

miércoles, 1 de julio de 2015

RELACIONES ENTRE CLASES

Fecha de Clase: 29 de Junio - 3 de Julio del 2015

INTRODUCCIÓN
Existen varios diagramas UML, los cuales son de mucha importancia para el desarrollo de un proyecto de software. Pero estos diagramas tienen que seguir reglas para su correcto funcionamiento.
Es por esto que los diagramas de clases, están formados por clases pero estas clases no funcionan de manera independiente, estas clases están relacionadas una de otra es por esto que en este documento se hablara de los diferentes tipos de relación de clases. Existen diversas relaciones entre clases y estas son utilizadas dependiendo del problema o de la necesidad, en este documento se detallaran las más utilizadas.

OBJETIVO
Identificar los diferentes tipos de relación que existen entre las clases, para crear diagramas UML eficientes y  funcionales.

MARCO TEÓRICO
RELACIONES ENTRE CLASES
Según Velasco (2009), las relaciones entre clases juegan un papel muy importante en el modelo de objetos. Las clases, al igual que los objetos, no existen de modo aislado. Por esta razón existirán relaciones entre clases y entre objetos. Las relaciones entre clases, se deben a dos razones:
Una relación de clases puede indicar algún tipo de compartición
Una relación entre clases puede indicar algún tipo de conexión semántica.

NAVEGACION DE LAS ASOCIACIONES
Bidireccional: se pueden recorrer de los dos sentidos, se representa con una línea.
 
Unidireccional: restringe su navegación hacia un único sentido, cuando es unidireccional la línea termina en una punta de flecha que indica el sentido de la asociación.

MULTIPLICIDAD
En esta se determina cuantos objetos de cada tipo intervienen en la relación, cabe recalcar que  cada asociación tiene dos multiciplidades.

Tipos de multiciplidad entre clases

RELACIONES INVOLUTIVAS
Cuando la misma clase está asociada en los dos extremos: 

AGREGACIÓN
La agregación es un tipo de asociación que indica que una clase es parte de otra clase (composición débil). Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la composición.
La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo en el que está la clase que representa el “todo”. (Megino, 2013)

COMPOSICIÓN
Composición es una forma fuerte de composición donde la vida de la clase contenida debe coincidir con la vida de la clase contenedor. Los componentes constituyen una parte del objeto compuesto. De esta forma, los componentes no pueden ser compartidos por varios objetos compuestos. La supresión del objeto compuesto conlleva la supresión de los componentes.
El símbolo de composición es un diamante de color negro colocado en el extremo en el que está la clase que representa el “todo”. (
Megino,  2013)

DEPENDENCIA
Es una relación de uso, es decir que una clase utiliza a otra. Y si esta última se altera, la anterior se puede ver afectada.

RELACIÓN DE GENERALIZACIÓN/ ESPECIALIZACIÓN
Uno de los motivos por los cuales las clases se relacionan entre ellas es el hecho de poseer propiedades comunes. Las clases con propiedades comunes se organizan en superclases. Una superclase representa una generalización de las subclases. De igual modo, una subclase de una clase dada representa una especialización  de la clase superior. La clase derivada es un tipo de clase de la clase base o súper clase. Una superclase representa una generalización de las subclases. Una subclase de la clase representa una especialización de la clase ascendente.

HERENCIA MULTIPLE
El concepto básico de la herencia múltiple suena bastante simple: puede crear un nuevo tipo heredando de más una una clase base. La sintaxis es exactamente la que espera, y en la medida en que los diagramas de herencia sean simples, la herencia múltiple  puede ser simple también.
Sin embargo, la herencia múltiple puede presentar un buen número de situaciones ambiguas y extrañas, que se cubren en este capítulo. Pero primero, es útil tener algo de perspectiva sobre el asunto.

EJEMPLO DE RELACIONES ENTRE CLASES
Ejercicio de diagrama de clases de un medio de transporte, utilizando las diferentes relaciones que se describieron en este documento.


CONCLUSIÓN
Puedo concluir que para que exista un correcto funcionamiento en los diagramas UML, es necesario conocer todos estos tipos de relaciones ya que con ellas se van a realizar la relación entre los objetos.
Los diagramas de clases, no podrían funcionar sin estas relaciones ya que las clases no sirven de nada de manera independiente,  es por esto que son necesarias las relaciones de clases, para ser capaces de crear diagramas funcionales y eficientes, que sean útiles para la documentación de proyectos de software.
Las relaciones entre clases dan a conocer las diferentes características que existen al momento de realizar una relaciones entre las clases, para así determinar que tipo de relación se está utilizando y si es la más idónea para la situación.

BIBLIOGRAFÍA
Berzal, F. 2004?. Relaciones entre clases: Diagramas de clases UML. Formato PDF. (En Línea).

Booch, G; Rumbaugh, J; Jacobson, I. 2004. El lenguaje unificado de modelado UML. Formato PDF.

Ferre, X y Sanchez, M. 2010?. Desarrollo orientado a objetos con UML. UPM.

Díaz, A. 2008. UML Relaciones, Composición, Agregación, Asociación, Dependencia, Generalización, Realización. Formato HTML. (En línea).

Velasco, J. 2009. MODELACIÓN DE RELACIONES ENTRE CLASES. Formato PDF. (En Linea).

miércoles, 10 de junio de 2015

DIAGRAMA DE CLASE

Fecha de Clase: 8 -12 de junio del 2015
INTRODUCCIÓN
Para el desarrollo de un proyecto de software, es importante por esto detallar o especificar o determinar cuáles son los principales requisitos del sistema, es por esto que hay que desarrollar soluciones que permitan cliente o al programador tengan claro que va hacer el sistema.
Dentro de los diagrama de UML, uno de los más reconocido es el diagrama de clases,  este tipo de diagramas es estático en él se representa mediante tablas los atributos, métodos y relaciones entre objetos. Lo que permite que el desarrollador del proyecto reconozca todas las características del sistema.

OBJETIVO
Identificar cual es la funcionalidad de los diagramas de clases y donde se pueden implementar.

MARCO TEÓRICO
DIAGRAMAS DE CLASE
Según García y Pardo (2002), el propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las fases de análisis y diseño, estando presente como guía en la implementación del sistema.
Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden utilizar los diagramas de clase:
Conceptual: El diagrama de clase representa los conceptos en el dominio del problema que se está estudiando. Este modelo debe crearse con la mayor independencia posible de la implementación final del sistema.
Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que un tipo representa una interfaz que puede tener muchas implementaciones diferentes.
Implementación: Esta vista representa las clases tal cual aparecen en el entorno de implementación.

ELEMENTOS ESENCIALES DE LOS DIAGRAMAS DE CLASE
CLASES
Una clase es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser la clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad de motores”, “la velocidad de crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta clase se encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”.
Un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que representan las asociaciones o maneras en que las clases se relacionan entre sí. Estos rectángulos tienen tres comportamientos:
NOMBRE DE LA CLASE: En la parte superior se encuentra el nombre que se le da a una clase o como se la va a conocer.
ATRIBUTOS:son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca, tamaño, color y peso. (Leon et al., 2013)
OPERACIONES: son aquellas actividades o verbos que se pueden realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar, cargar. El nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc. (Leon et al., 2013)

ASOCIACIÓN
En un diagrama de clases UML, puede dibujar asociaciones entre cualquier par de tipos. Un tipo es una clase, interfaz o enumeración.
Una asociación indica que el sistema que está desarrollando almacena vínculos de algún tipo entre las instancias de los tipos asociados. Por lo general, esto no conlleva nada para la implementación de los vínculos. 
Una asociación es un método en forma de diagrama para mostrar un atributo o un par de atributos. Por ejemplo, si definió una clase Restaurant para que tenga un atributo de tipo Menu, puede establecer la misma definición dibujando una asociación entre Restaurant y Menu. (Microsoft, 2015)
Las asociaciones pueden ser binarias (conectan dos clases) o n-arias (conectan n clases), aunque lo más normal en un modelo es utilizar sólo relaciones binarias (en general, y sin entrar en detalles, se puede afirmar que una relación n-aria puede modelarse mediante un conjunto finito de relaciones binarias).
La forma de representar las asociaciones binarias en UML es mediante una línea que conecta las dos clases. En general, las asociaciones son bidireccionales, esto es, no tienen un sentido asociado.


AGREGACIÓN
La agregación es un tipo de asociación que indica que una clase es parte de otra clase (composición débil). Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la composición.
La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo en el que está la clase que representa el “todo”. (Megino, 2013.)


COMPOSICIÓN
Composición es una forma fuerte de composición donde la vida de la clase contenida debe coincidir con la vida de la clase contenedor. Los componentes constituyen una parte del objeto compuesto. De esta forma, los componentes no pueden ser compartidos por varios objetos compuestos. La supresión del objeto compuesto conlleva la supresión de los componentes.
El símbolo de composición es un diamante de color negro colocado en el extremo en el que está la clase que representa el “todo” (Compuesto). (Megino,  2013)


EJERCICIO PRÁCTICO
Una línea aérea ofrece distintos vuelos. Los vuelos están compuestos de segmentos de vuelo que son los destinos o paradas intermedias. Es decir un vuelo es una sucesión de segmentos de vuelo. Los pasajeros tienen un asiento por cada segmento de vuelo.  Un segmento de vuelo necesita un avión, un aeropuerto de salida, uno de llegada, así como un piloto y copiloto.



CONCLUSIÓN
Los diagramas de clase son muy conocido ya que nos dan a conocer los atributos métodos y los objetos de las clases que se encuentran relacionadas entre sí. Los diagramas de clases son conocidos como un modelo o un bosquejo básico de una base de datos. Estos diagramas se relacionan entre si cumpliendo con ciertas relaciones como la agregación y la composición que estas depende de las clases que se vayan a relacionar. Están basados en la programación orientada a objeto, y son de gran ayuda al momento de desarrollar un proyecto de software para el desarrollador, sirven como guía y para documentar el proyecto.

BIBLIOGRAFÍA
Booch, G; Rumbaugh, J; Jacobson, I. 2004. El lenguaje unificado de modelado UML. Formato PDF.

Ferre, X y Sanchez, M. 2010?. Desarrollo orientado a objetos con UML. UPM.

García, F y Pardo, C.2002. Diagramas de Clase en UML. Universidad de Burgos.

Leon, M; Vidal, M; Linares, J. 2013.Diagrmas de Clases. Formato HTML.

Megino, J. 2013. Agregación Vs Composición en diagramas de clases. UML.

Microsoft. 2015. Propiedades de las asociaciones de diagramas de clases de UML.


Popkin Software and Systems. 2002. Modelado de sistemas con UML. Formato PDF.

miércoles, 3 de junio de 2015

DIAGRAMA CASO DE USO

Fecha de Clase:  1-5 de junio del 2015
INTRODUCCIÓN
En esta clase se trató sobre unos de los diagrama de comportamiento, sin duda uno de los más populares, y más reconocido por el cliente como lo son los casos de usos. El diagrama de Caso de Uso es muy utilizados, para demostrarle al cliente como va a funcionar el sistema de manera general, mostrando las acciones y los usuarios que van a intervenir en el sistema. Este diagrama representa de manera gráfica como va a trabajar nuestro sistema, para que sea más fácil de entender para el cliente y para presentar de manera visual los requisitos que debe tener el sistema. La importancia de los casos de usos dentro del desarrollo de sistema, es fundamental para tener en claro que va hacer en sistema.

OBJETIVO
Conocer el funcionamiento y la importancia del diagrama caso de uso para su implementación en el desarrollo de proyecto de un sistema.

MARCO TEÓRICO
CASOS DE USOS
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML. (Popkin Software and Systems, 2002)
El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. (Hernández, 2002).

PARTES DE LOS CASOS DE USOS
Actor: Algo con comportamiento (persona, otro programa, organización), que interactúa con el sistema o también conocido como un rol.

Sistema: El rectángulo representa los límites del sistema que contiene los casos de uso. Los actores se ubican fuera de los límites del sistema

Caso de Uso= Colección de escenarios (éxito y fracaso) que describen actores que usan el sistema para conseguir un objetivo.

Relaciones entre dos casos de uso:
·     Generalización: Es un caso particular entre los  casos de usos,  también se puede tener esta relación entre dos actores
·    Inclusión: Una relación "incluir" indica que un caso de uso es necesitado por otro para poder cumplir una tarea.
·       Extensión: Las relaciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original.


PASOS PARA LA CREACION DE LOS CASOS DE USOS
Según la Escuela Politécnica Superior (2009), los pasos para desarrollar un buen diagrama de caso de uso  son:
1.   Identificar los límites del sistema.
2.    Identificar los actores principales.
3.    Para cada uno, identificar sus objetivos.
4.    Definir casos de uso que satisfagan sus objetivos.


EJEMPLO PRÁCTICO
Según el proceso de atención de pacientes en la unidad de cuidados intensivos UCI, se han realizado los siguientes diagramas de caso de uso que tratan de modelar este sistema:
  • Registro de ingreso de pacientes a la unidad


 Registro de medicamentos y procedimientos en pacientes

  • Registro de especialistas en la unidad para la atención de pacientes

  • Registro de diagnósticos de los pacientes que ingresan al hospital



CONCLUSIÓN
Puedo concluir que el diagrama de caso de uso, es uno de los diagramas más importante dentro de los diagramas de comportamiento, ya que permite conocer al usuario el funcionamiento del sistema, indicándole a través de los actores los usuarios que van a interactuar con el sistema, y las acciones que van a realizar los usuarios a través de los casos de usos y las relaciones que estas van a tener. Este diagrama es uno de los más implementados al momento de desarrollar un sistema, porque permite al usuario o al cliente tener en claro que es lo que va a hacer el sistema, detallando los requisitos básico que va tener el sistema.

BIBLIOGRAFÍA
Booch, G; Rumbaugh, J; Jacobson, I. 2004. El lenguaje unificado de modelado UML. Formato PDF.

Hernandez, E. 2002?. El lenguaje unificado de modelado UML. Formato PDF.

Escuela Politécnica Superior. 2009. UML: Lenguaje Unificado Modelado. Formato PDF.

Ferre, X y Sanchez, M. 2010?. Desarrollo orientado a objetos con UML. UPM.

Popkin Software and Systems. 2002. Modelado de sistemas con UML. Formato PDF.

sábado, 23 de mayo de 2015

LENGUAJE UNIFICADO DE MODELADO UML

Fecha de Clase: 18 - 22 de mayo 2015

INTRODUCCIÓN
El tema de esta clase fue UML (lenguaje unificado de modelado), la cual es importante su estudio puesto que este ayuda a los profesionales dentro de la ingeniería en software. El UML es muy utilizado, ya que ayuda a representar de manera gráfica la funcionabilidad de los sistemas de software intensivo, ayudando al cliente a entender el software, también a los desarrolladores a construir software.
El lenguaje unificado de modelado tiene modelos estructurales y de comportamiento, los cuales tienen diagramas que son de gran importancia y  de gran utilidad en la ingeniería. A continuación en este documento se describirá el lenguaje unificado de modelado.

OBJETIVO
Conocer las características  y la importancia del lenguaje unificado de modelado (UML).

MARCO TEÓRICO
Según Enrique Hernández “Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual. El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De la misma forma que para construir una choza no hace falta un modelo, cuando se intenta construir un sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelos que el ser humano pueda entender”. Un modelado tiene características como son:


Es por esto que nace el lenguaje unificado de modelado para dar solución a esta problemática.

LENGUAJE UNIFICADO DE MODELADO
En 1997 UML fue aprobado como estándar por el OMG (Object Management Group). Aunque en los últimos años este lenguaje ha sido modificado.
UML es un lenguaje unificado de modelado que sirve para visualizar, construir, especificar y documentar los sistemas de software. El lenguaje unificado de modelado es muchas veces confundido como un lenguaje de programación, pero no lo es, es simplemente una herramienta que ayuda a generar código o facilita la construcción de software. Este modelo usa información estructural (estática) y de comportamiento (dinamica) de un sistema.
Imagen 1. UML

BENEFICIOS DE UML
Muchas veces para desarrollar software complejos, es muy difícil describirlo a través de texto, pero si lo expresamos a través de diagrama es más fácil entenderlo. Es por esto que UML presenta tres beneficios: este modelo
  • Visualizar: se expresa a través de gráficos un sistema, de manera que sea fácil de entender.
  • Especificar: puede especificar las características de un sistema.
  • Construir: se  pueden diseñar sistemas
  • Documentar: sirven para documentar el desarrollo del software.

MODELOS ESTRUCTURALES O ESTÁTICOS

Imagen 2. Modelo estructurales UML
Diagrama de clases: muestra las clases y la relaciones entre ellas.
Diagrama de Objeto: están vinculados con los diagramas de clase.
Diagrama de paquetes: organiza los elementos del modelado.
Diagrama de despliegue: Muestra la relación entre los componentes de hardware y software
Diagrama de componentes: muestra los componentes de mayor nivel de la programación.

MODELOS DE COMPORTAMIENTO

Imagen 2. Modelo de comportamiento UML
Diagrama de casos de uso: muestra a los actores, los casos de uso y sus relaciones.
Diagrama de secuencia: muestra los objetos y las relaciones entre ellos.
Diagrama de colaboración: muestra objetos y sus relaciones, pero en esta se destaca los objetos que intercambia mensajes.
Diagrama de actividad: detalla las actividades, sus cambios y sus eventos.
Diagrama de estado muestra los cambios de estado y eventos en un objeto o en parte del sistema.
Diagrama de cronológico: muestra las interacciones de tiempo de los objetos.
Diagrama de interacciones: representa la forma como un actor y la clase se comunican a través de eventos

CONCLUSIÓN
En conclusión los modelados permiten analizar y  desarrollar software más complejos y eficaces, permitiendo obtener un modelo visual del sistema.
El lenguaje unificado de modelado es de gran importancia en la ingeniería, ayuda a modelar grandes sistemas y es muy utilizado en distintos tipos de software. El UML cada vez es más implementado, ya que ayuda a obtener un mayor entendimiento sobre las funcionalidades del software tanto para el desarrollador y para el cliente. Este modelado no  solo permite diseñar, graficar, etc; sino que también facilita la construcción de los sistemas, a través de los diferentes modelos de estructurales y de comportamientos. Estos diagramas son utilizados según la necesidad y el tipo de sistema que se vaya a desarrollar.

BIBLIOGRAFÍA
Larman, C. 1999. UML y Patrones. Pearson.

Lopez, P Y Ruiz, F. 2010?. Lenguaje Unificado de Modelado – UML. (En Linea). Formato PDF.

Hernández, E.  2002. El Lenguaje  Unificado de Modelado (UML). (En Linea). Formato PDF.

Gutiérrez, D. 2009. UML diagramas de Paquetes. Universidad de los Andes. (En Linea). Formato PDF.

Ferré X, Sánchez M. Desarrollo Orientado a Objetos con UML. Facultad de Informática – UPM. Formato PDF.

Pressman, R. 2010. Ingeniería del Software un enfoque Práctico. 7ma. ed. México: Mc Graw Hill.

Sommerville, I. 2005. Ingeniería del software. 7ma ed. Madrid. Pearson Educación.

_________. 2010. Diagrama de objetos, secuencias y despliegue en UML. (En Linea). Formato PDF.