Anda di halaman 1dari 7
Análisis de Sistemas Diseño Orientado a Objetos Este documento es la base fundamental de todo proyecto
Análisis de Sistemas
Diseño Orientado a Objetos
Este documento es la base fundamental de todo proyecto informático, pues, facilita la toma de
decisiones acerca de la identificación de clases, objetos, polimorfismo y herencia del sistema mediante
un proceso de cinco pasos.
Análisis de Sistemas Diseño Orientado a Objetos Este documento es la base fundamental de todo proyecto

Análisis de Sistemas

Diseño Orientado a Objetos

Este documento es la base fundamental de todo proyecto informático, pues, facilita la toma de decisiones acerca de la identificación de clases, objetos, polimorfismo y herencia del sistema mediante un proceso de cinco pasos:

  • 1. Recoger requerimientos.

  • 2. Describir la aplicación.

  • 3. Identificar los objetos principales.

  • 4. Describir las interacciones.

  • 5. Crear un diagrama de clases.

  • 1. RECOGER REQUERIMIENTOS.

¿Qué problema va a resolver la aplicación?, ¿Qué

necesita hacer?

Se debe escribir específicamente todo aquello que en

realidad se necesita que haga la aplicación, es aquí donde se solucionan de manera anticipada aquellos conflictos que surgen de las ideas de los usuarios y los programadores sobre lo que debería y no debería hacer la aplicación en contra lo que realmente va a hacer.

Los requerimientos pueden ser expresados de manera resumida mediante frases que expresen lo que debe y/o no debe hacer el sistema, como por ejemplo:

Requerimientos funcionales

  • - El sistema debe:

o

permitir al usuario buscar clientes por

o

apellido, número de teléfono y cedula de identidad. Permitir generar avisos por e-mail.

o

Producir automáticamente de manera

o

mensual reportes corporativos (usando el mes actual y comparándolo con el mismo mes del periodo anterior), el reporte debe contener … impedir la modificación de algunos datos previamente almacenados en el sistema…

Construir

mejores

aplicaciones.

Comprende

Planifica

Construye

Con este documento se busca evitar que te sientes frente al editor

de código y al el cursor

mirar

parpadeante, pienses:

-

¿Y ahora qué hago?

Porque la respuesta

siempre será:

-

¡Aléjate del código!,

toma este documento, rellena sus formularios y luego ¡Manos a la obra!

Análisis de Sistemas

1
1

Análisis de Sistemas

2
2

Construir

mejores

aplicaciones.

Claridad

Agilidad

Precisión

Mantenibilidad

Los programadores quieren ir directamente al editor de código y cuando lo hacen, sienten que están avanzando pero, muchas veces es una ilusión, puede que a veces esto funcione pero, en la gran mayoría de los trabajos, sentarte directamente a escribir código, sin antes haber planificado, te llevara a escribir masas

inmensas de código; cuando este punto llega, tu progreso volver más lento y tu

se va a

código difícil de

mantener

Requerimientos no funcionales

Los requerimientos no funcionales son aquellos que no intervienen en el comportamiento del sistema pero deben ser tomados muy en cuenta, ejemplo:

 
  • - Ayuda:

o

El sistema debe contar con manuales de usuario, video-tutoriales, tooltips, todos los anteriores, etc.

  • - Rendimiento:

o

Cuántas personas usaran la aplicación.

  • - Soporte:

o

El sistema no debe tardar más de 5seg en

responder…

o

¿Es necesario tener disponible el soporte técnico

o

fuera de horarios de oficina? ¿Por qué? Vías de soporte idóneas para el sistema (Presencial, telefónico, chat, escritorio remoto, etc.)

  • - Aspectos legales: Si el sistema almacenará información de los usuarios y/o sus clientes u objetos de trabajo, seguramente habrá que ceñirse a ciertas reglas normas o incluso leyes, esto debe quedar muy claro y debidamente documentado, con la asesoría de personal calificado.

    • 2. DESCRIBIR LA APLICACIÓN.

Se trata de escribir unos pocos párrafos en lenguaje narrativo, simple y desde el punto de vista del usuario,

que de una manera muy descriptiva, te ayuden a especificar qué es lo que va a hacer la aplicación y para

quien lo va a hacer. Estaremos incluyendo “Casos de uso” e “Historia de usuario”.

No se bebe ser exhaustivo, por el contrario se debe ser minimalista para establecer una descripción que simiente la aplicación, incluso se puede esbozar algunos elementos de la interfaz gráfica de usuario pero esto será puro relleno por ahora.

  • 3. IDENTIFICAR LOS OBJETOS PRINCIPALES.

Se extraen los conceptos más importantes de las descripciones anteriores y se descartan los no importantes. No todo lo que saques se convertirá en clases pero, seguramente muchos de ellos si lo harán.

  • 4. DESCRIBIR LAS INTERACCIONES.

Describimos formalmente los comportamientos, las

interacciones entre los objetos y el orden en que se ejecutaran, una manera de hacer esto es mediante un

“Diagrama secuencial”.

5.

HACER UN DIAGRAMA DE CLASES.

Este es una representación visual de las clases necesarias y es aquí donde se analiza la herencia y el

polimorfismo.

Análisis de Sistemas

3
3

Análisis de Sistemas

Contenido

1

2

Recoger requerimientos .............................................................................................................................................

5

Requerimientos funcionales

5

5

¿Qué

5

Requerimientos no funcionales .............................................................................................................................

6

Ayuda

6

 

Rendimiento

6

Soporte

6

6

4
4

Recoger requerimientos

Requerimientos funcionales

¿Qué problema va a resolver la aplicación?

Recoger requerimientos Requerimientos funcionales ¿Qué problema va a resolver la aplicación? ¿Qué necesita hacer? 5 Análisis

¿Qué necesita hacer?

5 Análisis de Sistemas
5
Análisis de Sistemas

Análisis de Sistemas

6
6

Requerimientos no funcionales

Ayuda Rendimiento
Ayuda
Rendimiento
Análisis de Sistemas 6 Requerimientos no funcionales Ayuda Rendimiento Soporte Aspectos legales

Soporte

Análisis de Sistemas 6 Requerimientos no funcionales Ayuda Rendimiento Soporte Aspectos legales

Aspectos legales

Análisis de Sistemas 6 Requerimientos no funcionales Ayuda Rendimiento Soporte Aspectos legales