martes, 21 de junio de 2011

CUADRO COMPARATIVO

NOMBRE
DIFERENCIA
Diagrama de Clases
Son los más comunes en el modelado de sistemas orientados a objetos a diferencia de los otros que tienen mas aplicaciones
Diagrama de componentes
Prevalecen en el campo de la arquitectura de software a diferencia de los de clase y de objetos tiene otra aplicación y otra estructura.
Diagrama de Objetos
Están más completos que los diagramas de clases ya que incluyen tanto las clases como los objetos.
Diagrama de estructura compuesta
Aquí se muestra mas completo el desarrollo de algún sistema y su relación a diferencia de los otros.
Diagrama de despliegues
A diferencia del diagrama de componentes que evalúan o estudian el software estos analizas el hardware de un sistema.
Diagrama de paquetes
Los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema en general a diferencia de los de componentes y los de despliegue.

Diagrama de Actividades
Este muestra en general lo que ocurre en un sistema a diferencia de los otros que son más completos.
Diagrama de casos de uso
Son diagramas que son más fáciles de comprender y pueden ser mas accesibles que otros.
Diagrama de estados
Se enfocan principalmente en los cambios de algún objeto en particular.
Diagrama de secuencia
Se refieren a algo en general tanto en un caso de uso como en varios.
Diagrama de colaboraciones
Es un diagrama muy parecido a uno de secuencia solo que con otro tipo de estructura.
Diagrama de Tiempos
Muestra los cambios en un determinad tiempo tanto de un objeto como también lo puede hacer de varios.
Diagrama Global de Interacciones
Es una agrupación de los anteriores diagramas  y esto provoca que sea mas completo y mas útil en todos los sentidos.

CUADROS COMPARATIVOS

NOMBRE
DESCRIPCION
Diagrama de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Son los más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática.
Diagrama de componentes
Representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
Diagrama de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos.
Diagrama de estructura compuesta
Es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción a otras partes del sistema. Esto muestra la configuración y relación de las partes que juntas realizan el comportamiento de clasificador contenido.
Diagrama de despliegues
Es un diagrama que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y relaciones con sus componentes
Se usan mayormente en sistemas empotrados, sistemas cliente-servidor, sistemas completamente distribuidos
Diagrama de 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.
Diagrama de Actividades
Muestra una visión simplificada de lo que ocurre durante una operación o proceso, es una extensión del diagrama de estados. Cuenta con un punto inicial (representado por un círculo relleno) y uno final (representado por una diana).
Diagrama de casos de uso
Se emplean para visualizar el comportamiento de un sistema, un subsistema o una clase, de forma que los usuarios puedan comprender cómo utilizar ese elemento y de forma que los desarrolladores puedan implementarlo. Muestran un conjunto de casos de uso, actores y sus relaciones, estas pueden ser relaciones de inclusión o extensión.
Diagrama de estados
Muestra los estados en los que puede encontrarse un objeto junto con las transiciones entre dichos estados, mostrando los puntos inicial y final de la secuencia. Se enfoca en los cambios de estado de un solo objeto.
Diagrama de secuencia
Agrega la dimensión de tiempo a las interacciones entre objetos. Puede referirse a un escenario de un caso de uso o a todos los escenarios posibles.
Diagrama de colaboraciones
Forma alternativa de representar la información de un diagrama de secuencias Muestra las asociaciones entre objetos y los mensajes que se pasan del uno al otro..
Diagrama de Tiempos
Muestran el comportamiento de los objetos en un determinado periodo de tiempo. Se emplean para mostrar el cambio en el estado o valor de uno o más elementos tomando en cuenta el factor tiempo. Permite apreciar la interacción entre los eventos de tiempos, las restricciones de tiempo y la duración que los gobierna
Diagrama Global de Interacciones
Aportan una visión general del flujo de control de las interacciones en el sistema.- Utilizan la misma notación que para los diagramas de actividad (nodos inicial, final, decisión, combinación, bifurcación y unión son todos lo mismo), introduciendo dos elementos nuevos, ocurrencias de interacción y elementos de interacción

ANALISIS

Un Análisis de Sistema :

°°Identificar las necesidades del Cliente.

°°Evaluar que conceptos tiene el cliente del sistema para establecer su viabilidad.

°°Realizar un Análisis Técnico y económico.

°°Asignar  funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.

°°Establecer las restricciones de presupuestos y planificación temporal.

°°Crear una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.





Objetivo:


Con la informacion obtenida hacerca de las necesidades del cliente se podra seleccionar  mejor el calzado deacuerdo a sus gustos y necesidades para haci obtener mejores resultados en ventas.

ROLES Y RESPONSABILIDADES

Roles y responsabilidades en un procesos de venta de calzado


provedor: encargado de prover mercancia al vendedor

cliente: este es el que consume el calzado a la venta

vendedor: encargado de brindar un servicio al cliente

administrador: es la persona encargada del  funcionamiento del negocio





ACTIVIDADES DE UNA  ZAPATERIA

ºCompra de calzado

ºAtender las necesidades del cliente

ºVenta del calzado

ºSeguimento  de cobros y pagos puntuales

ºEnvios de calzado puntuales

FLUJOS PRINCIPALES Y ALTERNOS

FLUJO DE EVENTOS ALTERNATIVOS

En un caso de uso, los flujos de eventos se refieren a los pasos que alternativamente van realizando los actores y el sistema en el contexto del requisito funcional capturado en el caso. Dichos pasos por claridad, se separan en el flujo principal y los flujos alternativos; de forma tal que en el flujo principal representamos el día feliz, donde todo ocurre sin problemas y en los flujos alternativos lidiamos con las situaciones de error y el comportamiento esperado del sistema en respuesta a dichos errores.

Los pasos del flujo alternativo han de tener una enumeración propia de forma tal que no choquen los unos con los otros ni con los pasos del flujo principal. La forma exacta en que vamos a enumerar es cosa de cada quien, por lo que es un punto a documentar como parte del Plan de Gestión de Requisitos, documento este que suele ser parte del Plan de Desarrollo de Software.


FLUJO DE EEVNTOS PRINCIALES

Un flujo de eventos consiste en enumerar los pasos que sucesivamente realizan los actores y el sistema en el contexto de un caso de uso. Es decir, que un flujo de eventos es en su forma más básica un simple listado de acciones, que corresponden con un caso de uso en concreto.
Al flujo de eventos principal, ese que contiene el caso más probable, se le llama Flujo de Eventos del Día Feliz, como forma de hacer referencia a la ausencia de condiciones de error. En otras palabras, le llamamos día feliz ya que en este flujo de eventos principal vamos a asumir que todo ocurre de la mejor forma: el actor tiene disponible la información y la indica sin fallas, el sistema puede completar todas las operaciones y así sucesivamente para cada posible desviación. En el flujo del día feliz simplemente todo ocurre correctamente.

OBJETIVO DE CLASES UML

Herramientas CASE
 
Son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, documentación o detección de errores entre otras.
Sistema de software  proporcionan ayuda automatizada a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan como apoyo al método.
 
Objetivos

ººMejorar la productividad en el desarrollo  del software.

ººMejorar la productividad en el mantenimiento del software.

ººAumentar la calidad del software.

ººReducir el tiempo y costo de desarrollo del sistema.

ººReducir el tiempo y costo en el mamtenimiento del sistema.

ººAumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones.

ººAutomatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores  del proyecto.

ººAyuda a la reutilización del software, portabilidad y estandarización de la documentación .

ººFacilitar el uso de las distintas metodologías propias de la ingeniería del software

ººGestión global en todas las fases de desarrollo de software con una misma herramienta.

Definicion de caso de uso de UML

¿QUE ES UN CASO DE USO?

ººDescribe una interacción típica entre un usuario (actores) y un sistema de computo

ººEs una tecnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo de desea que trabaje

ººProduce algo de valor para algún actor como el cálculo de algún resultado.

ººDescribe que hace un sistema peo no especifica como lo hace.

ºº   Capta alguna función visible para el usuario

ºº   Puede ser pequeño o grande

ºº   Debe ser simple, claro y conciso



EN DONDE LO APLICAMOS:


Lo podemos aplicar para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento,como medio de comprensión del sistema para desarrollar, usuarios finales y expertos del dominio.