Archivo

Archive for the ‘Análisis y diseño orientados a objetos con UML’ Category

Casos de uso en nuestro caso de estudio

22 junio, 2010 3 comentarios

1. Identificamos los actores y los casos de uso.

En nuestro caso de estudio el único actor que hay es el Usuario que va a manejar la interfaz gráfica del simulador de la cantera. La interfaz gráfica del simulador dispondrá de dos campos para introducir una fecha y una hora para poder probar la funcionalidad del sistema.

A partir de los requerimientos del sistema software que nos dió el director de la empresa Canteras S.L podemos identificar una serie de casos de uso:

- Registrar cliente.
– Registrar empresa.
– Registrar cliente fisíco.
– Registrar vehículo.
– Registrar solicitud.
– Registrar entrada de vehículo.
– Registrar salida de vehículo.

- Ver clientes.
– Ver vehículos.
– Ver solicitudes.
– Ver cargas (albaranes).
– Ver facturas.
– Ver cuadrantes.

- Iniciar simulación.
– Detener simulación.

- Programar explosiones.
– Ejecutar explosiónes.

2. Escribimos los casos de uso en el formato de alto nivel.

Caso de uso: Registrar cliente
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra un cliente en el sistema rellenando los datos del cliente. El sistema comprueba si el cliente existe.  Sino existe registra el cliente en el sistema.
Caso de uso: Registrar vehiculo
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra un vehiculo en el sistema rellenando los datos del vehículo. El sistema comprueba si el vehiculo existe.  Sino existe registra el vehiculo en el sistema.
Caso de uso: Registrar solicitud
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra una solicitud en el sistema rellenando los datos de la solicitud.
Caso de uso: Registrar entrada de vehículo
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra la entrada de un vehículo en el sistema. El sistema comprueba si el vehículo puede entrar.  Sino no le permite el acceso.
Caso de uso: Registrar salida de vehículo
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra la salida de un vehículo que está cargando en el sistema.
Caso de uso: Ver clientes
Actores:  Usuario
Tipo: Primario
Descripción: Muestra una lista de los clientes registrados en el sistema.
Caso de uso: Ver solicitudes
Actores:  Usuario
Tipo: Primario
Descripción: Muestra una lista de las solicitudes registradas en el sistema.
Caso de uso: Ver vehículos
Actores:  Usuario
Tipo: Primario
Descripción: Muestra una lista de los vehículos registrados en el sistema.
Caso de uso: Ver cargas
Actores:  Usuario
Tipo: Primario
Descripción: Muestra una lista de las cargas registradas en el sistema.
Caso de uso: Ver facturas
Actores:  Usuario
Tipo: Primario
Descripción: Muestra una lista de las facturas registradas en el sistema.
Caso de uso: Ver cuadrantes
Actores:  Usuario
Tipo: Primario
Descripción: Muestra los cuadrantes de la cantera con su estado, explosiones y cargas.
Caso de uso: Iniciar simulacion
Actores:  Usuario
Tipo: Primario
Descripción: Inicia la simulacion de la cantera.
Caso de uso: Detener simulacion
Actores:  Usuario
Tipo: Primario
Descripción: Detiene la simulacion de la cantera.
Caso de uso: Programar explosiones
Actores: Ningún actor interviene en este caso de uso.
Tipo: Primario
Descripción: Programa las explosiones en los cuadrantes de la cantera dependiendo de las solicitudes registradas.
Caso de uso: Ejecuta las explosiones
Actores: Ningún actor interviene en este caso de uso.
Tipo: Primario
Descripción: Ejecuta las explosiones que han sido programadas.

3. Relacionamos los casos de uso.

El caso de uso Iniciar simulación es el caso de uso de arranque o de inicio. La mayoría de sistemas cuentan con un caso de uso de arranque y no suele mostrarse en el diagrama de casos de uso. Pero en nuestro caso vamos a mostrarlo porque en nuestro sistema simulador este caso de uso utilizará los casos de uso Programar explosiones y Ejecutar explosiones. Además el usuario no podrá utilizar los demás casos de uso si el caso de uso de arranque no se ha producido. Pero eso lo veremos más tarde en el diseño y la implementación.

Los casos de uso más importantes que satisfacen el requisito funcional más importante de nuestro sistema software son Programar explosiones y Ejecutar explosiones. Estos casos de uso no los inicia el actor Usuario de forma directa. Son incluidos en el caso de uso Iniciar Simulación, de tal forma que cuando el usuario inicie la simulación con una fecha y una hora el sistema inicie estos casos de uso.

Si el sistema no fuera un simulador de una cantera donde el usuario introduce la fecha y la hora, y fuera un sistema software para una cantera en la cual se programaran las explosiones de acuerdo a la hora del sistema podríamos haber considerado el tiempo como un actor posible y eliminar los casos de uso Iniciar Simulación y Detener Simulación ya que estos dos casos de uso no representarían procesos de negocio dentro del problema que queremos resolver y no entrarían en la categoría de caso de uso, más bien de transacción. De esta forma tendríamos dos actores, Tiempo y Usuario y los casos de uso Programar Explosiones y Ejecutar Explosiones los iniciaría el actor Tiempo.

Por otro lado vemos que los casos de uso también soportan generalización y especialización. El caso de uso Registrar Cliente es el caso base y puede iniciar el caso de uso Registrar empresa o Registrar cliente fisico dependiendo del tipo de cliente que queramos registrar.

4. Dibujamos un diagrama de casos de uso.

Como vemos nos ha quedado un diagrama de casos de uso inmenso que muestra todos los casos de uso del sistema que vamos a desarrollar así como las relaciones entre los diferentes actores y los casos de uso. Afortunadamente en nuestro sistema simulador solo existe un actor.

5. Escribimos el formato expandido de los casos de usos más importantes.

Los casos de usos más importantes son Programar explosiones y Ejecutar explosiones ya que son dos de los requisitos más importantes para que funcione el simulador de la cantera. Vamos a describir de momento los casos esenciales de uso expandidos de estos dos casos de uso.

Caso de uso: Programar explosiones
Actores: Ningún actor interviene en este caso de uso.
Propósito: Programar las explosiones en función de las solicitudes registradas en la cantera
Tipo: Primario
Descripción: El sistema programa las explosiones que se producen en los cuadrantes de la cantera en función de las toneladas de áridos que demanden las solicitudes en trámite de la cantera.
Curso normal de los eventos:
1. El sistema obtiene la fecha y la hora de la simulación.
2. El sistema obtiene todas las solicitudes en trámite registradas para esa fecha y una hora entre las 08:00 y las 15:00.
3. El sistema calcula las toneladas totales de todas las solicitudes.
4. El sistema obtiene los cuadrantes donde se puedan realizar explosiones.
5. El sistema calcula el número de explosiones a programar y sus categorías.
6. El sistema programa el número de explosiones en los primeros cuadrantes donde se pueda explosionar.
Cursos alternos:
Línea 2: El sistema obtiene todas las solicitudes en trámite registradas para esa fecha y una hora entre las 15:00 y las 24:00.
Línea 4: No hay cuadrantes disponibles.
Línea 5: El número de explosiones sobrepasa el número de cuadrantes disponibles.
Caso de uso: Ejecutar explosiones
Actores: Ningún actor interviene en este caso de uso.
Propósito: Ejecutar las explosiones programadas de la cantera.
Tipo: Primario
Descripción: El sistema ejecuta las explosiones que estén programadas en la cantera.
Curso normal de los eventos:
1. El sistema obtiene la fecha y la hora de la simulación.
2. El sistema obtiene las explosiones programadas.
3. El sistema ejecuta las explosiones programadas.
Cursos alternos: 
No hay cursos alternos.

RESUMEN

Aquí acaba nuestro proceso de planificación. Ya hemos identificado y descrito los requerimientos y los casos de uso principales y construido el diagrama de casos de uso. Ahora planificaremos una serie de ciclos iterativos en los que realizaremos versiones cada vez con más funcionalidades del sistema software que vamos a desarrollar. Cada ciclo iterativo contará con una serie de etapas de Análisis, Diseño e Implementación.

En la primera etapa del análisis construiremos el modelo conceptual completo del dominio de la cantera identificando las clases. Analizaremos con más detalle los casos de uso Registrar cliente, Registrar Solicitud, Registrar Vehículo, Ver clientes, Ver solicitudes y Ver vehículos. Aprenderemos a  construir diagramas de secuencias para identificar las  operaciones del sistema y crearemos contratos para las operaciones del sistema.

En la primera fase del diseño describiremos los casos reales de uso de los casos de uso Registrar cliente, Registrar Solicitud, Registrar Vehículo, Ver clientes, Ver solicitudes y Ver vehículos. Aprenderemos a crear diagramas de colaboración y a utilizar los patrones Grasp para asignar responsabilidades a los objetos. Diseñaremos parte de la interfaz gráfica para poder hacer frente a los casos de uso que tratamos en el primer ciclo. Diseñaremos la arquitectura que tendrá el futuro sistema software que implementemos. Aprenderemos a crear diagramas de clase en UML.

Por último en la fase de implementación, programaremos en C# las clases diseñadas, parte de la interfaz gráfica y toda la lógica necesaria para hacer frente a los casos de uso que trataremos en el primer ciclo de desarrollo.

Nos queda un gran camino por delante hasta que nuestro sistema sea capaz de simular el funcionamiento de una cantera cumpliendo con todos los requerimientos funcionales que el director de la empresa Canteras S.L desea.

Introducción a los casos de uso

22 junio, 2010 4 comentarios

Ya hemos realizado una entrevista al director de la empresa Canteras S.L y tenemos un nuestro poder un documento que especifíca los requisitos funcionales que debe tener el sistema software que desarrollemos.

Casos de uso

Una buena manera de comprender los requerimientos es creando casos de uso.

Un caso de uso es un documento narrativo que describe el comportamiento de un sistema desde el punto de vista de un actor. El actor es una entidad externa del sistema que participa en el caso de uso, suelen ser seres humanos o cualquier tipo de sistema.

Para entenderlo mejor vamos a poner un ejemplo. En nuestro caso de estudio podemos identificar a partir de los requerimientos el caso de uso Registrar empresa y el actor Usuario que es el que registrará la empresa en el sistema mediante una interfaz gráfica.

Un error común es identificar las operaciones o transacciones individuales como casos de uso. Un ejemplo de esto en nuestro caso de estudio es identificar la operación de comprobar si la empresa está registrada en la cantera como un caso de uso. Esa operación forma parte del caso de uso Registrar empresa, pero no es un caso de uso en sí.

Los casos de uso son descripciones amplias de un proceso de negocios, esta descripción abarca muchos pasos o transacciones.

Podemos identificar los casos de uso de nuestro sistema software a partir de los actores. Para ello primero identificamos a los actores y para cada actor vemos los procesos de negocios que inicia o en los que participa.

Diagramas de casos de uso

UML no especifica un formato para describir casos de uso. UML utiliza diagramas de casos de uso para explicar gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre estos y los casos de usos.

Formatos de casos de uso

Narrativamente podemos escribir un caso de uso en diferentes formatos y con diferentes niveles de detalle:

- Formato de alto nivel: Un caso de uso de alto nivel describe un proceso de negocios del sistema muy brevemente. Utilizamos este tipo de formato durante el examen inicial de los requerimientos para entender rapidamente la funcionalidad del sistema.

Una muestra de un caso de alto nivel:

Caso de uso: Registrar empresa
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra una empresa en el sistema rellenando los datos de la empresa. El sistema comprueba si la empresa existe. Sino existe registra la empresa en el sistema.

- Formato expandido: Un caso de uso expandido describe un proceso de negocios más a fondo que el de alto nivel. Durante la fase del análisis conviene escribir en este formato solo los casos más importantes.

Una muestra de dos casos expandidos:

Caso de uso: Registrar empresa
Actores:  Usuario
Propósito: Registrar una empresa en el sistema.
Tipo: Primario
Descripción: El usuario registra una empresa en el sistema rellenando los datos de la empresa. El sistema comprueba si la empresa existe.  Sino existe registra la empresa en el sistema.
Curso normal de los eventos:
1.El usuario introduce los datos de la empresa que quiere registrar.
2.El sistema busca entre las empresas registradas si existe una empresa con el mismo identificador.
3.El sistema informa al usuario que la empresa se ha registrado satisfactoriamente.
Cursos alternos:
Línea 3: El sistema informa al usuario que ya existe una empresa con el mismo identificador registrada en el sistema.
Caso de uso: Registrar vehículo
Actores:  Usuario
Propósito: Registrar un vehículo en el sistema.
Tipo: Primario
Descripción: El usuario registra un vehículo a una empresa en el sistema rellenando los datos del vehiculo. El sistema comprueba si el vehiculo existe.  Sino existe registra el vehiculo en el sistema.
Curso normal de los eventos:
1.El usuario introduce los datos del vehículo que quiere registrar.
2.El sistema muestra una lista de empresas registradas en el sistema
3.El usuario selecciona una empresa.
4.El sistema busca la empresa seleccionada y muestra los datos de la empresa.
5.El sistema busca en los vehiculos registrados si el vehiculo ya esta registrado en el sistema.
6.El sistema registra el vehiculo en la empresa y muestra un mensaje satisfactorio al usuario.
Cursos alternos:
Línea 6: El sistema no registra el vehiculo y muestra un mensaje informando al usuario que el vehiculo ya está registrado.

Caso esenciales de uso y casos reales de uso

Los casos esenciales de uso son casos que se expresan de forma muy abstracta, sin detalles de implementación. Los detalles de diseño se dejan para la etapa del diseño.

En la etapa del diseño veremos los casos reales de uso. Estos casos de uso describen concretamente el proceso de negocios con detalles de diseño y sujeto a tecnologías de entrada y salida, como por ejemplo la interfaz gráfica.

Casos de uso dentro de un proceso de desarrollo

En la fase de planificación y especificación de requerimientos (en la que estamos ahora) después de haber definido los requerimientos del sistema software estamos preparados para identificar los casos de uso.

1. Identificamos los actores y los casos de uso.
2. Escribimos los casos de uso en el formato de alto nivel.
3. Relacionamos los casos de uso.
4. Dibujamos un diagrama de casos de uso.
5. Escribimos en el formato expandido los casos de uso más importantes.

En la fase de análisis escribimos los casos esenciales de uso en formato expandido para los que todavía no lo hemos hecho.

En la fase de diseño escribimos los casos reales de uso a partir de los casos esenciales de uso de la fase del análisis.

RESUMEN

Ya hemos visto la teoría de los casos de estudio y ya estamos preparados para identificar los casos de uso de nuestro caso de estudio y de dibujar un diagrama de casos de uso que muestre las relaciones de los actores y los casos de uso de nuestro caso de estudio.

Caso de estudio: Simulador de una cantera

22 junio, 2010 Deja un comentario

El caso de estudio que vamos a tratar es un sistema simulador de una cantera. La empresa Canteras S.L (empresa totalmente ficticia) nos ha contratado para que le realizemos un sistema software que le permita integrar y sistematizar un conjunto de tareas que se llevan a cabo en su cantera.

Así que concertamos una entrevista para que el director de la empresa nos hable en persona un poco de como funciona su cantera y que funcionalidades debe incluir el sistema software que desarrollemos.

Nuestro analista, Francisco Belmonte va a ser el encargado de realizarle una entrevista para poder desarrollar una especificación de requerimientos que sirva como base para comenzar el proceso de análisis.

ENTREVISTA

Analista:
– Cuentéme un poco sobre su negocio.

Director:
– Bueno, somos una empresa que lleva más de 100 años en activo. Nos dedicamos a la explotación minera. Tenemos una cantera de donde extraemos piedra, greda y otros tipos de áridos. Estos áridos tienen distintas aplicaciones en la construcción ya sea para construir carreteras, paredes, hormigón, o en la industria para fabricar cemento, vidrio o acero.

Analista:
-Veo que el negocio ha funcionado muy bien ya que lleva activo mucho tiempo.

Director:
– Sí, la verdad es que funciona bastante bien, pero lo malo es que seguimos funcionando igual que hace 100 años cuando no existían sistemas que pudieran automatizarnos tareas. Cogemos cada día todas las solicitudes de las empresas que nos llaman y programamos explosiones para sacar los áridos en función a las toneladas que nos demandan. Lo que queremos es un sistema que permita automatizar todo este proceso.

Analista:

– Bueno, vayamos por partes. Por lo que he entendido para extraer áridos primero hay que programar una serie de explosiones. ¿Cuántas explosiones realizais al día?

Director:
– En la cantera cada día se suelen programar mínimo dos explosiones controladas de pólvora para extraer los áridos demandados. Una se programa a las 06:00 y se ejecuta a las 08:00. La otra se programa a la 13:00 para ser ejecutada a las 15:00.

Analista:
– ¿Que son los áridos demandados?

Director:
– Pues las empresas que tenemos registradas en la cantera pueden llamarnos por teléfono para solicitar una cantidad de toneladas de áridos.

Analista:
– Entonces, las empresas os llaman, os solicitan una cantidad de áridos y programais una explosión para extraer los áridos demandados. ¿Qué haceis con esos áridos cuando se han extraído?

Director:
– Le explico para que no se pierda. Nosotros no tenemos un servicio de entrega de áridos, así que las empresas que nos solicitan los áridos tienen que entrar dentro de la cantera con un vehículo que pueda cargar la cantidad de áridos seleccionados. Otra cosa, nosotros no programamos una explosión por cada solicitud, lo que hacemos es calcular las toneladas totales de todas las solicitudes que quieren cargar y programamos una explosión de cierta categoría para poder extraer los áridos.

Analista:
– ¿Que significa eso de explosión de cierta categoría?

Director:
– Clasificamos las explosiones que se pueden producir en cuatro categorías. Las explosiones de nivel uno permiten extraer 50 toneladas de áridos, las de nivel dos permiten extraer 30 toneladas de áridos, las explosiones de nivel tres permiten extraer 15 toneladas, y la de nivel 4 permite extraer 5 toneladas.

Analista:
– A ver si lo he entendido, calculais el total de toneladas y programais una explosión de una categoría que pueda cubrir los áridos demandados.

Director:

– Exacto, con una condición. Si la demanda de áridos es suficiente programamos las explosiones de menor nivel.

Analista:
– ¿Y qué pasa cuando las toneladas totales de áridos sobrepasa las 50 toneladas?

Director:
– En ese caso, programamos más de una explosión si quedan cuadrantes activos para explosionar.

Analista:
– ¿Qué es eso de cuadrantes activos para explosionar?

Director:
– Nuestra cantera está dividida en 4 secciones consecutivas: A,B,C y D, las cuales delimitan horizontalmente la superficie de la cantera. Verticalmente la cantera se delimita en filas: 1,2,3,4 y 5. Cada explosión se ejecuta en una sección y una fila determinada, es lo que se conoce como cuadrante.

Analista:
– Vale, vamos a hacer un pequeño resumen de lo visto hasta ahora. La cantera cuenta con una serie de cuadrantes donde realizais explosiones para extraer áridos. Esos áridos que extraeis os los demandan las empresas que tienen vehículos que pueden entrar en la cantera a cargar. Programais dos explosiones al día o más si hace falta de distintas categorías. Las explosiones de las 08:00 tienen en cuenta aquellas solicitudes que quieran cargar hasta las 15:00. Y las explosiones de las 15:00 tienen en cuenta las solicitudes que quieren cargar de 15:00 a 24:00. ¿No es así? ¿Se me pasa algo por alto?

Director:
– Es una buena forma de resumirlo. Tambien tiene que tener en cuenta que los clientes físicos pueden entrar en la cantera a cargar también.

Analista:
-¿No es lo mismo una empresa que un cliente físico?

Director:
– No. Hacemos distinción. Las empresas pueden solicitar áridos por teléfono. Los clientes físicos no pueden solicitar áridos, pero pueden entrar a la cantera a extraer áridos siempre que sobren.

Analista:
– Entendido. Ya hemos visto como funciona de forma general la cantera. ¿Qué funcionalidades desea que tenga el sistema que quiere que desarrollemos?

Director:
– Les he preparado un documento que especifica todas las funcionalidades que quiero que tenga el sistema software.

El director le acerca el documento a nuestro analista Francisco, que le echa un vistazo y lee lo siguiente:

ESPECIFICACIÓN DE REQUERIMIENTOS

El sistema software debe gestionar las siguientes tareas:

- Registro de Clientes (Empresas y Personas Físicas). De cada cliente se debe registrar su nombre y dirección. En el caso de las empresas también su CIF y teléfono. Para las personas físicas se registrará el DNI.

- Registro de Solicitudes. De cada solicitud se registrará: fecha, hora, cantidad toneladas solicitada y empresa cliente. Es necesario controlar el estado de la solicitud (en trámite, ejecutada, o desestimada).

- Registro de Entrada y Salida de Vehículos. Las cargas que se realicen en el sistema deberán quedar registradas, para ello es necesario identificar: matrícula del vehículo, fecha de entrada, hora de entrada, nombre conductor, fecha salida, hora salida, toneladas cargadas.

- Programación de Explosiones. Cada día a las 6:00 y a la 13:00 se programará una explosión. Los requisitos para programar las explosiones son:
1. El nivel y número de explosiones se determinará en función de la demanda de áridos. Para ello se deberá tener en cuenta las solicitudes en trámite que tiene la cantera.
2. La ubicación de la explosión se realizará teniendo en cuenta que es necesario ir rotando por los distintos cuadrantes.

- Facturación. El día 25 de cada mes se debe facturar a las empresas clientes las diferentes cargas que hayan realizado desde el día 25 del mes anterior.

- La interfaz gráfica debe mostrar el estado de todos los cuadrantes, así como los clientes registrados, las solicitudes, las cargas realizadas, los vehiculos registrados y las facturas facturadas.

FINAL DE  LA ENTREVISTA

Analista:
– Este documento nos servirá como especificación de los requerimientos funcionales del sistema que tenemos que desarrollarle. Iremos desarrollando diferentes versiones que vayan englobando funcionalidades, así podrá ir viendo que es lo que vamos creando.

Director:
– Pues muchas gracias por todo, Francisco. Un placer tratar con usted.

El analista se marcha. Reúne a su equipo de desarrollo y le explica como ha ido la entrevista, les entrega una copia de la documentación que les ha proporcionado el director de Canteras S.L y juntos comienzan el proceso de análisis.

Análisis y diseño orientado a objetos con UML siguiendo un caso de estudio. (II)

22 junio, 2010 Deja un comentario

Creamos sistemas software para hacer frente a un problema de negocios que queremos solucionar. Lo que no podemos hacer es comenzar a escribir código sin tener una idea del sistema en general, eso está bien cuando el sistema es pequeño o cuando empezamos a aprender a programar pequeños ejercicos como una calculadora. Pero cuando queremos construir un sistema de tamaño mediano o grande necesitamos seguir un proceso de desarrollo. Existe una diversidad de modelos diferentes de procesos de desarrollo que podemos utilizar (RUP, programación extrema, etc). En este curso no vamos a dar mucha importancia al proceso de desarrollo porque lo que pretendo es aprender a realizar buenos análisis y diseños desde la perspectiva de los objetos independiente del proceso de desarrollo que sigamos.

La mayoría de procesos de desarrollo tiene una serie de actividades en común, dos de ellas son el análisis y el diseño.

El análisis se centra en la investigación del problema que queremos solucionar, no en la manera de definir una solución. La actividad principal del análisis es identificar los objetos dentro del dominio del problema al que nos enfrentamos.

El diseño refina y extiende los modelos desarrollados en el análisis
para generar una especificación orientada a la solución del sistema software.

Como bien dice el libro de Craig Larman, la división entre el análisis y el diseño es poco clara. Cuando empezé estudiando este mundillo tenía la necesidad de saber diferenciar bien que pasos equivalían al análisis y que pasos al diseño, esto me llevaba a veces a no comprender bien los conceptos. Podemos ver las dos actividades como un continuo donde el análisis responde a la pregunta ¿qué es lo que queremos hacer? y el diseño a la pregunta ¿cómo lo vamos a hacer?

Vamos a utilizar UML para visualizar los diferentes modelos o artefactos que vamos a ir desarrollando para documentar nuestro caso de estudio. UML es un lenguaje gráfico que utilizamos para construir los modelos de nuestro sistema software. Cuenta con un conjunto de diagramas que iremos viendo cuando los vayamos necesitando.

El proceso de desarrollo va a ser como el del libro, uno iterativo dirigido por los casos de usos, muy similar al Proceso Unificado de Rational. Pero en este caso vamos a ir haciedo versiones cada vez con mayor funcionalidad debido al tamaño del caso de estudio que vamos a realizar. Sobre la marcha iremos definiendo los diferentes incrementos que vayamos realizando. Eso sí, el modelo conceptual del dominio lo vamos a ver completo desde el primer incremento.

Realmente podíamos haber elegido un proceso de desarrollo en cascada, porque en el caso de estudio que ahora veremos tenemos claramente los requerimientos y sabemos que no van a cambiar.

En el siguiente artículo os pondré la especificación de requerimientos y os explicaré un poco el caso de estudio que vamos a crear, en concreto, un simulador de una cantera de minerales, piedras y esas cosas.

Análisis y diseño orientado a objetos con UML siguiendo un caso de estudio.

21 junio, 2010 Deja un comentario

Este va a ser uno de los proyectos más ambiciosos de este blog. Voy a tratar de redactar una serie de artículos que expliquen métodos y técnicas utilizadas en el análisis y diseño de sistemas software orientados a objetos utilizando un caso de estudio. La idea de realizar este proyecto surgió cuando estaba releyendo el libro UML y patrones de Craig Larman donde el autor utiliza un caso de estudio para explicar buenas prácticas de análisis y diseño orientado a objetos. El caso de estudio en cuestión es un sistema de punto de ventas utilizado en muchas tiendas. El autor mediante este caso de estudio planifica un proceso de desarrollo iterativo basado en los casos de uso y explica el papel de UML en las etapas de análisis y desarrollo comunes a casi todos los procesos de desarrollo. Además introduce el uso de patrones GRASP para asignar responsabilidades a los objetos, así como el uso de otros patrones de diseño incluidos en el libro de los 23 patrones de diseño que he recomendado antes.

UML es un lenguaje gráfico para construir modelos, no guía al desarrollador en la forma de realizar buenos análisis y diseños, ni le indica cual proceso de desarrollo adoptar. La idea de esta serie de artículos va más allá de aprender la notación UML utilizada para diseñar y construir sistemas software orientados a objetos de buena calidad independiente del proceso de desarrollo utilizado. Guiará al desarrollador principiante como yo a realizar buenos análisis y diseños orientados a objetos utilizando patrones de diseño.

El caso de estudio que vamos a tratar es el simulador de la cantera que he diseñado para las prácticas de la asignatura Ingeniería del software de la universidad. Voy a intentar realizarlo todo más o menos siguiendo la temática del libro UML y patrones de Craig Larman. De esta forma me sirve a mí mismo para mejorar la implementación y el diseño que realizé y afirmar todo lo aprendido. Como soy un novato principiante en este mundillo, si algún lector sigue mis artículos y encuentra alguna burrada sería recomendable que me avisara para rectificarlo. De todas formas este curso va a seguir una bibliografía recomendada así que me voy a basar en principios reales y no inventar conceptos nuevos.

En este curso, aprenderemos a crear modelos conceptuales del dominio del problema al que nos enfrentamos y a representarlos mediante diagramas de clases en UML.  Aprenderemos a extraer los casos de usos funcionales a partir de la especificación de requerimientos del sistema que vamos a desarrollar y a representarlos mediante diagramas de casos de uso en UML. Aprenderemos a realizar diagramas de secuencia, de colaboración y de estado en UML. Paralelamente a este curso voy a intentar redactar otros artículos dedicados exclusivamente a los patrones de diseño, esta vez sin seguir un caso de uso, sino a partir de ejemplos donde podamos aplicarlos.

Este proyecto puede durar mucho tiempo, debido a que paralelamente estoy redactando otros cursillos de PHP, y MySQL que incorporar al blog. Además en unas semanas empiezo a trabajar diseñando una aplicación de gestión inmobiliaria, así que no voy a tener mucho tiempo libre.

En breves os explicaré el caso de estudio y realizaremos una especificación de funcionalidades que incorporar a nuestro sistema software. La implementación la desarrollaremos en el lenguaje C#. Para este curso voy a presuponer que se tienen ciertos conocimientos de la metodología orientada a objetos, así como del lenguaje C# y de construcción de aplicaciones mediante formularios windows. No va a tener acceso a base de datos para simplificar un poco el desarrollo. Ya explicaré el sistema que realizaremos para cargar y guardar datos.

Hasta la próxima.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 127 seguidores