INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÒGICO PÙBLICO

“PADRE ABAD”

“Año del Fortalecimiento de la Soberanía Nacional”

Trabajo de Investigacion:
“ESTRUCTURA SWICHT”

PROGRAMA DE ESTUDIO : COMPUTACIÓN E INFORMÁTICA

MÓDULO : DESARROLLO DE SOFTWARE Y GESTIÓN DE

BASE DE DATOS

CICLO : III

UNIDAD DIDÁCTICA : TALLER DE MODELAMIENTO DE SOFTWARE

DOCENTE : JACKSON ORDOÑEZ BOCANEGRA

INTEGRANTES :

 RAMIREZ RAMOS CARLOS DANIEL

 USURIANO NIETO RUTH KAREN
 DAMASO POMATANTA JAZMYN
 OSORIO NATIVIDAD KATHIA

AGUAYTIA-PERÚ
2022
 DEDICATORIA

Este trabajo monográfico está dedicado a

Dios por mantenerme con vida y poder
lograr mis metas para culminar
satisfactoriamente mi carrera profesional,
a mis padres que siempre están ahí
apoyándome y dándome fuerzas para
seguir adelante.

ii
 AGRADECIMIENTO

Agradecer a mis padres por brindarme su

apoyo incondicional y estar presentes en
los momentos más difíciles dándome
ánimos para poder lograr mis objetivos, al
docente por impartir nuevos conocimientos
que me están ayudando en el desarrollo
de la carrera profesional.

iii
 ÌNDICE
DEDICATORIA................................................................................................................................ii

AGRADECIMIENTO......................................................................................................................iii

ÍNDICE.............................................................................................................................................iv

I. INTRODUCCIÓN.....................................................................................................................5

II. OBJETIVOS.............................................................................................................................5

2.1. Objetivo General............................................................................................................5

2.2. Objetivos Específicos...................................................................................................5
III. EJECUCIÓN DEL TRABAJO...............................................................................................6

3.1. DIAGRAMAS DE CLASES............................................................................................6

3.1.1. Perspectivas...........................................................................................................6
3.1.2. Clases.......................................................................................................................7
3.1.3. Relaciones en un diagrama de clases............................................................10
3.1.4. Asociación.............................................................................................................10
3.1.5. Tipos de asociación............................................................................................12
3.2. DIAGRAMAS DE CASOS DE USO...........................................................................13
3.2.1. ¿Para qué se usa un diagrama de casos de uso?.......................................13
3.2.2. Los 4 componentes principales de un diagrama de casos de uso.........14
3.2.3. ¿Cómo puedes crear un diagrama de casos de uso?................................15
3.2.4. Descripción grafica del diagrama de casos de uso....................................15
3.2.5. Diferencia entre los diagramas UML y de Casos de Uso...........................16
3.2.6. Descripción de diagrama de casos de uso...................................................16
3.2.7. Características.....................................................................................................17
3.2.8. Ventajas.................................................................................................................17
3.2.9. Desventajas...........................................................................................................17
IV. CONCLUSIÓN.......................................................................................................................18

V. ANEXO...................................................................................................................................19

VI. BIBLIOGRAFÍA.....................................................................................................................20

ÍNDICE

iv
I. INTRODUCCIÓN
Los programas definidos hasta este punto se ejecutan de modo secuencial, es
decir, una sentencia después de otra. La ejecución comienza con la primera
sentencia del programa y prosigue hasta la última sentencia, cada una de las
cuales se ejecuta una sola vez. Esta forma de programación es adecuada para
programas sencillos. Sin embargo, para la resolución de problemas de tipo general
se necesita la capacidad de controlar cuáles son las sentencias que se ejecutan, y
en qué momentos. Las estructuras de control o construcciones de control
controlan la secuencia o flujo de ejecución de las sentencias. Las estructuras de
control se dividen en tres grandes categorías en función del flujo de ejecución:
secuencia, selección e iteración.

 Secuencia
 Selección
 Repetición
Este capitulo considera las estructuras selectivas o condicionales
 Sentencias IF
 Sentencias SWITCH

Que controlan si una sentencia o lista de sentencias se ejecutan en función del

cumplimiento o no de una condición.

II. OBJETIVOS
II.1. Objetivo General
 Desarrollar un informe detallado acerca de la estructura SWITCH.

II.2. Objetivos Específicos

 Indagar y buscar información en diversas fuentes como, por ejemplo, el
internet.
 Organizar la información encontrada.
 Realizar la elaboración del informe con toda la información encontrada y
organizada.
 Presentar y exponer el informe desarrollado.

5
III.EJECUCIÓN DEL TRABAJO

III.1. ESTRUCUTURA SWITCH

Es un tipo de mecanismo de control de selección utilizado para permitir que el
valor de una variable o expresión cambie el flujo de control de la ejecución del
programa mediante búsqueda y mapa.
Las declaraciones de interruptor funcionan de manera similar a la declaración
IF en lenguajes de programación como C/C++, C#, Visual Basic .NET o Java, y
existe en la mayoría de los lenguajes de programación imperativos de alto nivel
como Pascal, Ada, así como los previamente indicados.
Las declaraciones de cambio vienen en dos variantes principales: un cambio
estructurado, como en Pascal, que toma exactamente una rama, y un cambio no
estructurado, como en C, que funciona como un tipo de goto. Las principales
razones para usar un interruptor incluyen mejorar la claridad, reduciendo la
codificación repetitiva de múltiples  if  y (si la heurística lo permite) también ofrecer
potencial para una ejecución más rápida, a través de una optimización del
compilador más fácil en muchos casos.

III.1.1. Funcionamiento

Variable de control: prácticamente un mandato impuesto por el uso habitual es

utilizar la letra i Iterador como variable de control, o bien sus sucesoras en caso
de bucles anidados. El uso de esta letra críptica quizás a primera vista es sin
embargo una excelente forma de aportar agilidad de lectura al Código por su
uso tan extensivo. Como raras veces los bucles anidados superan las tres
dimensiones (por una sencilla cuestión de explosión exponencial), las letras i, j
y que suelen ser las únicas relacionadas con este uso. En C se define en el
primer parámetro de la instrucción junto con la inicialización (opcional).

III.1.2. Similitud
Con la nomenclatura anterior, el Switch se puede asemejar a este otro algoritmo
basado en if y for:
'Variable de control': prácticamente un mandato impuesto por el uso habitual
es utilizar la letra i Iterador como variable de control, o bien sus sucesoras en
caso de bucles anidados. El uso de esta letra críptica quizás a primera vista es
sin embargo una excelente.

6
 III.1.2.1. Consideraciones acerca del uso de la sentencia Switch

La estructura Switch es especialmente útil cuando la selección se basa en el

valor de una variable simple o de una expresión simple denominada expresión
de control o selector.

Los valores de cada case del Switch han de ser constantes

El valor de esta expresión puede ser de tipo INT o CHAR, pero no pude ser del
tipo float ni double.

La etiqueta default marca el bloque de código que se ejecuta por defecto

(cuando al evaluar la expresión se obtiene un valor no especificado por los
casos anteriores del SWITCH)

La sentencia SWITCH compara solamente igualdad.

Switch (variable)la variable es de tipo entero o caracter   {
case valor1:
accion1;
break;

case valor2:

accion2;
break;
case valorN:
acciónN;
break;

default: accionD;

}  

III.1.2.2. Sintaxis del Condicional Switch en C++:

es bastante distinta a la de un condicional típico, sin embargo, es bastante intuitiva

y fácil de comprender, es solo cuestión de acostumbrarse. Veamos a continuación
la estructura general de un condicional Switch y luego unos cuantos ejemplos:

7
Línea 1:Aquí, tenemos la declaración del condicional Switch, estamos diciendo
que lo que viene a continuación es esto, entre los paréntesis, el Switch recibe la
variable que vamos a usar para comparar en cada uno de los casos.
Línea 2: En la línea 2 tenemos una llave abriendo "{" lo cual como hemos visto en
secciones anteriores, indica que allí comienzan los bloques de instrucciones que
se ejecutarán para cada caso.
Línea 3:En esta línea tenemos una parte vital del condicional Switch, aquí
tenemos definido un caso posible que puede cumplir nuestra variable, la sintaxis
es simple, usamos la instrucción "case" para indicar que allí comienza un caso,
luego indicamos el valor que puede tomar la variable, puede ser un número, una
cadena de caracteres o lo que necesitemos, de esto se siguen dos puntos ":" y
después de estos ponemos la o las instrucciones a ejecutar para este caso, como
ejemplo, podríamos tener algo como esto : case "Hola": cout << "Usted ha escrito
Hola";.
Línea 4:Esta línea contiene la instrucción break, es una instrucción simple, pero
fundamental al interior del condicional Switch, esta instrucción indica que hasta allí
va el bloque de instrucciones del caso inmediatamente anterior a este, de este
modo evitamos que el algoritmo ejecute los demás casos, a modo de ejercicio,
podrías intentar ejecutar el código del ejemplo que veremos más adelante y quitar
las instrucciones break, con esto podrás comprobar que si el usuario ingresa por
ejemplo un 1, se ejecutarán todos los casos, es por esto que el break es
fundamental.
Línea 5 a 8:Estas líneas contienen una repetición de las instrucciones de las
líneas 3 y 4, evidentemente cada una contiene un caso distinto, ten en cuenta que
se pueden definir todos los casos que sean necesarios al interior del Switch.

8
Líneas 9, 10 y 12: Estas líneas como deberías saber ya, contienen diferentes
comentarios aclarativos sobre el código, en caso de que no comprendas
adecuadamente estas líneas, te recomiendo visitar la sección de comentarios.
Línea 11: Esta línea cambia un poco con respecto a las anteriores, sin embargo,
conserva la misma esencia, en vez de poner el comando "case", usamos el
comando "default", y luego los 2 puntos ":", notemos que no se pone ningún valor
a evaluar, pues esta es la acción que se ejecuta en caso de que no lleguemos a
entrar en ninguno de los casos.
Línea 13: En esta línea hacemos uso de la llave cerrando "}", una vez más como
seguramente ya sabrás esta nos indica que allí termina el bloque del condicional y
se dará por terminada la ejecución de este para continuar ejecutando el resto del
programa.

III.1.2.3. Detalles sobre el condicional Switch en C++

En C++, NO puedes usar otra cosa diferente a número en cada case. Si necesitas
comparar cadenas de texto u otros tipos de datos, seguramente un condicional
como el if o if-else sean una mejor alternativa.

Los caracteres también se pueden usar, pues en esencia se pueden representar

como números enteros (el lenguaje se encarga de eso por ti). Sin embargo, como
indiqué, otros tipos de datos no son recomendables.

La sentencia default es opcional, así que si no lo deseas no la debes poner. Sin

embargo, es recomendable hacerlo, para así controlar todas las opciones posibles
y que tu programa no quede a la "suerte" en ciertos casos.

Dentro de cada case eres libre de poner varias líneas de código, incluso otras
estructuras como condicionales o ciclos. Sin embargo, es preferible mantener tu
código ordenado y no poner muchas. Recomendaría no poner más de 5 y
preferiblemente solo una. Si deseas hacer tareas complejas al interior de un case
de un Switch en C++, posiblemente sea mejor hacer esas tareas en una función y
llamar a esa función desde el case o simplemente usar un if-else.

Así que, efectivamente, los condicionales Switch y de hecho todos los

condicionales en sí, son extremadamente útiles pues permiten definirle a nuestro
software múltiples vías de ejecución contemplando así todas las posibilidades
durante la ejecución. Me gustaría hacer una leve aclaración, el condicional Switch
encuentra su utilidad al momento de tener más de una posibilidad de valores para
una variable cualquiera, evidentemente si nuestra variable solo puede adquirir un
valor útil para nosotros, nuestra alternativa inmediata debería ser un if o un if-else,
no un Switch que resulta un poco más engorroso de escribir, sin embargo cuando
tenemos varias posibilidades es mejor un Switch que tener condicionales anidados
o un condicional después de otro. Espero que todo te haya quedado claro en esta
sección.
9
 III.1.3. Sentencia CASE en SQL
La declaración de la sentencia CASE en SQL retorna un valor en una condición
especificada. Trataremos de usar una declaración de case en las consultas que
fueron seleccionadas junto con la cláusula Where, Order By y Group By. A su vez
se puede utilizar en la opción de Insertar declaración. En este artículo, vamos a
desarrollar la declaración CASE y todos sus diferentes casos de uso.
Supongamos que se tiene una tabla que contiene el ProductID para todos los
productos en una tienda pequeña. Y se desea tratar de obtener el Productname
para un ProductID en particular.
Veamos el siguiente ejemplo; Vamos a declarar una variable la cual va a ser:
@ProductID y le asignamos el valor
1.En la declaración del caso, vamos a definir las condiciones. el momento en el
que se cumple una condición, se devuelve su valor correspondiente.

De la misma manera, si modificamos la condición en una declaración de case en

SQL, se va a devolver la expresión apropiada. En el próximo ejemplo, lo que
queremos obtener es el nombre del Producto para ProductID 4. Pero no cumple la
condición de declaración del Case; por lo tanto, dio salida de la expresión Else.

10
Examinamos algunos ejemplos de la declaración del case en SQL. Antes de poder
continuar, tiene que crear una tabla de muestre e inserte algunos registros en esa
tabla.

Tenemos los siguientes registros en la tabla de empleados.

11
 III.1.4. Distintos formatos de declaraciones CASE

 Una simple expresión de declaración CASE

En este formato, vamos a evaluar una expresión contra múltiples valores. En

una declaración de case simple, este va a evaluar todas las condiciones una
por una. El momento en el que la condición y la expresión llegan a coincidir, se
devuelve la expresión mencionada en la cláusula THEN.

A continuación, tenemos la siguiente sintaxis para una declaración de case en

SQL con una expresión simple.

Generalmente, vamos almacenando abreviaturas en una tabla en lugar de su

forma completa. Como, por ejemplo, en mi tabla de empleados, he utilizado las
siguientes abreviaturas en Gender y StateCode. Quiero tratar de usar una
declaración Case para poder devolver valores como el Masculino y el Femenino
en la salida, envés de M y F.
Vaya a ejecutar el siguiente código y va a observar que estamos intentando
evaluar el CASE Gender en esta consulta.

En la imagen que viene a continuación, se puede notar una diferencia en la salida

utilizando una instrucción Case en SQL.

12
 .
III.1.5. características de Switch
Switch es una sentencia C++ que se utiliza para seleccionar una de entre múltiples
alternativas. El estatuto Switch es especialmente útil cuando la selección se basa
en el valor de una variable simple o de una expresión simple denominada
expresión de control o selector.

Asociación
normal
Una asociación normal entre dos clases representa una relación
estructural entre sus objetos, lo que significa que ambas clases están
conceptualmente al mismo nivel, ninguna es más importante que la otra.
Se trata de una relación no muy fuerte.

1. Agregación

13
 Una agregación sirve para modelar una relación “todo-parte”, lo que
significa que un objeto del todo tiene objetos de la parte. Podemos
distinguir:

 Agregación normal
Una agregación normal se denota dibujando una línea con un rombo
sin rellenar al final de la misma del lado del todo (del lado de la clase
que contiene a la otra clase). También puede tener un nombre (con
dirección) y ser navegable, así como añadir roles en el lado de la
parte (lado de la clase contenida).
Una agregación normal es un caso especial de la multiplicidad de
una asociación, pues la cardinalidad del lado del todo sólo puede ser
uno.
 Agregación compartida
Una agregación compartida es aquella en la que las partes pueden
ser partes en varios todos. Se representa de la misma forma que una
agregación normal. Para que una agregación se considere
compartida es necesario que la multiplicidad en el lado del todo sea
superior a uno.
Una agregación compartida es un caso especial de una agregación
normal.
 Agregación de composición
Una agregación de composición se denota dibujando una línea con
un rombo relleno al final de la misma del lado del todo (del lado de la
clase que contiene a la otra clase). La multiplicidad en el lado del
todo puede ser uno (1) ó cero-auno (0..1), pero la multiplicidad en el
lado de la parte puede ser cualquier intervalo. Se trata de una
relación de pertenencia muy fuerte.

III.2. DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso permiten visualizar las interacciones que podría
tener un usuario o un cliente con un sistema. Anteriormente se usaban en la
programación de computadoras, sin embargo, los diagramas de casos de uso
se han hecho populares en las industrias minoristas y en las de atención al
cliente para explicar la interacción de los clientes con una empresa o negocio.

14
El diagrama que se muestra como ejemplo, describe la funcionalidad de
un Sistema Restaurante muy simple. Los casos de uso están representados por
elipses y los actores están, por ejemplo, los casos de uso se muestran como
parte del sistema que está siendo modelado, los actores no.
En este caso, podemos apreciar tanto declaraciones correctas como
incorrectas. El probar la comida y pagarla es un requerimiento funcional del
sistema, pero beber vino no lo es, por lo tanto, este caso de uso está incorrecto.
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta
interacción es esencial para una descripción coherente del comportamiento
deseado, quizás los límites del sistema o del caso de uso deban de ser re-
examinados. Alternativamente, la interacción entre actores puede ser parte de
suposiciones usadas en el caso de uso. Sin embargo, los actores son una
especie de rol, un usuario humano u otra entidad externa puede jugar varios
papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma
persona.

III.2.1. ¿Para qué se usa un diagrama de casos de uso?

Aunque aún son utilizados principalmente para la programación de
computadoras u otros campos técnicos, los diagramas de casos de uso se han
extendido a otras áreas de negocios, y son muchas las organizaciones que
crean diagramas de casos de uso para ayudar a visualizar todas las formas en
las que una persona puede interactuar con su empresa.
En un contexto de negocios, las organizaciones pueden crear un diagrama de
caso de uso o emplear ilustraciones para visualizar el flujo de ventas y

15
marketing, describir las interacciones típicas con su tecnología y aplicaciones o
analizar un flujo de trabajo complejo.
Por ejemplo, este diagrama de caso de uso, le da sentido al proceso
comúnmente caótico de gestionar un restaurante, con la gran cantidad de
partes móviles involucradas en crear una experiencia fluida y amena para los
comensales.
III.2.2. Los 4 componentes principales de un diagrama de casos de uso
Estos son los cuatro elementos de un diagrama de caso de uso:

 Sistem
a
 Actores
 Casos
de uso
 Relacio
nes

En otras palabras, un diagrama de caso de uso debería visualizar una razón

(caso de uso) por la que un individuo (actor) debería interactuar con tu
organización (sistema) y las relaciones que existen entre una empresa y las
personas. Los diagramas de casos de uso pueden ser un poco simples al
visualizar estos cuatro elementos, como lo muestra el siguiente ejemplo, donde
se describe por qué (casos de uso) dos tipos de clientes (actores) podrían
interactuar con un banco (sistema) y las relaciones que resultan de ello.
Estos tipos de diagramas también pueden ser más complejos y describir
muchos tipos de funciones que podrían o no ocurrir siempre en el curso de la
relación de un individuo con un sistema. En este ejemplo se ilustran algunos
casos de uso que siempre van a ocurrir y algunos que podrían ocurrir.

III.2.3. ¿Cómo puedes crear un diagrama de casos de uso?

Primero, tienes que organizar tus cuatro elementos claves —sistema, actores,
casos de uso y relaciones. Después, organizarlos visualmente de forma que

16
tenga sentido y que te permita ver de inmediato las conexiones que hay entre
ellos. Algunos diagramas de casos de uso definen ciertos pasos que podrían
ser parte de cada caso de uso o de solo algunos; y es común utilizar los
términos “incluir” o “extender” para ello, como muestra el siguiente ejemplo.
 Extensión: Al describir un caso de uso de un cajero automático, se
utilizaría una línea de exclusión o se conectaría un escenario condicional,
por ejemplo, si un usuario no realiza operaciones bancarias con esa
institución normalmente y debe pagar una comisión para retirar efectivo.
 Inclusión: En nuestro ejemplo de caso de uso de un cajero automático,
esto podría aplicar para un usuario que está colocando su tarjeta en la
máquina, introduce su PIN y se le muestra un menú.
En otras palabras, las interacciones que ocurren siempre, deberían ser
descritas con una nota de inclusión, mientras que aquellas que podrían ocurrir
bajo ciertas condiciones deberían ser descritas con una notación de extensión.

III.2.4. Descripción grafica del diagrama de casos de uso

III.2.5. Diferencia entre los diagramas UML y de Casos de Uso

Algunos diagramas UML son diagramas de casos de uso, sin embargo no todos
los diagramas de casos de uso son creados bajo un modelo UML, y existen

17
muchos más tipos de diagramas que podrían apoyar a una metodología basada
en UML.
Aquí tienes tan solo algunos de los tipos de diagramas posibles usando UML:
Diagramas estructurales de:
 Clase  Objeto
 Componente  Paquete
 Estructura compuesta  Perfil
 Despliegue

Diagramas conductuales de:

 Actividad  Estado
 Comunicaciones  Tiempo
 Resumen de interacción  Caso de uso
 Secuencia

III.2.6. Descripción de diagrama de casos de uso

Las descripciones de casos de uso son reseñas textuales del caso de uso.
Normalmente tienen el formato de una nota o un documento relacionado de
alguna manera con el caso de uso, y explica los procesos o actividades que
tienen lugar en el caso de uso.

18
III.2.7. Características
 Describe el comportamiento de un sistema desde el punto de vista de un
usuario bajo la forma de acciones y reacciones.
 Cada caso de uso es independiente de los demás
 Permite definir los límites del sistema y las relaciones entre el sistema y
su entorno.
III.2.8. Ventajas
 Expresar la intención que tiene el actor (usuario)
 Extraer los requerimientos del usuario y del sistema
 Centrar al analista en las tareas principales de usuario (describiendo los
casos de mayor importancia).
 Tener en cuenta todos los usuarios evitando que las personas
especializadas en informática dirijan la funcionalidad del nuevo sistema
basándose solamente en criterios tecnológicos.
 Lenguaje de comunicación entre usuarios y desarrolladores.
 Comprensión detallada de la funcionalidad del sistema.
 Acotación precisa de las habilitaciones de los usuarios.
 Gestión de riesgo más eficiente para gobernar la complejidad.

III.2.9. Desventajas
 No establecen los requisitos funcionales.
 Tampoco permiten establecer los requisitos no funcionales.
 Los casos de uso deben complementarse con información adicional
como:
 Reglas de negocio.
 Requisitos no funcionales.
 Diccionario de datos que complementen los requerimientos del
sistema.
 Cada caso crítico del uso debe tener un requisito no funcional centrado
en el funcionamiento asociado.
 Los problemas grandes se complican debido a que el diagrama se
extiende demasiado.
 La inclusión de estas relaciones hace que los diagramas sean más
difíciles de leer, sobre todo para los clientes.

19
IV. CONCLUSIÓN

Cuando se realiza un diagrama de caso de uso o uno de clases se debe tener

en cuenta que ambos están relacionados como mínimo con un actor. Cada
diagrama esta iniciado por un actor y siempre debe devolver un valor.

Ambos diagramas permiten documentar los requerimientos de un sistema o

software, lo cual es importante cuando el proyecto tiende a extenderse para
nuevas versiones.

Es muy importante la utilización de los diagramas de caso de uso al momento

de realizar un proyecto de desarrollo de software porque permite visualizar el
sistema desde la perspectiva del usuario y de esta forma se hace entendible
para cualquier persona permitiendo a los desarrolladores trabajar en
colaboración con los usuarios que van a interactuar con el sistema.

Además, modelar el vocabulario de un sistema implica tomar una decisión

sobre qué abstracciones forman parte del sistema y qué otras caen fuera de
sus límites. Aquí usamos los diagramas de clases para especificar dichas
abstracciones y sus responsabilidades.

20
V. ANEXO
Ejemplo de diagrama de casos de uso y diagrama de clases:
 Software para graficación

 Asociaciones normales

VI. BIBLIOGRAFÍA

 https://es.venngage.com/blog/diagrama-de-caso-de-uso/

21
 http://www.codecompiling.net/files/slides/
UML_clase_02_UML_casos_de_uso.pdf
 https://es.m.wikipedia.org/wiki/Diagrama_de_casos_de_uso
 https://ingenieriaensoftwarenathalyalava.wordpress.com/2015/06/01/
diagramas-de-casos-de-uso/
 https://lsi.ugr.es/~mvega/docis/casos%20de%20uso.pdf
 https://diagramasuml.com/diagrama-de-clases/
#Elementos_de_un_diagrama_de_clases

22