Está en la página 1de 16

METODOLOGIA ESTRUCTURADA

Herramientas:

Diagrama flujo de datos Diagrama de entidad relación Diagrama de estructura Diccionario de datos

Diagrama de Flujo de Datos (DFD)

Es una herramienta que permite visualizar un sistema como una Red de procesos funcionales,conectados entre sí. Describe la transformación de entradas a salidas en un diagrama.

Componentes de un DFD

Proceso

El proceso muestra una parte del sistema que transforma entradas en salidas. Gráficamente serepresenta con un circulo. La burbuja se debe describir con un nombre o frase. Es conveniente la

utilización de verbos y objetos

Flujo

METODOLOGIA ESTRUCTURADA Herramientas: Diagrama flujo de datos Diagrama de entidad relación Diagrama de estructura Diccionario de

Se representa gráficamente por una flecha que entra o sale de un Proceso. Se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Los flujos representan datos en movimientos. La flecha cuenta con puntas que indican la dirección de la misma e indica básicamente si los datos(material) se están moviendo hacia adentro o hacia afuera de un proceso (o ambas cosas), este el caso que en el flujo se produce un dialogo. Debe existir la precaución de nombrar con exactitud los flujos, debido a que dos flujos pueden tener el mismo contenido, pero distinto significado.

METODOLOGIA ESTRUCTURADA Herramientas: Diagrama flujo de datos Diagrama de entidad relación Diagrama de estructura Diccionario de

Almacén

Se utiliza para modelar una colección de paquetes de datos en reposo. Gráficamente se representa con dos líneas paralelas. Normalmente la tendencia es asociar el Almacén con Archivo y/o Base de datos. De hecho es así como se implementan los almacenes en un sistema. Los almacenes se conectan por flujos a los procesos. El contexto en que se muestra un Almacén en DFD, son algunos de estos o ambos:

• Un flujo desde un almacén (lectura)

• Un flujo hacia un almacén (actualización) La lectura o acceso al almacén significa:

• Se recupera del almacén un solo paquete (registro de un Cliente). • Varios paquetes que cumplen con cierta condición. • Una porción del paquete. • Varias porciones de más de un paquete.

Entidad

Gráficamente se representa con un rectángulo. Comúnmente una Entidad es una persona, un departamento, un grupo, que están dentro o fuera de la organización. La entidad puede ser otro sistema con la cual existe una comunicación (retroalimentación). Al representar una Entidad se debe tener en cuenta que:

• La Entidad es externa al sistema que se está modelando. Los flujos que conectan entidades con procesos o almacenes, indican una interfaz entre él y el mundo externo. • El analista no puede modificar los contenidos, la organización, ni los procedimientos internos asociados con las entidades. • Las relaciones que pudieran existir entre las entidades, no se reflejan en un DFD (no son partes del sistema que se está estudiando). Si la relación que existe entre entidades es esencial para el analista y éste necesita modelarlas para poder documentar los requerimientos del sistema, entonces, las Entidades son en realidad parte del sistema y deberán ser modeladas como Procesos.

• Un flujo hacia un almacén (actualización) La lectura o acceso al almacén significa: • Se

Diagramas de Entidad -Relación

El diagrama de entidad-relación (también conocido como DER, o diagrama E-R) es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.

¿Porque podríamos estar interesados en modelar los datos de un sistema?. Primeramente, porque las estructuras de datos y las relaciones pueden ser tan complejas que se deseará enfatizarlas y examinarlas independientemente del proceso que se llevará a cabo. De hecho, esto se da sobre todo si mostramos el modelo del sistema correspondiente a los usuarios ejecutivos quienes se preocupan más por los datos: ¿Qué dato requerimos para manejar nuestro negocio? ¿Quién lo tiene? ¿Quién tiene acceso a ellos?.

Para el analista, el DER representa un gran beneficio: porque enfatiza las relaciones entre almacenes de datos en el DFD que de otra forma se hubiera visto sólo en la especificación de procesos. Por ejemplo, un DER típico se muestra en la figura 4.2.1 Cada una de las cajas rectangulares corresponden a un almacén de datos en DFD y puede verse que hay relaciones que normalmente no se aprecian en un DFD.

Para el analista, el DER representa un gran beneficio: porque enfatiza las relaciones entre almacenes de

Figura 4.2.1: Diagrama de entidad-relación típico.

Hay cuatro componentes principales en un diagrama de entidad- relación:

Tipos de objetos.

Relaciones.

Indicadores asociativos de tipo de objeto.

Indicadores de supertipo/subtipo.

Tipos de objetos

El tipo de objeto se representa en un diagrama de entidad-relación por medio de una caja rectangular; en la figura 4.2.2 se muestra un ejemplo. Representa una colección de objetos (cosas) del mundo real cuyos miembros individuales o instancias tienen las siguientes características:

Cada una puede identificarse de manera única por algún medio. Por ejemplo, si se tiene un tipo de objeto conocido como cliente, debemos ser capaces de distinguir uno de otro (tal vez por un número de cuenta, por su apellido, o por su número de Seguro Social).

Para el analista, el DER representa un gran beneficio: porque enfatiza las relaciones entre almacenes de

Figura 4.2.2: Un tipo de objeto

Cada uno juega un papel necesario en el sistema que se construye. Es decir, para que el tipo de objeto sea legítimo, debe poder decirse que el sistema no puede operar sin tener acceso a esos miembros.

Cada uno puede describirse por uno o más datos. Es decir, un cliente puede describirse por medio de datos tales como nombre, domicilio, límite de crédito y número telefónico.

En muchos de los sistemas que desarrolle, los tipos de objetos serán la representación del sistema de algo material del mundo real. Esto significa que los clientes, artículos de inventario, empleados, partes manufacturadas, etc., son objetos típicos. El objeto es algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo, un objeto pudiera ser algo no material: por ejemplo, horarios, planes, estándares, estratégias y mapas.

Una persona (o cualquier cosa material) pudiera ser diversos tipos de objetos distintos en distintos modelos de datos, o incluso en un mismo modelo. Juan Pérez, por ejemplo puede ser empleado en un modelo de datos y cliente en otro. También pudiera ser empleado y cliente dentro del mismo modelo.

Relaciones

Una relación representa un conjunto de conexiones entre objetos, y se representa por medio de un rombo. La figura 4.2.3 muestra una relación sencilla, que pudiera existir entre dos o más objetos.

Cada uno puede describirse por uno o más datos. Es decir, un cliente puede describirse por

Figura 4.2.3: Una relación

Cada instancia de la relación representa una asociación entre cero o más ocurrencias de un objeto y cero o más ocurrencias del otro. Así, en la figura 4.2.3, la relación etiquetada como compras puede contener las siguientes instancias individuales:

Instancia 1: el cliente 1 compra el artículo 1

Instancia 2: el cliente 2 compra los artículos 2 y 3.

Instancia 3: el cliente 3 no compra ningún artículo.

La relación representa algo que debe ser recordado por el sistema:

algo que no pudo haberse calculado ni derivado mecánicamente. Así, el modelo de datos de la figura 4.2.3 indica que existe alguna razón relacionada con el usuario para recordar el hecho de que el cliente 1 compra el artículo 1, etc. Y también indica que no existe nada prioridad que hubiera permitido determinar que el cliente 1 compró el artículo 1 y nada más.

Notación alternativa para relaciones

El diagrama E-R son multidireccionales, esto es, puede leerse siguiendo cualquier dirección. Y no muestran cardinalidad, es decir, no muestran el número de objetos que participan en la relación.

Una notación alternativa utilizada por algunos analistas muestra tanto la cardinalidad como la ordinalidad.

Indicadores asociativos de tipo de objeto

El indicador asociativo de tipo de objeto representa algo que funciona como objeto y como relación. Por ejemplo, un cliente que adquiere un artículo. En donde la relación de compra no hace más que asociar un cliente con uno o más artículos. Pero suponga que existen datos que deseamos recordar acerca de cada instancia de una compra (por ejemplo a qué hora del día se hizo). ¿Dónde se podría almacenar dicha información? "Hora del día" no es un atributo de cliente, ni de artículo. Más bien, se asocia "Hora del día" con la compra misma, y esto se muestra en un diagrama como el que ilustra la figura 4.2.5.

El diagrama E-R son multidireccionales, esto es, puede leerse siguiendo cualquier dirección. Y no muestran cardinalidad,

Figura 4.2.5:Indicador asociativo de tipo objeto

Nótese que compra ahora se escribe dentro de una caja rectangular conectada por medio de líneas dirigidas, a un rombo de relación sin nombre. Esto pretende indicar que compra funciona como:

Un

tipo

de objeto,

algo acerca

de

lo

cual

se desea almacenar

información. En este caso la hora en la cual se realizó la compra y el

descuento, que se dio al cliente.

Una relación que conecta los dos tipos de objetos cliente y artículo. Lo que significa aquí es que cliente y artículo se mantienen solo. Existirían con o sin la compra.

Indicadores de subtipo/supertipo

Los tipos de objetos de subtipo/supertipo consisten en tipos de objeto de una o más subcategorías, conectados por una relación. La figura 4.2.6 muestra un subtipo /supertipo típico: la categoría general es empleado y las subcategorias son empleados asalariados y empleado por horas. Nótese que los subtipos se conectan al supertipo por medio de una relación sin nombre. Note también que el supertipo se conecta con una línea que contiene una barra

Figura 4.2.6:Indicador de subtipo/supertipo Reglas para la construcción de diagramas de Entidad- Relación. El primer DER

Figura 4.2.6:Indicador de subtipo/supertipo

Reglas para la construcción de diagramas de Entidad- Relación.

El primer DER típicamente se creará a apartir de entrevista iniciales con el usuario, y de su conocimiento de la materia en cuanto al negocio del usuario. Después de desarrollar el primer DER, el siguiente paso es asignar los datos del sistema a los diversos tipos de objetos. Se supone, que se sabe cuales son los datos. Esto puede suceder en cualquier de tres maneras:

  • 1. Si el modelo del proceso (DFD) ya se ha desarrollado o se está

desarrollando paralelamente al modelo de datos, entonces el

diccionario de datos ya existirá.

  • 2. Si el modelo del proceso no se ha desarrollado o no tiene intención

de desarrollar, entonces pudiera tener que empezar por entrevistar a todos los usuarios apropiados para construir una lista exhaustiva de datos y sus definiciones.

  • 3. Si está trabajando con un grupo de administración de datos, hay

una buena probabilidad de que ya exista un diccionario de datos, que

podría obtener durante el proyecto.

Diccionario de Datos (DD)

El Diccionario de Datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos intermedios. El Diccionario de datos define los datos haciendo lo siguiente:

• Describe el significado de los flujos y almacenes que se muestran en los DFD. • Describe la composición de almacenes (paquetes).

• Especifica los valores y unidades relevantes de piezas elementales de información de los flujos de datos y en los almacenes de datos. • Describe los detalles de las relaciones entre almacenes en un diagrama de Relación- Entidad.

Contenido de un Diccionario de Datos

Elemento de Datos La información mínima necesaria para definir un elemento de datos es su nombre y su descripción.

El nombre debe elegirse de manera tal que tenga la mayor significación posible para el usuario. La descripción podrá ser un breve esbozo del significado del elemento de datos y puede incluir un típicoejemplo. Para definir por completo un dato, debe incluir:

• Significado: dentro del contexto de la aplicación • Composición: si se compone de partes elementales con significado • Tipo de dato. Adicionalmente se podrá registrar:

Alias de elementos de datos. Aparecen debido a que varios distintas áreas de la organizacióndenominan a un mismo objeto con nombres diferentes

Elementos de datos relacionados. Son elementos de datos que representan distintas características de un mismo objeto.

Rango de los valores y significado de los valores. Son datos continuos cuando el elemento de datos puede tomar cualquier valor dentro de un rango determinado; y datos discretos cuando solo puede tomar determinados valores.

• Longitud. Especificar la longitud del dato (o posible rango de

longitudes). • Codificación. Se debe registrar en el diccionario de datos la forma en que el elemento de datos serácodificado físicamente en el sistema

Otras

informaciones

de

validación.

consistencia, congruencia, etc.

Rutinas de validación,

Diagrama de Estructura

Los diagramas de estructura (DE) sirven para el modelamiento top- down de la estructura de control de un programa descripto a través de un árbol de invocación de módulos. Un diagrama de estructura permite modelar un programa como una jerarquía de módulos. Cada nivel de la jerarquía representa una descomposición más detallada del módulo del nivel superior. La notación usada se compone básicamente de tres símbolos:

• Módulos • Invocaciones • Cuplas

Módulos

Un módulo es un conjunto de instrucciones que ejecutan alguna actividad, un procedimiento o función en PASCAL, una función en C o un parágrafo en COBOL. Tal vez, la definición más precisa es que un módulo es una caja negra, pero como será mostrado a continuación son cajas “casi” negras o grises. Desde un punto de vista práctico, un módulo es una colección de instrucciones de un

programa con cuatro características básicas:

  • 1. Entradas y Salidas: lo que un módulo recibe en una invocación y lo

que retorna

como resultado.

  • 2. Función: las actividades que un módulo hace con la entrada para

producir la salida.

  • 3. Lógica Interna: por la cual se ejecuta la función.

  • 4. Estado Interno: su área de datos privada, datos para los cuales sólo

el módulo hace referencia. Las entradas y salidas son, respectivamente, datos que un módulo necesita y produce. Una función es la actividad que hace un módulo para producir la salida. Entradas, salidas y funciones proveen una visión externa del módulo. La lógica interna son los algoritmos que ejecutan una función, esto es, junto con su estado interno representan la visión interna del módulo. Un módulo es diseñado como una caja, su función es representada

por un nombre en el interior y las entradas y salidas de un módulo son representadas por pequeñas flechas que entran y salen del módulo. Cuando una función o un procedimiento, en un lenguaje convencional, es invocado, comúnmente un conjunto de argumentos es comunicado y, en el caso de las funciones,también se espera que retorne un resultado. Estos datos comunicados en una invocaciónson modelados por medio de flechas, sobre el símbolo de invocación, llamadas cuplas. Cupla de Datos

Una cupla de datos transporta datos “puros” a un módulo. No es necesario conocer la lógica interna del módulo receptor, para determinar los valores válidos de la cupla (ej.: número de cuenta, saldo,tabla de movimientos)

Invocaciones. Las invocaciones entre modulos se realizan por medio de las cuplas, estas invocaciones se pueden escribir sobre la cupla que se este utilizando.

METODOLOGIA OO Para poder modelar un sistema se utilizan los diagramas de UML Siendo:

Diagrama de objetos Diagrama de clases Diagrama de casos de uso Diagrama de interacción Diagrama de secuencia Diagrama de colaboración Diagrama de estado

Diagrama de actividades Diagrama de componentes Diagrama de despliegue.

DIAGRAMA DE OBJETOS.

Un objeto es una representación de una entidad, ya sea real o conceptual, con límites bien definidos y con significado dentro de un modelo. Cada objeto en un modelo se caracteriza por su estado, su comportamiento y su identidad. El estado de un objeto es una de las posibles condiciones bajo las que el objeto puede existir. El estado de un objeto cambia con el tiempo y está definido por un conjunto de propiedades (atributos), por los valores de esas propiedades y por las relaciones que dicho objeto puede tener con otros objetos.

Un diagrama relaciones.

de objetos

muestra un conjunto

de objetos

y

sus

Su notación se presenta de la sig manera:

 
Diagrama de actividades Diagrama de componentes Diagrama de despliegue. DIAGRAMA DE OBJETOS. Un objeto es unaClase : Nombre de la clase, atributos, métodos. ∑ Relaciones : Herencia, Composición, Agregación, Asociación y Uso y de composicion. Elementos ∑ Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones: " id="pdf-obj-8-24" src="pdf-obj-8-24.jpg">
 

(verbo)

objeto

DIAGRAMA DE CLASES

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 contenido.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase : Nombre de la clase, atributos, métodos. Relaciones : Herencia, Composición, Agregación, Asociación y Uso y de composicion.

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

En donde: Superior : Contiene el nombre de la Clase o Intermedio : Contiene los atributos

Superior: Contiene el nombre de la Clase o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).

o

o Inferior: Contiene los métodos u operaciones, los cuales

son la forma como interactúa el objeto con su entorno

(dependiendo de public).

la

visibilidad: private, protected o

o

Atributos:

 

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

 

public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-,): Indica

que

el

atributo

sólo

será

 

accesible desde dentro de la clase (sólo sus

métodos lo pueden accesar).

 
 

protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

o

Métodos:

 

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

public (+,): Indica que el método será visible tanto

dentro como fuera de la clase, es decir, es accsesible desde todos lados. private (-,): Indica que el método sólo será

accesible desde dentro

de

la

clase

(sólo

otros

métodos de la clase lo pueden accesar).

 

protected

(#,): Indica

que

el método

no

será

accesible desde fuera de la clase, pero si podrá ser

accesado por

métodos

de

la

clase

además

de

métodos

de

las

subclases

que

se deriven

(ver

herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

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:

Agregación:

Esta relación

sirve para

indicar

cuando

una

clase se

agrega a otra

clase, por ejemplo la clase

mantel se

le

agrega a la clase mesa y cada una existe por separado

pero para dar un servicio se agregan las clases.

Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. 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 (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.

Composicion:

Es una relación de cuando una clase compone a otra es decir que sin esa clase entonces no podría existir. Ejem:

Una mesa. La mesa sin las patas no seria mesa es decir que la clase mesa se compone de la clase patas.

DIAGRAMA DE CASOS DE USO.

Los casos de uso son una técnica para especificar el comportamiento de un sistema:

“Un caso de uso es una secuencia de interacciones entre un sistema

y alguien o algo que usa alguno de sus servicios.”

Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresando pedido. Actores

Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema queestamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en formatelefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un único actor: Empleado de Ventas. Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamosempezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema a debe ser el primerobjetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos. Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que unusuario es una persona que, cuando usa el sistema, asume un rol. Otro sistema que interactúa con el que estamos construyendo también es un actor. Por ejemplo, si nuestrosistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este últimosistema será un actor, que usa los servicios de nuestro sistema. También puede ocurrir que el actor sea una máquina, en el caso en que el software controle sus movimientos, o sea operado por una máquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un robot, el hardware del robot será un actor, asumiendo que dentro de nuestro sistema están las rutinas de bajo nivel que controlan al hardware. Los actores se representan con dibujos simplificados de personas, llamados en inglés “stickman” (hombres de palo). Las flechas, pueden usarse para indicar el flujo de información entre el sistema y el actor. Si la flecha apunta desde el actor hacia el sistema, esto indica que el actor está ingresando información en el

sistema. Si la flecha

apunta

desde el sistema

hacia

el actor,

el

sistema está generando información para el actor.

Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Relaciones de Extensión

Muchas veces, la funcionalidad de un caso de uso incluye un conjunto

de pasos que ocurren sólo en algunas oportunidades. Se representa

con una flecha del caso de uso principal hacia el caso de uso que se extiende.

Relaciones de Uso

Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Se representa por del caso de uso que se usa hacia el caso de uso principal Ambas relaciones son con una línea descontinua.

DIAGRAMAS DE INTERACCION

Diagrama de Secuencia:representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Objeto/Actor/Clase:

∑ Objeto/Actor/Clase : El rectángulo representa una instancia de un Objeto en particular, y la línea

El rectángulo representa una

instancia

de

un

Objeto

en

particular, y la línea punteada representa las llamadas a

métodos del objeto.

Mensaje a Otro Objeto:

∑ Objeto/Actor/Clase : El rectángulo representa una instancia de un Objeto en particular, y la línea

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

DIAGRAMA DE COLABORACIÓN

Así mismo, se cuenta con el diagrama de colaboración, el cual se centra tanto en las interacciones y las ligas entre un conjunto de objetos colaborando entre ellos (una liga es una instancia de una asociación). Ambos, el diagrama de secuencia y el diagrama de colaboración, muestran interacciones, pero el diagrama de secuencia se centra en el tiempo mientras que el diagrama de colaboración se centra en el espacio. Las ligas muestran los objetos actuales y cómo ellos se relacionan unos con otros. Así como los diagramas de secuencia, los diagramas de colaboración pueden ser utilizados para ilustrar la ejecución de una operación, una ejecución de un use-case o simplemente un escenario de interacción dentro del sistema. En este diagrama también se representa a los objetos en cajas rectangulares y con el nombre subrayado. Las ligas se dibujan con líneas y se puede agregar una etiqueta para un mensaje y un número que define la secuencia de las ligas.

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a

DIAGRAMA DE ESTADO (DE UN OBJETO)

Los diagramas de estados son una técnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a él. En la mayor parte de las técnicas OO, los diagramas de

estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.

Inicio

Estado

Final

estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo
estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo
estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo

DIAGRAMA DE ACTIVIDADES.

Representa el comportamiento interno de una operación o de un estado de un objeto, bajo la forma de desarrollo por etapas, agrupadas secuencialmente. El propósito del diagrama de actividad es: Modelar el flujo de tareas o las actividades para alcanzar el estado de un objeto.

Actividad Nombre diagrama Clase::Operación

Estado de Acción

Transición o flujo

activid

ad

estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo

Barras de sincronización o de bifurcación

estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo

Nodo de decisión

estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo

Calles

Inicio y Fin

estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo

DIAGRAMA DE COMPONENTES.

Un componente es una parte física y reemplazable de un sistema, conforma con un conjunto de interfaces y realiza esas interfaces.

Este

diagrama

como

su

nombre

lo

indica

muestra

todos

los

componentes o sistema.

elementos

de

sw

que

se utilizan

dentro

de

un

El símbolo principal de un diagrama de componentes es un rectángulo que tiene otros dos sobrepuestos en su lado izquierdo, con el nombre del componente dentro del rectángulo más grande, como se muestra en la siguiente figura:

Un componente es una parte física y reemplazable de un sistema, conforma con un conjunto de

El diagrma de componentes

también considera agrupar los

componentes mediante portafolios en el cual se puede etiquetar en el

portafolio el nombre de la aplicación y mostrar los componentes de esa aplicación.

DIAGRAMA DE DESPLIEGUE.

Es un diagrama que a diferencia del diagrama de componentes muestra los elementos de hardware de un sistema y se representa mediante un nodo.

Un componente es una parte física y reemplazable de un sistema, conforma con un conjunto de

Complementelo con sus notas.

Mucha Suerte!!!!!