DIAGRAMA DE SECUENCIA

DIAGRAMA DE ACTIVIDADES

DIAGRAMA DE PAQUETES

DIAGRAMA DE ESTRUCTURA

DIAGRAMA DE DESPLIEGUE

DIAGRAMA DE COMPONENTES Y DESPLIEGUE

DIAGRAMA DE CLASES

VIDEO CASOS DE USO

DIAGRAMA DE COMPONENTE

MAPA CONCEPTUAL



DIAGRAMA DE OBJETOS "LOTERIA"

DIAGRAMA DE CLASES "BASE DE DATOS UNIVERSIDAD"

GUIA PARA USAR LA BASE DE DATOS ECOPEBASE

MANTENIMIENTO DEL SOFTWARE

El mantenimiento de software o manutención de software de la base de datos es una de las actividades más comunes en la ingenieria de software, es el proceso de mejora y optimización del software después de su entrega al usuario final (es decir; revisión del programa), así como también correccion y prevención de los defectos.
El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en inglés de system development life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.

El mantenimiento del software es la totalidad de las actividades necesarias para proporcionar soporte económico (cost-effective) al sistema software. Estas actividades se desarrollan tanto antes como después de la entrega. Las actividades previas a la entrega incluyen la planificación de las operaciones posteriores a la entrega, planificación del soporte y determinación de la logística. Las actividades posteriores a la entrega incluyen la modificación del software, la formación de usuarios, y la operación de un help desk.

Como se ve, hay una diferenciación en las diferentes definiciones entre actividades pre- y post- entrega del software. Para clarificar los conceptos, en esta obra diferenciaremos entre: actividades de mantenimiento propiamente dichas (posteriores a la entrega) y actividades de preparación para el mantenimiento.

El criterio para diferenciarlo de otras actividades es el hecho de la entrega del producto software. Se debe tener en cuenta que en ocasiones esa entrega es un acto formal dentro de un contrato, pero en muchas otras es una simple decisión de disponibilidad pública de un grupo de desarrollo. Por ejemplo, en los proyectos de fuente abierto, desarrollados de manera voluntaria, el qué es una entrega lo determinan los propios desarrolladores cuando piensan que la funcionalidad implementada ha llegado a un determinado nivel.

La guía SWEBOK2 considera que el mantenimiento ocurre durante todo el ciclo de vida, y coincide en su definición con la de Pigoski antes mencionada.

Es importante resaltar que el concepto de mantenimiento del software difiere de la concepción de mantenimiento en otras disciplinas de ingeniería. Esto es debido a que el software no se “deteriora” con el uso. En la ingeniería mecánica, el mantenimiento consiste en las acciones de reparación necesarias para que la máquina o sistema mecánico siga funcionando. En la Ingeniería del Software, el mantenimiento tiene un significado más amplio, cubriendo su adaptación a necesidades

TODO LO RELACIONADO CON: EVALUACIÓN DEL SISTEMA.

La Evaluación del Sistema:

Se lleva a cabo para identificar puntos débiles y fuertes del Sistema implantado. La evaluación ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones:

• Evaluación operacional:

Es el Momento en que se evalúa la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la Información, contabilidad global y su nivel de Utilidad.

• Impacto Organizacional:

Identifica y mide los beneficios operacionales para la Empresa en áreas tales como, Finanzas (Costos, Ingresos y Ganancias), eficiencia en el desempeño laboral e impacto competitivo, Impacto, rapidez y organización en el flujo de Información interna y externa.

• Desempeño del Desarrollo.

Es la evaluación del Proceso de desarrollo adecuado tomando en cuentas ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con presupuesto y estándares y otros criterios de Administración de Proyectos.

Además se incluyen la valoración de los métodos y herramientas utilizados durante el desarrollo del Sistema.

DEFINICIÓN DE CAPACITACIÓN DE USUARIOS DEL SISTEMA, QUE OTROS SERVICIOS DE CAPACITACIÓN EXISTEN Y CUALES SON SUS OBJETIVOS.

Definición de capacitación:

Es enseñar a los usuarios que se relacionan u operan en un proceso de implantación.

La Responsabilidad de esta capacitación de los Usuarios primarios y secundarios es del Analista, desde el personal de captura de datos hasta aquellos que toman las decisiones sin usar una Computadora.

No se debe incluir a personas de diferentes niveles de habilidad e intereses de trabajo; debido a que si en una Empresa existen trabajadores inexpertos no se pueden incluir en la misma sección de los expertos ya que ambos grupos quedaran perdidos.

“Es como querer conducir dos Barcos con diferentes destinos con un mismo Mapa de  rutas o con el mismo timón”.

Otros servicios de capacitación:

Vendedores: Son aquellos que proporcionan capacitación gratuita fuera de la Empresa de uno o dos días.

Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de las computadoras pero para algunos usuarios esta no es una capacitación necesaria.

Instructores en casa: Están familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltaría experiencia en Sistemas de Información que es realmente la necesidad del usuario.

Objetivos:

Es lograr que los usuarios tengan el Dominio necesario de las cosas básicas acerca de las maquinarias y procesos que se emplean para su operación de manera eficiente y segura.

DEFINICION DE IMPLANTACIÓN, ENUMERE LOS ENFOQUES DE IMPLEMENTACIÓN

La implementación: es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un análisis y diseño previo como resultado de la sustitución o mejoramiento de la forma de llevar a cabo un proceso automatizado.

Al Implantar un Sistema de Información lo primero que debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios puedan operarlo.

Existen varios enfoques de Implementación:

• Es darle responsabilidad a los grupos.
• Uso de diferentes estrategias para el entrenamiento de los usuarios.
• El Analista de Sistemas necesita ponderar la situación y proponer un plan de conversión que sea adecuado para la organización.
• El Analista necesita formular medidas de desempeño con las cuales evaluar a los Usuarios.
• Debe Convertir físicamente el sistema de información antiguo, al nuevo modificado.

En la preparación de la Implantación, aunque el Sistema esté bien diseñado y desarrollado correctamente su éxito dependerá de su implantación y ejecución por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento.

9. DISEÑE LA INTERFAZ DE ENTRADA Y LA INTERFAZ DE SALIDA DE SU PROYECTO

Interfaz de entrada

Interfaz de salida

¿CUÁLES SON LOS PASOS PARA LA EVALUACIÓN DEL DISEÑO?

Evaluación del diseño

La evaluación de la interfaz del usuario es un ciclo iterativo que se resume en los siguientes pasos:

1)     Diseño preliminar

2)    Construcción del primer prototipo de la interfaz

3)    El usuario valida la interfaz

4)    El diseñador estudia la evaluación

5)    Se realizan cambios en el diseño

6)    Construcción del siguiente prototipo

7)    Si la interfaz no está completa se regresa al paso 3.

¿QUE DEBE REALIZAR UN ANALISTA PARA EL DISEÑO DE SALIDA?

• Determine qué información presentar. Decidir si la información será presentada en forma visual, verbal o impresora y seleccionar el medio de salida.
• Disponga la presentación de la información en un formato aceptable.
• Decida cómo distribuir la salida entre los posibles destinatarios.

COHESION

La cohesión es una medida de la fuerza funcional relativa de  un módulo, es decir, su interés es determinar qué tan cercanamente relacionados están los elementos de un módulo unos con otros.

ENUMERE LOS PRINCIPALES ATRIBUTOS DE CALIDAD A EVALUAR EN UN SISTEMA.

• Correcto
• Eficiente
• Mantenible
• Eficiente en costos

DESCRIBA LAS ACTIVIDADES DEL DISEÑO CLASICO.

• El diseño clásico consiste en tres actividades:
• El diseño de la arquitectura (conocido también como el diseño lógico o diseño de alto nivel).
• Diseño detallado (conocido como diseño de módulos, diseño físico o diseño de alto nivel).
• Diseño de las pruebas.

DEFINICION DE DISEÑO DE SOFTWARE

El diseño es la fase del proceso del desarrollo del software "donde se crea una presentación o modelo del software. a diferencia del análisis donde se describen los datos y funciones requeridos, el modelo del diseño proporciona lo detalles acerca de las estructuras de los datos, las arquitecturas , las interfaces  y  los componentes del software  necesarios para implementar el sistema”  (Pressman, 2005). 

2. DISEÑAR UN LOGO DE LA EMPRESA CREADA O DEL SOFTWARE A RELIZAR COMO PROYECTO.

DIAGRAMA DE COMPORTAMIENTO " 4. DIAGRAMA DE INTERACCION" "d. DIAGRAMA GLOBAL "

El diagrama global de las interacciones es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades.

Los modelos de interacción pueden llegar a ser muy grandes para sistemas complejos. Si el número de líneas de vida participantes y el número de mensajes intercambiados exceden una cierta medida, se impone “modularizar” las interacciones y dividir en partes pequeñas, más manejables, de acuerdo a principios universales del diseño de sistemas, que también pueden ser visualizadas con la ayuda de un clásico diagrama de secuencias. La visión de conjunto de toda la interacción, de manera que la Big Picture o bien el cuadro global, puede entonces ser representada con la ayuda del diagrama global de las interacciones, provisto para eso.

DIAGRAMA DE COMPORTAMIENTO " 4. DIAGRAMA DE INTERACCION" "c. DIAGRAMA DE TIEMPOS "

Un diagrama de tiempos o cronograma es una gráfica de formas de onda digitales que muestra la relación temporal entre varias señales, y cómo varía cada señal en relación a las demás.

Un cronograma puede contener cualquier número de señales relacionadas entre sí. Examinando un diagrama de tiempos, se puede determinar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes.

El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.

En el estándar de Lenguaje de Modelado Unificado de OMG los diagramas de tiempo son una representación especial de interacción que se enfoca en el tiempo de los mensajes enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones detalladas sobre el tiempo, ó para mostrar los cambios con líneas de vida respecto al tiempo. Los diagramas de tiempo son generalmente utilizados con sistemas en tiempo real o en sistemas embebidos.

DIAGRAMA DE COMPORTAMIENTO " 4. DIAGRAMA DE INTERACCION" "b. DIAGRAMA DE COMUNICACION "

Diagrama de comunicación es una versión simplificada del diagrama de colaboración de la versión de UML 1.x.

Un diagrama de comunicación modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.

Los diagramas de comunicación y de secuencia describen información similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad.

Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son etiquetados con un número cronológico y colocado cerca del enlace por el cual se desplaza el mensaje. Leer un diagrama de comunicación conlleva comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto hasta el siguiente, sucesivamente.

DIAGRAMA DE COMPORTAMIENTO " 4. DIAGRAMA DE INTERACCION" "a. DIAGRAMA DE SECUENCIA"

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"

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. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

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.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

• De instancia: describe un escenario especifico (un escenario es una instancia de la ejecución de un caso de uso).
• Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

DIAGRAMA DE COMPORTAMIENTO " 4. DIAGRAMA DE INTERACCION"

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

DIAGRAMA DE COMPORTAMIENTO " 3. DIAGRAMA DE ESTADO"

Diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.

Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.

El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.

Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.

Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

DIAGRAMA DE COMPORTAMIENTO " 2. DIAGRAMA DE CASOS DE USO"

Los Diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

Este tipo de diagramas describe cómo se usa el sistema, partiendo desde el punto de vista del usuario final . Esto da una buena pauta para conocer más a fondo los requisitos  que deberá tener el sistema a desarrollar. Debe tenerse el cuidado de no confundir la palabra "cómo", cuando se dice los diagramas de caso de uso describen "cómo se usa el sistema". Esto se refiere al "cómo" desde el punto de vista de los pasos que se van a realizar por parte del usuario final, y no al "cómo" del procedimiento técnico que se va a utilizar para dar solución  a un problema o caso específico.

El objetivo de este tipo de diagramas es mostrar la manera en la que un usuario final va a interactuar con el sistema a desarrollar, sin preocuparse por la forma en la que se va a lograr implementar eso, técnicamente hablando, es decir, sin tomar en cuenta los mecanismos que se van a utilizar para crear o hacer funcionar el sistema.

SIMBOLOGIA

DIAGRAMA DE COMPORTAMIENTO " 1. DIAGRAMA DE ACTIVIDADES"

Diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.

En UML 1.x, un diagrama de Actividades es una variación del Diagrama de estados UML donde los "estados" representan operaciones, y las transiciones representan las actividades que ocurren cuando la operación es completa..

El diagrama de Actividades UML 2.0, mientras que es similar en aspecto al diagrama de Actividades UML 1.x, ahora tiene semánticas basadas en redes de Petri. En UML 2.0, el diagrama general de Interacción está basado en el diagrama de Actividades.

Diagrama de actividad. Es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso.

La especificación del Lenguaje de Modelado Unificado UML define un diagrama de actividad como: “… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realización de las acciones o subactividades.” ^[1] El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones. Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz. Una Interfaz es un grupo de operaciones relacionadas con la semántica.

DIAGRAMA DE ESTRUCTURAS " 6. DIAGRAMA DE PAQUETES"

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.

Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

DIAGRAMA DE ESTRUCTURAS " 5. DIAGRAMA DE DESPLIEGUE"

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Usos

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

• 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 encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. 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.

DIAGRAMA DE ESTRUCTURAS " 4. DIAGRAMA DE ESTRUCTURA COMPUESTA"

Un diagrama de estructura compuesta  muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.

Conceptos de estructura compuesta.

Las entidades de estructura compuesta claves identificadas en la especificación UML 2.0 son: clasificadores estructurados, partes, puertas, conectores, y colaboraciones.

Parte

Una parte representa un rol jugado en tiempo de ejecución por una instancia de una clase o por una colección de instancias. La parte puede nombrar solamente un rol, una superclase abstracta, o puede nombrar una clase concreta específica. La parte puede incluir un factor de multiplicidad (cardinalidad), tal como el [0..*] mostrado para Viewer en el diagrama.

Puerta

Una puerta es un punto de interacción que puede ser usado para conectar clasificadores estructurados con sus partes y con el ambiente. Las puertas pueden opcionalmente especificar los servicios que proveen y los servicios que requieren de otras partes del sistema. En el diagrama, cada uno de los cuadrados pequeños es una puerta. Cada puerta tiene un tipo y esta etiquetado con un nombre, tal como "var", "indVar1", or "view" en el diagrama. Las puertas pueden contener un factor de multiplicidad, por ejemplo [3].

Las puertas pueden ya sea delegar los requerimientos recibidos a partes internas, o pueden entregarlos directamente para el comportamiento del clasificador estructurado en el que la puerta está contenido. Las puertas públicas que son visibles en el ambiente son mostradas sobre el borde (límite o frontera), mientras que las puertas protegidas que no son visibles en el ambiente son mostradas dentro de la frontera (borde o límite). Todas las puertas en el diagrama son privadas, excepto por la puerta view a lo largo del límite derecho de FibonacciSystem.

Conector

Un conector une dos o más entidades, permitiéndoles interactuar en tiempo de ejecución. Un conector es representado por una línea que une una combinación de partes, puertas y clasificadores estructurados. El diagrama muestra tres conectores entre puertas, y un conector entre un clasificador estructurado y una parte.

Colaboración

Una colaboración es generalmente más abstracta que un clasificador estructurado. Ésta es mostrada como un óvalo sin relleno conteniendo los roles que las instancias pueden jugar en la colaboración.

Clasificador estructurado

Un ClasificadorEstructurado representa una clase, frecuentemente una clase abstracta, cuyo comportamiento puede ser completa o parcialmente descrito mediante interacciones entre partes.

Un ClasificadorEncapsulado es un tipo de clasificador estructurado que contiene puertas. En el diagrama abajo, ambos FibonacciSystem y Variable son clasificadores encapsulados, porque ambos tienen puertas a lo largo de sus límites.

DIAGRAMA DE ESTRUCTURAS " 3. DIAGRAMA DE OBJETIVOS"

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.

Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase.

Por ejemplo, Miguel: Persona.

DIAGRAMA DE ESTRUCTURAS " 2. DIAGRAMA DE COMPONENTES"

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. 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.

Debido a que estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

DIAGRAMA DE ESTRUCTURAS " 1. DIAGRAMA DE CLASES"

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos.

• Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.

• Operaciones comùnmente llamados mètodos, son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

• Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto. Hace referencia a polimorfismo.asi sera exitos pamela

• Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además cada uno tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario del empleado, etc.

DIAGRAMAS DE UML (DEFINICION GENERAL)

Diagramación UML

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

·         Diagrama de clases

·         Diagrama de componentes.

·         Diagrama de objetos.

·         Diagrama de estructura compuesta.

·         Diagrama de despliegue.

·         Diagrama de paquetes.

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

·         Diagrama de actividades.

·         Diagrama de casos de uso.

·         Diagrama de estados.

·         Diagrama de interacción.

o   Diagrama de secuencia.

o   Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración.

o   Diagrama de tiempos.

o   Diagrama global de interacciones o Diagrama de vista de interacción.