miércoles, 22 de junio de 2011
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.
°°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
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
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.
ºº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.
Suscribirse a:
Entradas (Atom)