lunes, 1 de diciembre de 2014

Diagrama de estructuras

INTRODUCCIÓN
DIAGRAMAS DE ESTRUCTURA
Como ya lo dije estos temas no los hemos visto en clase, solo los vimos de forma rápida, pero aquí esta de forma detallada. En esta parte se aprende a usar cada uno de los diagramas y cuáles eran los beneficios que se obtienen al utilizar cada uno de estos diagramas, es bueno indicar de  que cada diagrama tiene su función, son importantes para ayudar a desarrollar un proyecto de software.
Consiste en cuadros rectangulares que representan a los módulos, junto con flechas para conectarlos.
Un diagrama de estructura fomenta el diseño descendente mediante el uso de módulos.

MARCO TEÒRICO
Diagrama de Clase
Para modelar clases, incluidos sus atributos, operaciones, relaciones y asociaciones con otras clases, el UML proporciona un diagrama de clase, que aporta una visión estática o de estructura de un sistema, sin mostrar la naturaleza dinámica de las comunicaciones entre los objetos de las clases.
Los elementos principales de un diagrama de clase son cajas, que son los íconos utilizados para representar clases e interfaces. Cada caja se divide en partes horizontales. La parte superior contiene el nombre de la clase. La sección media menciona sus atributos. Un atributo es algo que un objeto de dicha clase conoce o puede proporcionar todo el tiempo. Por lo general, los atributos se implementan como campos de la clase, pero no necesitan serlo. Podrían ser valores que la clase puede calcular a partir de sus variables o valores instancia y que puede obtener de otros objetos de los cuales está compuesto. Por ejemplo, un objeto puede conocer siempre lahora actual y regresarla siempre que se le solicite. Por tanto, sería adecuado mencionar la hora actual como un atributo de dicha clase de objetos. Sin embargo, el objeto muy probablemente no tendría dicha hora almacenada en una de sus variables instancia, porque necesitaría actualizar de manera continua ese campo. En vez de ello, el objeto probablemente calcularía la hora actual (por ejemplo, a través de consulta con objetos de otras clases) en el momento en el que se le solicite la hora. La tercera sección del diagrama de clase contiene las operaciones o comportamientos de la clase. Una operación es lo que pueden hacer los objetos de la clase. Por lo general, se implementa como un método de la clase.
La figura que se muestra a continuación presenta un ejemplo simple de una clase Thoroughbred (pura sangre) que modela caballos de pura sangre. Muestra tres atributos: mother (madre), father (padre) y birthyear(año de nacimiento). El diagrama también muestra tres operaciones: getCurrentAge() (obtener edad actual), getFather() (obtener padre) y getMother() (obtener madre); puede haber otros atributos y operaciones suprimidos que no se muestren en el diagrama.
Cada atributo puede tener un nombre, un tipo y un nivel de visibilidad. El tipo y la visibilidad son opcionales. El tipo sigue al nombre y se separa de él mediante dos puntos. La visibilidad se indica mediante un –, #, ~ o + precedente, que indica, respectivamente, visibilidad privada, protegida, paquete o pública. En la figura, todos los atributos tienen visibilidad privada, como se indica mediante el signo menos que los antecede (–). También es posible especificar que un atributo es estático o de clase, subrayándolo. Cada operación puede desplegarse con un nivel de visibilidad, parámetros con nombres y tipos, y un tipo de retorno.

Una clase abstracta o un método abstracto se indica con el uso de cursivas en el nombre del diagrama de clase. Vea, por ejemplo, la clase Horse (caballo) en la figura. Una interfaz se indica con la frase “<<interface>>” (llamada estereotipo) arriba del nombre. Vea la interfaz OwnedObject(objeto posesión) en la figura. Una interfaz también puede representarse gráficamente mediante un círculo hueco.
Los diagramas de clase también pueden mostrar relaciones entre clases. Una clase que seauna subclase de otra clase se conecta con ella mediante una flecha con una línea sólida ycon una punta triangular hueca. La flecha apunta de la subclase a la superclase. En UML, tal relación se llama generalización.
Una asociación entre dos clases significa que existe una relación estructural entre ellas. Las asociaciones se representan mediante líneas sólidas. Una asociación tiene muchas partes opcionales.
Puede etiquetarse, así como cada una de sus terminaciones, para indicar el papel de cada clase en la asociación.
Una asociación con una flecha en un extremo indica navegabilidad en un sentido. La flecha significa que, desde una clase, es posible acceder con facilidad a la segunda clase asociada hacia la que apunta la asociación; sin embargo, desde la segunda clase, no necesariamente puede accederse con facilidad a la primera clase. Otra forma de pensar en esto es que la primera clase está al tanto de la segunda, pero el segundo objeto de clase no necesariamente está directamente al tanto de la primera clase. Una asociación sin flechas por lo general indica una asociación de dos vías.
Una relación de dependencia representa otra conexión entre clases y se indica mediante una línea punteada (con flechas opcionales en los extremos y con etiquetas opcionales). Una clase depende de otra si los cambios en la segunda clase pueden requerir cambios en la primera. Una asociación de una clase con otra automáticamente indica una dependencia. No se necesitan líneas punteadas entre clases si ya existe una asociación entre ellas. Sin embargo, para una relación transitoria (es decir, una clase que no mantiene alguna conexión de largo plazo con otra, sino que usa dicha clase de manera ocasional), debe dibujarse una línea punteada desde la primera clase hasta la segunda.

Diagrama de Componentes
El diagrama de componentes muestra los componentes del sistema, como un archivode clase, un paquete, las bibliotecas compartidas, una base de datos, etcétera, y la forma en que se relacionan entre sí. Los componentes individuales en un diagrama de componentes se consideran con más detalle dentro de otros diagramas de UML, como los diagramas de clases y los diagramas de casos de uso.


En los diagramas de componentes se muestran los elementos de diseño de un sistema de software. Un diagrama de componentes permite visualizar con más facilidad la estructura general del sistema y el comportamiento del servicio que estos componentes proporcionan y utilizan a través de las interfaces. Para crear un diagrama de componentes UML, en el menú Arquitectura, haga clic en Nuevo diagrama.
Puede usar un diagrama de componentes para describir un diseño que se implemente en cualquier lenguaje o estilo. Solo es necesario identificar los elementos del diseño que interactúan con otros elementos del diseño a través de un conjunto restringido de entradas y salidas. Los componentes pueden tener cualquier escala y pueden estar interconectados de cualquier manera. 

Diagrama de Despliegue
El diagrama de despliegue ilustra la implementación física del sistema, incluyendo el hardware, las relaciones entre el hardware y el sistema en el que se va a desplegar. El diagrama de despliegue puede mostrar los servidores, estaciones de trabajo, impresoras, etcétera.

El Diagrama de despliegue es un diagrama estructurado que muestra la arquitectura del sistema desde el punto de vista del despliegue (distribución) de los los artefactos del software en los destinos de despliegue.


Usos
Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.
·         Sistemas cliente-servidor: Los sistemas Cliente-Servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.
·         Sistemas completamente distribuidos: En el otro extremo se encuentra aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores.
Ventajas
·         Muestra un conjunto de nodos y sus relaciones.
·         Se utilizan para describir la vista de despliegue estática de un sistema.
·         Se relacionan con los diagramas de componentes, ya que un nodo normalmente incluye uno o más componentes.
Desventajas
·         La posible falla en la modelación de un hardware.
·         Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro.El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.
Componentes
Nodo
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento.Un Nodo es un elemento de hardware o software.

CONCLUSIÓN
Los diagramas de clases muestran las características estáticas del sistema y no representan ningún procesamiento en especial. Un diagrama de clases también muestra la naturaleza de las relaciones entre las clases.
Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones.

Un diagrama de despliegue muestra la configuración de nodosque participan en la ejecución y de los componentes que residenen ellos.

BIBLIOGRAFÍA
Kendall, K.2011.ANÁLISIS Y DISEÑO DE SISTEMAS. Octava Edición.
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

Rubiano,M. 2012.DIAGRAMA DE DESPLIEGUE.(En Lìnea).Disponible en: http://es.scribd.com/doc/19808824/diagramas-de-despliegue-2222

Diagrama de flujo de Datos

INTRODUCCIÒN
En esta clase hicimos exposiciones, dichas exposiciones se realizaron de acuerdo a los grupos de proyecto de año. 
Los diagramas de flujos son una manera de personificar visualmente el flujo de datos a través de sistemas de tratamiento de información. Los diagramas de flujo refieren que operaciones  y en que secuencia se requieren para solucionar un problema planteado.
MARCO TEÒRICO
Niveles.
Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0"
Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un requisito funcional, siendo en realidad u requisito-no funcional.
Diagrama de Detalle o Expansión: Nivel 2
En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos.
El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama de nivel superior.
DIAGRAMA DE  FLUJO DE DATOS
Los diagrma de flujos  son una manera de representar visualmente el flujo de datos a través de sistemas de tratamiento de información. Los diagramas de flujo describen que operaciones  y en que secuencia se requieren para solucionar un problema dado.
Un diagrama de flujo u organigrama es una representación diagramática que ilustra la secuencia de las operaciones que se realizarán para conseguir la solución de un problema. Los diagramas de flujo se dibujan generalmente antes de comenzar a programar el código frente a la computadora. Los diagramas de flujo facilitan la comunicación entre los programadores y la gente del negocio. Estos diagramas de flujo desempeñan un papel vital en la programación de un problema y facilitan la comprensión de problemas complicados y sobre todo muy largos. Una vez que se dibuja el diagrma de flujo, llega a ser fácil escribir el programa en cualquier idioma de alto nivel. Vemos a menudo cómo los diagramas de flujo nos dan ventaja al momento de explicar el programa a otros. Por lo tanto, está correcto decir que un diagrama de flujo es una necesidad para la documentación mejor de un programa complejo.
MARCO TEÒRICO
Niveles.
Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0"
Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un requisito funcional , siendo en realidad un  requisito-no funcional.
Diagrama de Detalle o Expansión: Nivel 2
En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos.
El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama de nivel superior.
RESPECTO AL PROYECTO DE AÑO
TEMA:
APLICACIÓN WEB DE COTIZACIÓN Y COMPRAS VÍA ONLINE EN EL ASERRÍO Y FERRETERÍA “LA KAROLINA” DE LA CIUDAD DE CALCETA DEL CANTÓN BOLIVAR.

De acuerdo con nuestro tema de proyecto, procedimos a realizar el diagrama de flujo en nivel 0 y en nivel 1.
 
 

CONCLUSIÒN
El Nivel 0 o Diagrama de Contexto es aquel que muestra las entidades externas o terminadores con los que interactúa el sistema.
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal.
Es una  representación estructurada y gráfica que describe cómo marcha la información a través de un sistema y los diferentes procesos de transformación a los que se ve   sometida.
BIBLIOGRAFÍA
KENDALL, K. 2011. Análisis y Diseños de Sistemas: Diagramas de flujo de datos. Consultado, 03 de jul. 2014. Formato (PDF), octava. ed.
Fernández,C.2013. Diagrama de flujo de datos Nivel 0, 1 y 2.Disponible en :http://blogdecandyfernandez.blogspot.com/