paradigmas de la ingenieria del software

1. o El enfoque estructurado
o El enfoque orientado a objetos.
Competencias Genéricas a
desarrollar en la unidad
• Capacidad crítica y autocrítica
• Solución de problemas
• Capacidad de aplicar los conocimientos
• Habilidad para buscar y analizar
información proveniente de fuentes diversas.
Criterios de evaluación de la
Unidad (Conceptuales,
Procedimentales y
Actitudinales)
Conceptuales: 50%
Procedimentales: 40%
Actitudinales: 10%

2. La Ingeniería de Software está compuesta por una serie
de pasos que abarcan los métodos, herramientas y
procedimientos mencionados, a los que se denominan
Paradigmas de la Ingeniería de Software.

3. El análisis estructurado es el método más usado para el
modelado de requisitos, utiliza el modelo de datos y el
modelo de flujos para crear la base de un adecuado
modelo de análisis.
Los sistemas de datos y flujos de control son la base de
representación de la trasformación de datos y control. Al
mismo tiempo, estos métodos son usados para crear un
modelo funcional del software y proveerse de un
mecanismo para dividir funciones.

4. •El método intenta dar forma al proceso de determinación
de los requerimientos comenzando con la documentación
del sistema existente;
•el proceso está organizado de tal forma que intenta incluir
todos los detalles relevante que describe al sistema en uso;
•es fácil verificar cuando se han omitido detalles
relevantes;
•la identificación de los requerimientos será similar entre
varios analistas e incluirá las mejora soluciones y
estrategias para las oportunidades de desarrollo de
sistemas; y
•los documentos de trabajo generados para documentar los
sistemas existente o propuesto son dispositivos de
comunicación eficientes.

5. Símbolos gráficos; iconos y convenciones para identificar
y describir los componentes de un sistema junto con las
relaciones entre estos componentes.
Diccionario de datos; descripciones de todos los datos
utilizados en el sistema.
Descripciones de procesos y procedimientos;
declaraciones formales que emplean técnicas y lenguajes
que permiten a los analistas describir actividades
importantes que forman parte del sistema.
Reglas; estándares para describir y documentar el sistema
en forma correcta y completa.

6. 1. Diagrama de Flujos de datos:
Los diagramas de flujos de datos son una técnica de análisis
estructurado que van de lo general a lo específico muestran
las posibles entradas, procesos y salidas del sistema. Los
diagramas son usados cuando los analistas tratan de
comprender los requerimientos de información de los
usuarios de una manera gráfica utilizando solo cuatro
símbolos combinados entre sí.

7. •Proceso.
•Flujo.
•Almacén.
•Entidad o
Terminador

8. El primer componente del DFD se conoce
como proceso. Los sinónimos comunes son
burbuja, función, transformación. El
proceso muestra una parte del sistema que
transforma entradas en salidas. El proceso
se representa gráficamente como un
círculo, como se muestra en figura .
Calcular
impuesto
de venta

9. Algunos analistas prefieren usar un
óvalo o un rectángulo con esquinas
redondeadas.
1
Calcular
Impuesto
De ventas
Las diferencias entre estas tres formas son
puramente cosméticas, aunque obviamente
es importante usar la misma forma de
manera consistente para representar todas
las funciones de un sistema.

10. Un flujo se representa gráficamente por
medio de una flecha que entra o sale de un
proceso; un ejemplo se muestra en la figura.
El flujo se usa para describir el movimiento
de bloques o paquetes de información de una
parte del sistema a otra.
Pregunta de un cliente

11. En la mayoría de los sistemas que modele como
analista, los flujos realmente representan datos, es
decir, bits, caracteres, mensajes, números de punto
flotante y los diversos tipos de información con los
que las computadoras pueden tratar.
Nótese que el flujo de la figura tiene nombre. El
nombre representa el significado del paquete que se
mueve a lo largo del flujo. Un corolario de esto es
que el flujo sólo lleva un tipo de paquete, como lo
indica su nombre.

12. El almacén se utiliza para modelar una
colección de paquetes de datos en reposo. Se
denota por dos líneas paralelas, como lo
muestra la figura. De modo característico el
nombre que se utiliza para identificar al
almacén es el plural del que se utiliza para
los paquetes que entran y salen del almacén
por medio de flujos.

13. Para el analista con conocimiento de proceso de
datos es tentador referirse a los almacenes como
archivos o base de datos; pero un almacén también
pudiera consistir en datos almacenados en tarjetas
perforadas, microfilm, microfichas, discos ópticos,
etc. y un almacén también puede ser un conjunto
de fichas de papel en una caja de cartón, nombres y
domicilios en un directorio, diversos archivos en
un archivero, o varias formas no computarizadas.

14. El terminador gráficamente se representa
como un rectángulo, como se muestra en la
figura. Los terminadores representan
entidades externas con las cuales el sistema
se comunica.
DEPARTAMENTO DE
VENTAS

15. Comúnmente, puede ser una persona, o un grupo,
por ejemplo, una organización externa o una
agencia gubernamental, o un grupo o
departamento que esté dentro de la misma
compañía u organización, pero fuera del control
del sistema que se está modelando. En algunos
casos, un terminador puede ser otro sistema, como
algún otro sistema computacional con el cual se
comunica éste.

16. El diagrama de contexto debe mostrar un panorama
global que incluya las entradas básicas, el sistema
general y las salidas. Este diagrama será el más
general , con una visión muy superficial del
movimiento de los datos en el sistema y una
visualización lo más amplia posible del sistema.
Al proceso se le asigna el número cero. En el diagrama de
contexto se muestran todas las entidades externas, así como
también los flujos de datos principales que van desde y hacia
dichas entidades. El diagrama no contiene ningún almacén de
datos.

17. 1. Piense en el sistema que está analizando como si
fuera un recipiente, para diferenciar su interior del
exterior.
2. Ignore las tareas puramente internas del recipiente;
aplicando así el concepto de caja negra.
3. Pregunte a sus usuarios finales cuales son los
sucesos o transacciones a los cuales debe responder
el sistema. Por ejem: Pedidos, Reclamos, Pagos, etc.
4. Para cada suceso, pregunte cuáles son las respuestas
que debería generar el sistema. Por ejemplo:
Pedido - Programar pedido
Reclamo - Dar respuesta
Pago - Elaborar recibo

18. 5. Pregunte cuales son los informes de formato
fijo que debe producir el sistema .
6. Identifique las fuentes netas de datos para cada
suceso o transacción. Estas fuentes se convertirán
en los agentes internos o externos del sistema.
7. Identifique los recipientes netos de cada
respuesta o salida que debería generar el sistema.
Estos destinos serán también agentes internos o
externos.

19. 8. Identifique todos los posibles almacenes de datos
externos.
9. Dibuje un diagrama de contexto para toda la
información anterior.

24. Se ha propuesto como la gramática casi formal
para describir el contenido de los objetos definido
durante el análisis. El diccionario de datos es un
listado organizado de todos los elementos de
datos que son pertinentes para el sistema, con
definiciones precisas y rigurosas que permiten
que el usuario y el analista de sistemas tengan
una misma comprensión de las entradas, salidas,
de los componentes de los almacenes y [también]
de los cálculos intermedios.

25. El diccionario de datos guarda y organiza los
detalles del Diagrama de Flujo de Datos (DFD).
Es el segundo componente del análisis
estructurado. También se conoce como "Data
Repository". Incluye el contenido de los data
flow (flujos de datos), los "data store", las
entidades externas y los procesos.

26. 1. Validar la integridad y exactitud del DFD
2. Proporcionar un punto de partida para desarrollar
pantallas e informes.
3. Determinar el contenido de los datos almacenados en
archivos.
4. Desarrollar la lógica para los procesos del diagrama
de flujo de datos.

27. La información capturada para cada flujo de datos se podría
resumir usando un formulario que contenga la siguiente
información:
1. ID, un número de identificación opcional.
2. Un solo nombre descriptivo para este Flujo de datos.
3. Un descripción general del flujo de datos.
4. La fuente del flujo de datos.
5. El destino del flujo de datos.
6. Algo que indique si el flujo es un registro que está entrando
o saliendo de un archivo o un registro que contiene un
informe, formulario o pantalla.
7. El nombre de la estructura de datos que describe los
elementos encontrados en este flujo de datos.
8. El volumen por unidad de tiempo.
9. Un área para comentarios adicionales.

28. Estas se describen usando una notación algebraica, que usa
los siguientes símbolos:
1. Un signo (=) significa “esta compuesto de”
2. Un signo de suma (+) significa “y”
3. Las llaves { } indican elementos repetitivos, también
llamados grupos de repetición o tablas.
4.Los corchetes [ ] representan una situación de uno u otro.
Se podría representar un elemento u otro, pero no ambos.
5. Los paréntesis ( ) representan un elemento opcional. Los
elementos opcionales se podrían dejar en blanco en la
entrada de las pantallas y podrían contener espacios o ceros
para campos numéricos en las estructuras de archivos.

29. Pedido del cliente= número de cliente + nombre del
cliente + dirección+ telefono+ numero de catalago+
fecha de pedido.
nombre del cliente= nombre + (inicial del segundo
nombre)+ apellido.

30. Las especificaciones de procesos se crean para los
procesos primitivos en un diagrama de flujo de
datos así como también para algunos procesos de
nivel superior que se amplían a un diagrama hijo.
Estas especifican la lógica de la toma de decisiones
y las fórmulas que transformarán los datos de
entrada de un proceso en salidas.

31. 1. Reducir la ambigüedad del proceso. Esta meta obliga al
analista aprender los detalles acerca del funcionamiento
de un proceso. Es necesario detectar, anotar e integrar las
áreas indefinidas de todas las especificaciones de
procesos. Estas observaciones constituyen una base y
proporcionan las preguntas para las entrevistas de
seguimiento con la comunidad de usuarios.
2. Obtener una descripción precisa de lo que se está
realizando, lo cual normalmente se incluye en un
paquete de especificaciones para el programador.

32. 3. Validar el diseño del sistema. Esta meta incluye
garantizar que un proceso tenga todo el flujo de
datos de entrada necesario para producir salida.
Además, todas las entradas y salidas deben
representarse en el DFD.

33. 1. Procesos que representan entrada o salida física, tal
como leer y escribir. Por lo general estos procesos sólo
requieren lógica simple.
2. Procesos que representan una validación de datos
simple, la cual normalmente es bastante fácil de realizar.
3. Procesos que usen código pre escrito. Estos procesos
generalmente se incluyen en un sistema como
subprogramas y funciones.

34. 1. El número del proceso, el cual debe coincidir con el
ID del proceso del DFD. Estas especificaciones
permiten al analista trabajar con cualquier proceso o
modificarlo y localizar fácilmente el diagrama de
flujo de datos donde se encuentra el proceso.
2. El nombre del proceso, el cual nuevamente debe ser
el mismo que el asentado en el símbolo del proceso en el
DFD.
3. Una descripción breve de lo que realiza el proceso.

35. 4. Una lista de flujos de datos de entrada, usando los
nombres que están en el diagrama de flujos de datos. Los
nombres de datos que se usan en la fórmula o lógica deben
coincidir con los diccionarios de datos.
5. Los flujos de datos salida, utilizando también los
nombres del DFD y del diccionario de datos.
6. Una indicación del tipo de proceso: por lote, en línea o
manual. Todos los procesos en línea requieren diseños de
pantalla, y todos los procesos manuales deben tener
procedimientos bien definidos bien definidos para que los
empleados realicen las tareas del proceso.

36. 7. Si el proceso usa código preescrito, incluya el nombre del
subprograma o función que contenga al código.
8. Una descripción de la lógica del proceso que indique las
políticas y reglas del negocio en el lenguaje cotidiano, no en
pseudocódigo de lenguaje de computadoras. Las reglas del
negocio son los procedimientos, o quizás un conjunto de
condiciones o fórmulas, que permiten a una corporación
dirigir su negocio. Los formatos comunes de las reglas del
negocio incluyen lo siguiente:
Definiciones de los términos del negocio.
Condiciones y acciones del negocio.
Restricciones de la integridad de los datos.
Derivaciones matemáticas y funcionales.
Inferencias lógicas.
Secuencias de procesamiento.
Relaciones entre las circunstancias del negocio.

37. 9. Si no hay suficiente espacio en el formulario para una
descripción completa del Español estructurado o si hay
una tabla o árbol de decisión que describa la lógica , incluir
el nombre de la tabla o árbol correspondiente.
10. Mencione cualquier problema sin resolver, partes
incompletas de la lógica u otras consideraciones. Estos
problemas constituyen la base de las preguntas usadas
para entrevistas de seguimiento.

38. Formulario de especificaciones del proceso
Número: 1.3
Nombre: Determinar cantidad disponible
Descripción: Determinar si un artículo está disponible para la venta.
Si no está disponible, crear un registro de artículo por reabastecer.
Determinar la cantidad disponible.
Flujo de datos de entrada
Artículo válido del proceso 1.2
Cantidad disponible según el Registro del artículo
Flujo de datos de salida
Artículo disponible (Número del artículo + Cantidad vendida) para los
procesos 1.4 y 1.5
Artículo por reabastecer para el control de inventario.

39. Tipo de proceso:
 En línea
Por lote
 Manual
Nombre de subprograma/Función
Tipo de proceso:
IF Cantidad pedida del artículo es mayor que la Cantidad disponible
THEN Mueva la Cantidad pedida del artículo a la Cantidad disponible del
artículo
Mueva el Número del artículo pedido al Número del artículo
disponible
ELSE
Reste la Cantidad disponible de la Cantidad pedida del artículo para obtener la
Cantidad por reabastecer
Mueva la Cantidad por reabastecer al Registro del artículo por reabastecer
Mueva el Número del artículo al Registro del artículo por reabastecer
DO Registro por reabastecer
Mueva la Cantidad disponible a la Cantidad del artículo disponible
Mueva Número del artículo pedido al Número del artículo disponible
ENDIF

40. Consulte :
Nombre:________________________________________________________
Español estructurado Tabla de decisión Árbol de decisión
Asunto sin resolver:
¿se debe tomar en cuenta la cantidad del pedido para este artículo?
¿Esto podría, combinado con la flecha esperada de llegada de los artículos del
pedido, cambiar la forma en que se calcula la cantidad disponible?

41. Fundamentos de lo Orientado a Objetos
El paradigma OO se basa en el concepto de objeto. Un
objeto es aquello que tiene estado (propiedades más
valores), comportamiento (acciones y reacciones a mensajes)
e identidad (propiedad que lo distingue de los demás
objetos). La estructura y comportamiento de objetos
similares están definidos en su clase común; los términos
instancia y objeto son intercambiables. Una clase es un
conjunto de objetos que comparten una estructura y
comportamiento común.

42. La diferencia entre un objeto y una clase es que un objeto es
una entidad concreta que existe en tiempo y espacio,
mientras que una clase representa una abstracción, la
"esencia" de un objeto, tal como son. De aquí que un objeto
no es una clase, sin embargo, una clase puede ser un objeto.
En el enfoque OO las propiedades del objeto son claves. Los
principios del modelo OO son: abstracción, encapsulación,
modularidad y jerarquía, fundamentalmente, y en menor
grado tipificación (typing), concurrencia, persistencia. [Booch
1986] dice que si un modelo que se dice OO no contiene
alguno de los primeros cuatro elementos, entonces no es OO.

43. Abstracción. Es una descripción simplificada o
especificación de un sistema que enfatiza algunos de los
detalles o propiedades del sistema, mientras suprime otros.
Encapsulación. En el proceso de ocultar todos los detalles
de un objeto que no contribuyen a sus características
esenciales.
Modularidad. Es la propiedad de un sistema que ha sido
descompuesto en un conjunto de módulos coherentes e
independientes.
Jerarquía o herencia. Es el orden de las abstracciones
organizado por niveles.

44. Tipificación. Es la definición precisa de un objeto de tal
forma que objetos de diferentes tipos no puedan ser
intercambiados o, cuando mucho, puedan intercambiarse de
manera muy restringida.
Concurrencia . Es la propiedad que distingue un objeto que
está activo de uno que no lo está.
Persistencia. Es la propiedad de un objeto a través de la cual
su existencia trasciende el tiempo (es decir, el objeto
continua existiendo después de que su creador ha dejado de
existir) y/o el espacio (es decir, la localización del objeto se
mueve del espacio de dirección en que fue creado).

45. Según [Booch 1986], los beneficios del enfoque OO son:
Primero, el uso del modelo OO nos ayuda a explotar el
poder expresivo de todos los lenguajes de programación
basados en objetos y los orientados a objetos, como
Smalltalk, Object Pascal, C++, CLOS, Ada, [ y recientemente
Java] .
Segundo, el uso del modelo OO alienta el reuso no solo del
software, sino de diseños completos.
Tercero, produce sistemas que están construidos en formas
intermedias estables y por ello son más resistentes al
cambio en especificaciones y tecnología.

46. El mismo autor considera que el principal beneficio del
OOD es que da un mecanismo para formalizar el modelo
de la realidad.
Las relaciones entre objetos definen el comportamiento
del sistema. Se dice que un objeto es un actor, si su única
función es operar sobre otros objetos. El objeto es un
servidor si solo es manejado por otros objetos y es un
agente si tiene ambas propiedades. Se dice que los objetos
actúan entre sí mediante mensajes, es decir, acciones que
pide el objeto transmisor que ejecute el objeto receptor.
Dependiendo del comportamiento definido para un
objeto, éste tomará las acciones para ejecutar o no el
mensaje, de manera apropiada.

47. [Greiff 1994] comenta que el Análisis Orientado a Objetos
(OOA por sus siglas en inglés de Object Oriented Analysis)
"es un método de análisis que examina los requerimientos desde
la perspectiva de las clases y objetos encontrados en el
vocabulario de del dominio del problema".
Según [Booch 1986], el Diseño Orientado a Objetos "es un
método de diseño abarcando el proceso de descomposición
orientado a objetos y una notación para representar ambos
modelos lógico y físico tal como los modelos estáticos y
dinámicos del sistema bajo diseño“.

48. En cuanto a las metodologías OO, diremos que hay un gran
número de métodos orientado a objetos actualmente. Muchos
de los métodos pueden ser clasificados como orientados a
objetos porque soportan de manera central los conceptos de la
orientación a objetos. Algunos de las metodología más
conocidas y estudiadas hasta antes del UML según [Jacobson
1992] son:
Object-Oriented Design (OOD), Booch.
Object Modeling Technique (OMT), Rumbaugh.
Object Oriented Analysis (OOA), Coad/Yourdon.
Hierarchical Object Oriented Design (HOOD), ESA.
Object Oriented Structured Design (OOSD), Wasserman.
Object Oriented Systems Analysis (OOSA), Shaler y Mellor.
Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.

49. Actualmente las metodologías más importantes de análisis
y diseño de sistemas han confluido en lo que se es el UML.

50. El Lenguaje Unificado de Modelado pre escribe un conjunto
de notaciones y diagramas estándar para modelar sistemas
orientados a objetos, y describe la semántica esencial de lo
que estos diagramas y símbolos significan.
Mientras que ha habido muchas notaciones y métodos
usados para el diseño orientado a objetos, ahora los
modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de
sistemas: sistemas de software, sistemas de hardware, y
organizaciones del mundo real.

51. UML ofrece nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos
’business’.
• Diagramas de Secuencia para modelar el paso de mensajes
entre objetos.
• Diagramas de Colaboración para modelar interacciones entre
objetos.
• Diagramas de Estado para modelar el comportamiento de los
objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de
los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las
clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de
los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución
del sistema.

52. Imagínese como una colección de situaciones
respecto al uso de un sistema.
Cada escenario describe una secuencia de eventos.
Cada secuencia se inicia por una persona, otro
sistema, una parte del hardware o por el paso del
tiempo.
A las entidades que inician secuencias se les conoce
como actores.

54. ``Comunica (<<communicates>>): Relación (asociación) entre
un actor y un caso de uso que denota la participación del actor
en dicho caso de uso.
``usa ( <<uses>>) (o <<include>> en la nueva versión de
UML): Relación de dependencia entre dos casos de uso que
denota la inclusión del comportamiento de un escenario en
otro.
``extiende (<< extends>>): Relación de dependencia entre dos
casos de uso que denota que un caso de uso es una
especialización de otro.

57. •Un documento de flujo de eventos es creado por
cada uno de los casos de uso.
•Escrito desde el punto de vista del actor.
•Detalla de que proveerá el sistema al actor cuando
el caso de uso sea ejecutado.
Contenido típico:
•Precondiciones : Cómo el caso de uso empieza .
•Flujo Principal o normal de eventos
•Flujo alterno de eventos
•Flujo excepcional de eventos

58. Mantener información de
usuario
ABD usuario
Flujos de eventos del CU “ Mantener Información de
Usuarios ”
1.1.- Precondiciones.
El usuario al que se le asignará una contraseña debe de ser
un empleado de la empresa.
1.2.-Flujo Principal.
Este CU empieza cuando el administrador de la base de
datos (ABD) se conecta al sistema e introduce su
contraseña. El sistema verifica su contraseña (E-1) y el
sistema presenta un menú de opciones, las cuales son las
siguientes: Altas, Bajas, Cambios, Consultas o Salir.

59. Si la actividad deseada es Altas se hace el subflujo S-1 “Agregar
Usuario”
Si la actividad deseada es Bajas se hace el subflujo S-2 “Borrar
Usuario”
Si la actividad deseada es Cambios se hace el subflujo S-3
“Modificar Datos del Usuario ”
Si la actividad deseada es Consultas se hace el subflujo S-4
“Consultar Usuario”
Si la actividad deseada es Salir el CU termina.
1.3.- Subflujos.
S-1: “ Agregar Usuario ”
El sistema muestra la pantalla de usuario que contiene cuatro
campos (idUsuario, nombre, contraseña, tipoUsuario). El ABD
introduce los cuatro campos (E-2). El sistema muestra los
nuevos datos del usuario (E-3). El CU comienza de nuevo.

60. 1.4.- Flujos alternativos.
E-1: Si el identificador del ABD no es valido el
usuario puede ingresar de nuevo o salir del sistema.
E-2: idUsuario/ nombre/ contraseña/
tipoUsuario no valido repetir o salir.
E-3: Los datos de un nuevo usuario no pueden
mostrarse. Se informa al usuario que la información
no esta disponible. El CU comienza.

61. Un diagrama de clases muestra la existencia de clases y
sus relaciones desde el punto de vista lógico del sistema.
Los elementos de modelado del UML en un diagrama de
clases son:
•Clases, sus estructuras y comportamiento.
•Relaciones de Asociación, agregación, dependencia y
herencia.

62. Una clase es una colección de objetos que tienen una
estructura, comportamiento, relaciones y semántica
comunes.
Las clases son encontradas examinando a los objetos
en un diagrama de secuencia y de colaboración.
Una clase es dibujada como un rectángulo con tres
compartimientos.
Una clase debe de ser nombrada utilizando el
vocabulario del dominio.
Deben ser creados estándares para dar nombre a las
clases.

63. Los atributos describen el estado del objeto. Un atributo consta
de dos partes: un nombre de atributo y un valor de atributo.
Los objetos simples pueden constar de tipos primitivos, tales
como enteros, carácter, boolean, reales, o tipos simples
definidos por el usuario. Los objetos complejos pueden constar
de pilas, conjuntos, listas array, etc., o incluso estructuras
recursivas de alguno o todos los elementos. Ejemplo:
Automóvil
marca
modelo
color
Celular
Marca
modelo
Precio
Alumno
nombre
dirección
teléfono

64. 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.
Cada método tiene un nombre y un cuerpo que realiza la
acción o comportamiento asociado con el nombre del método.
Ejem:
Automóvil
marca
modelo
color
acelerar()
frenar()
reversa()
Celular
marca
modelo
llamar()
colgar()
recibirMensaje()
enviarMensaje()
Alumno
nombre
dirección
teléfono
reinscripción()
imprimirBoleta()
bajaTemporal()
bajaDefinitiva()

65.  Modela la interacción entre los objetos de un Caso de
Uso.
 Los objetos están conectados por enlaces (links) en los
cuales se representan los mensajes enviados
acompañados de una flecha que indica su dirección.
Ofrece una mejor visión del escenario cuando el analista
está intentando comprender la participación de un objeto
en el sistema.

66. insertar ( contraseña, seleccion)
:Pantalla
de Usuario
1: agregar(contraseña, seleccion)
:sistema
[contraseña= T
2.1: enviar(seleccion)
[ contraseña=F ]
2.2: Salir
:datosUsuario
5: Salir
:Usuario
3: verificar(seleccion)
4.1:crearUsuario()
4.2:borrarUsuario()
4.3::modificarDatosUsuario()
4.4:consultarDatosUsuario()