Este documento describe los casos de uso, su estructura y documentación. Explica que existen dos formatos principales para documentar casos de uso: diagramas UML y documentos detallados. También define el análisis y diseño orientado a objetos, sus características principales y cómo difiere de la programación imperativa/procedimental. Finalmente, enumera lenguajes de programación orientados a objetos como Java, C++ y Python.

1. ACTIVIDAD
Estructura de casos de uso
Presentado por:
Carlos Andrés Pérez Cabrales
Tutor:
Luis Manuel Cabrales
Centro Educativo Nacional De Aprendizaje
Región Montería
Curso Virtual
Ficha: 476461- DISEÑO DE CASO DE USO
Servicio Nacional de Aprendizaje - SENA
Montería
Junio - 26 – 2013

2. INTRODUCCIÓN
Eltérmino de Programación Orientada a Objetos indica más una forma de diseño y
una metodología de desarrollo de software que un lenguaje de programación, ya
que en realidad se puede aplicar el Diseño Orientado a Objetos
(En inglés abreviado OOD, Object Oriented Design), a cualquier tipo de lenguaje
de programación.
El desarrollo de la OOP empieza a destacar durante la década de los 80 tomando
en cuenta la programación estructurada, a la que engloba y dotando al
programador de nuevos elementos para el análisis y desarrollo de software.

3. 1. ¿QUÉ FORMATO SE EMPLEA PARA DOCUMENTAR CASOS DE USO?
Existen dos formas principales de documentar un caso de uso:
 Un diagrama en UML:
El Lenguaje Unificado de Modelado (UML) provee de un grupo de elementos
gráficos para representar un Caso de Uso, de manera explícita, sucinta y
esquemática. Utiliza un monito para representar a los actores, una elipse con una
leyenda para representar un caso de uso y una línea recta entre un actor y un
caso de uso para representar la asociación entre ellos.
 Un documento detallado:
Se utiliza una plantilla (en un procesador de textos) con un formato de documento
a llenar.

4. Caso de uso: Nombre del caso de uso
Actores: Actores primarios y secundarios que interaccionan con el caso
de uso
Tipo: Tipo de flujo básico, inclusión, extensión, generalización o
algún otro.
Propósito: Razón de ser del caso de uso.
Resumen: Resumen del caso de uso.
Precondiciones: Condiciones que deben satisfacerse para poder ejecutar el
caso de uso.
Flujo Principal: El flujo de eventos más importante del caso de uso, donde
dependiendo de las acciones de los actores continuara con
alguno de los subflujos.
Subflujos: Los flujos secundarios del caso de uso, numerados como (S-
1), (S-2), etc.
Excepciones: Excepciones que pueden ocurrir durante el caso de uso,
numerados como (E-1), (E-2), etc.
Actor: Nombre del Actor
Cao de Uso: Nombre de los casos de uso en los cuales participa
Tipo: Primario o secundario.
Descripción: Breve descripción del autor.
Documentar casos de usos no es una tarea fácil que se pueda dominar de un día
para otro, requiere de tiempo, disciplina y experiencia, sin embargo podemos
definir una serie de pasos identificables para escribir los casos de uso.
 Identifique a todos los actores que intervienen.
 Identifique todas las tareas que realizará cada actor.
 Agrupe las tareas repetidas.
 Genere el diagrama(s) UML que represente esquemáticamente los Casos de
Uso.

5.  De una prioridad a cada caso de uso.
 Por cada caso de uso escriba un documento detallado siguiendo la plantilla
especificada anteriormente.
2. ¿QUÉ ES EL ANÁLISIS Y DISEÑO DE SOFTWARE ORIENTADO A
OBJETOS?
El análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de
software que modela un sistema como un grupo de objetos que interactúan entre
sí. Este enfoque representa un dominio en términos de conceptos compuestos por
verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.
En éste método de análisis y diseño se crea un conjunto de modelos utilizando
una notación acordada como, por ejemplo, el lenguaje unificado de modelado
(UML). ADOO aplica técnicas de modelado de objetos para analizar los
requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto
de módulos de software - y para diseñar una solución para mejorar los procesos
involucrados. No está restringido al diseño de programas de computadora, sino
que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño
más modernas son casos de uso guiados a través de requerimientos, diseño,
implementación, pruebas, y despliegue.
3. ¿CUÁLES SON SUS PRINCIPALES CARACTERÍSTICAS?
 Mejoran el mantenimiento del programa.
 Grandes partes de los programas pueden ser reutilizables.
 Reduce el costo de desarrollo de los Sistemas de Información.
 Son efectivos en interfaz gráfica de usuario.
 Son efectivos en bases de datos.
 Hacia el futuro mucha carga de programación se moverá hacia la O-O
 Combina aspectos de los diagramas E-R y de flujo de datos.
 Con O-O muchos productos se están fabricando cada vez más bajo pedido o
fabricados en lotes pequeños.
 Los fabricantes buscan mayor concentración sobre la satisfacción del cliente y
la penetración de mercados nicho.

6.  Sistemas de Información complicados están sufriendo mantenimiento,
adaptación y rediseños continuos.
 El desarrollo O-O no fue una evolución instantánea.
 La notación de diseño O-O combina aspectos tanto de los diagramas de
entidad-relación y de flujo de datos.
4. QUÉ LENGUAJES DE PROGRAMACIÓN ESTÁN ORIENTADOS A ESTA
METODOLOGÍA DE DESARROLLO
c++, objective, c , java, smalltalk, eiffel, ruby, python, ocaml, object, pascal, clips,
visual .net, actionscript, cobol, perl, c#, visual basic.net, php, simula, delphi,
powerbuilder.
5. ¿QUÉ DIFERENCIA EXISTE CON LA TÉCNICA DE PROGRAMACIÓN
PRODECIMENTAL O IMPERATIVA?
La programación imperativa es una serie de códigos con ciertos parámetros por
líneas que se realiza por medio del código de máquina que es el que entiende el
computador son un conjunto de instrucciones para que realice ciertas tareas.
Mientras que la prodecimental es por líneas cada línea de código es una
instrucción orden cada una independiente.

7. CONCLUSIÓN
El análisis es una etapa fundamental dentro de la realización de una aplicación,
esta etapa se puede resumir en una sola frase:Entender el problema. Cuando
terminamos el análisis tenemos ya una comprensión mayor del problema,
sabemos cuáles son las abstracciones claves, y empezamos a estudiar cómo se
desenvuelve la aplicación en el tiempo.
También expresan los requerimientos funcionales que los usuarios comunicaron al
sistema durante la redacción del pliego de condiciones.Comprobar que el sistema
cumple dichos requisitos en el momento de la entrega, determinar las fronteras del
sistema, escribir la documentación del sistema, confeccionar juegos de test.

8. CIBERGRAFIA
 http://www.slideshare.net/msch/como-documentar-casos-de-uso
 http://www.slideshare.net/SergioRios/unidad-4-mad-modelado-analisis-casos-
de-uso
 http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf
 http://es.scribd.com/doc/96199604/Como-Documentar-Casos-de-Uso
 http://es.wikipedia.org/wiki/An%C3%A1lisis_y_dise%C3%B1o_orientado_a_ob
jetos
 http://www.slideshare.net/maria8003/qu-es-el-anlisis-y-diseo-de-software-
orientado-a-objetos
 http://www.buenastareas.com/ensayos/Qu%C3%A9-Es-El-An%C3%A1lisis-y-
Dise%C3%B1o/1904015.html
 http://www.oocities.org/es/annadugarte/ads1/Objetos.htm
 http://www.genbetadev.com/paradigmas-de-programacion/diferencias-entre-
paradigmas-de-programacion
 http://es.wikipedia.org/wiki/Programaci%C3%B3n_imperativa
 http://www.alegsa.com.ar/Diccionario/C/12117.php