Prueba del Avatar en VOKI

Diagrama de Clase

Un diagrama de clases es mas que un tipo de diagrama estático en el cual se  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.

Los Diagramas de Clase lleban los siguientes atributos:

Tipo: puede llegar a depender del lenguaje de programación a utilizar.• Valor inicial: valor que poseerá el atributo al crear un objeto.• Visibilidad: está relacionado con el encapsulamiento.• Multiplicidad: determinar si un atributo debe estar o no, y si posee un único valor ouna lista de valores.• Ordenamiento: especifica si el atributo determina alguna relación de orden dentro de laclase.• Capacidad de cambio: permite definir atributos con valores constantes.• Modificadores: un atributo puede ser de clase, derivado, volátil, transitorio.

Generalización en diagramas de clase:

Una generalización se refiere a una relación entre una

clase general (superclase o padre) y una versión más

específica de dicha clase (subclase o hija).

La herencia múltiple debe manejarse con precaución. Algunos
problemas son el conflicto de nombre y el conflicto de precedencia, se recomienda un uso restringido y disciplinado de la herencia, este tambien permite modelar jerarquías alternativas.

Uno de tantos programas que existen para crear modelaientos de clases yo les recomendaria Netbeans el cual trae una macnifica opcion para hacer diagramas de clases, pero no solo esto tambien casos de uso, diagramas de secuencias entre otras...

Les dejo este video para que se guien como hacer un diagrama de clases en netbeans...

Diagramas de Secuencia

El diagrama de secuencias en UML muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo. 
El diagrama muestra:

• Los objetos participando en la interacción
• La secuencia de mensajes intercambiados . 

Un diagrama de secuencia contiene: 

• Objetos con sus “líneas de vida”. 
• Mensajes intercambiados entre objetos en una secuencia ordenada.
• Línea de Vida Activa (opcional).

• Objetos

• El diagrama de secuencias consta de objetos que se representan del modo usual: rectángulos con nombre (subrayado), mensajes entre los objetos representados por líneas continuas con una punta de flecha y el tiempo representado como una progresión vertical. Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama.

• Tiempo
• Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto a la de otro. Un objeto puede enviarse un objeto a sí mismo (es decir, de su línea de vida a su propia línea de vida). Un mensaje puede ser simple, síncrono o asíncrono. Un mensaje simple es la transferencia del control de un objeto a otro. Un mensaje síncrono es aquel en el que el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo. Un mensaje asíncrono es aquel en el que el objeto no espera la respuesta a ese mensaje antes de continuar. En el diagrama de secuencias, los símbolos del mensaje varían. Por ejemplo, la punta de la flecha de un mensaje simple está compuesta por dos líneas, la punta de flecha de un mensaje síncrono es un triángulo relleno, y la de uno asíncrono solo tiene una sola línea.

¿Que es UML?

El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

• Mejores tiempos totales de desarrollo (de 50 % o más).

• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.

• Establecer conceptos y artefactos ejecutables.

• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

• Mejor soporte a la planeación y al control de proyectos.

• Alta reutilización y minimización de costos.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

Diagramas de Casos de Uso para modelar los procesos 'business'.

Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

Diagramas de Colaboración para modelar interacciones entre objetos.

Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.

Diagramas de Clases para modelar la estructura estática de las clases en el sistema.

Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.

Diagramas de Componentes para modelar componentes.

Diagramas de Implementación para modelar la distribución del sistema.

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
  
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
  
• Establecer conceptos y artefactos ejecutables.
  
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
  
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
  
• Mejor soporte a la planeación y al control de proyectos.
  
• Alta reutilización y minimización de costos.

¿Como se debe crear un caso de uso?

Tras haber localizado los actores se procede a describirlos, se especifican describiendo un flujo de eventos y dichos actores sólo pueden conectar a los casos de uso a través de asociaciones.

Generalmente hay pocos actores asociados a cada caso de uso, por lo cual se hacen las siguientes preguntas:

1. ¿cuales son las tareas del actor?
2. ¿que información crea. guarda, modifica, destruye o lee el actor?
3. ¿debe el actor notificar al sistema los cambios externos?
4. ¿debe el sistema informar al actor de los cambios internos?

les dejo de un ejemplo en el cual muestra como crear el modelo de un caso de uso:

El post anterior fue sacado de una diapositiva la cual no las facilito nuestro profesor Marco Chico

de Slideshare caso de uso

¿Que es un caso de uso?

El caso de uso no es mas que una técnica para capturar información de cómo un sistema o negocio trabaja actualmente o de cómo se desea que trabaje; también es aquel que describe una interacción típica entra un usuario(actores) y un sistema de computo.

Los casos de uso sirven para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento, sirve como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio y ayuda a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este.

Los casos de uso se representan con un ovalo

 

y los actores con un monigote

 

¿Qué es el COCOMO?

El Modelo Constructivo de Costos (o COCOM0, por su acrónimo del ingléses COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costos desoftware. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.


Es un modelo que permite estimar el costo, el esfuerzo, y programar la hora de planificar una nueva actividad de desarrollo de software.

El modelo provee tres “niveles” de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.

Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).

Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de “guías de costo” que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.

Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.

Pruebalo en este enlace  <----------------------