miércoles, 22 de julio de 2015

DIAGRAMA DE SECUENCIA


ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ
MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

    SEMESTRE  SÉPTIMO           PERIODO  ABR 2015/SEP 2015

TEMA:

DIAGRAMA DE SECUENCIA

MATERIA:

INGENIERÍA DE SOFTWARE


AUTOR:

CARLOS A. ZAMBRANO VIDAL

FACILITADORA:

ING. HIRAIDA SANTANA



CALCETA,  JULIO 2015

INTRODUCCIÓN
En esta ocasión vamos a conocer a fondo sobre los diagramas de secuencias ya que estos son primordiales saber y conocer que elementos intervienen en él y cómo funcionan cada uno de ellos, los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. El diagrama de secuencia muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo.
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. 
MARCO TEÓRICO
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. 
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "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 flechas horizontales.
Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros.
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. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.

OBJETOS

Los diagramas de secuencia constan de objetos que se representan de modo usual: rectángulo con nombre, mensajes entre los objetos representados por líneas continuas con una punta de flecha y el tiempo representado como una progresión vertical. 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 (en forma descendente) de cada objeto será una línea discontinua conocida como la línea de vida de un objeto, junto con la línea de vida de un (objeto rectángulo) se le conoce como activación, el cual una operación que realiza el objeto la interpreta como la duración de la activación.


LÍNEA DE VIDA
Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee el diagrama de secuencia.


MENSAJE
Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto al de otro. Un objeto puede enviarse un objeto a sí mismo es decir de su línea de vida así propia línea de vida.
Un mensaje puede ser simple, síncrono y asíncrono

Mensaje simple: es la transferencia del control de un objeto a otro.
Mensaje síncrono: es cuando el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo.
Mensaje asíncrono: es cuando el objeto no espera la respuesta a ese mensaje antes de continuar.

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 mas cerca de la parte superior ocurrirá antes que uno que esté cerca de la parte inferior.
Con ellos el diagrama de secuencia tiene 2 dimensiones: la dimensión horizontal (es la disposición de los objetos) y la dimensión vertical (muestra el paso del tiempo).
La siguiente figura muestra el conjunto básico de símbolos del diagrama de secuencia, junto con los símbolos de su funcionamiento.


RECURSIVIDAD
En ocasiones un objeto posee una operación que se invoca a sí misma. A esto se le conoce como recursividad y es una característica fundamental de varios lenguajes de programación.


CONCLUSIÓN
Se concluye que el Diagrama de Secuencia es muy importante para los proyectos o aplicaciones más complejas, este diagrama de secuencia:
Ø  Está centrado en los objetos individuales.
Ø  Es más adecuado para observar la perspectiva cronológica de las interacciones.
Ø  Muestra la secuencia explícita de mensajes
Ø  Son mejores para especificaciones de tiempo real y para escenarios complejos.

BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.
Larman, Craig. UML y Patrones. Introducción al análisis y diseño orientado a objetos. Prentice Hall, México, 1999.




miércoles, 15 de julio de 2015

RELACIONES ENTRE CLASES


ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ
MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

    SEMESTRE  SÉPTIMO           PERIODO  ABR 2015/SEP 2015

TEMA:
RELACIONES ENTRE CLASES

MATERIA:

INGENIERÍA DE SOFTWARE


AUTOR:

CARLOS A. ZAMBRANO VIDAL

FACILITADORA:

ING. HIRAIDA SANTANA



CALCETA,  JULIO 2015


INTRODUCCIÓN
En la sección anterior hablamos de los diagramas de clases, ahora vamos a enfocarnos en los tipos de relaciones que pueden existir en un diagrama de clases cómo funcionan como van ubicados entre sí como se relacionan en nuestro diagrama ya que es muy importante conocer cómo se utilizan las relaciones entre clases porque es necesario para nuestro diagrama final este bien realizado y que sea entendible para nuestros analistas y cliente.
MARCO TEÓRICO
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)

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), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehículo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en cambio atributos como Descapotable no son visibles por ser privados.
AGREGACIÓN

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 construye 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).
Un Ejemplo es el siguiente:

En donde se destaca que:
· Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
· Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
· La composición (por Valor) se destaca por un rombo relleno.
·  La agregación (por Referencia) se destaca por un rombo transparente.
·  La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.
ASOCIACIÓN:

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.
Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.
DEPENDENCIA O INSTANCIACIÓN (USO)

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

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

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


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

CONCLUSIÓN
Se concluye que las relaciones entre clases juegan un papel importante en el desarrollo de nuestro diagrama de clase ya que de estos depende como estén relacionadas nuestras clases, también nos enseña como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, estas son algunas de las funcionalidades de las relaciones entre clases.
BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.
Larman, Craig. UML y Patrones. Introducción al análisis y diseño orientado a objetos. Prentice Hall, México, 1999.





miércoles, 8 de julio de 2015

DIAGRAMA DE CLASES


ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ
MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

    SEMESTRE  SÉPTIMO           PERIODO  ABR 2015/SEP 2015

TEMA:

DIAGRAMA DE CLASES

MATERIA:

INGENIERÍA DE SOFTWARE


AUTOR:

CARLOS A. ZAMBRANO VIDAL

FACILITADORA:

ING. HIRAIDA SANTANA


CALCETA,  JULIO 2015

INTRODUCCIÓN
En esta sección vamos a conocer a fondo sobre los diagramas de clases, en el contexto de UML, estos permiten documentar la estructura estática de una aplicación informática desde el punto de vista del análisis diseño orientado a objeto.Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
MARCO TEÓRICO
DIAGRAMA DE CLASES

DIAGRAMA DE CLASES

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

CLASE

Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.

ATRIBUTOS

En UML, los atributos se muestran al menos con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente:
·         + Indica atributos públicos
·         # Indica atributos protegidos
·         - Indica atributos privados
OPERACIONES
Las operaciones (métodos) también se muestan al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:
·         + Indica operaciones públicas
·         # Indica operaciones protegidas
·         - Indica operaciones privadas
PLANTILLAS
Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en C++ y se introducirán en Java 1.5 con el nombre de Genéricos.

ASOCIACIONES DE CLASES

Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras:
GENERALIZACIÓN
La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias.
En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base.



CONCLUSIÓN
Se concluye que el diagrama de clases es muy fundamental en un sistema que estemos desarrollando ya que esta permite ampliar las oportunidades, para que las personas involucradas en el proyecto comprendan de una mejor manera la aplicación. El diagrama de clases nos facilita o nos ayuda en el entendimiento de otro analista de sistemas y así saber las necesidades del cliente.
BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.
Larman, Craig. UML y Patrones. Introducción al análisis y diseño orientado a objetos. Prentice Hall, México, 1999.




viernes, 3 de julio de 2015

DIAGRAMA DE CASO DE USO


ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ
MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

    SEMESTRE  SÉPTIMO           PERIODO  ABR 2015/SEP 2015

TEMA:

DIAGRAMA DE CASO DE USO

MATERIA:

INGENIERÍA DE SOFTWARE


AUTOR:

CARLOS A. ZAMBRANO VIDAL

FACILITADORA:

ING. HIRAIDA SANTANA



CALCETA,  JULIO 2015

INTRODUCCIÓN
Con el fin de dar a conocer la función que cumplen los diagramas de uso. Para poder hacer posible esto se profundiza en este tema para poder elaborar un trabajo correcto. La ingeniería de software, se dedica al estudio y aplicación de métodos sistemáticos para el desarrollo y mantenimiento de software, responde a las necesidades de los usuarios con nuevas técnicas de caso de uso que facilitan la comunicación de necesidades de procesamiento de información de los usuarios y plantearlas en forma de requerimientos de forma tal, que guíen la construcción, administración y pruebas del software. 
MARCO TEÓRICO
DIAGRAMA DE CASO DE USO
Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema.
Los diagramas de caso de uso son uno de los cinco diagramas en UML para modelar los aspectos dinámicos del sistema (diagramas de actividad, diagramas de estado, diagramas de secuencia y diagramas de colaboración son los otros cuatro). Los diagramas de caso de uso son centrales para modelar el comportamiento de un sistema, subsistema o una clase. Cada uno muestra un conjunto de casos de uso y actores y sus relaciones.
Aplicarás diagramas de caso de uso para modelar la vista de caso de uso de un sistema. Para la mayoría de las partes, esto involucra modelar el contexto de un sistema, subsistema o clase o modelar los requerimientos del comportamiento de estos elementos.

Los diagramas de caso de uso son importantes para visualizar, especificar y documentar el comportamiento de un elemento. Hacen al sistema, subsistema y clases accesibles y entendibles al presentar una vista externa de cómo aquellos elementos pueden ser usados en contexto. Los diagramas de caso de uso también son importantes para probar sistemas ejecutables a través de ingeniería hacia delante y para comprender sistemas ejecutables a través de ingeniería en reversa.
Suponga que alguien le da una caja. En un lado de esa caja hay algunos botones y un panel pequeño de LCD. Aparte de esto, la caja no está descrita; no te dan ninguna pista de cómo usarlo. Puedes azarosamente oprimir los botones y ver qué sucede, pero estarás estresado para darte una idea de qué hace la caja y cómo lo usas apropiadamente a menos que dediques mucho tiempo a prueba y error.
Sistemas de software intensivos pueden ser como lo anterior. Si eres un usuario, pudieras tener una aplicación y solicitarte que la uses. Si la aplicación sigue las convenciones normales del sistema operativo que acostumbras, puede ser que hagas algo útil después de un rato, pero no tendrás una comprensión de su comportamiento más detallado y complejo de esta manera. Similarmente, si eres un desarrollador, puede ser que tengas una aplicación heredada o un conjunto de componentes y te dicen que los uses. Estarás presionado para saber cómo usar los elementos hasta que te hayas formado un modelo conceptual de su uso.
Con UML aplicas los diagramas de caso de uso para visualizar el comportamiento del sistema, subsistema o clase para que los usuarios puedan comprender cómo usar ese elemento y los desarrolladores puedan implantarlo.
Un diagrama de casos de uso es sólo una clase especial de diagrama y comparte propiedades comunes como todos los otros diagramas. Un nombre y contenido gráfico que son proyecciones del modelo. Lo que distingue a un diagrama de caso de uso de otros diagramas es su contenido particular.

CASO DE USO
Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible.
Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas:
  • Cada caso de uso está relacionado como mínimo con un actor
  • Cada caso de uso es un iniciador (es decir, un actor)
  • Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre casos de uso son:
  • <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso
  • <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro.
  • Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.

ACTOR

Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.
Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención telefónica a clientes y realiza pedidos para los clientes estaría representada por un actor «equipo de soporte» y por otro actor «representante de ventas».

DESCRIPCIÓN DE CASOS DE USO

Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso.

CONCLUSIÓN
Se concluye  que el caso de uso para poder ser utilizado necesitamos de varia cosas entre ellas el actor, la descripción de los casos de uso, diagrama de clases, clases, atributos, operaciones, plantillas, asociación de clases y generación. Cada una de estas contribuye con el caso de uso para poder elaborarlo de una manera correcta. También  todo sistema interacciona con actores humanos o automatizados que utilizan el sistema con algún propósito, y esos actores esperan que el sistema se comporte previsiblemente.  Un caso de uso especifica el comportamiento de un sistema o una parte de él y es la descripción de un conjunto de secuencias de acciones.
BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.
Larman, Craig. UML y Patrones. Introducción al análisis y diseño orientado a objetos. Prentice Hall, México, 1999.