DIAGRAMAS UML (MODELADO DE CLASES)

Diagramas de clases (ejemplos y conceptos)

Las clases son el centro operativo de un sistema orientado a objetos.

El sistema se compone de pequeñas colecciones llamadas "Objetos".

Las clases describen diferentes tipos de objetos que puede obtener un sistema.

"Una clase" es una familia de objetos.

"Un objeto" no es una clase, tan solo es una versión de ella.

• El nombre de la clase son -sustantivos-
• Los objetos son -instancias de una clase-
• Los métodos son -verbos-

Ejemplo:

Modelar  -la clase lavadora-

Atributos(características)          Comportamiento

   * modelo                                * sacar ropa

   * marca                                  * agregar ropa

   * numero de serie                   * agregar detergente

   * capacidad 

Todos los atributos de la clase propuesta deben aplicarse a todos los objetos de la clase.

Los tributos describen el significado de la clase, para determinarlos pueden formularse las siguientes preguntas:

• ¿Cómo se describe?
• ¿Cómo se describe en el contexto del problema?
• ¿Qué debo saber para poder funcionar?
• ¿Cuáles de mis estados necesito conocer para funcionar?
• ¿Qué estados deben estar como miembros de la clase?

La multiplicidad permite especificar que un atributo es una colección de datos,se representa por números para indicar su cantidad exacta o * para indicar que son demasiados; este es un concepto mas para los diagramas de clases.

Existen otros conceptos que se utilizan en este tipo de diagrama como lo son:

Herencia: cuando una clase hereda atributos a otra clase, esta contendrá todos los métodos de la clase anterior.

Polimorfismo: son métodos llamados igual pero en sentido diferente.

Regresando a los atributos, estos pueden ser declarados dentro de la clase como:

Públicos (+): significa que estos serán accesibles por métodos de la misma clase.

Protegidos (#): significa que serán accesibles por métodos de la clase.

Privados(-): significa que solo podrán ser accedidos por la clase donde fueron declarados y no sera posible para todas aquellas clases ajenas.

Estas son algunas de las relaciones que se utilizan entre las clases.

Asociación: se utilizan cuando una clase necesita trabajar con un objeto de otra clase.

Dependencia: esta relación declara que una clase requiere conocer acerca de otra para usar sus objetos.

Herencia o generalización: define la herencia entre clases.

Composición: palabra clave "tiene un", su relación es muy fuerte.

Agregación: indica que una clase tiene objetos que pude compartir con otras clases, palabras clave "tiene" o "esta formado" 

DIAGRAMAS PARA EL MODELADO

Dentro de la planeación que se realiza antes de llevar a cabo un proyecto, se encuentra inmersa el orden del sistema, es decir, como es que vamos a ordenar y manipular cada una de las actividades a realizar en el proceso del armado de sistema.

Para esto empleamos los famosos "diagramas de actividades", mejor conocidos en el ámbito computacional, estos reflejan como el sistema va a lograr las metas requeridas.

Las acciones tan solo son un paso dentro del proceso de toda una actividad, mientras que una actividad es el proceso de llevar a cabo algo.

Para los diagramas de actividades emplean lo siguiente:

Acciones o tareas: pasos a seguir para desarrollar una actividad.

Rutas o caminos: flechas que nos sirven para guiar nuestro proceso.

Decisión: tomar una u otra opción.

Unión: aquí convergen las decisiones, para continuar con el proceso. 

Fork: flujo donde se separan en 2 caminos.

Join: se unen los caminos en una sola acción.

Sale señal: emerge una acción.

Entra señal: recibe una acción.

Estas son solo por mencionar algunos de los elementos básicos que se utilizan para el desarrollo de los diagramas de actividades.

Como sugerencia pueden utilizar la herramienta de YED para modelar esto.

Ejemplo:

MODELADO DE TAREAS

El modelado de tareas como tal es un método que se necesita para el desarrollo de software; como su nombre lo menciona, lo que se pretende es que el ingeniero de software tenga la habilidad para poder definir cada una de las tareas que se le solicitan, ademas de agregar las que crea conveniente, de esta forma obtendrá un listado de las cuales habrá de ordenar y modelar para el buen y optimo funcionamiento del sistema.

Este método esta basado en las siguientes características:

El modelado de tareas describen cada una de las actividades del usuario.

el propósito en general es indicar como las actividades se deben realizar para obtener un nuevo sistema.

Pueden ser representadas en diversos niveles de abstracción.

         *Alto nivel: son las actividades de las principales tareas.

         *Bajo nivel: las actividades se presentan con una granularidad pequeña.

Dentro de este modelado de tareas, podríamos emplear el uso de una herramienta denominada "ConcurTask Trees (CTT)" .

-Esta herramienta es de sintaxis gráfica.

- Esto facilita el uso y sobre todo su comprensión.

- Aquí cada tarea debe ser especificada con : un identificador, nombre, categoría, tipo, referencia, frecuencia de uso, plataforma, donde se usa, anotaciones informales, precondiciones.

He aquí algunas de las categorías para trabajar.

Interacción

Aplicación

Usuario

Abstracta

Este es un pequeño "árbol", donde se muestran cada uno de ellos.

Prototipo

Inmediatamente después de definir requerimientos, políticas, visión, modelado de tareas, entre otros aspectos, viene de la mano el prototipo, este es una estrategia para enfrentar la complejidad de lo imprescindible, ademas este no debe ser completo, tiene que ser fácil de modificar y que por supuesto tendrá una caducidad dado que solo sera una "versión de prueba".

los prototipos son como preguntas.

1.- ¿Cómo debe lucir?

2.- ¿Cómo debe funcionar?

3.- ¿Cómo debe ser la experiencia del usuario?

Estas son tan solo algunas que podrían formularse para ayudar a definir y crear el prototipo.

Luego de esto viene la "Arquitectura de Software", ésta es caracterizada por: 

*El sistema debe ser amable y atento con el usuario.

*Tiene que satisfacer todo imposible.

*La arquitectura conlleva: documentación, planos y especificaciones que describen el objeto a construir.

Esta "Arquitectura" esta basada prácticamente en el diseño de un todo, es decir, es la base, la idea de lo que se quiere construir, con todo lo anterior concluimos que es necesario llevar una secuencia de procesos, para el buen desarrollo de un software, es vital llevar una serie de pasos que nos orienten a terminar satisfactoriamente cada uno de los requisitos de sistema, de tal manera que el cliente quede sumamente satisfecho.

TIPOS DE DESARROLLO Y REQUERIMIENTOS

Tipos de Desarrollo

Dentro de la Ingeniería de Software se necesita el mejor desempeño en las actividades laborales que este conlleva, se necesita de una buena organización, optimización y un buen desarrollo de habilidades y métodos. Es por eso que a continuación se listan algunas características en los tipos de desarrollo.

*Métodos Clásicos de Desarrollo de Software*

-Difieren en su naturaleza.

-Poseen un espíritu normativo.

-Comienzan con la licitación y el análisis completo de los requerimientos del usuario.

-Los ingenieros integran sus ideas.

-Los programadores implementan el diseño.

-Legislación negativa.

-Crisis de confianza en los procesos regidos por metodologías prescriptivas en el análisis de requerimientos.

*Métodos Ágiles de Desarrollo de Software*

-Se promueve la documentación.

-Se planifica y reconoce los limites de planificación.

-"La gente es el primer factor de éxito de un proyecto de software".

-No necesitan de desarrolladores brillantes, sino alguien que se adapte ante cualquier circunstancia.

-No se producen documentos a menos de que sean necesarios.

-Los documentos deben ser cortos y centrarse en lo fundamental a atacar.

-Colaboración con el cliente, esta colaboración entre ambos será las marca inicial.

-El Desarrollo Ágil de software es un marco de trabajo conceptual.

-Su meta al final del día es conseguir un "demo" sobre lo que se esta trabajando.

-Los métodos ágiles enfatizan que el software funcional es la primera medida del progreso.

A groso modo se puede deducir que los proyectos que usan métodos ágiles han logrado un nivel de madurez mayor, ademas de muy buenos resultados, a comparación a los que se han elaborado utilizando los métodos clásicos, aunque esto depende del tipo de organización que se maneje dentro del  Desarrollo de Software.

(2)

*Ingeniería de Requerimientos*

En la Ingeniería de Software, ademas de necesitar lo antes ya mencionado (en otras entradas), también necesita una serie de requisitos que serán propiamente indicados por el cliente que solicita el proyecto y ademas de algunos otros requerimientos que vienen implícitos en él, es decir, "El Desarrollador" será capaz de interactuar con el cliente para llegar a un acuerdo y aclarar los requerimientos que su sistema necesita, ya sean explícitos o implícitos.

(1)

Ciclo de Vida 

1.- Ingeniería de Requerimientos.

2.- Diseño.

3.- Complementación.

4.- Validación.

5.- Liberación.

6.- Mantenimiento.

De acuerdo al Ciclo de Vida, mencionado aquí arriba, los requerimientos sin duda alguna son el primer paso para el buen manejo de un proyecto.

Los Requerimientos facilitan en gran medida el mecanismo para comprender lo que quiere el cliente analizando todas sus posibles soluciones.

Existen los requerimientos:

Funcionales.- Son los que dicen que debe hacer el sistema, en el sentido del servicio.

No funcionales.- Son las características del sistema como la mantenibilidad, Sistema Operativo, etc.

Definición de Requisito:

Es una capacidad que el sistema debe tener porque el cliente lo ha pedido explícita o implícitamente, la determinación de requerimientos es el primer paso en la construcción de la aplicación.

Los requisitos son de vital importancia ya que permite gestionar las necesidades del proyecto, mejora la capacidad de predecir cronogramas, mejora la calidad del software si se cumple con todos y cada uno de los requisitos solicitados por el cliente, ademas de que evitas los rechazos de usuarios finales debido a que obliga a los usuarios a considerar sus requerimientos cuidadosamente.

(3)

Lo siguiente es una serie de pasos que pueden ayudar a determinar los requerimientos necesarios.-Identificar lo que se necesita, es decir, sus requisitos.

-Análisis de requisitos y negociación.

-Especificación de requisitos.

-Modelado del sistema.

-Validación de requisitos y gestión de los mismos.

La obtención de requisitos no es para nada fácil de obtener por diversas razones:

*La naturaleza de los requisitos es cambiante.

*Surgen nuevos requisitos.

*El cliente puede no tenerlos claros.

La clave para poder obtenerlos de manera más sencilla es "La Comunicación"

De esta manera concluimos que podemos elegir alguno de los tipos de desarrollo antes mencionado de tal forma que la organización interna de quienes desarrollan el software se vea lo mejor coordinada posible, tomando en cuenta los requerimientos necesarios para el buen funcionamiento de todo lo que se realice.

(1)http://www.infinitumpage.mx/TMX5557343198/WEB/

(2)http://www.intergrupo.com/blog/mobile/desarrollo-agil-software-mantenimiento.aspx

(3)http://requerimientossoftware.blogspot.mx/