UML Casos de Uso

DEFINICIÓN.

Caso de uso es un documento narrativo que describe la secuencia de eventos de un ACTOR (agente externo) que utiliza el sistema para completar un proceso.

Jacobson, 1992

Un CASO DE USO es una descripción de las INTERACCIONES y las RESPONSABILIDADES de un sistema, "objeto de debate " o "sistema en diseño”, con AGENTES EXTERNOS o ACTORES. Un actor puede ser una persona un grupo de personas o un sistema informático. El caso de uso es asociado con el OBJETIVO de un actor en particular, que es llamado el ACTOR PRINCIPAL del caso de uso. El caso de uso describe los distintos conjuntos de interacciones que pueden ocurrir entre diversos agentes externos o actores mientras que el actor principal está en la búsqueda de su objetivo. También se describen las responsabilidades del sistema bajo diseño sin tener en cuenta técnicas de implementación o componentes del sistema. Cada posible secuencia de interacciones es llamada ESCENARIO. El caso de uso agrupa juntos todos los escenarios relacionados con el objetivo del actor principal, incluyendo tanto los escenarios donde el objetivo es conseguido como los escenarios donde el objetivo debe ser abandonado.

Cockburn, Alistair. 2000. Writing Effective Use Cases

En la definición anterior, se resaltan en letra mayuscula algunos conceptos destacados, la definición original no resalta ningun concepto.

DESCRIPCIÓN DE UN CASO DE USO.

 

La descripción de un caso de uso se compone de dos partes principales, el diagrama que representa gráficamente el caso de uso y una descripción textual que aclara de forma literal el diagrama, en esta sección se explicara la descripción textual que es la más importante pues documenta completamente el caso de uso y sus posibles escenarios.

 

1. ENCABEZADO

 

1.1. Identificador del caso de uso

Cada caso de uso tiene un único identificador numérico, también se pueden agrupar de forma jerárquica usando otras notaciones como X.Y o combinar un código numérico con un código alfabético como RF1, RNF1, etc.

 

1.2. Nombre del caso de uso

El nombre debe ser conciso, debe estar orientado al resultado del caso de uso. Debe reflejar las tareas que el usuario necesita llevar a cabo para usar el sistema. El nombre debe llevar un verbo pues es una acción. Ejemplo.

1. Generar orden de compra
2. Registrar PIN.

 

1.3. Registro Histórico

 

1.3.1 Creado Por.

En esa parte se pone el nombre de la persona “Autor” de ese caso de uso.

 

1.3.2 Fecha de creación

En esta parte se pone la fecha de creación inicial del caso de uso.

 

1.3.3 Actualizado Por.

Se pone el nombre de la persona que realizo la última actualización, también se pueden conservar los nombres de las personas que actualizaron previamente el caso de uso.

 

1.3.4 Fecha de actualización.

Se escribe la fecha de la última actualización.

 

2. DEFINICIÓN DE LOS CASOS DE USO.

 

2.1. Actores

En esta parte se ubican los nombres de los actores implicados en el caso de uso, tenga en cuenta que en un caso de uso o un conjunto de ellos pueden interactuar uno o muchos actores.

 

2.2. Trigger o Disparador.

Identifica el evento que inicia el caso de uso. Podría ser un evento de negocios externos o de sucesos del sistema que hace que el caso de uso pueda empezar, también podría ser el primer paso en el flujo normal.

 

2.3. Descripción

Proporcionar una breve descripción de la razón y los resultados del caso de uso, o una descripción de alto nivel de la secuencia de acciones y los resultados de la ejecución del caso de uso.

 

2.4. Precondiciones

Lista todas las actividades que deben ser tenidas en cuenta o todas las condiciones que deben ser cumplidas, antes de que el caso de uso empiece. Las precondiciones deben ser numeradas.

1. El usuario debe autenticar su identidad. 

 

2.5. Postcondiciones

Describen el estado del sistema una vez terminada la ejecución del caso de uso. Deben ir numeradas.

1. El articulo queda registrado en la base de datos.
2. El precio del artículo queda actualizado en la base de datos.

 

2.6. Escenarios

 

2.6.1 Flujo norma de eventos.

Provee una descripción detallada de las acciones del usuario y las respuestas del sistema durante la ejecución normal del caso de uso, son las condiciones esperadas cuando el caso de uso se ejecuta sin contratiempos, Esta secuencia de diálogo en última instancia conduce a lograr el objetivo expuesto en el nombre y la descripción de casos de uso. Esta descripción puede ser escrita como una respuesta a la pregunta hipotética: ¿Cómo se pueden hacer cumplir las tareas que sugiere el nombre del caso de uso?. Para lograr una buena conformación del flujo normal se recomienda numerar las acciones de los usuarios y las respuestas del sistema a manera de pasos para llegar a la meta del caso de uso.

 

2.6.2 Flujos alternos.

Documenta los escenarios que pueden ocurrir cuando el caso de uso no puede ser ejecutado completamente. Se enumeran igual que el flujo normal de eventos con las acciones del usuario y las respuestas del sistema.

 

2.7. Puntos de extensión.

Es donde se establece en qué momento, del hilo de ejecución del caso de uso se va a extender a otro.

 

2.8. Excepciones.

 Describir las condiciones de error que podrían ocurrir durante la ejecución del caso de uso y define cómo el sistema es responder a esas condiciones. Además, se describe cómo el sistema ha de responder si la ejecución de casos de uso falla por alguna razón imprevista. Las excepciones se pueden identificar en términos de una 4 tupla, de la forma “X.Y.E.Z”, donde X es el identificador del caso de uso, Y indica el flujo normal si es (0) o alternativo si es mayor que (0), E indica excepción y Z es el numero de secuencia de las excepciones. Por ejemplo. 4.0.E.1 significa que el caso de uso 4, en su flujo normal presenta una excepción y que dicha excepción es la número 1.

 

2.9. Includes

Lista de todos los casos de uso de que son incluidos, llamados por el presente caso de uso.

 

2.10. Prioridad.

En esta parte se indica la prioridad relativa de la implementación de la funcionalidad del caso de uso, puede usar una escala de 3 valores como alto, medio y bajo aun cuando usar escalas más amplias podría ayudar a mejorar la priorización y trazabilidad de los casos de uso.

 

2.11. Frecuencia de uso

Estimar el número de veces en que el caso de uso se llevará a cabo por los actores, debe indicarse alguna unidad de tiempo.

 

2.12. Reglas de negocio.

Lista todas las reglas de negocio que influencian el caso de uso.

 

2.13. Requerimientos especiales

Se incluyen los requisitos adicionales, tales como los requisitos no funcionales que pueden necesitar para el caso de uso, que se abordarán durante el diseño o implementación de él. Estos pueden incluir requisitos de rendimiento u otros atributos de calidad.
  

NOTA: En el siguiente link podrá encontrar un ejemplo que se será útil para realizar su propia platilla para documentar casos de uso.

Descarga plantilla para documento Casos de Uso

Ejemplo Abstraccion.

Ejemplos.

 

En esta sección usaremos el lenguaje de programación java para realizar ejemplos de abstracción, polimorfismo, encapsulamiento y herencia.

 

Ejemplo Abstracción.

 

Para este ejemplo se va a trabajar la abstracción de un vehículo, para lo cual se hace el siguiente razonamiento.

1. Los vehículos pueden ser de varias clases (aéreo, terrestre, acuático e híbridos), por tanto todos los vehículos tienen una clase.
2. Todos los vehículos tienen una velocidad máxima.
3. Todos los vehículos mecánicos consumen algún tipo de combustible.
4. Todos los vehículos pueden llevar un número determinado de pasajeros o carga, para el ejemplo se considera solo el transporte de pasajeros.

Y se podrían seguir poniendo tantas características como se consideren necesarias para conseguir una buena abstracción del objeto. La siguiente es la representación de la abstracción en java solo de los atributos, y un método constructor.

 
    public class Vehiculo {
    String clase;
    int velocidadMax;
    String combustible;
    int numeroPasajeros;

    public Vehiculo(String clase, int velocidadMax, 
    String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }
} 

 

Ejemplo Encapsulamiento.

El encapsulamiento en Java se implementa con las palabras reservadas private o protected, y su función es esconder el estado del objeto. Cabe resaltar que cuando los atributos del objetos son privados se deben implementar interfaces que permitan el acceso a los mismos, estas son llamadas propiedades y se notan setNombreAtributo y getNombreAtributo. Los set se usan para asignar valores a los atributos y los get para retornar el valor del atributo. 

    public class Vehiculo {
    private String clase;
    private int velocidadMax;
    private String combustible;
    private int numeroPasajeros;

    public Vehiculo(String clase, int velocidadMax, 
    String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }

    
    public String getClase() {
        return clase;
    }
    public void setClase(String clase) {
        this.clase = clase;
    }
    public int getVelocidadMax() {
        return velocidadMax;
    }
    public void setVelocidadMax(int velocidadMax) {
        this.velocidadMax = velocidadMax;
    }
    public String getCombustible() {
        return combustible;
    }
    public void setCombustible(String combustible) {
        this.combustible = combustible;
    }
    public int getNumeroPasajeros() {
        return numeroPasajeros;
    }
    public void setNumeroPasajeros(int numeroPasajeros) {
        this.numeroPasajeros = numeroPasajeros;
    }
}

 

Ejemplo Polimorfismo.

Para el ejemplo de polimorfismo se tomara la clase con atributos y se van a agregar dos constructores, dicho polimorfismo se llama sobre carga, se observa cómo dos métodos tienen el mismo nombre pero reciben diferentes parámetros. En este tipo de polimorfismo hay que tener cuidado con la firma del método ya que dos métodos con el mismo nombre no pueden tener la misma firma. 

    public class Vehiculo {
    public class Vehiculo {
    private String clase;
    private int velocidadMax;
    private String combustible;
    private int numeroPasajeros;

    // Constructor lleno
    public Vehiculo(String clase, int velocidadMax, 
            String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }
    
    // Constructor vacio
    public Vehiculo(){}
} 

 

Ejemplo Herencia.

Para el ejemplo de herencia vamos a crear la clase automóvil que también es un vehículo, la herencia en java se implementa con la palabra reservada extends y la referencia al constructor del padre.

    

/**********************************
CLASE PADRE
**********************************/

    public class Vehiculo {
    private String clase;
    private int velocidadMax;
    private String combustible;
    private int numeroPasajeros;

    // Constructor lleno
    public Vehiculo(String clase, int velocidadMax, 
            String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }

    public String getClase() {
        return clase;
    }
    public void setClase(String clase) {
        this.clase = clase;
    }
    public int getVelocidadMax() {
        return velocidadMax;
    }
    public void setVelocidadMax(int velocidadMax) {
        this.velocidadMax = velocidadMax;
    }
    public String getCombustible() {
        return combustible;
    }
    public void setCombustible(String combustible) {
        this.combustible = combustible;
    }
    public int getNumeroPasajeros() {
        return numeroPasajeros;
    }
    public void setNumeroPasajeros(int numeroPasajeros) {
        this.numeroPasajeros = numeroPasajeros;
    }
}


/**********************************
CLASE HIJO
**********************************/
    
    public class Automovil extends Vehiculo{
    private int numeroLlantas;
    private int numeroPuertas;
    private String modelo;

    // Constructor que incluye atributos de la super clase o clase padre.
    
    public Automovil(String clase, int velocidadMax, String combustible, 
    int numeroPasajeros, int numeroLlantas, int numeroPuertas, String modelo)
    {
        super(clase,velocidadMax, combustible, numeroPasajeros);
        this.numeroLlantas = numeroLlantas;
        this.numeroPuertas = numeroPuertas;
        this.modelo = modelo;
    }
    public int getNumeroLlantas() {
        return numeroLlantas;
    }
    public void setNumeroLlantas(int numeroLlantas) {
        this.numeroLlantas = numeroLlantas;
    }
    public int getNumeroPuertas() {
        return numeroPuertas;
    }
    public void setNumeroPuertas(int numeroPuertas) {
        this.numeroPuertas = numeroPuertas;
    }
    public String getModelo() {
        return modelo;
    }
    public void setModelo(String modelo) {
        this.modelo = modelo;
    }    
}

Programación OO - Objeto

Objetos.

 

El concepto objeto es fundamental en la programación OO, por lo cual se explica a continuación.

 

Definición de objeto:

 

"Un objeto tiene estado, comportamiento, e identidad; la estructura y comportamiento de objetos similares son definidos en su clase común; los terminos instancia y objeto son intercambiables".

Booch, 1991

" Nosotros definimos un objeto como un concepto, abstracción o cosa con un significado y límites bien definidos para el problema a manejar".

Rumbaugh, 1991

" Un objeto es cualquier cosa a la que se le aplica un concepto, el que representa una idea o noción que nosotros compartimos y aplicable a ciertos objetos en nuestro conocimiento".

Martin, 1992

De las definiciones anteriores se puede determinar que un objeto es:

Los conceptos de estado, comportamiento e identidad, son explicados a continuación con algunos ejemplos sencillos para facilitar su comprensión.

 

Estado

El estado hace referencia a los valores presentes en el conjunto de atributos de un objeto. El estado es variable en el tiempo, el comportamiento de un objeto puede cambiar el estado del mismo. 

Por ejemplo imagine un objeto círculo, con un atributo nombrado “radio”. Ahora observe la figura, el objeto circulo en un tiempo t determinado tiene 5 como valor del atributo radio, sin embargo en un tiempo t diferente el valor del atributo radio cambia por 3, tratándose del mismo objeto en tiempos t diferentes. 

Comportamiento

El comportamiento de un objeto, agrupa las operaciones que este puede realizar o a las que puede responder mediante estímulos externos representados en forma de mensajes enviados por otros objetos. Las operaciones pueden tener efecto directo sobre los atributos. 

Ahora teniendo como base la figura anterior donde se muestran los círculos, imagine la operación calcular área, esta operación deberá retornar el valor de la operación matemática PI * (radio * radio), donde radio es el valor de dicho atributo en ese instante de tiempo.

 

Identidad

La identidad es el mecanismo por el cual se puede diferenciar un objeto de otro, se puede tomar como un identificador univoco y es interesante cuando se tienen objetos con los valores de sus atributos iguales, la identidad es implementada en los lenguajes de programación de manera implícita, así que no es responsabilidad del programador crearla. Un ejemplo de ello son los OID o identificadores de objetos por sus siglas en ingles que proveen la identidad de un objeto independientemente de su ubicación física.

 

Clasificación de objetos según su comportamiento.

Los objetos según su comportamiento se pueden agrupar en 3 categorías que son:

1. Actores
2. Servidores
3. Agentes

Los objetos Actores, son iniciadores de la interacción, son generalmente objetos activos.

Los objetos Servidores, por el contrario de los actores no son iniciadores de una interacción su función se limita a responder peticiones de otros objetos, siempre son destinatarios de los mensajes.

Los objetos Agentes, reúnen las características de clientes y servidores, los agentes pueden interactuar con otros objetos en todo momento bien sea por iniciativa propia o a consecuencia de una solicitud externa.

 

Comunicación entre objetos.

La unidad de comunicación entre objetos se denomina mensaje, existen 5 categorías de mensajes que son:

1. Simple
2. Síncrono
3. Esperado
4. Cronometrado
5. Asíncrono

Los mensajes a su vez se componen de los siguientes componentes.

1. Nombre del receptor del mensaje
2. Método invocado
3. Información necesaria para la ejecución del método

Programación OO - Clases

Definición.

 

Independientemente del lenguaje de programación en que se implementen, las clases son plantillas de objetos, también se puede tomar como la descripción abstracta de un grupo de objetos, estas tienen una estructura que se conforma de dos componentes principales atributos y métodos (operaciones). 

La representación grafica que prevalece en la actualidad es la de Yurdon y Coad, donde se dibuja un rectángulo divido horizontalmente en 3 partes, En la parte superior se ubica el nombre de la clase, en la parte media es destinada a los atributos y la parte inferior se reserva para los métodos. 

Atributos

Los atributos describen el estado de un objeto, En términos generales son características generales de la clase, que la diferencian de otras. 

En las implementaciones que se encuentran en los lenguajes de programación los atributos suelen representarse como variables de instancia, ademas deben ser privados.

 

Métodos

Los métodos (operaciones o servicios) describen el comportamiento asociado a un objeto. La ejecución de un método puede conducir a cambiar el estado del objeto o dato local del objeto, los métodos deben ser privados con excepción de los métodos que solo son usados únicamente en la misma clase

 

Ejemplo de clase con atributos y métodos

La figura muestra la clase Punto con sus atributos coordenadaX y coordenadaY que son los elementos necesarios para definirlo y diferenciarlo de la clase línea por ejemplo que necesitaría cuando menos un par de puntos. También se observan los métodos moverCoordenadaX y moverCoordenadaY. Que representan posibles comportamientos que se pueden lograr por un objeto de la clase Punto. 

El siguiente video muestra cómo crear clases en la herramienta de modelado ArgoUml.

Programación OO - Elementos principales.

Elementos principales.

Independientemente del leguaje de implementación, el paradigma de programación objeto se basa en 4 conceptos fundamentales. La abstracción, el encapsulamiento, el polimorfismo y la herencia. Dichos pilares van a ser explicados a continuación en forma superficial. 

  

Abstracción:

En POO la abstracción hace referencia a la capacidad de expresar las características principales de un objeto. Como consecuencia de esto se logra tener un modelo claro del objeto centrado en la pregunta ¿qué hace? 

El método de abstracción es arbitrario. Lo que permite que un objeto pueda ser visto a través de abstracciones diferentes. La siguiente figura muestra la colección de toros de Picasso que ejemplifica de forma magistral el espíritu de la abstracción, en dicha secuencia se puede observar como los primeros toros son muy ricos en detalles que no hacen parte esencial de la representación del toro hasta llegar al número 11, donde se encuentra un toro reducido a una representación de muy pocos trazos pero con expresividad suficiente para saber que es un toro.  

Imagenes tomadas de: http://www.artyfactory.com/art_appreciation/animals_in_art/pablo_picasso.htm

 

Encapsulamiento. 

El encapsulamiento se utiliza para ocultar o esconder las características esenciales de un objeto, de manera que no pueda ser alterado por otros objetos, en cierto modo proveen un efecto de caja negra donde la interacción entre objetos debe hacerse por medio de su interfaz y no directamente. 

Dependiendo de la implementación del lenguaje OO. Se tienen diferentes reglas de visibilidad para atributos, métodos y / o clases, dichas reglas son:

1. Privado: visible sólo para la clase y para las clases amigas o del mismo paquete en C++ y Java, respectivamente.
2. Protegida: visible sólo para las clases derivadas (subclases).
3. Pública: visible para todas las clases con las que está asociada.

 

Herencia:

 

Tiene su justificación en una ventaja de la programación OO, que es la reutilización de código, tomando en cuenta la analogía con la herencia genética, en programación se trata de que una clase puede heredar de otra u otras. Las clases hijas son especializaciones de la súper clase por lo que deben incluir atributos y métodos propios, Existen dos tipos de herencia denominadas herencia simple y herencia múltiple. 

La herencia simple se da cuando una clase hija hereda de solo una clase llamada padre o súper clase, como resultado la clase hija hereda los atributos y métodos de su padre ( este tipo de herencia es el soportado en java). 

Sabiendo cómo se da la herencia simple es fácil imaginar cómo funciona la herencia múltiple, básicamente consiste en que una clase herede de más de una clase padre, aunque es mucho más natural que la herencia simple dado que en muchos casos un objeto posee caracterizas y comportamientos de otros varios y no solo de uno, hay que ser cuidadoso con su uso ya que se pueden tener resultados indeseados (soportada en C++).

Polimorfismo:

Quizá es uno de los pilares de la programación OO, más complejos de entender, sin embargo se va a tratar de explicar de forma sencilla, el polimorfismo se aplica en los métodos y se refiere a que el mismo método puede ser usado para diferentes fines según se necesite. 

Para explicar mejor este concepto vamos a echar mano de la implementación en java. En ese lenguaje se tienen dos clases de polimorfismo uno se llama sobrecarga y el otro se llama sobre escritura. Esta definición puede variar según la implementación, sin embargo el concepto de polimorfismo es el mismo. 

La sobrecarga se refiere a que un método puede implementarse para varios fines con el mismo nombre en la misma clase, el ejemplo más simple se observa con los métodos constructores que se pueden implementar con varios parámetros diferentes como el constructor vacío y el constructor lleno.

La sobre escritura se aplica cuando una clase hereda de otra u otras (en java solo existe herencia simple), en ese sentido la clase hija hereda sus atributos y métodos, sin embargo esto no implica que los métodos se tengan que utilizar estrictamente en la forma que lo hace su padre, en caso de haber cambios en la implementación de un método este se escribe de nuevo en la clase hija con sus particularidades.

Introducción Programación OO.

Introducción.

 

La programación Orientada a Objetos o programación OO, ha sido muy exitosa y ha logrado posicionarse en muchas actividades de la informática desde el desarrollo de aplicaciones científicas, comerciales, Web y móviles. Sus inicios se remontan a los años 90 y desde entonces se han desarrollado lenguajes de programación que incorporan sus características. 

La programación OO sugiere una forma de pensar en la cual el programador debe poder crear una abstracción del problema del mundo real que desea resolver, el nivel de abstracción determinas las capas y objetos que se utilizaran en el programa, cabe destacar que cada programador abstrae de manera diferente la realidad que lo rodea y la programación OO ofrece mucha flexibilidad en ese sentido.

 

Beneficios de OO

 

1. Reuso
2. Calidad
3. Modelamiento del mundo real
4. Facil mantenimiento

En la actualidad los lenguajes más populares son orientados a objetos prueba de esto, es que en 10 primeros lugares del ranking de lenguajes de programación la mayoría son lenguajes orientados a objetos, donde se encuentran Java, C++, C#, PHP y Delphi entre otros. 

Como un elemento a favor la programación OO, cuenta con herramientas que ayudan en la etapa de análisis y diseño, como es el caso de los patrones de diseño y el lenguaje de modelado unificado UML.

Requerimientos

Definición

Los requerimientos son una especificación de lo que debe ser implementado. Estos son descripciones de cómo el sistema se debe comportar, de las propiedades y atributos del mismo. Deben ser una restricción del proceso de desarrollo del sistema Sommerville and Sawyer, 1997

1. Una condición o capacidad que un usuario necesita para resolver un problema o alcanzar un objetivo.
2. Una capacidad o condición que debe poseer el sistema o los componentes del sistema para satisfacer un contrato, estándar, especificación, u otro documento formalmente impuesto.
3. Una representación documentada de una condición o capacidad documentada como las descritas en (1) y (2).

Estándar de la Terminología de la Ingeniería de Software de la IEEE,1997.

Características de un buen requerimiento.

1. Escrito en forma de “Debe”
2. Correcto
3. Realizable
4. Necesario
5. Priorizable
6. No Ambiguo
7. Verificable
8. Traceable (Puede Seguirse)
9. Independiente del Diseño
10. Identificador único
11. Necesario
12. Conciso
13. Consistente (No en conflicto con otros)
14. No Repetido
15. Localizado (en un componente o elemento del sistema)

 

Requerimientos funcionales.

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que debe reaccionar ante entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer. Sommerville, 2005

Ejemplos de requerimiento funcional correcto

1. El sistema debe contar con un mecanismo de seguridad conformado por nombre de usuario, contraseña y un campo de verificación que aplica la prueba de Turing inversa.
2. El sistema deber permitir almacenar artículos en una base de datos relacional.

Los requerimientos anteriores son claros y expresan en forma correcta los deseos del cliente.
Ejemplos de requerimiento funcional incorrecto

1. El sistema debe contar con un mecanismo que provea gran seguridad.
2. El sistema debe permitir almacenar algunos datos importantes

Los requerimientos son incorrectos porque en el numero 1 la palabra gran no es explicita y puede prestarse para varias interpretaciones presenta ambigüedad. En el requerimiento 2 algunos no es un cuantificador valido y también se presta para interpretaciones variadas además no dice en ningún momento donde deben almacenarse los datos en cuestión.

 

Requerimientos no funcionales

Los requerimientos no funcionales como su nombre lo indica no se centran en las funcionalidades especificas del software o lo que debe hacer, estos se ocupan de propiedades emergentes del software como la fiabilidad, tiempos de respuesta, apariencia, capacidad de almacenamiento, etc.
No por lo anterior se deben subestimar este tipo de requerimientos un error frecuente dado que son igual y en algunos casos más importantes que los mismos requerimientos funcionales en el sentido de que si un programa es capaz de cumplir a la perfección con todos los cómputos para los que fue creado y tiene una interfaz de usuario inaccesible quedara en desuso.

 

Algunos ejemplos de requerimientos no funcionales, requerimientos de:

 

1. Eficiencia.
2. Usabilidad.
3. Rendimiento.
4. Espacio
5. Fiabilidad.
6. Portabilidad.
7. Implementación.
8. Uso de estándares.
9. Interoperabilidad.
10. Éticos.
11. De ley
12. De privacidad
13. De seguridad

 

Problemas frecuentes

 

1. Difíciles de Recolectar
2. Imposibilidad de Rastrear el cambio
3. Difíciles de Escribir
4. Demasiada forma, poco contenido
5. Falta de organización  

El siguiente Link lo llevara a la platilla de IEEE 830 para documentar requerimientos.

IEEE 830 PDF

Crisis del software

Introducción.
 

La crisis del software fue un término utilizado los años 70, para expresar las dificultades del desarrollo de software, frente al vertiginoso incremento de la demanda por software, las complejidades de los problemas a resolver y de la inexistencia de técnicas establecidas para el desarrollo de sistemas que funcionaran adecuadamente o pudieran ser validadas. En dicho momento la ingeniería de software era incipiente. 

En primera instancia el término crisis del software fue utilizado por el científico de la computación holandés y ganador del premio TURING, Edsger Dijkstra. Sin embargo se adjudica a F. L. Bauer, el término se acuño en 1968 en la primera conferencia organizada por la OTAN sobre desarrollo de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software".

 

Síntomas.

1. Sobre costos (No se respetan los presupuestos).
2. Incumplimiento (No se entrega el software a tiempo);
3. Software que no cubre los requerimientos.
4. Software de baja calidad.
5. Dificultad para mantener mejorar o modificar proyectos de software. 

Conoce algún proyecto de software actual con los anteriores problemas? Cualquier parecido con la realidad es pura coincidencia! La siguiente imagen representa un poco mejor la realidad.

Reflexión.

 

De algún modo si se observa lo citado anteriormente se puede evidenciar que muchos proyectos de software actuales, aun continúan teniendo comportamientos que se pueden asociar a la crisis del software ya identificada en la década de los 60, lo que suscita la pregunta ¿Cómo hacer frente a la crisis del software? 

La pregunta anterior no tiene una única solución, si se hace la analogía con un humano enfermo, la mayoría de enfermedades requieren recetas que incluyen varios medicamentos, para atacar sus síntomas. En dicho sentido se puede hacer otra analogía “Si la crisis del software es la enfermedad, la ingeniería de software es la medicina”.

Introdución al análisis y diseño.

Les quiero dar la bienvenida a este Blog que tiene como fin publicar algunos apuntes sobre diseño de software. Esencialmente el blog se enfoca en modelado desde los conceptos más básicos y como estos modelos pueden llevarse a una implementación.

Para empezar quiero hacer una introducción al análisis y diseño orientado a objetos.

Análisis y diseño OO.

Introducción.

En los modelos de procesos del software como el modelo en cascada, desarrollo evolutivo, desarrollo en espiral y en modelos iterativos, las etapas de análisis y diseño son consideradas como los dos primeros pasos para abordar un proyecto software, sin embargo en muchos modelos denominados agiles se enfocan menos esfuerzos en el análisis y diseño detallado destinando más esfuerzo y tiempo en la codificación y pruebas, lo que ha despertado una discusión interesante a partir de si es importante o no tener un diseño detallado que requiere mucho tiempo y esfuerzo, en este sitio no se pretende tomar una postura en la discusión, solo se ilustran algunos conceptos basicos. 

En la figura se ilustran las etapas del modelo en cascada y sobresalen en color rojo las etapas de análisis y diseño.

 

Como su nombre lo indica el análisis y diseño OO, están fuertemente relacionado con la programación OO, en el pasado y aun en algunos sistemas de actuales se usa el modelo estructurado y se hablaba de análisis y diseño estructurado. El análisis y diseño OO, están destinados a ofrecer mecanismos que permitan abordar un proyecto software cualesquiera independiente del lenguaje de implementación siempre y cuando se ajuste al paradigma objeto.

Análisis OO.

El análisis OO comprende el desarrollo de un modelo OO del dominio de la aplicación. Los objetos identificados reflejan las entidades y operaciones que se asocian con el problema a resolver.

         Sommerville, 2005

Típicamente el análisis OO se enfoca en los requerimientos y las actividades que tienen que ver con ellos tales como el levantamiento (recolección), análisis, especificación, validación y control de cambios.

Diseño OO.

El diseño orientado a objetos comprende el desarrollo de un modelo OO de un sistema de software para implementar los requerimientos identificados. Los objetos en un diseño OO están relacionados con la solución del problema por resolver. Pueden existir relaciones estrechas entre muchos objetos del problema y algunos objetos de la solución, pero inevitablemente el diseñador tiene agregar nuevos objetos para transformar los objetos del problema e implementar la solución.

Sommerville, 2005

El diseño OO está enfocado en el “cómo” y su “solución lógica”, apoyado en el análisis el diseño se encarga de establecer elementos arquitectónicos que permitan implementar la solución al problema en cuestión, para lo cual se vale de diferentes vistas que proporcionan perspectivas orientadas a usuarios, programadores, probadores y de mas actores implicados en el proceso del software.

Fuentes

1. Sommerville, Ian. 2005. Ingeniería del software