ANALISIS Y DISEÑ O DE SISTEMAS

ANALISIS Y DISEÑ O DE
SISTEMAS

Pá gina 0
 ANALISIS Y DISEÑ O DE SISTEMAS

ACTIVIDAD Nº 1
INTRODUCCION AL UML/RUP
ANÁLISIS Y DISEÑO DE SISTEMAS

Para llegar al término aná lisis y diseñ o conozcamos algunas definiciones:

Análisis:

Es el diagnostico de una realidad tal y como está se encuentra.

Acció n de descomponer un todo en sus partes.
Consiste en separar funciones esenciales diferenciar entre lo que se debe hacer y lo que se
hace.
A nivel general, puede decirse que un aná lisis consiste en identificar los componentes de
un todo, separarlos y analizarlos para lograr acceder a sus principios má s elementales.
Un análisis es el acto de separar las partes de un elemento para estudiar su
naturaleza, su función y/o su significado.

Un análisis es un efecto que comprende diversos tipos de acciones con distintas

características y en diferentes á mbitos, pero en suma es todo acto que se realiza con el
propó sito de estudiar, ponderar, valorar y concluir respecto de un objeto, persona o
condició n.

Estudio, mediante técnicas informá ticas, de los límites, características y posibles

soluciones de un problema al que se aplica un tratamiento por ordenador.
Proceso de separación de las partes de un determinado elemento para estudiar su
función, significado y naturaleza.

Este proceso puede aplicarse en distintos ámbitos, uno de ellos es el de la tecnología, para
abordar a aquellos productos hechos para ser comercializados. A la hora de estudiarlos, se
pueden aplicar distintos tipos de aná lisis:

Ejemplos:
 Morfológico
 Estructural
 De funcionamiento
 Funcional
 Relacional
 Económico
 Tecnológico
 Histórico
 Comparativo
 Clínicos, etc.
 Planificar los procesos de investigación.
 Procesar la información recopilada, etc.

Pá gina 1
 ANALISIS Y DISEÑ O DE SISTEMAS
Diseño:

Es un proceso coordinado para crear un objeto.

Actividad, creatividad que tiene por fin proyectar objetos.
Proceso de creació n y desarrollo para producir un nuevo objeto (objeto, proceso, servicio,
conocimiento entorno).
Del italiano disegno, la palabra diseñ o se refiere a latraza odelineació n de unedificio o de
unafigura. Se trata, por ejemplo, de la concepció n original de un objeto u obra destinados a
la producció n en serie.
También puede referirse a un proyecto o plan, a la descripció nverbal de algo, a la
disposició n de manchas, colores o dibujos que caracterizana animales y plantas, y a la
forma de los objetos.
Diseñ o implica plasmarel pensamientoa través de esbozos, dibujos, bocetos
yesquemastrazados en cualquier soporte.
El acto de diseñ ar puede ser considerado como creatividad (el acto de la creació n),
innovació n (cuando el objeto no existe) o una modificació n de algoyaexistente (a través de
la abstracció n, la síntesis, la ordenació n o la transformació n).

Ejemplos:

 Diseño de imagen corporativa.

 Diseño gráfico.
 Diseño web.
 Diseño universal.
 Diseño gráfico.
 Diseño industrial.
 Diseño de circuitos.
 Diseño de páginas web.
 Diseño arquitectónico.
 Diseño de evaluación.

Sistema

Conjuntos de elementos definidos (instituciones, personas, documentos, procesos, cosas,

etc) y organizados de tal forma que interactú an y se relacionan para cumplir con su
misió n, interactú an con su medio ambiente.

Conjunto de elementos relacionados entre sí para cumplir un objetivo en comú n.

Un sistema es un conjunto de partes o elementos organizados y relacionados que
interactú an entre sí para lograr un objetivo.
Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen (salida)
informació n, energía o materia.

Los sistemas se compones de otros sistemas a los que llámanos subsistemas.

Del latín sistema, un sistema es mó dulo ordenado de elementos que se encuentran
interrelacionados y que interactú an entre sí. El concepto se utiliza tanto para definir a un
conjunto de conceptos como a objetos reales dotados de organizació n.

Pá gina 2
 ANALISIS Y DISEÑ O DE SISTEMAS
La palabra Sistemas corresponde al plural del término sistema, en tanto, la palabra
sistema presenta diferentes usos de acuerdo al contexto en el cual se la emplee.
Un sistema de informació n (SI) es un conjunto de elementos orientados al tratamiento y
administració n de datoseinformació n, organizados y listos para su uso posterior,
generados para cubrir una necesidad u objetivo.

Ejemplos:

 Sistema solar
 Sistema digestivo
 Sistemas Abiertos.
 Sistemas Cerrados.
 Sistema Operativo UNIX.
 Sistema Operativo Windows.
 Sistema aislado.
 Sistemas Competitivos.
 Sistemas Cooperativos.
 Sistemas que modifican el estilo de operación del negocio.

Información:

Es un conjunto organizado de datos procesados, que constituyen un mensaje.

Segú n Idalberto Chiavenato, información"es un conjunto de datos con un significado, o
sea, que reduce la incertidumbre o que aumenta el conocimiento de algo. En verdad, la
informació n es un mensaje con significado en un determinado contexto, disponible para
uso inmediato y que proporciona orientació n a las acciones por el hecho de reducir el
margen de incertidumbre con respecto a nuestras decisiones.
Comprende los datos y conocimientos que se usan en la toma de decisiones.

Es un conjunto organizado de datos procesados, que constituyen un mensaje sobre un

determinado ente o fenómenos iste en datos seleccionados y ordenados con un propó sito
específico.

Información es un conjunto de datos acerca de algún suceso, hecho o fenómeno, que

organizados en un contexto determinado tienen su significado, cuyo propósito puede ser el
de reducir la incertidumbre o incrementar el conocimiento acerca de algo.
La informació n es un conjunto de datos con significado que estructura el pensamiento de
los seres vivos, especialmente, del ser humano.

Consiste en la transmisió n de los datos obtenidos sensorialmente, a través de un mensaje,

desde un transmisor hacia un receptor, en un proceso comunicacional, utilizando el
lenguaje oral, escrito o gestual, expuestos de manera sistemá tica para otorgarles
significació n, y generar conocimiento.

Pá gina 3
 ANALISIS Y DISEÑ O DE SISTEMAS
Ejemplos:

 Informació n privada.(promedios finales)

 Informació n pú blica. (noticias k se obtienen a través de perió dicos, radio, tv, etc.)
 Informació n interna. (es el sistema de informació n que se da en las empresas).

Sistema de información

Es un conjunto formal de elementos y procesos que permiten transformar los datos de

entradas en informació n valida sin ambigü edades y en forma oportuna para la toma de
decisiones.
Conjunto de elementos orientados al tratamiento y administració n de datos e informació n
organizados y listos para su posterior uso.

Un sistema de informació n (SI) es un conjunto de elementos orientados al tratamiento y

administració n de datoseinformació n, organizados y listos para su uso posterior,
generados para cubrir una necesidad u objetivo.
Un sistema de información es el sistema de personas, registros de datos y actividades que
procesa los datos y la informació n en cierta organizació n, incluyendo manuales de
procesos o procesos automatizados.

Un sistema de informació n consiste de 3 componentes: humano, tecnología y organizació n.

Un sistema de informació n es un conjunto de elementos interrelacionados con el
propó sito de prestar atenció n a las demandas de informació n de una organizació n, para
elevar el nivel de conocimientos que permitan un mejor apoyo a la toma de decisiones y
desarrollo.
Un sistema de informació n realiza cuatro actividades bá sicas:
entrada,almacenamiento,procesamiento y salida deinformació n.

Pá gina 4
 ANALISIS Y DISEÑ O DE SISTEMAS

Sistema informático

Es un sistema de informació n que aplica o utiliza el computador como componente de

proceso.
Es un conjunto de elementos, como son Hardware, software y recursos humanos para
cumplir un objetivo, que permiten almacenar y procesar informació n.

Conjunto de elementos interconectados o relacionados para el tratamiento de

informació n. El má s bá sico es un ordenador típico. Los má s complejos son las redes,
sistemas de procesamiento en paralelo.

Un sistema informá tico utiliza dispositivos programables por medio de computadoras,

siendo una síntesis de hardware y software.
Un sistema informá tico es el conjunto de elementos de hardware y software orientados al
procesamiento Automatizado de la informació n en una rama concreta de la actividad
humana, a los efectos de proveer los resultados informativos en un tiempo y con un costo
tal que no pudieran ser obtenidos por otros medios.
Un sistema informá tico utiliza ordenadores para almacenar datos, procesarlos y ponerlos
a disposició n de quien se considere oportuno.

Ejemplos

 Sistema informá tico. de facturació n

 Sistema informá tico. De un cajero de bancos, etc
 Sistema informá tico de cuenta de usuarios de un banco.
 Sistema informá tico registro de materiales de colegios.
 Sistema informá tico de pasajes.
 Sistema informá tico de RENIEC.
 Sistema informá tico de cajeros.
 Sistema informá tico control de stock de una bodega.

¿Qué es Análisis y Diseño?

Para crear una aplicació n de Software, es necesaria una descripció n del problema y de los
requerimientos, Qué problema vamos a resolver y qué debe hacer el sistema son las
preguntas principales que deben responderse en esta fase. El aná lisis se centra en una
investigació n del problema má s que en una solució n.

Para desarrollar una aplicació n es necesario contar con una descripció n de alto nivel y de
una descripció n detallada de la solució n propuesta, y como dicha solució n cumple con los
requerimientos y restricciones planteados. El Diseñ o se centra en una solució n ló gica, es
decir, có mo el sistema propuesto cumple con los requerimientos.

Finalmente el diseñ o se implementa en un software y hardware (Implementació n).

Pá gina 5
 ANALISIS Y DISEÑ O DE SISTEMAS

¿Qué es Análisis y Diseño Orientado a Objetos?

La esencia del aná lisis y diseñ o orientado a objetos es el considerar tanto el dominio del
problema como la solució n ló gica desde la perspectiva de los objetos (cosas, conceptos o
entidades).
El análisis enfatiza la bú squeda y descripció n de objetos o conceptos del dominio del
problema. Por ejemplo, en un sistema de préstamo, los posibles conceptos son: Libro,
Librería, Préstamo, etc.

1. Comprender el problema que tendrá que resolver el software

2. Suscitar cuestiones relevantes acerca del problema y del sistema
3. Proporcionar una base para responder preguntas acerca de las propiedades
específicas del problema y del sistema
4. Decidir lo que tiene que hacer el sistema
5. Decidir lo que no tiene que hacer el sistema
6. Asegurar que el sistema satisfaga las necesidades del usuario y definir criterios de
aceptació n
7. Proporcionar una base para el desarrollo del sistema

Mientras que el diseño enfatiza la definició n de modelos ló gicos de software que será n
finalmente implementados en un lenguaje orientado a objetos. Estos conceptos también
cuentan con atributos y métodos, por ejemplo, Libro tiene un Autor y un Título.

1. Lenguaje donde se llevará a cabo la implementació n

2. Desarrollo o gestió n de la interfaz grá fica
3. Limitaciones de equipo que deben tomarse en cuenta
4. Compatibilidad de versiones
5. Promover la reutilizació n de có digo.
6. Ensamblar partes reusables
7. Sistemas independientes de equipo y portabilidad de los sistemas.
8. Atributos derivados, operaciones, etc.

Por ú ltimo durante la construcció n, los componentes del diseñ o se implementan en un

lenguaje orientado a objetos.

La Implementación, Involucra la generació n de có digo en el lenguaje seleccionado en el

diseñ o y respetando las distintas decisiones de los distintos niveles. La salida de esta etapa
es el có digo fuente.

Las Pruebas, Consiste en ver que los requerimientos del usuario se cumplan en el sistema
de forma correcta.

Análisis de sistemas Informáticos:

Pá gina 6
 ANALISIS Y DISEÑ O DE SISTEMAS
Sirven para recopilar o relevar la informació n del sistema o la realidad para identificar sus
principales características y así proponer una posible solució n.
El aná lisis de sistemas es la ciencia encargada del análisis de sistemas grandes y complejos
y la interacció n entre esos sistemas.
se denomina aná lisis de sistemas a una de las etapas de construcció n de un sistema
informá tico, que consiste en relevar la informació n actual y proponer los rasgos generales
de la solució n futura.

Los sistemas en relació n con el aná lisis de sistemas está n relacionados con cualquier
campo tales como: procesos industriales, administració n, toma de decisiones, procesos,
protecció n al medio ambiente, etc.
El aná lisis de sistemas es una guía que permite estructurar el proceso de desarrollo de
sistemas de informació n.

Ejemplos:

 Recoger datos de có mo funciona el sistema informá tico.

 Definir y evaluar pará metros de utilizació n.
 Modelador de aná lisis de sistemas.
 Procesar la informació n recopilada.
 Organizar instrumentos de validació n.
 Mostrar las conclusiones del proceso de investigació n.

Diseños de sistemas informáticos:

Proceso de aplicar ciertas técnicas y principios con el propó sito de definir un proceso o
sistema con suficiente detalle como para permitir su interpretació n y realizació n física
(Fácil de manejar y entendible).

Ejemplos:

 Modelado del diseñ o de sistema.

 Elaborar la presentació n del sistema.
 Desarrollar el menú de navegació n del sistema.
 Desarrollar la interfaz de mantenimiento de sistema.
 Elaborar la interfaz de los formularios de sistema.

APLICACIÓN DE LA METODOLOGIA

El enfoque que se va a realizar en este curso es el enfoque orientado a objetos, utilizando

el RUP (Rational UnifiedProcess) como la metodología que va a servir como base para el
aná lisis y diseñ o del nuevo sistema de informació n presentado pero el cual va hacer uso
del Lenguaje Modelado Unificado (UML) para la diagramació n y representació n de los
modelos a utilizar en las fases de aná lisis y diseñ o del sistema.
En el enfoque orientado a objetos se cambia la visió n que se tenía de los Sistemas como
una secuencia de acciones las cuales permitían obtener salidas de informació n.

Pá gina 7
 ANALISIS Y DISEÑ O DE SISTEMAS
En el enfoque orientado a objetos vamos a ver la manera sobre có mo se entiende el
concepto de aná lisis y diseñ o orientado a objetos.
3.1. Análisis y Diseño Orientado a Objetos.

A. Análisis Orientado a Objetos.

“En esta fase se aplican los conceptos orientados a objetos (Herencia,

poliformismo, etc.) al modelo de problemas y sistemas”. (Bunge: 1999)
“Esta fase produce un modelo conceptual de la forma en que percibimos la
realidad”. (Martin J: 1997).

Esta fase es una de las importantes debido a que aquí vemos que es lo que
queremos obtener y si no se realiza bien, tal vez los resultados no sean los
deseados.

B. Diseño Orientado a Objetos.

“Viene a ser el proceso de construir la arquitectura del sistema mediante la

aplicació n de los elementos y conceptos del enfoque orientado a objetos”.
(Bunge:1999)
“Esta fase va a producir el modelo en que se especifica la forma en que se
implementara el Modelo Conceptual” (Martin J: 1997)

3.2. Descripción de la Metodología y Lenguaje de Modelado Utilizado.

A. Metodología RUP (Proceso Unificado Racional)

a. Definición de RUP
El proceso unificado Racional es una metodología creada por la Rational
Rose Corporation para brindar a los analistas y desarrolladores de
software una metodología que permita guiar el proceso de aná lisis y
diseñ o de sistemas así como su desarrollo de manera fá cil y clara, esta
metodología.

b. Fases del desarrollo con RUP

La metodología RUP cuenta de 4 fases fundamentales las cuales son el

aná lisis de requerimientos, el diseñ o del sistema, diseñ o detallado e
implementació n y pruebas.

Análisis de requerimientos

En esta etapa se logra claridad sobre lo que desea el usuario y en la forma

en la cual se le va a presentar la solució n que se esta buscando.
Las actividades que se realizan en esta fase son las siguientes:
 Identificar los casos de usos
 Dar detalle de los casos de usos descritos.
 Definir una interfaz inicial del sistema (si es aplicable)

Pá gina 8
 ANALISIS Y DISEÑ O DE SISTEMAS
 Desarrollar el modelo del mundo.
 Validar los modelos.
Diseño del sistema

En esta etapa se define una subdivisió n en aplicaciones del sistema (si es

lo suficientemente grande) y la forma de comunicació n con los sistemas
ya existentes con los cuales debe interactuar.
En esta fase se realizan las actividades siguientes:

 Identificar la arquitectura del sistema

 Definir componentes del sistema, las aplicaciones y su ubicació n
 Definir mecanismos de comunicació n.

Diseño detallado

En esta etapa se adecua el aná lisis a las características específicas del

ambiente de implementació n y se completan las distintas aplicaciones del
sistema con los modelos de control, interfaz o comunicaciones, segú n sea
el caso. En esta fase se realizan las siguientes actividades:

 Agregar detalles a la implementació n al modelo del mundo, mediante

diagramas de clases y paquetes, con el detalle de la implementació n.
 Desarrollar el modelo de interfaz, a través de diagramas de
interacció n con el detalle de las operaciones mas importantes del
sistema.
 Desarrollar los modelos de control, persistencia y comunicaciones,
realizando los diagramas de estados y/o actividades para las clases
concurrentes.

Implementación y Pruebas

Se desarrolla el có digo de una manera certificada. En esta fase se realizan

las siguientes actividades:

 Definir está ndares de programació n

 Codificació n y pruebas unitarias
 Pruebas de mó dulos y de sistema

Diagrama de las fases de la Metodología RUP

Análisis de requerimientos

Diseño del Sistema

Diseño Detallado

Implementación y Pruebas

Pá gina 9
 ANALISIS Y DISEÑ O DE SISTEMAS

Como el sentido de una metodología es dar unas pautas para seguir un proceso de
desarrollo, no es una estructura rígida la cual se tiene que seguir a pie de la letra,
es por eso que estas se pueden adoptar de acuerdo al requerimiento del analista o
desarrollador.

Ademá s las metodologías pueden usar distintos tipos de lenguaje de modelado, en

el caso de la metodología RUP puede utilizar también distintos tipos de lenguajes
modeladores, pero la Rational Software en su afá n de establecer un está ndar el
cual sea utilizado por todos, creo el Lenguaje de Modelado Unificado como un
está ndar que utilice la Metodología RUP para llevar a cabo el modelado del aná lisis
y diseñ o del sistema, esta vinculació n hace mucho má s flexible la Metodología RUP
haciéndola adaptarse al uso de los modelos de este lenguaje.

B. Lenguaje de Modelado Unificado (UML)

Es un lenguaje grá fico para visualizar, especificar y documentar cada una de

las partes que comprende el desarrollo del software. UML entrega una forma
de modelar cosas conceptuales como lo son procesos de negocio y funciones
del sistema, ademá s de cosas concretas como lo son escribir clases en el
lenguaje determinado, esquemas de base de datos y componentes de software
reusables. (Grady Booch, JimRumbaugh, Ivar Jacobson, 1999).

UML ha sido creado por los expertos de metodología Grady Booch, Ivar
Jacobson, y JimRumbaugh en Rational Software, utilizando informació n de
otros importantes expertos en metodología, vendedores de software, y
usuarios finales.

Su objetivo era unificar los diversos sistemas que había y crear un lenguaje de
modelado con las mejores características de cada uno.
UML fue adoptado por el OMG (Object Management Group) como está ndar en
noviembre de 1997.

¿Qué es UML?

 UML = UnifiedModelingLanguage
 Un lenguaje de propó sito general para el modelado orientado a objetos
 UML combina notaciones provenientes desde:

• Modelado Orientado a Objetos

• Modelado de Datos
• Modelado de Componentes
• Modelado de Flujos de Trabajo (Workflows)

Pá gina 10
 ANALISIS Y DISEÑ O DE SISTEMAS

Situació n de Partida

 Diversos métodos y técnicas OO, con muchos aspectos en comú n pero utilizando
distintas notaciones
 Inconvenientes para el aprendizaje, aplicació n, construcció n y uso de herramientas,
etc.
 Pugna entre distintos enfoques (y correspon-dientes gurú s)

=> Necesidad de una notació n está ndar

Historia de UML

 Comenzó como el “Método Unificado”, con la participació n de Grady Booch y

JimRumbaugh. Se presentó en el OOPSLA’95.
 El mismo añ o se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañ ía
Rational Software. Herramienta CASE Rational Rose.

Pá gina 11
 ANALISIS Y DISEÑ O DE SISTEMAS
Participantes en UML 1.0

 Rational Software
(Grady Booch, Jim Rumbaugh y Ivar Jacobson)
 Digital Equipment
 Hewlett-Packard
 i-Logix (David Harel)
 IBM
 ICON Computing
(DesmondD’Souza)
 Intellicorp and James Martin & co. (James Odell)
 MCI Systemhouse
 Microsoft
 ObjecTime
 Oracle
 PlatiniumTechnology
 Sterling Software
 Taskon
 Texas Instruments
 Unisys

UML aglutina enfoques OO

Pá gina 12
 ANALISIS Y DISEÑ O DE SISTEMAS
Perspectivas de UML

 UML será el lenguaje de modelizació n de objetos está ndar predominante los pró ximos
añ os.
 Razones:
• Participació n de metodó logos influyentes.
• Participació n de importantes empresas.
• Aceptació n del OMG como notació n está ndar.
 Evidencias:
• Herramientas que proveen la notació n UML.
• “Edició n” de libros.
• Congresos, cursos, “camisetas”, etc.

Uso de UML
 El objetivo de UML es describir cualquier tipo de sistema en términos de diagramas
orientados a objetos

 Algunas categorías de Sistemas

• Sistemas de Informació n
• Sistemas de Tiempo Real
• Sistemas Distribuidos
• Software de Sistemas
• Sistemas de Negocios

Modelado con UML

State
iagrams
Diagramas
Diagram
Use de State
State
Use
Cams
Diagramas de
Cas s
Clases Diagramas
Diagramas Casos deUso Diagram
Diagram
de
Cas
de
Secuencia
Objetos

Scenario
Scenario State
Diagramas
Diagram iagrams
Diagram
Diagramas de
Diagram
de
Colaboración Modelo Componentes

enario
Scenario ams
Diagramas
Diagramas grams
Diagram
Diagram
de Diagramas
de
Estados Despliegue
De
Actividad

Pá gina 13
 ANALISIS Y DISEÑ O DE SISTEMAS
“Un modelo es una descripció n completa de un sistema desde una perspectiva concreta”
Tipos de Diagramas UML

Diagrama de Casos de Uso

Diagrama de Clase (incluyendo Diagrama de Objetos)

Diagramas de Comportamiento

 Diagrama de Estados
 Diagrama de Actividad

Diagramas de Interacción

 Diagrama de Secuencia
 Diagrama de Colaboració n

Diagramas de implementación

 Diagrama de Componentes
 Diagrama de Despliegue

Pá gina 14
 ANALISIS Y DISEÑ O DE SISTEMAS

ACTIVIDAD Nº2
DIAGRAMAS DE CASOS DE USO

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el

punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos
funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar.
Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente
ú tiles en la comunicació n con el cliente.

Elementos Básicos

Casos de Uso

Es una técnica para capturar informació n de có mo un sistema o negocio trabaja

actualmente, o de có mo se desea que trabaje.

No pertenece realmente al enfoque orientado a objeto, má s bien es una técnica para el

modelado de escenarios en los cuales el sistema debe operar.

Cada Caso de Uso puede estar definido por:

 Texto que lo describe
 Secuencia de pasos ejecutados dentro del escenario
 Condiciones pre-post para que el escenario comience o termine
 Mezclando las anteriores

Un Caso de Uso es representado por una elipse y describe una situació n de uso del sistema
interactuando con actores

Pá gina 15
 ANALISIS Y DISEÑ O DE SISTEMAS

Actor

Un actor es un agente, alguien o algo que solicita un servicio al sistema o actú a

como catalizador para que ocurra algo

Los actores representan un tipo de usuario del sistema. Se entiendo como usuario
cualquier cosa externa que interactú a con el sistema. No tiene por qué ser un ser humano,
puede ser otro sistema informá tico o unidades organizativas o empresas. Siempre hay que
intentar independizar los actores de la forma en que se interactú a con el sistema.

Por ejemplo un teclado no es un actor en la mayor parte de los casos, só lo un medio para
introducir informació n al sistema. Suele ser ú til mantener una lista de los usuarios reales
para cada actor.
Un actor en un diagrama de casos de uso representa un rol que alguien puede estar
jugando, no un individuo particular por lo tanto puede haber personas particulares que
puedan estar usando el sistema de formas diferentes en diferentes ocasiones: socio de
biblioteca y bibliotecario.

Asociaciones
Hay una asociació n entre un actor y un caso de uso si el actor interactú a con el sistema
para llevar a cabo el caso de uso

Escenario
Es una interacció n entre el sistema y los actores, que puede ser descrito mediante una
secuencia de mensajes. Un caso de uso es una generalizació n de un escenario.

Ejemplos
 Escenario 1: José García se lleva prestado el tercer ejemplar de “Guerra y Paz” que
hay en la biblioteca. No tiene ningú n otro libro en préstamo.

 Escenario 2: Mó nica Díaz intenta llevarse prestado el primer ejemplar de “Ana

Karenina”, pero no puede porque ya tiene tres libros en préstamo, que es el
má ximo.

Todos los escenarios de un caso de uso deben tener en comú n que son intentos de hacer
esencialmente “lo mismo”, en este caso llevarse un libro en préstamo.
Los escenarios pueden y deben posteriormente documentarse mediante diagramas de
secuencia.

Pá gina 16
 ANALISIS Y DISEÑ O DE SISTEMAS
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el punto de vista del usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno
Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la
implementació n.

Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de

usuarios que participan en el mismo
Está n basado en el lenguaje natural, es decir, es accesible por los usuarios
El modelo de los Casos de Uso comprende los actores, el sistema y los propios casos de uso
El conjunto de funcionalidades de un sistema se determina examinando las necesidades
funcionales de cada actor, expresadas en forma de interacciones

Ejemplo:

Verificar Situación
Vendedor

Realizar Venta

Secretaria
Cliente

Preparar Catálogo

Supervisor
Establecer Crédito

Pá gina 17
 ANALISIS Y DISEÑ O DE SISTEMAS
Los actores se determinan observando:

 Usuarios directos del sistema.

 Responsables del uso o mantenimiento del sistema.
 Otros sistemas que interactú an con el sistema en cuestió n.

La misma persona física puede interpretar varios papeles como actores distintos
El nombre del actor describe el papel desempeñ ado.

La determinació n de los actores permite delimitar el alcance del sistema de manera

progresiva

Categorías de actores:

 Principales: personas que usan el sistema.

 Secundarios: personas que mantienen o administran el sistema.
 Material externo: dispositivos materiales imprescindibles que forman
parte del á mbito de la aplicació n y deben ser utilizados.
 Otros sistemas: sistemas con los que el sistema interactú a.

Tras localizar los actores, procede el describirlos.

Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias
de interacció n, los escenarios, desde el punto de vista del usuario.

Un escenario es una instancia de un caso de uso.

Los casos de uso intervienen durante todo el ciclo de vida

Pá gina 18
 ANALISIS Y DISEÑ O DE SISTEMAS

Pá gina 19
 ANALISIS Y DISEÑ O DE SISTEMAS

Pá gina 20
 ANALISIS Y DISEÑ O DE SISTEMAS
EJEMPLOS

Ejemplo: 01

En una bodega un cliente

pregunta, si venden leche el
vendedor le responde que si
vende leche entonces el
cliente realiza la compra de
2 litros de leche, luego el
cliente cancela, y el
vendedor le entrega los 2
litros de leche.

1. Identificando actores

-Cliente
-Vendedor

2. Identificando caso de
usos(proceso)

-Realizar consulta
-Realizar compra
-Cancelar compra
-Entregar producto

Ejemplo 02:

La secretaria de un Instituto” realiza el registro de las fichas de matrícula de los alumnos.

Ademá s, tiene que solicitar el horario de los profesores, para luego elaborar el cuadro de
horarios del IST.

Por otro lado tiene que realizar el cuadro de aulas disponibles para el desarrollo de clases y
finalmente entregar un informe final a direcció n.

Ejemplo 03:

Desarrolle un DCU para cancelar el recibo de luz en una oficina. De cancelació n de recibos de
Luz.

Ejemplo 04:

Desarrolle un DCU para retirar dinero de un cajero automá tico

Pá gina 21
 ANALISIS Y DISEÑ O DE SISTEMAS

Ejemplo 05:

En el restaurant “LA OLLA GORDA” se realizan los siguientes procesos para atender a los
diferentes clientes cuando el cliente ingresa la anfitriona les da la bienvenida y recibe las
prendas y los objetos de los clientes.

Los clientes son atendidos por meseros los cuales le van a indicar una mesa disponible. el
mesero entregara a los clientes la carta con el menú del día .
Los clientes deben seleccionar el menú a degustar.

El mesero recoge la carta con el menú seleccionado y se dirige hacia la cocina , en donde
entregara la lista con el menú seleccionado. Cocina servirá los menú s seleccionados el cual
el mesero le hará llegar a los clientes que le solicitaron.

Los clientes después de disfrutar la comida llamaran al mesero para solicitarle la cuenta.
Finalmente los clientes se retiran del restaurant “la olla gorda “recogiendo sus prendas y
objetos que será n entregados por la anfitriona.

Ejemplo 06:

Una persona desea realizar los trá mites para actualizar los datos de su DNI en la oficina de
RENIEC, esta persona debe realizar los siguientes procesos.
La persona en primer lugar debe esperar turno.

El agente de seguridad entregara un ticket de turno a la persona.

Luego la persona de acuerdo a su turno ingresara a la oficina, el asistente de administració n
solicita los documentos para verificarlos si está n correctamente.

Luego la persona se acerca al administrador, el administrador solicita los documentos

verificados, luego el administrador ingresa el nú mero de DNI a sistema de La RENIEC el
sistema de la RENIEC verifica los datos de la persona.

Luego el administrador solicita los datos de la persona para actualizarlos.

Luego el administrador con la conformidad de la persona, guarda los datos
Finalmente la persona firma y sella el padró n de actualizació n de datos de la persona.

Pá gina 22
 ANALISIS Y DISEÑ O DE SISTEMAS
CASOS PRACTICOS

CASO PRACTICO1

Un técnico en sistemas está operando un sistema de administració n de películas, el cual tiene

que tener en cuenta registrar a los actores de cada película, registrar el género, registrar la
película y ademá s registrar la programació n de las películas.
Identifique los actores y casos de uso.

CASO PRACTICO2

Una persona ingresa a una oficina de transporte terrestre, se acerca a la recepcionista y

realiza consultas.
Una vez informado, decide viajar. La recepcionista le solicita su DNI, la recepcionista ingresa
el DNI al sistema, el sistema proporciona los datos de la persona.
La recepcionista le solicita nú mero de asiento y finalmente imprime el boleto de viaje.
La persona cancela el valor del boleto de viaje y recibe el boleto de viaje.
Identifique los actores y casos de uso.

CASO PRACTICO3

Una persona ingresa a una farmacia. Se acerca al vendedor y realiza unas consultas. El
vendedor ingresa los datos del medicamento al sistema, el sistema proporciona la informació n
del medicamento.
La persona decide comprar, entonces el vendedor registra en un ticket los datos de la compra.
Luego la persona se acerca a caja para canjear el ticket por un comprobante de pago, cancela
el monto y recibe el comprobante. Luego se acerca a despacho, entrega el comprobante de
pago y recibe el medicamento.

Pá gina 23
 ANALISIS Y DISEÑ O DE SISTEMAS
ACTIVIDAD Nº3
TIPOS DE ASOCIACIONES

Hay una asociació n entre un actor y un caso de uso si el actor interactú a con el sistema para
llevar acabo el caso de uso.

Tipos de asociaciones:

 Existen tres tipos de asociaciones o relaciones en los diagramas de casos de uso :

 Extend
 Include
 generalizació n
INCLUDE

Se puede incluir una relació n entre dos casos de uso de tipo “include” si se desea especificar
comportamiento comú n en dos o má s casos de uso.

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso
de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido.
Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples
casos de uso a una descripción individual, desde el caso de uso.

En el diagrama, se indica mediante una flecha a trazos y abierta, como en este ejemplo:

 En el ejemplo indica que tanto “reservar libro” como “renovar préstamo “hacen algo
en comú n: “comprobar reserva”.
 Ventajas:
 Las descripciones de los casos de uso son má s cortas y se entienden mejor.
 La identificació n o funcionalidad comú n puede ayudar a descubrir el posible uso
de componentes ya existentes en la implementació n.
 Desventajas:
 La inclusió n de estas relaciones hace que los diagramas sean mas difíciles de leer,
sobre todo para los clientes.

Los casos de uso obligatoriamente deben realizarse para que el caso de uso base
funcione

Pá gina 24
 ANALISIS Y DISEÑ O DE SISTEMAS
<<include>>

iniciar sesion verificar datos

usuario

caso de uso base caso de uso incluido

caso de uso primario caso de uso secundario
caso de uso padre caso de uso hijo
caso de uso origen caso de uso destino

Ejemplo1

<<include>>
retirar dinero
verificar usuario
usuario

Interpreta:_______________________________________________________________________
___________________________________________________________________
Ejemplo2

<<include>>
iniciar sesion
verificar datos
usuario

Interpreta:_______________________________________________________________________
___________________________________________________________________
Ejemplo3

Interpreta:_________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________

Pá gina 25
 ANALISIS Y DISEÑ O DE SISTEMAS

EXTEND

Se puede incluir una relació n entre

dos casos de uso de tipo “extend” si
se desea especificar diferentes
variantes del mismo caso de uso.
Dicho de otra forma, la relació n
“extend” implica que el
comportamiento de un caso de uso
es diferente dependiendo de ciertas
circunstancias.
En principio, esas variaciones
pueden también mostrar de como
diferentes descripciones de
escenarios asociadas al mismo caso de uso.

Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a
otro. Esta relación indica que el comportamiento del caso de la extensión se
utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o
inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido
bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea
discontinua, desde el caso de uso extensión al caso de uso extendido, con la
etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para
acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.
Atenció n: la flecha en el caso de las relaciones “extend” va hacia el caso de uso
“original”.

Ejemplo1
Interpreta:_________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
_

Pá gina 26
 ANALISIS Y DISEÑ O DE SISTEMAS

Ejemplo2

Interpreta:________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
______________________________________

Ejemplo3

Interpreta:________________________________________________________________________
________________________________________________________________________________
_______________________________________________________________________________

Pá gina 27
 ANALISIS Y DISEÑ O DE SISTEMAS

GENERALIZACION

En un diagrama de casos de uso también pueden mostrarse generalizaciones (relaciones de

herencia) para mostrar que diferentes elementos está n relacionados como tipos de otros.
Son aplicables a actores o casos de uso, pero para estos ú ltimos la semá ntica es muy similar a
las relaciones “extend”.

Es la actividad de identificar elementos en común entre conceptos y definir las relaciones

de una superclase (concepto general) y subclase (concepto especializado). Es una manera
de construir clasificaciones taxonómicas entre conceptos que entonces se representan en
jerarquías de clases. Las subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una relació n

generalizació n/especializació n. Un caso de uso dado puede estar en una forma especializada
de un caso de uso existente. La notació n es una línea só lida terminada en un triá ngulo
dibujado desde el caso de uso especializado al caso de uso general.

Ejemplo1

Interpreta:_____________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
_________________

Pá gina 28
 ANALISIS Y DISEÑ O DE SISTEMAS

Ejemplo2

Interpreta:________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________

Pá gina 29
 ANALISIS Y DISEÑ O DE SISTEMAS
Ejemplo3

Interpreta:______________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________
_______________________

CASOS PRACTICOS

Caso1

 Un cliente ingresa a una farmacia se acerca a una vendedora para comprar un

determinado medicamento la vendedora realiza la consulta en el sistema sobre el
medicamento sobre si está disponible.
 Luego la vendedora le elabora un ticket, ademá s también le solicita al cliente si desea
acumular puntos bonos.
 El cliente se acerca a caja para cancelar sobre el medicamento, la cajera le solita el
ticket para canjearlo por un comprobante.
 En el comprobante se debe registrar los datos del cliente los datos del medicamento
los datos del vendedor.
 Al momento de cancelar la cajera le solicita al cliente si desea aportar una donació n
con fines benéficos.
 El cliente cancela el monto a pagar y se acerca a la ventanilla de despacho.
 En despacho para que le entreguen el medicamento debe entregar el comprobante.
 El cliente entrega el comprobante recibe el medicamento recibe su medicamento y se
retira.

Elabore un diagrama de caso de uso considerando clase de uso include, caso de uso extend.

Pá gina 30
 ANALISIS Y DISEÑ O DE SISTEMAS

Caso 2

 El jefe de personal de una empresa, cada fin de mes debe realizar el respectivo pago a
los trabajadores que elaborar en dicha empresa.
 En primer lugar, para efectuar el sueldo neto del trabajador, debe calcular el sueldo
bruto, los aportes y descuentos de ley.
 Teniendo en cuenta que para calcular el sueldo bruto debe verificar el control de días
elaborados de cada trabajador.
 Todos los datos son ingresados al sistema de control de pagos.
 Dependiendo del mes el jefe de personal decide calcular o no para los trabajadores un
aporte extra.
 Por otro lado para cancelar los pagos a los trabajadores de puede realizar mediante
cheque, deposito o en efectivo.

Realiza un diagrama de caso de uso considerando includes y extend.

Caso 3

 Una empresa de combustibles, desea administrar adecuadamente el servicio que

brinda a todos sus clientes para esto describe los procesos que se realizan para la
atenció n de los clientes.
 En primer lugar cuando se acerca un cliente con su vehículo el empleado solicita el
valor, valor que se ingresara al surtidor. Este valor puede ser monetario o cantidad de
galones.
 En segundo lugar al momento de cancelar el servicio el empleado registra la
cancelació n considerando los datos del cliente y el servicio y por ú ltimo el empleado
ofrece al cliente acumular puntos o registrarle un comprobante de pago.
 Si el cliente esta registro y acumula puntos le regala gorros.
 Ademá s los pagos se pueden hacer en efectivo o con tarjeta.

Realice un diagrama de caso de uso considerando casos de uso include y extend.

Caso 4

 Una encuestadora del gobierno desea conocer la informació n familiar de vivienda y

laboral de cada familia de un determinado lugar.
 En primer lugar para recopilar la informació n familiar se considera registrar los datos
del padre, de la madre y de las hijos y ademá s de cada uno se debe registrar el lugar y
fecha de nacimiento, registrar grado académico.
 En segundo lugar para recopilar la informació n de la vivienda se considera registrar el
estado de la vivienda la condició n e la vivienda y el nú mero de habitantes.
 En tercer lugar para recopilar la informació n econó mica se considera registrar los
datos del padre y de la madre y ademá s de cada uno se debe registrar el centro de
trabajo, añ o de servicio y condició n laboral.

Pá gina 31
 ANALISIS Y DISEÑ O DE SISTEMAS
Realice un diagrama de caso de uso considerando includes y generalización.

ACTIVIDAD Nº4
DIAGRAMA DE SECUENCIA

El diagrama de secuencia es un tipo de diagrama usado para modelar interacció n entre

objetos en un sistema segú n UML.

Utilidad

Un diagrama de secuencia muestra la interacció n de un conjunto de objetos en una aplicació n

a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de
uso permite el modelado de una vista bacines del escenario, el diagrama de secuencia
contiene detalles de implementació n del escenario, incluyendo los objetos y clases que se
usan para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripció n de un caso de uso para determinar qué objetos son
necesarios para la implementació n del escenario. Si se dispone de la descripció n de cada caso
de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos
para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama
de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas
verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincró nicos y asincró nicos. Los mensajes sincró nicos se
corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el
mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan
con flechas con la cabeza llena. Los mensajes asincró nicos terminan inmediatamente, y crean

Pá gina 32
 ANALISIS Y DISEÑ O DE SISTEMAS
un nuevo hilo de ejecució n dentro de la secuencia. Se representan con flechas con la cabeza
abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas:

 De instancia: describe un escenario específico (un escenario es una instancia de la

ejecució n de un caso de uso).
 Genérico: describe la interacció n para un caso de uso; Utiliza ramificaciones
("Branches"), condiciones y bucles.

Estructura

Los mensajes se dibujan cronoló gicamente desde la parte superior del diagrama a la parte
inferior; la distribució n horizontal de los objetos es arbitraria. Durante el aná lisis inicial, el
modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje.
Má s tarde, durante el diseñ o, el nombre 'business' es reemplazado con el nombre del método
que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a
la definició n de la clase instanciada por el objeto en la recepció n final del mensaje.

ELEMENTOS PRINCIPALES DE UN DIAGRAMA DE SECUENCIA

El diagrama de secuencias consta de objetos, representados del modo usual: rectá ngulos con
nombres subrayados, estímulos (también conocidos como mensajes) representados por
líneas continuas con una punta de flecha y el tiempo representado por una progresió n
vertical.

a. Objetos

Los objetos se colocan cerca de la parte superior del diagrama, de izquierda a derecha y se
acomodan de manera que simplifiquen el diagrama. La extensió n que está debajo y en forma
descendente será una línea discontinua conocida como la línea de vida del objeto. Junto con la
línea de vida del objeto se encuentra un pequeñ o rectá ngulo conocido como activació n, el cual
representa la ejecució n de una operació n que realiza el objeto. La longitud del rectá ngulo se

Pá gina 33
 ANALISIS Y DISEÑ O DE SISTEMAS
interpreta como la duració n de la activació n NOMBRE 1Representació n de un objeto con su
línea de vida y su activació n.

b. Estímulos

Un estímulo que va de un objeto a otro pasa de la línea de vida de un objeto a la de otro. Un

objeto puede enviarse un mensaje a si mismo ( es decir desde su línea de vida hacia su propia
línea de vida).Un estímulo puede ser simple, síncrono o asíncrono. Un mensaje simple es la
transferencia del control de un objeto a otro. Si un mensaje envía un mensaje síncrono,
esperara la respuesta a tal mensaje antes de continuar. En el diagrama de secuencias, los
símbolos del mensaje varia, por ejemplo, la punta de flecha de flecha de un mensaje simple
está formada por dos líneas, la punta de flecha de un mensaje sincró nico esta rellena y la de
un asíncrono tiene una sola línea.

c. Tiempo

El diagrama representa el tiempo en direcció n vertical. El tiempo se inicia en la parte superior

y avanza hacia la parte inferior. Un mensaje que este mas cerca de la parte superior ocurrirá
antes de uno que esté má s cerca de la parte inferior. Con ello el diagrama de secuencias tiene
dos dimensiones. La dimensió n horizontal es la disposició n de los objetos y la dimensió n
vertical muestra el paso del tiempo.

EJEMPLO1: INTERACCION ENTRE ACTORES

Registrar comprobante de pago de una venta de un producto

1. En primer lugar se elabora el Diagrama de casos de usos

Pá gina 34
 ANALISIS Y DISEÑ O DE SISTEMAS
Diagrama de casos de usos

registrar empleado
registrar cliente

<<include>>

empleado
<<include>>

registrar comprobante

cliente

<<include>>

sistema
registrar producto

2. En segundo lugar se explota o se especifica los procesos o mensajes de cada caso de

uso, en ejemplo detallaremos el diagrama de secuencia del caso de uso Registrar
Cliente.

3. Se elabora un diagrama de secuencia en donde para mostrar todos los mensajes que
suceden entre los actores u objetos. Segú n como se muestra el ejemplo.

Diagrama de secuencia: Registrar cliente

Pá gina 35
 ANALISIS Y DISEÑ O DE SISTEMAS

Como pueden darse cuenta, es aquí donde se insertan todos los mensajes entre los actores u objetos en este
caso, solo hay interacción de mensajes entre actores. Como pueden darse cuenta se visualizan los mensajes
en un tiempo transcurrido.

EJEMPLO2:INTERACCION ENTRE ACTORES Y OBJETOS

Encuesta social para registrar el aspecto de la vivienda familiar

DIAGRAMA DE CASOS DE USOS

Pá gina 36
 ANALISIS Y DISEÑ O DE SISTEMAS

miembro familiar

encuestador
registrar aspecto de vivienda familiar

DIAGRAMA DE SECUENCIA: REGISTRAR ASPECTO DE VIVIENDA FAMILIAR

Este es un ejemplo entre actores y objetos. Como pueden darse cuenta el encuestador ingresa
los datos manualmente a una ficha de vivienda familiar que el miembro de la familia informa.

CASO1
ATENCION EN RESTAURANTE

Pá gina 37
 ANALISIS Y DISEÑ O DE SISTEMAS

Un restaurante desea implementa un S.I para esto identifica los siguientes procesos:

1. Recepcionar cliente
El mozo se acerca, le da la bienvenida y ofrece los dos tipos de mesa: mesa ejecutiva, mesa
comú n.
El cliente comunica sobre que mesa ubicarse.
2. Tomar pedido.
El mozo solicita al cliente lo que desea servirse.
El cliente informa lo que va a servirse.
Todos los datos son registrados en nota pedido los cuales numero mesa, platos, precio de
plato, bebida, precio bebida, cantidad y por ú ltimo los datos del cliente: nombres, apellidos y
DNI.
3. Registrar pedido.
Luego el mozo se acerca al asistente de cocina y le entrega la nota pedido, registra todos los
datos al sistema y luego la nota de pedido es alcanzarlo al cocinero. Para que este sirva el
plato y bebidas.
Luego el mozo atiende la mesa.
4. Cancelar servicios.
Finalmente el mozo se acerca a la mesa a realizar las respectivas cobranzas, el mozo entrega el
total a pagar, el cliente cancela con efectivo o tarjeta, los datos del cliente son ingresados al
sistema, con la fecha, total y el servicio luego el sistema imprime el comprobante de pago.
El mozo entrega el comprobante y el cliente se retira.
Desarrolle:

 Realice diagrama de casos de usos.

 Realice diagrama de secuencia de cada caso de uso

CASO2

Pá gina 38
 ANALISIS Y DISEÑ O DE SISTEMAS
PRODUCCIÓN AUDIOVISUAL

La Producció n “ROLANDOSTUDIOS”, desea realizar un cortometraje, para esto deben

realizarse las siguientes actividades.

1. Elaborar el guió n, Responsable el Guionista.

2. Realizar casting, Responsable de Casting y Actores.
3. Buscar locació n, Responsable Director de Fotografía.
4. Realizar la filmació n, Responsable Producció n.
5. Realizar posproducció n, Responsable Jefe de Postproducció n.
6. Realizar estreno, Responsable .Productor Ejecutivo.

1. Elaborar el guión:

El guionista escribe la historia en el guió n luego el guió n es entregado a la Producció n,

producció n verifica, el cual puede ser aceptado ó rechazado.

2. Realizar casting:

Aquí el responsable de casting, publica un programa de casting, en donde los actores

se registran para ser evaluados, después de la evaluació n pueden ser aprobados o
desaprobados.

3. Buscar locación:
El director de fotografía busca y registra todos los escenarios de la filmació n, los
cuales son entregados a la producció n, y estos pueden ser aceptados o rechazados.

4. Realizar filmación:

Pá gina 39
 ANALISIS Y DISEÑ O DE SISTEMAS
El responsable es la producció n, junto a un equipo técnico y actores.
Donde la producció n ordena al equipo técnico y actores cumplir sus funciones, luego
producció n guardara los archivos.

5. Realizar Postproducción

El responsable es el jefe de producció n junto a un equipo técnico y el material.

El jefe producció n ordena la edició n y el acabado final del material.

6. Realizar estreno:

El productor ejecutivo se encargara de realizar contratos con los responsables de las

grandes salas de cine. Se pide
 Diagrama casos de usos
 Diagrama secuencia de cada caso de uso

CASO3
VENTA DE PASAJES

Pá gina 40
 ANALISIS Y DISEÑ O DE SISTEMAS

El señ or Juan Pérez Cruz ingresa a la Agencia por primera vez. Se acerca a la recepcionista de
venta de pasajes, la recepcionista le solicita el nú mero de DNI para que ingrese al sistema;
pero Don Juan Pérez Cruz no está en el sistema. Entonces la recepcionista tiene que registrar
al usuario. Para esto se solicita los siguientes datos:

 Nú mero de DNI
 Nombres
 Apellidos

Con esta informació n de usuario que se ha ingresado al sistema Don Juan Perez Cruz ya puede
realizar una compra de pasaje. Para registrar el boleto de pasaje la secretaria le solicita los
siguientes datos:

 Ruta
 Fecha de viaje
 Hora de viaje
 Numero de asiento.

De esta manera Don Juan Pérez Cruz obtiene su boleta de pasaje. Recordar que en el boleto de
pasaje también se debe incluir los datos de la recepcionista.

Realice el diagrama de caso de uso y los casos de secuencia

ACTIVIDAD Nº5
DIAGRAMAS DE COLABORACION

Pá gina 41
 ANALISIS Y DISEÑ O DE SISTEMAS

Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama

que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas
de secuencia, los diagramas de colaboració n, también llamados diagramas de comunicació n,
muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de
comunicació n no muestra el tiempo como una dimensión aparte, por lo que resulta
necesario etiquetar con nú meros de secuencia tanto la secuencia de mensajes como los hilos
concurrentes.

 Muestra có mo las instancias específicas de las clases trabajan juntas para conseguir un
objetivo comú n.
 Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de
un objeto a otro. Dicha implementació n es llamada "enlace".

Un diagrama de comunicació n es también un diagrama de clases que contiene roles de

clasificador y roles de asociació n en lugar de só lo clasificadores y asociaciones. Los roles de
clasificador y los de asociació n describen la configuració n de los objetos y de los enlaces que
pueden ocurrir cuando se ejecuta una instancia de la comunicació n. Cuando se instancia una
comunicació n, los objetos está n ligados a los roles de clasificador y los enlaces a los roles de
asociació n. El rol de asociació n puede ser desempeñ ado por varios tipos de enlaces
temporales, tales como argumentos de procedimiento o variables locales del procedimiento.
Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

DIAGRAMA DE CASOS DE USOS

CASOS PROPUESTO: REGISTRAR ALUMNO

Pá gina 42
 ANALISIS Y DISEÑ O DE SISTEMAS
1. Crea el diagrama de casos de usos

alumno

sistema

registrar alumno

secretaria

2. Agrega un Diagrama de secuencia, sabiendo que los diagramas de secuencia se

originan en el caso de uso.

1. clic derecho

2. clic
3. clic

3. Arrastra los actores del diagrama de casos de usos, al diagrama de secuencia.

Pá gina 43
 ANALISIS Y DISEÑ O DE SISTEMAS

4. arrástralos al área
de trabajo

4. Inserta los mensajes segú n le corresponde, es decir mensaje desde la secretaria hacia
el alumno y viceversa.

5. Inserta los
mensajes

5. Convierta el diagrama de secuencia en diagrama de colaboració n.

Pá gina 44
 ANALISIS Y DISEÑ O DE SISTEMAS

6. Arrastre los mensajes para que quede debe manera organizada.

6. Muévelos

Pá gina 45
 ANALISIS Y DISEÑ O DE SISTEMAS
ACTIVIDAD Nº6
DIAGRAMA DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un

sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases
son utilizados durante el proceso de aná lisis y diseñ o de los sistemas, donde se crea el diseñ o
conceptual de la informació n que se manejará en el sistema, y los componentes que se
encargaran del funcionamiento y la relació n entre uno y otro.

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de consentimiento.

Un diagrama de clases está compuesto por los siguientes elementos:

 Clase: atributos, métodos y visibilidad.

 Relaciones: Herencia, Composició n, Agregació n, Asociació n y Uso.

Pá gina 46
 ANALISIS Y DISEÑ O DE SISTEMAS
Elementos

 Clase

Es la unidad bá sica que encapsula toda la informació n de un Objeto (un objeto es una
instancia de una clase). A través de ella podemos modelar el entorno en estudio (una
Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectá ngulo que posee tres divisiones:

En donde:

o Superior: Contiene el nombre de la Clase

o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan
a la Clase (pueden ser prívate, protected o public).

Atributos, características o propiedades, son valores que

corresponden a un objeto, como color, material, cantidad, ubicació n.
Generalmente se conoce como la informació n detallada del objeto.
Suponiendo que el objeto es una puerta, sus propiedades serían: la
marca, tamañ o, color y peso.

o Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactú a el objeto con su entorno (dependiendo de la visibilidad: prívate,
protected o public).

Operaciones comú nmente llamados métodos, son aquellas actividades

o verbos que se pueden realizar con/para este objeto, como por
ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma
manera que el nombre de un atributo, el nombre de una operació n se
escribe con minú sculas si consta de una sola palabra. Si el nombre
contiene má s de una palabra, cada palabra será unida a la anterior y
comenzará con una letra mayú scula, a excepció n de la primera palabra
que comenzará en minú scula. Por ejemplo: abrirPuerta, cerrarPuerta,
buscarPuerta, etc.

Pá gina 47
 ANALISIS Y DISEÑ O DE SISTEMAS

Ejemplo:

Una Cuenta Corriente que posee como característica:

o Balance

Puede realizar las operaciones de:

o Depositar
o Girar
o y Balance

 El diseñ o asociado es:

Pá gina 48
 ANALISIS Y DISEÑ O DE SISTEMAS
 Atributos y Métodos:
o Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que
definen el grado de comunicació n y visibilidad de ellos con el entorno, estos
son:

 public (+, ): Indica que el atributo será visible tanto dentro como
fuera de la clase, es decir, es accsesible desde todos lados.

 private (-, ): Indica que el atributo só lo será accesible desde

dentro de la clase (só lo sus métodos lo pueden accesar).

 protected (#, ): Indica que el atributo no será accesible desde

fuera de la clase, pero si podrá ser accesado por métodos de la clase
ademá s de las subclases que se deriven (ver herencia).

o Métodos:

Los métodos u operaciones de una clase son la forma en como ésta interactú a
con su entorno, éstos pueden tener las características:

 public (+, ): Indica que el método será visible tanto dentro como
fuera de la clase, es decir, es accsesible desde todos lados.

 private (-, ): Indica que el método só lo será accesible desde dentro

de la clase (só lo otros métodos de la clase lo pueden accesar).

 protected (#, ): Indica que el método no será accesible desde fuera

de la clase, pero si podrá ser accesado por métodos de la clase ademá s
de métodos de las subclases que se deriven (ver herencia).

Pá gina 49
 ANALISIS Y DISEÑ O DE SISTEMAS

Al diseñ ar una clase se debe pensar en có mo se puede identificar un objeto real, como una
persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos
reales, es sobre lo que un sistema se diseñ a. Durante el proceso del diseñ o de las clases se
toman las propiedades que identifican como ú nico al objeto y otras propiedades adicionales
como datos que corresponden al objeto. Con los siguientes ejemplos se definen tres objetos
que se incluyen en un diagrama de clases:

Ejemplo 1: Una persona tiene nú mero de documento de identificació n, nombres, apellidos,

fecha de nacimiento, género, direcció n postal, posiblemente también tenga nú mero de
teléfono de casa, del mó vil, FAX y correo electró nico.

Ejemplo 2: Un sistema informá tico puede permitir administrar la cuenta bancaria de una
persona, por lo que tendrá un nú mero de cuenta, nú mero de identificació n del propietario de
la cuenta, saldo actual, moneda en la que se maneja la cuenta.

Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dó nde las operaciones bancarias de
una cuenta (como en el ejemplo 2) se manejará n realizando diferentes operaciones que en el
diagrama de clases de balurdes só lo se representan como operaciones, que pueden ser:

 Abrir
 Cerrar
 Depó sito
 Retiro
 Acreditar Intereses

Pá gina 50
 ANALISIS Y DISEÑ O DE SISTEMAS
Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u
operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de
datos y el tercero clase de ló gica de negocio, dependiendo de quién diseñ e el sistema se
pueden unir los datos con las operaciones.

El diagrama de clases incluye mucha má s informació n como la relació n entre un objeto y otro,
la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son
implementadas para una interfaz grá fica.

Ejemplos:

DIAGRAMAS DE CLASES

cliente
empleado
#codcliente boleta
+nomcliente #codemp
+apelcliente #numbol 1 +nomemp
*
+dircliente +fecha +apelemp
+teldcliente +total
1 * +vender()
+emailcliente +codcliente
+dnicliente +codemp

+comprar() +guardar()

producto
*
#codprod
1 +desprod
detalle +punitario
*
+numbol +guardar()
+codprod
+cant
+guardar()

Los diagramas de clases sirven para identificar las clases y como estas se relacionan
entre sí en un sistema de informació n.
Una clase es una representació n grá fica de un objeto.
Una clase está dividida en 3 partes:
 Nombre. Termino definido de la clase
 Atributos. Características del objeto
 Operaciones. Métodos o comportamientos del objeto

Pá gina 51
 ANALISIS Y DISEÑ O DE SISTEMAS

CASO PRÁCTICO

DESARROLLAR EL DIAGRAMA DE CLASES DE ORGANIZACIÓN DE LIBROS DE UNA BIBLIOTECA

autor
+codautor
#nomautor genero
+escribir() #codgen
1 1 +descripcion

libro
*
#codlibro
*
+titulo
+numpag
+codautor
+codgen

Pá gina 52
 ANALISIS Y DISEÑ O DE SISTEMAS
1. CARGAR STARUML

2. EN STAR UML, EN MODELO ANALISIS

Pá gina 53
 ANALISIS Y DISEÑ O DE SISTEMAS
3. INSERTANDO LA CLASE

4. AGREGANDO ATRIBUTOS

Pá gina 54
 ANALISIS Y DISEÑ O DE SISTEMAS
5. AGREGANDO OPERACIONES

6. INSERTANDO LLAVE PRIMARIA

7. ASOCIAR LAS CLASES

Pá gina 55
 ANALISIS Y DISEÑ O DE SISTEMAS

8. AGREGAR MULTIPLICIDAD

9. GUARDAR

Pá gina 56
 ANALISIS Y DISEÑ O DE SISTEMAS
CASO PRACTICO 2
PROVEEDOR
#CODPROVEEDOR
+NOMCIA
+DIRCIA CATEGORIA
+TELCIA PRODUCTOS
+WEBCIA 1 #CODCAT
1 +CODPROD +DESCRIPCION
*
+NOMPROD
*
+PUNITARIO
+SMAX
+SMIN
+CODPROVEEDOR
+CODCAT

CASO PRACTICO 3

cliente
empleado
#codcliente boleta
+nomcliente #codemp
+apelcliente #numbol 1 +nomemp
*
+dircliente +fecha +apelemp
+teldcliente +total
1 * +vender()
+emailcliente +codcliente
+dnicliente +codemp

+comprar() +guardar()

producto
*
#codprod
1 +desprod
detalle +punitario
*
+numbol +guardar()
+codprod
+cant
+guardar()

Pá gina 57
 ANALISIS Y DISEÑ O DE SISTEMAS
DIAGRAMAS DE CLASES
CASOS PRACTICOS

cliente
empleado
#codcliente boleta
+nomcliente #codemp
+apelcliente #numbol 1 +nomemp
*
+dircliente +fecha +apelemp
+teldcliente +total
1 * +vender()
+emailcliente +codcliente
+dnicliente +codemp

+comprar() +guardar()

producto
*
#codprod
1 +desprod
detalle +punitario
*
+numbol +guardar()
+codprod
+cant
+guardar()

Pá gina 58
 ANALISIS Y DISEÑ O DE SISTEMAS
CASO1
VENTA EN RESTAURANTE

Un restaurante desea implementa un S.I para esto identifica los siguientes procesos:
1. Recepcionar cliente
El mozo se acerca, le da la bienvenida ofrece los dos tipos de mesa: mesa ejecutiva, mesa
común.
El cliente comunica sobre que mesa ubicarse.
2. Tomar pedido.
El mozo solicita al cliente lo que van servirse.
El cliente informa lo que va a servirse.
Todos los datos son registrados en nota pedido los cuales numero mesa, platos, precio de
plato, bebida, precio bebida, cantidad y por último los datos del cliente: nombres, apellidos
y DNI.
3. Registrar pedido...
Luego el mozo se acerca al asistente de cocina y le entrega la nota pedido, registra todos los
datos al sistema y luego la nota de pedido es alcanzarlo al cocinero. Para que este sirva el
plato y bebidas.
Luego el mozo atiende la mesa.
4. Cancelar servicios.
Finalmente el mozo se acerca a la mesa a realizar las respectivas cobranzas, el mozo
entrega el total a pagar, el cliente cancela con efectivo o tarjeta, los datos del cliente son
ingresados al sistema, con la fecha, total y el servicio luego el sistema imprime el
comprobante de pago.
El mozo entrega el comprobante y el cliente se retira.
Por otro lado el restaurante cuenta con tres pc cada una con impresora.
Desarrolle un diagrama de clases

Pá gina 59
 ANALISIS Y DISEÑ O DE SISTEMAS
CASO2
PARTIDO POLITICO

Un partido político independiente encarga la responsabilidad al personero técnico registrar

a los adherentes, para los cuales se toman los siguientes datos:
DNI, nombres, apellido paterno, apellido materno.
Luego los datos son ingresados al sistema.
Luego el personero técnico valida los datos del sistema con RENIEC, para verificar si son
correctos, si son correctos se guardan en el sistema, sino serán rechazados.
Finalmente el personero realizara una impresión con el Padrón de adherentes, el cual
entrega al jurado nacional de elecciones (JNE).
Desarrolle un diagrama de clases

CASO3
LIBRERÍA

El propietario de una librería desea implementar un sistema informático para registrar los
libros de acuerdo al autor y al género.
Considerando las siguientes características de acuerdo al objeto definido; para libro se debe
considerar código de libro, titulo, fecha de publicación, numero de página.
Para el autor se consideran los siguientes datos:

Pá gina 60
 ANALISIS Y DISEÑ O DE SISTEMAS
 Código del autor
 Nombre del autor
 Apellido del autor
Para género se considera los siguientes datos:
 Código de genero
 Nombre de genero
Las actividades que realizan son las siguientes:
El objeto autor permitirá:
 inserta,
 guardar,
 editar
 buscar
De la misma manera ocurre para género y libro.
Interpretación 1.
 Un autor puede hacer uno a muchos libros
 Uno a muchos libros pertenecen a un autor.
Interpretación 2.
 Un género puede tener uno a muchos libros
 Uno a muchos libros pertenecen a un género.

Desarrolle un diagrama de clases

CASO4
APERTURA DE MODULOS

La especialidad de computación informática desea apertura un módulo de los muchos que

ofrece la carrera para esto la carrera de computación e informática desea implementar un
sistema informático que permita organizar dichos módulos.
Teniendo en cuenta que un módulo puede tener uno o muchos temas y por lo consiguiente
uno o muchos temas pertenecen a un módulo.
Por otro lado un módulo puede tener muchos materiales o no puede tener materiales por lo
consiguiente muchos materiales pertenecen a un módulo.
Un módulo se caracteriza por los siguientes datos:

Pá gina 61
 ANALISIS Y DISEÑ O DE SISTEMAS
 Código del modulo
 Titulo
 fecha de inicio
 Fecha final.
Las características del tema son los siguientes:
 Código de tema
 Título de tema
 Número de horas.
Las características de los materiales son los siguientes:
 Código de material
 Título.
Las actividades que realiza cada objeto son:
 Insertar
 Guardar
 Actualizar
 Buscar.
El modulo debe completar un total de horas para que culmine.
Interpretación 1.
 Uno a muchos temas pertenecen a un módulo.
 Un módulo pueden tener uno a muchos temas.
Interpretación 2.
 Un módulo puede tener mucho o no puede tener material.
 Muchos materiales pertenecen a un módulo.
Desarrolle un diagrama de clases

CASO5
ORGANIZAR PROVEEDOR

El propietario de una bodega desea implementar un sistema de registro de productos.

Para esto considera al proveedor con las siguientes características

Pá gina 62
 ANALISIS Y DISEÑ O DE SISTEMAS
 código de proveedor
 razón social
 dirección
 teléfono
 email

También considera la característica de categoría

 Código de la categoría
 Nombre de la categoría.

Las características del producto son:

 Código del producto
 Nombre del producto
 Precio unitario
 Stock máximo
 Stock mínimo

Las actividades son

 Insertar
 Guardar
 Editar
 buscar

Desarrolle un diagrama de clases

CASO6
AGENCIA DE TRANSPORTE

Una agencia de transporte desea implementar un sistema informático para los cuales se
considera lo siguiente. El pasajero el cual tiene las siguientes características:
 DNI

Pá gina 63
 ANALISIS Y DISEÑ O DE SISTEMAS
 Nombres
 Apellidos
 Dirección
 Razón social y
 RUC
Además considerar al empleado,el cual tiene las siguientes características
 DNI
 Nombres y
 Apellidos
Los datos del boleto del viaje son lo siguiente:
 Número del boleto
 Fecha de emisión
 Fecha de viaje
 Hora de viaje
 Numero de asiento
 Origen
 Destino
 Valor
Como dato de boleto se registra los datos del pasajero y los datos del empleado que los
emite.
Desarrolle un diagrama de clase considerando sus relaciones

CASO7
VENTA DE UTILES DE ESCRITORIO

Un propietario de una tienda de ventas de útiles de escritorio desea implementar un sistema

informático para los cuales tiene encuentra los siguientes catos:
 Código de cliente
 Nombres
 Apellido
 Dirección
 razón social
 Ruc
Con respecto al producto se considéralos siguientes datos

Pá gina 64
 ANALISIS Y DISEÑ O DE SISTEMAS
 Código del, producto
 Descripción
 Precio unitario
 Stock máximo
 stock mínimo
Teniendo en cuenta que los productos pertenecen a una categoría para lo cual se considera los
siguientes datos:
 Código de categoría
 Nombre
La tienda solo emite comprobante de pago por horas y por boletas. Para los cuales considera
los siguientes datos
 Numero de boleta
 Fecha de emisión
 Total
 código de empleado
 código del cliente
En< los detalles de las boletas se considera
 número de boleta
 código de productos
 cantidad
Desarrolle un diagrama de clase considerando sus relaciones

CASO8
ORGANIZAR PROVEEDOR

Una empresa comercializadora de productos desea implementar un sistema

informá tica considera los siguientes datos: los datos del proveedor son los siguientes:
Có d. proveedor

Pá gina 65
 ANALISIS Y DISEÑ O DE SISTEMAS
Razó n social
Ruc
Direcció n
Telefoneo
Correo electró nico.

Por otro lado se considera a los productos los cuales son:

Có d. producto
Nombre
Precia
Stock mínimo
Stock má ximo

Teniendo en cuenta que pertenecen a una categoría Los cuales son:

Có digo
Descripció n
También se considera a los datos del empleado los cuales son:
Có digo del empleado
Nombre
Apellido
Direcció n
Teléfono.
La empresa comercializadora contara con los servicios se transporte de envío para
esto se considera:
el có digo de transporte de envío
nombre de compañ ía
direcció n
teléfono
Por otro lado se considera la nota de pedido de,los Cuales son los siguientes datos:
numero de pedido
fecha de emisió n
fecha de pedido
fecha de entrega
total
Teniendo en cuenta que la nota de o pedido le pertenece a un proveedor le emite un
empleado y lo transporta a una compañ ía de envío.
Ademá s se considera el detalle a la nota de pedido en él se contempla:
Numero de pedido Có digo de producto Cantidad de descuento.

Desarrolle un diagrama de clase considerando sus relaciones

CASO9
Pá gina 66
 ANALISIS Y DISEÑ O DE SISTEMAS
SISTEMA MATRICULA

La oficina del instituto desea implementar un sistema informá tico para los cuales
desea Con respecto al alumno
 Có digo alumno.
 Nombre
 Apellido
 Direcció n
 Teléfono
Por otro lado los datos de la secretaria
 Có digo secretaria
 Nombre
 Apellido
 Direcció n
 Teléfono
Ademá s se considera el concepto del servicio como puede ser:
 Có digo concepto
 Descripció n
 Monto.
Los datos se registran en una ficha de matrícula los cuales son:
 Numero
 Fecha
 Có digo alum
 Có digo secretaria
 Có digo carrera
Considerando los datos de la carrera
 có digo de la carrera
 Nombre carrera
Cada ficha de matrícula genera un recibo de pago en los cuales se considera
 Numero de recibo
 Fecha
 Total
 Có digo concepto
CASO 10
Pá gina 67
 ANALISIS Y DISEÑ O DE SISTEMAS
ALQUILER DE DISFRACES

Una tienda de alquiler de disfraces desea implementar un sistema de informá tico para el
mejor control de alquiler.

Para esto tiene en cuenta al cliente, al cual se le considera los siguientes datos: có digo del
cliente, DNI, nombres, apellidos, direcció n, teléfono.

Ademá s se considera la empleada que realiza el alquiler, para ello se considera los
siguientes datos, có digo del empleado,nombres, apellidos, direcció n, teléfono.

Por otro lado se considera, todo alquiler de disfraces se registra en una ficha de alquiler,
en la cual se considera nú mero del alquiler, fecha de solicitud, fecha de salida, fecha de
devolució n, có digo del cliente, có digo del empleado y el total del alquiler.

Por otro lado se considera al disfraz y se considera los siguientes datos.

Có digo del disfraz, nombre del disfraz, nú mero de piezas

Ademá s el disfraz pertenece a una categoría y tiene los siguientes datos, có digo de
categoría, descripció n.

Toda ficha de alquiler, tiene detalle en donde se considera el nú mero del alquiler, có digo
del disfraz y la cantidad.

Desarrolle el diagrama de clases.

Pá gina 68
ANALISIS Y DISEÑ O DE SISTEMAS
ACTIVIDAD Nº7
DIAGRAMAS DE CLASES
TIPOS DE RELACIONES

Pá gina 69
 ANALISIS Y DISEÑ O DE SISTEMAS
RELACIONES ENTRE CLASE

Ahora ya definido el concepto de Clase, es necesario explicar có mo se pueden

interrelacionar dos o má s clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la

cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relació n y éstas pueden ser:

 uno o muchos: 1..* (1..n)

 0 o muchos: 0..* (0..n)
 número fijo: m (m denota el número).

1. ASOCIACIÓN:

La relació n entre clases conocida como Asociació n, permite asociar objetos que
colaboran entre si. Cabe destacar que no es una relació n fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.

Ejemplo:

Pá gina 70
 ANALISIS Y DISEÑ O DE SISTEMAS

2. AGREGACION Y COMPOSICION

Para modelar objetos complejos, n bastan los tipos de datos bá sicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicació n,
tenemos dos posibilidades:

 Por Referencia: Es un tipo de relació n diná mica, en donde el tiempo de vida del
objeto incluido es independiente del que lo incluye. Este tipo de relació n es
comú nmente llamada Agregació n (el objeto base utiliza al incluido para su
funcionamiento). La agregació n (por Referencia) se destaca por un rombo
transparente.

 Por Valor: Es un tipo de relació n está tica, en donde el tiempo de vida del objeto
incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de
relació n es comú nmente llamada Composició n (el Objeto base se construye a
partir del objeto incluido, es decir, es "parte/todo"). La composició n (por Valor)
se destaca por un rombo relleno.

Ejemplo1

En donde se destaca que:

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).

Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.

Pá gina 71
 ANALISIS Y DISEÑ O DE SISTEMAS
La flecha en este tipo de relació n indica la navegabilidad del objeto referenciado.
Cuando no existe este tipo de particularidad la flecha se elimina.

Ejemplo2

universidad * facultad * especialidad

estudiante

Como pueden darse cuenta la universidad está compuesta por facultades y está esta
compuesta por especialidades, si la clase facultad se destruye se destruyen las
especialidades de dicha facultad, ahora si se destruye la universidad se pierden todas
las facultades y a su vez todas las especialidades es decir es un ejemplo de agregació n
por composició n.

Ahora si se destruye la universidad no afecta a los estudiantes, ya que estos no son

composició n de la universidad sino simplemente una agregació n, porque pueden
estudiar en otra universidad.

Ejemplo3

Pá gina 72
 ANALISIS Y DISEÑ O DE SISTEMAS

motor
1

automovil

1
carroceria

conductor

Un automó vil está compuesto por un motor y carrocería, ya que si se destruye el

automó vil, se destruyen las clases de composició n pero esto no afecta a la clase
conductor ya que es una agregació n

3. GENERALIZACION

Indica que una subclase hereda los métodos y atributos especificados por una Super
Clase, por ende la Subclase ademá s de poseer sus propios métodos y atributos,
poseerá las características y atributos visibles de la Sú per Clase (public y protected),
ejemplo:

Pá gina 73
 ANALISIS Y DISEÑ O DE SISTEMAS

En la figura se especifica que Auto y Camió n heredan de Vehículo, es decir, Auto posee
las Características de Vehículo (Precio, VelMax, etc) ademá s posee algo particular que
es Descapotable, en cambio Camió n también hereda las características de Vehículo
(Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo ú nico "visible" es el método

Características aplicable a instancias de Vehículo, Auto y Camió n, pues tiene definició n
pú blica, en cambio atributos como Descapotable no son visibles por ser privados.

PRACTICA

1. Interpreta el siguiente diagrama de clases considerando agregación y composición

Pá gina 74
 ANALISIS Y DISEÑ O DE SISTEMAS

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
___

2. Interpreta el siguiente diagrama de clases considerando agregación y generalización

Pá gina 75
 ANALISIS Y DISEÑ O DE SISTEMAS

3. Interpreta

Pá gina 76
 ANALISIS Y DISEÑ O DE SISTEMAS

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
____________________________________________________

4. interpreta

_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
_________________________________________________________________________________________________
____________________________________________________

Pá gina 77
 ANALISIS Y DISEÑ O DE SISTEMAS
ACTIVIDAD Nº8
DIAGRAMAS DE ESTADOS

registro guardado

generando nuevo codcliente guardando cliente

codcliente generado celcliente ingresado

ingresando nomcliente nomcliente ingresado apelcliente ingresado

ingreando apelcliente ingresando celcliente

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicació n en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones.
También ilustran qué eventos pueden cambiar el estado de los objetos de la clase.
Normalmente contienen: estados y transiciones.

Son ú tiles para modelar la vida de un objeto.

Un diagrama de estados muestra el flujo de control entre estados (en qué
estados posibles puede estar “cierto algo” y como se producen los cambios
entre dichos estados) Una máquina de estados es un comportamiento que
especifica las secuencias de estados por las que pasa un objeto a lo largo de
su vida en respuesta a eventos, junto con sus respuestas a esos eventos
(Booch, Rumbaugh, Jacobson)

ELEMENTOS DIAGRAMAS DE ESTADOS ESTADO

Es una condició n o situació n en la vida de un objeto durante la cual satisface una

condició n, realiza alguna actividad o espera algú n evento.

EVENTO

Es la especificació n de un acontecimiento significativo que ocupa un lugar en el

tiempo y en el espacio. Es la aparició n de un estímulo que puede (o no) activar una
transició n de estado.

Pá gina 78
 ANALISIS Y DISEÑ O DE SISTEMAS

Es una ocurrencia que puede causar la transició n de un estado a otro de un objeto.

Esta ocurrencia puede ser una de varias cosas:

 Condició n que toma el valor de verdadero o falso

 Recepció n de una señ al de otro objeto en el modelo
 Recepció n de un mensaje
 Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y
fecha particular

TRANSICION

Una transició n es una relació n entre dos estados que indica que un objeto que esté en
el primer estado realizará ciertas acciones y entrará en el segundo estado cuando
ocurra un evento especificado y se satisfagan unas condiciones especificadas.

NOTACIÓN DIAGRAMA DE ESTADOS

Pá gina 79
 ANALISIS Y DISEÑ O DE SISTEMAS

Caso1: Estados simples

De la clase cliente

cliente
+codcliente
+nomcliente
+apelcliente
+celcliente registro guardado

+insertar()
+guardar() guardando cliente
generando nuevo codcliente
+editar()
+buscar()

codcliente generado celcliente ingresado

ingresando nomcliente nomcliente ingresado apelcliente ingresado

ingreando apelcliente ingresando celcliente

Caso2: Estados simples

Pá gina 80
 ANALISIS Y DISEÑ O DE SISTEMAS
TIPOS DE DIAGRAMAS DE ESTADOS

Caso3: Estados compuesto secuenciales (Submaquina)

CLIENTE ingresando datos personales

+codcliente
+nomcliente
+apelcliente ingresando nomcliente
+dircliente ingresando apelcliente ingresando dircliente
+ciudad
+insertar()
+guardar()

datos personales ingresados

ingresando ciudad guardar cliente

Pá gina 81
 ANALISIS Y DISEÑ O DE SISTEMAS
Este tipo de estados compuestos es una ayuda para simplificar má quinas de estado
mediante un mecanismo de abstracció n de agregació n de estados dependientes.

Caso4: Estados compuesto concurrentes (Submaquina)

Las regiones ortogonales permiten especificar dos o má s má quinas de estados

anidadas que se ejecutan en paralelo en el contexto del objeto que las contiene.

El estado compuesto acaba mediante una sincronizació n de las regiones ortogonales:

las regiones que alcanzan sus estados finales quedan a la espera hasta que todas las
regiones acaban, y entonces concluye el estado compuesto.

Cada regió n ortogonal puede tener un estado inicial, un estado final y un estado de
historia.

tarjeta introducida

activo
inactivo
entry/leer tarjeta
exit/expulsar tarjeta

cancelar
validacion operacion seleccionada
ejecutar

tarjeta validada
continuar
procesamiento
seleccionar operacion
mantenimiento
do/probar
do/esperar orden
no continuar
probar perifericos autoanalizar impresion

esperar continuar no continuar

ordenar

tecla pulsada

Pá gina 82
 ANALISIS Y DISEÑ O DE SISTEMAS
Caso5: Ejemplo del termostato. Estado compuesto secuenciales

Algunos ejemplos: Estados Submaquinas

Pá gina 83
 ANALISIS Y DISEÑ O DE SISTEMAS
Estado Submaquinas

CASO PRÁCTICO:
AGENCIA DE TRANSPORTE

Una agencia de transporte desea implementar un sistema informá tico para los cuales
se considera lo siguiente. El pasajero el cual tiene las siguientes características:
 DNI
 Nombres
 Apellidos
 Direcció n
 Razó n social y
 RUC

Pá gina 84
 ANALISIS Y DISEÑ O DE SISTEMAS
Recordar que los datos del pasajero se verifican si es que ya existen.
Ademá s considerar al empleado, el cual tiene las siguientes características
 DNI
 Nombres y
 Apellidos
Recordar que los datos del pasajero se verifican si es que ya existen.
Loa datos del boleto del viaje son lo siguiente:
 Nú mero del boleto
 Fecha de emisió n
 Fecha de viaje
 Hora de viaje
 Numero de asiento
 Origen
 Destino
 Valor
Como dato de boleto se registra los datos del pasajero y los datos del empleado que
los emite.

Desarrolle un diagrama de clases

Desarrolle el diagrama de estados de las clases identificadas.
Considerar un diagrama que contemple diagrama de estados compuestos secuenciales,
concurrentes y Submaquinas de estados.

Pá gina 85
ANALISIS Y DISEÑ O DE SISTEMAS

ACTIVIDAD Nº9

DIAGRAMAS
DE
ACTIVIDADES

ingresar importe

importe >2000
NO
SI

calcular total aplicar descuento

calcular total

Pá gina 86
 ANALISIS Y DISEÑ O DE SISTEMAS
DIAGRAMA DE ACTIVIDADES

Un Diagrama de Actividades no es más que un caso especial de un diagrama de estados, en

el que todos los estados (o la gran mayoría) son actividades.

Un Diagrama de Actividades muestra el flujo de control entre una serie de tareas o

actividades.

Los Diagramas de Actividades son usados (entre otras cosas) para elaborar modelos de
flujos de trabajo*(workflow) de un sistema.

En general, un Diagrama de Actividades muestra una serie de acciones o tareas que se

ejecutan en cierto orden (y otros elementos adicionales).
*Un flujo de trabajo se puede ver como una serie de tareas (acciones) que son ejecutadas o
realizadas por ciertos actores en cierto orden preestablecido.

Pá gina 87
 ANALISIS Y DISEÑ O DE SISTEMAS
A cada actividad se le representa con un rectángulo de esquinas redondeadas. El
procesamiento dentro de una actividad se lleva a cabo y, al realizarse, se continúa con la
siguiente actividad. Una flecha representa la transición de una actividad a otra. El punto
inicial del diagrama se representa con un círculo relleno y uno final representado por una
diana.

COMPONENTES BASICOS

Actividad:
Es la especificación de un comportamiento que puede ser parametrizado y que define la
secuenciación coordinada de unidades subordinadas denominadas acciones.

Acción:
Una acción es la unidad fundamental de especificación de comportamiento. Una acción es
generalmente atómica, es decir, indivisible

Acción/Actividad
Una acción representa un paso del flujo de ejecución que se considera atómico,
mientras que una actividad representa un comportamiento compuesto de elementos
individuales que son acciones.

Transiciones:
Representan el paso de una acción a otra

Pá gina 88
 ANALISIS Y DISEÑ O DE SISTEMAS
Caso1: Cajero Automático

Caso2: Aplicar descuento si el importe es mayor a 2000

ingresar importe

importe >2000
NO
SI

calcular total aplicar descuento

calcular total

Pá gina 89
 ANALISIS Y DISEÑ O DE SISTEMAS
Caso3: Registrar pedido

Caso4: Diagrama de actividades para el proceso de negociación en una junta con un

cliente

Pá gina 90
 ANALISIS Y DISEÑ O DE SISTEMAS
Aplicación de carriles o particiones.
Sirve para agrupar las actividades en común.

Caso5: Procesar esquelas

Pá gina 91
 ANALISIS Y DISEÑ O DE SISTEMAS
Caso6: solicitar solvencia

Caso7: Enviar y Recepcionar señales

Pá gina 92
 ANALISIS Y DISEÑ O DE SISTEMAS
Caso8: Diagrama de actividades para el proceso de negociación en una junta con un
cliente.

Caso9: Realizar venta farmacia (utiliza carriles)

Una persona ingresa a una farmacia. Se acerca al vendedor y realiza unas consultas. El
vendedor ingresa los datos del medicamento al sistema, el sistema proporciona la
informació n del medicamento.
La persona decide comprar, entonces el vendedor registra en un ticket los datos de la
compra. Luego la persona se acerca a caja para canjear el ticket por un comprobante
de pago, cancela el monto y recibe el comprobante. Luego se acerca a despacho,
entrega el comprobante de pago y recibe el medicamento.

Caso10: Actualizar DNI (utiliza carriles)

Pá gina 93
 ANALISIS Y DISEÑ O DE SISTEMAS
Una persona desea realizar los trá mites para actualizar los datos de su DNI en la
oficina de RENIEC, esta persona debe realizar los siguientes procesos.
La persona en primer lugar debe esperar turno.
El agente de seguridad entregara un ticket de turno a la persona.
Luego la persona de acuerdo a su turno ingresara a la oficina, el asistente de
administració n solicita los documentos para verificarlos si está n correctamente.
Luego la persona se acerca al administrador, el administrador solicita los documentos
verificados, luego el administrador ingresa el nú mero de DNI a sistema de La RENIEC
el sistema de la RENIEC verifica los datos de la persona.
Luego el administrador solicita los datos de la persona para actualizarlos.
Luego el administrador con la conformidad de la persona, guarda los datos
Finalmente la persona firma y sella el padró n de actualizació n de datos de la persona.

Caso11: Atender mesa (utiliza carriles)

En el restaurant “LA OLLA GORDA” se realizan los siguientes procesos para atender
a los diferentes clientes cuando el cliente ingresa la anfitriona les da la bienvenida y
recibe las prendas y los objetos de los clientes.
Los clientes son atendidos por meseros los cuales le van ha indicar una mesa
disponible. el mesero entregara a los clientes la carta con el menú del día .
Los clientes deben seleccionar el menú a degustar.
El mesero recoge la carta con el menú seleccionado y se dirige hacia la cocina , en
donde entregara la lista con el menú seleccionado. Cocina servirá los menú s
seleccionados el cual el mesero le hará llegar a los clientes que le solicitaron.
Los clientes después de disfrutar la comida llamaran al mesero para solicitarle la
cuenta. Finalmente los clientes se retiran del restaurant “La Olla Gorda “recogiendo
sus prendas y objetos que será n entregados por la anfitriona.

Pá gina 94
ANALISIS Y DISEÑ O DE SISTEMAS
ACTIVIDAD Nº10

DIAGRAMA
DE
DESPLIEGUE

Pá gina 95
 ANALISIS Y DISEÑ O DE SISTEMAS
DIAGRAMA DE DESPLIEGUE

SERVIDOR

SWITCH

CLIENTE1

CLIENTE3
CLIENTE2

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado

que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y
las relaciones entre sus componentes.

EXPLICACIÓN

Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardware y
software en el sistema final, es decir, la configuración de los elementos de procesamiento
en tiempo de ejecución y los componentes software (procesos y objetos que se ejecutan en
ellos).
Describen la arquitectura física del sistema durante la ejecución, en términos de:
 procesadores
 dispositivos
 componentes de software
Describen la topología del sistema: la estructura de los elementos de hardware y el software
que ejecuta cada uno de ellos.

ELEMENTOS

NODOS

Los nodos son objetos físicos que existen en tiempo de ejecución, y que representan algún
tipo de recurso computacional (capacidad de memoria y procesamiento):
 Computadores con procesadores
 Otros dispositivos: impresoras, lectoras de códigos de barras, dispositivos de
comunicación.

Pá gina 96
 ANALISIS Y DISEÑ O DE SISTEMAS
DISPOSITIVOS

Los dispositivos del sistema también se representan como nodos. • Generalmente se usan
estereotipos para identificar el tipo de dispositivo.
Los nodos se conectan mediante asociaciones de comunicación.
Estas asociaciones indican:

 Algún tipo de ruta de comunicación entre los nodos.

 Los nodos intercambian objetos o envían mensajes a través de esta ruta.El tipo de
comunicación se identifica con un estereotipo que indica el protocolo de
comunicación o la red.

NODOS Y COMPONENTES Los nodos son los elementos donde se ejecutan los
componentes.

ARTEFACTOS

Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los
modelos del proceso. Ej: archivos fuente, ejecutables, documentos de diseño, reportes de
prueba, prototipos, manuales de usuario y más.

VENTAJAS

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología

del hardware sobre el que se ejecuta el sistema.

Pá gina 97
 ANALISIS Y DISEÑ O DE SISTEMAS

DESVENTAJAS

Tales sistemas contienen a menudo varias versiones de componentes software, alguno de

los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere
tomar decisiones que permitan un cambio continuo de la topología del sistema.

EJEMPLO1

Una tienda de desea implementar un sistemas, para eso necesita un computador

conectado a una impresora, además tiene acceso a Internet.

192.168.1.21

computadora CORE I7 IMPRESORA HP 2600

ROUTER 4 PUERTOS 192.168.1.1

EJEMPLO2:

Realizar un diagrama de despliegue en donde existen 3 Switch cada uno con un

servidor y 2 clientes. El primer Switch está conectado a un Router.
Los Switch están en topología lineal y los clientes en topología estrella.

Pá gina 98
 ANALISIS Y DISEÑ O DE SISTEMAS

pc6

switch3 servidor3

pc5

pc4

switch2
servidor2

pc3

pc2

switch1 servidor1

pc1

router

Caso1:
Implementa un centro de cómputo con 5 PC clientes y un servidor conectado a internet
(Router).
La interconexión es mediante un Switch de 8 puertos.
El servidor tiene impresora, scanner y parlantes.

Caso2:
Un edificio de 3 pisos, cada piso cuenta con 3 máquinas y un servidor, cada piso tiene un
Switch, los Switch están conectadas en topología bus.
Las máquinas están conectadas topologías estrella.

CASO3:
Representa mediante un diagrama de despliegue tu centro de cómputo.

Pá gina 99
ANALISIS Y DISEÑ O DE SISTEMAS
ACTIVIDAD Nº11

DISEÑOS DE
FORMULARIOS

Pá gina 100
 ANALISIS Y DISEÑ O DE SISTEMAS
DISEÑO DE FORMULARIOS
Clase abonado

ABONADO
+coda_abo
+apel_abo
+nom_abo
+dni_abo
+fecha
+lugar_abo
+dir_abo
+tel_abo
+insertar()
+guardar()
+buscar()
+modificar()

Tabla abonado

Formulario Abonado

Pá gina 101
 ANALISIS Y DISEÑ O DE SISTEMAS
Clases relacionados del sistema

ABONADO
boleta
+coda_abo
+apel_abo +numbol
+nom_abo +cod_abo
+dni_abo +total
+fecha +fecemi
+lugar_abo +estado
1 *
+dir_abo
+tel_abo +insertar()
+guardar()
+insertar() +imprimir()
+guardar()
+buscar()
+modificar() 1

*
concepto
detalle
+codcon
+numbol +descrip
+codcon 1 +monto
*
+mespago
+insertar()
+montocon
+guardar()
+agregar() +buscar()
+borrar() +modificar()

Tablas relacionadas del sistema

Formulario Boleta

Pá gina 102
ANALISIS Y DISEÑ O DE SISTEMAS

ANEXOS

Pá gina 103
 ANALISIS Y DISEÑ O DE SISTEMAS
CASOS DE USO
Ejemplos:
01. En una bodega un cliente pregunta si venden leche; el vendedor le responde que si
vende, entonces el cliente realiza la compra de 2 litros de leche, luego el cliente
cánsela, y el vendedor le entrega los 2 litros de leche.
 Identificando actores:
1. Cliente.
2. Vendedor.

 Identificando casos de uso(proceso):

1. Realizar consulta.
2. Realizar compra.
3. Cancelar compra.
4. Entregar producto.

REALIZAR CONSULTA

REALIZAR COMPRA

VENDEDOR
CLIENTE CANCELAR COMPRA

ENTREGAR PRODUCTO

Pá gina 104
 ANALISIS Y DISEÑ O DE SISTEMAS
02. La secretaria de un instituto realiza el registro de las fichas de matricula de los
alumnos. Además, tiene que solicitar el horario de los profesores, para luego
elaborar el cuadro de horarios del IST.

 Identificando actores:
1. Secretaria.
2. alumnos.
3. Profesores.
4. Dirección.

 Identificando casos de uso(proceso):

1. Registrar ficha de matricula.
2. Elaborar cuadro de horas.
3. Entregar informe.
4. Elaborar cuadro de aulas disponibles.

REGISTRAR FICHA MATRICULAS

SECRETARIA

ELABORAR CUADRO HORAS

PROFESORES
ALUMNO
ELEBORAR INFORME

DIRECCIÒN
ELEBORAR CUADRO AULAS

Pá gina 105
 ANALISIS Y DISEÑ O DE SISTEMAS

03. Desarrolle un DCU para cancelar el recibo de luz en una oficina. De cancelación de
recibos de luz.
 Identificando actores:
1. Usuario.
2. Empleado.
3. Sistema.

 Identificando los casos de uso(proceso):

1. Realizar consulta.
2. Entregar recibo.
3. Ingresar código.
4. Cancelar monto de recibo.
5. Solicitar recibo sellado.

REALIZAR CONSULTA

EMPLEADO
ENTREGAR RECIBO

INGRESAR CODIGO

USUARIO

CANCELAR MONTO RECIBIDO

SISTEMA

SOLICITAR RECIBO SELLADO

Pá gina 106
 ANALISIS Y DISEÑ O DE SISTEMAS
04. Desarrolle un DCU para retirar dinero de un cajero automático.
 Identificando actores:
1. Usuario.
2. Cajero.
 Identificando los casos de uso(proceso):
1. Ingresar tarjeta de crédito.
2. Ingresar clave.
3. Verificar usuario.
4. Seleccionar transacción.
-Retirar dinero.
5. Ingresar monto.
6. Confirmar monto.
7. Retirar dinero.
8. Imprimir Boucher.
9. Confirmar otra transacción.

INGRESAR TARJETA CREDITO

INGRESAR CLAVE

VERIFICAR USUARIO

SELECCIONAR TRANSACCIÒN RETIRAR DINERO

CAJERO
USUARIO
INGRESAR MONTO A SACAR

CONFIRMAR MONTO

RETIRAR DINERO

IMPRIMIR BOUCHER

CONFIRMAR OTRA TRANSACCIÒN

Pá gina 107
 ANALISIS Y DISEÑ O DE SISTEMAS
05. En el restaurante “LA OLLA GORDA” se realizan los siguientes procesos para
atender a los diferentes clientes cuando el cliente ingresa la anfitriona les da la
bienvenida y recibe las prendas y los objetos de los clientes.
Los clientes son atendidos por los meseros los cuales le van a indicar una mesa
disponible. El mesero entrega a los clientes la carta con el menú del día.
Los clientes deben seleccionar el menú a degustar. El mesero recoge la carta con
el menú seleccionado y se dirige hacia la cocina, en donde entregara la lista con el
menú seleccionado. Cocina servirá los menús seleccionados el cual el mesero le
hará llegar a los clientes que le solicitaron.
Los clientes después de disfrutar la comida llamaron al mesero para solicitarle la
cuenta.
Finalmente los clientes se retiran del restaurante “LA OLLA GORDA” recogiendo
sus prendas y objetos que serán entregados por la anfitriona.

 Identificando actores:
1. Cliente.
2. Anfitriona.
3. Mesero.
4. Cocina.

 Identificando los casos de uso(proceso):

1. Realizar consulta.
2. Entregar carta.
3. Seleccionar pedido.
4. Preparar pedido.
5. Consumir pedido.
6. Elaborar comprobante de pago.

06. Una persona desea realizar los trámites para actualizar los datos de su DNI en la
oficina de la RENIEC, esta persona debe realizar los siguientes pasos.
El agente de seguridad entrega un ticket de turno a la persona.
Luego la persona de acuerdo a su turno ingresa a la oficina, el sistema de
administración solicita los documentos para verificarlos si están correctamente.
Luego la persona se acerca al administrador, el administrador solicita los
documentos verificados, luego el administrador ingresa el número de DNI al
sistema de la RENIEC el sistema de la RENIEC verifica los datos de la persona.
Luego el administrador solicita los datos de la persona para actualizarlos.

Pá gina 108
 ANALISIS Y DISEÑ O DE SISTEMAS
Luego el administrador con la conformidad de la persona, guarda los datos,
finalmente la persona firma y sella el padrón de la actualización de los datos de la
persona.

 Identificando actores:
1. Persona.
2. Banco.
3. Agente de seguridad.
4. Asistente.
5. Sistema.

 Identificando los casos de uso(proceso):

1. Realizar consulta.
2. Cancelar derecho de actualización.
3. Solicitar ticket de turno.
4. Verificar documento.
5. Ingresar número de DNI.
6. Actualizar datos.
7. Solicitar ticket de reclamo.

REALIZAR CONSULTA
BANCO

CANCELAR DERECHO ACTUALIZACIÒN

AJENTE DE SEGURIDAD
SOLICITAR TICKET DE TURNO

PERSONA VERIFICAR DOCUMENTO

ASISTENTE

INGRESAR DNI

ACTUALIZAR DATOS

SISTEMA
SOLICITAR TICKET RECLAMO

Pá gina 109
 ANALISIS Y DISEÑ O DE SISTEMAS
07. Un técnico de sistemas esta operando un sistema de administración de películas
el cual tiene que tener en cuenta registrar a los actores de la película, registrar el
genero, registrar la película y además registrar la programación de las películas.
Identificar los actores y casos de uso.

 Identificando actores:
1. Técnico de sistemas.
2. Sistemas.

 Identificando casos de uso(proceso):

1. Registrar los actores.
2. Registrar genero
3. Registrar pelicula.
4. Registrar la programación.

REGISTRAR ACTORES

REGISTRAR GENERO

TECNICO SISTEMA ADMINISTRACIÒN

REGISTRAR LA PELICULA

REGISTRAR LA PROGRAMACIÒN

Pá gina 110
 ANALISIS Y DISEÑ O DE SISTEMAS

08. Una persona ingresa a una oficina de transporte terrestre, se acerca a la

recepcionista y realiza consultas.
Una vez informado, decide viajar. La recepcionista le solicita su DNI, la
recepcionista ingresa el DNI al sistema, el sistema proporciona los datos de la
persona.
La recepcionista le solicita número de asiento y finalmente imprime el boleto de
viaje. Identificar los actores y casos de uso.

 Identificando actores:
1. Pasajero.
2. Recepcionista.
3. Sistema.

 Identificando casos de uso(proceso):

1. Realizar consulta.
2. Registrar pasajero.
3. Registrar boleto.
4. Cancelar boleto

REALIZAR CONSULTA

REGISTRAR PASAJERO RECEPCIONISTA

PASAJERO

REGISTRAR BOLETO

SISTEMA

CANCELAR BOLETO

Pá gina 111
 ANALISIS Y DISEÑ O DE SISTEMAS
09. Una persona ingresa a una farmacia. Se acerca al vendedor y realiza unas
consultas. El vendedor ingresa los datos del medicamento al sistema, el sistema
proporciona la información del medicamento.
La persona decide comprar, entonces el vendedor registra en un ticket los datos de
la compra. Luego la persona se acerca a caja para canjear el ticket por un
comprobante de pago, cancela el monto y recibe el comprobante.
Luego se acerca a despacho, entrega el comprobante de pago y recibe el
medicamento.

 Identificando actores:
1. Cliente.
2. Empleado.
3. Caja.
4. Despacho.
5. Sistema.

 Identificando casos de uso(proceso):

1. Realiza consulta.
2. Ingresar medicamento.
3. Registrar ticket.
4. Canjear comprobante.
5. Cancelar monto.
6. Entregar medicamento.

RALIZAR CONSULTA

EMPLEADO
INGRESAR MEDICAMENTO

REGISTRAR TICKET
SISTEMA

CLIENTE CANJEAR COMPROBANTE

CAJERO
CANCELAR MONTO

ENTREGAR MEDICAMENTO
DESPACHO

Pá gina 112
 ANALISIS Y DISEÑ O DE SISTEMAS
10. Un cliente ingresa a una farmacia se acerca a una vendedora para comprar un
determinado medicamento la vendedora realiza la consulta en el sistema sobre el
medicamento si está disponible.
Luego la vendedora le elabora un ticket, además le pregunta al cliente si desea
acumular putos bonos.
El cliente se acerca a caja para cancelar sobre el medicamento, la caja le solicita el
ticket para canjearlo por un comprobante.
El comprobante se debe registrar los datos del cliente los datos del medicamento
los datos del vendedor.
Al momento la cajera le solicita al cliente si desea aportar una donación con fines
benéficos.
El cliente cancela el monto a pagar y se acerca a la ventanilla de despacho.
En despacho para que le entreguen el medicamento debe entregar el
comprobante.
El cliente entrega el comprobante recibe el medicamento recibe su medicamento y
se retira.

 Identificando actores:
1. Cliente.
2. Vendedor.
3. Sistema.
4. Cajero.
5. Despacho.

 Identificando los casos de uso(proceso):

1. Realizar consulta.
2. Elaborar ticket.
3. Registrar comprobante.
4. Entregar medicamento.

Pá gina 113
 ANALISIS Y DISEÑ O DE SISTEMAS

REALIZAR CONSULTA

VENDEDOR
aumentar puntos

<<extend>>

elaborar ticket
CLIENTE SISTEMA

EMPLEADO
REGISTRAR medicamento

REGISTRAR CLIENTE <<include>>

<<include>>
CAJERO
REGISTRAR COMPROBANTE

<<include>> <<include>> <<include>>

cancelar comprobante
DONAR VUELTO
REGISTRAR CAJERA

ENTREGAR MEDICAMENTO
DESPACHO

Pá gina 114
 ANALISIS Y DISEÑ O DE SISTEMAS
11. El jefe de personal de una oficina de una empresa, cada fin de mes debe realizar el
respectivo pago a los trabajadores que elaboran en dicha empresa.
En primer lugar, para efectuar el sueldo neto del trabajador, debe calcular el
sueldo bruto, los aportes y descuentos de ley.
Teniendoen cuenta que para calcular el sueldo bruto debe verificar el control de
días elaborados de cada trabajador.
Todos los datos son ingresados al sistema de control de pagos. Dependiendo del
mes el jefe del personal decide calcular o no para los trabajadores un aporte extra.
Por otro lado para cancelar los pagos a los trabajadores de puede realizar
mediante cheque, deposito o en efectivo.

 Identificando actores:
1. Sistema.
2. Trabajador.
3. Jefe.

 Identificando los casos de uso(proceso):

1. Calcular sueldo neto.
2. Cancelar pago.

VERIFICAR CONTROL DIAS TRABAJADORES

<<include>> ASIGNAR DESCUENTO DE LEY

OBTENER APORTES
CALCULAR SUELDO
<<include>> <<include>>
<<include>>

CALCULAR SUELDO NETO SISTEMA

<<include>>
TRABAJADOR <<include>>

<<include>>

REGISTRAR TRABAJADOR CANCELAR PAGO JEFE

<<extend>>
<<extend>>
<<extend>> PAGAR CON TARGETA
CALCULAR APORTE EXTRA

PAGAR EN EFECTIVO

PAGAR POR DEPOSITO

PAGO

Pá gina 115
 ANALISIS Y DISEÑ O DE SISTEMAS
12. Una empresa de combustibles, desea administrar adecuadamente el servicio que
brinda a todos sus clientes para esto describe los procesos que se realizan para la
atención de los clientes.
En primer lugar cuando se acerca un cliente con su vehículo el empleado solicita el
valor, valor que se ingresara al surtidor. Este valor puede ser monetario o cantidad
de galones.
En segundo lugar al momento de cancelar el servicio el empleado registra la
cancelación considerando los datos del cliente y el servicio y por ultimo el
empleado ofrece al cliente acumular puntos o registrarle un comprobante de
pago.
Si el cliente esta registro y acumula puntos le regala puntos. Además los pagos se
pueden hacer en efectivo o con tarjeta.

 Identificando actores:
1. Cliente.
2. Empleado.
3. Surtidor.
 Identificando los casos de uso(proceso):
1. Vender combustible.

VENDER POR GALONES VENDER POR VALOR MONETARIO

VENDER COMBUSTIBLE
EMPLEADO

<<include>>

CLIENTE
REGISTRAR COMPROBANTE DE PAGO

<<include>> SURTIDOR

<<include>>

<<include>>
CANCELAR SERVICIO
REGISTRAR CLIENTE
ACUMULAR PUNTOS

PAGAR EN EFECTIVO
PAGAR CON TARJETA

Pá gina 116
 ANALISIS Y DISEÑ O DE SISTEMAS
13. Una encuestadora del gobierno desea conocer la información familiar de vivienda
y laboral de cada familia de un determinado lugar.
En primer lugar para recopilar la información familiar se considera registrar los
datos del padre, de la madre y de los hijos y además de cada uno se debe el lugar y
fecha de nacimiento, registrar grado académico.
En segundo lugar para recopilar la información de la vivienda se considera registrar
el estado de la vivienda la condición de la vivienda y el número de habitantes.
En tercer lugar para recopilar la información económica se considera registrar los
datos del padre y de la madre y además de cada uno se debe registrar el centro de
trabajo, año de servicio y condición laboral.
 Identificando actores:
1. Encuestadora.
2. Padre.
3. Madre.
4. Hijo.
 Identificando los casos de uso(proceso):
1. Recopilar información familiar.
2. Recopilar información de vivienda.
3. Recopilar información económica.

REGISTRAR LUGAR Y FECHA NACIMIENTO REGISTRAR GRADO ACADEMICO

<<include>>

PADRE

<<include>>
RECOPILAR INFORMACION FAMILIAR

REGISTRAR NUMERO HABITANTES

<<include>> MADRE MIEMBROS DE FAMILIA

ENCUESTADORA

RECOPILAR INFORMACION DE VIVIENDA

<<include>>

REGISTRAR ESTADO CONDICION VIVIENDA

HIJOS

RECOPILAR INFORMACION ECONOMICA

<<include>>

<<include>>
<<include>>
REGISTRAR AÑO DE SERVICIO REGISTRAR CONDICION LABORAL
REGISTRAR CENTRO DE TRABAJO

Pá gina 117
 ANALISIS Y DISEÑ O DE SISTEMAS

DIAGRAMAS DE SECUENCIAS
CASO1
ATENCION EN RESTAURANTE

Un restaurante desea implementa un S.I para esto identifica los siguientes procesos:
1. Recepcionar cliente
El mozo se acerca, le da la bienvenida y ofrece los dos tipos de mesa: mesa ejecutiva, mesa
común. El cliente comunica sobre que mesa ubicarse.
2. Tomar pedido.
El mozo solicita al cliente lo que desea servirse.
El cliente informa lo que va a servirse.
Todos los datos son registrados en nota pedido los cuales numero mesa, platos, precio de
plato, bebida, precio bebida, cantidad y por último los datos del cliente: nombres, apellidos
y DNI.
3. Registrar pedido.
Luego el mozo se acerca al asistente de cocina y le entrega la nota pedido, registra todos los
datos al sistema y luego la nota de pedido es alcanzarlo al cocinero. Para que este sirva el
plato y bebidas. Luego el mozo atiende la mesa.
4. Cancelar servicios.
Finalmente el mozo se acerca a la mesa a realizar las respectivas cobranzas, el mozo
entrega el total a pagar, el cliente cancela con efectivo o tarjeta, los datos del cliente son
ingresados al sistema, con la fecha, total y el servicio luego el sistema imprime el
comprobante de pago.
El mozo entrega el comprobante y el cliente se retira.
Desarrolle:
1 Realice diagrama de casos de usos.
2 Realice diagrama de secuencia de cada caso de uso

Pá gina 118
 ANALISIS Y DISEÑ O DE SISTEMAS

Diagrama de casos de usos.

RECEPCIONAR CLIENTE

MOSO

TOMAR PEDIDO CLIENTE

<<include>>

<<include>>

<<include>> PRECIO PLATO

<<include>>
NUMERO DE MESA <<include>>
<<include>>

ASISTENTE EMPLEADO <<include>> DATOS DE CLIENTE

PLATOS
CANTIDAD
BEBIDA

SISTEMA
REGISTRAR PEDIDO

COCINERO
GENERAR COMPROVANTE

CANCELAR SERVICIOS

<<extend>>

<<extend>>

EN EFECTIVO CON TARJETA

Pá gina 119
 ANALISIS Y DISEÑ O DE SISTEMAS

Diagrama de secuencia de cada caso de uso

: CLIENTE : MOSO : SISTEMA

1 : solicita nombre()

2 : dicta nombre()
3 : ingresa nombre()
4 : solicita apellidos()

5 : dicta apellidos()
6 : ingresa apellidos()
7 : solicita DNI()

8 : dicta DNI()
9 : ingresa DNI()
10 : ofrece tipo mesa()

11 : elige mesa()
12 : ingresa tipo mesa()
13 : solicita pedido()

14 : confirma pedido()
15 : ingresa pedido()
16 : solicita cantidad pedido()

17 : confirma cantidad pedido()

18 : ingresa cantidad pedido()
19 : solicita monto a pagar()

20 : informa monto a pagar() 21 : ingresa monto()

22 : cancela cuenta()

23 : ingresa monto cancelado()

24 : solicita nombre de emplado()

25 : ingresa nombre()

26 : solicita apellidos de empleado()

27 : ingresa apellidos()

28 : ingresa fecha()

29 : ordena guardar()

30 : guarda registro()

31 : ordena imprimir()

32 : imprime comprobante()

Pá gina 120
33 : entrega comprobante de pago()
 ANALISIS Y DISEÑ O DE SISTEMAS
CASO2
PRODUCCIÓN AUDIOVISUAL

La Producción “ROLANDOSTUDIOS”,
desea realizar un cortometraje, para esto deben realizarse las siguientes
actividades.

7. Elaborar el guión, Responsable el Guionista.

8. Realizar casting, Responsable de Casting y Actores.
9. Buscar locación, Responsable Director de Fotografía.
10. Realizar la filmación, Responsable Producción.
11. Realizar posproducción, Responsable Jefe de Postproducción.
12. Realizar estreno, Responsable .Productor Ejecutivo.

7. Elaborar el guión:
El guionista escribe la historia en el guión luego el guión es entregado a la
Producción, producción verifica, el cual puede ser aceptado ó rechazado.
8. Realizar casting:
Aquí el responsable de casting, publica un programa de casting, en donde los
actores se registran para ser evaluados, después de la evaluación pueden ser
aprobados o desaprobados.

9. Buscar locación:
El director de fotografía busca y registra todos los escenarios de la filmación, los
cuales son entregados a la producción, y estos pueden ser aceptados o rechazados.
10. Realizar filmación:

Pá gina 121
 ANALISIS Y DISEÑ O DE SISTEMAS
El responsable es la producción, junto a un equipo técnico y actores. Donde la
producción ordena al equipo técnico y actores cumplir sus funciones, luego
producción guardara los archivos.

11. Realizar Postproducción

El responsable es el jefe de producción junto a un equipo técnico y el material.
El jefe producción ordena la edición y el acabado final del material.

12. Realizar estreno:

El productor ejecutivo se encargara de realizar contratos con los responsables de
las grandes salas de cine.

Se pide

Pá gina 122
 ANALISIS Y DISEÑ O DE SISTEMAS
 Diagrama casos de usos

rechasar guión aceptar guión

<<extend>>

<<extend>>
producción
entregar guión

guionista <<include>>

elaborar guión
respon de casing

actores realizar casting

desaprobados <<extend>> <<include>> aprobados

registrar actores <<extend>>

director de fotografia buscar locación rechasar locación

<<include>>
<<extend>> <<extend>>
aceptar locación
entregar locación

realizar filmación guardar archivos

<<include>>
<<include>>
otorgar función a actores

realizar postproducción
jefe de postproducción
<<include>>

editar y finalizar el cortometraje

prodc ejecutivo
responsable de cine
realizar estreno

<<include>>

realizar contrato

 Diagrama secuencia de cada caso de uso

Pá gina 123
 ANALISIS Y DISEÑ O DE SISTEMAS

: Guionista : producción : respon de casing : actores : director de fotografia : jefe de postproducción : prodc ejecutivo : responsable de cine

1 : escribe guión()
2 : entrega el guión()

3 : aprueba o rechase guión()

4 : publica casting()
5 : solicita nombres()
6 : dicta nombres()
7 : solicita apellidos()
8 : dicta apellidos()

9 : emite codigo()

10 : aprueba o rechasa actor()

11 : busca locación()

12 : registra locación()
13 : entrega locación()

14 : acepta o rechasa locación()

15 : otorga funciones()
17 : edita cortometraje()
16 : guarda archivos()

18 : realiza contrato()

CASO PRÁCTICO

Un usuario desea crear cuentas de correo internet, para esto realiza varios
procesos.

1 Verificar disponibilidad de cuenta:

El usuario ingresa, el nombre de la posible cuenta al servidor de correos, el
servidor de correos verifica si existe; luego informa disponible o no.

2 Registrar cuenta de correo:

El usuario ingresa su nombre de su cuenta, y la clave. Luego ingresa
nombres, apellidos, país y ciudad del usuario. Luego el usuario acepta los
términos del servidor de correos, finalmente guarda los cambios.

Pá gina 124
 ANALISIS Y DISEÑ O DE SISTEMAS

3 Redactar mensaje:
El usuario ingresa al servidor de correos, ingresa nombres de la cuenta y la
clave; el servidor de correos verifica, si es correcto el servidor de correos
muestra bandeja de entada y el usuario ordena redactar mensaje nuevo, si
no; el servidor de correos informa ingresar usuario nuevamente.

Casos de uso

verificar disponibilidad de cuenta

registrar la cuenta servidor correo

usuario

redactar mensaje

Diagramas de secuencia

: usuario : servidor correo

1 : olicitar numero de cuenta()

2 : ingresa nombre de la cuenta()

3 : verifica nombre de la cuenta()

4 : informa disponibilidad de la cuenta()

Pá gina 125
ANALISIS Y DISEÑ O DE SISTEMAS

: usuario : servidor correo

1 : solicitar nombre de la cuenta()
2 : ingresar nombre de la cuenta()
3 : solicita contraseña()
4 : ingresar contraswña()
5 : solicita nombre de usuario()
6 : ingresa nombre de usuario()
7 : solicita apellido de cliente()
8 : ingresa apellido de cliente()
9 : solicita pais()
10 : selecciona pais()
11 : solicita ciudad()

12 : selecciona ciudad()
13 : solicita acptar los terminos()
14 : selecciona aceptar losterminos()

: USUARIO : SERVIDOR DE CORREO

1 : solicitanombre de cuenta()

2 : ingresa nombre de cuenta()

3 : solicita clave()

4 : ingresa clave()
5 : ordena iniciar seción()

6 : verifica cuenta()
7 : muestra bandeja de entrada()

8 : ordena redacte nuevo mensaje()

9 : ordena enviar mensaje()

10 : enviar mensaje()

11 : informa el mensaje enviado()

Pá gina 126
 ANALISIS Y DISEÑ O DE SISTEMAS
DIAGRAMAS DE CLASES
CASO PRÁCTICO 01
Desarrollar el diagrama de clases de organización de libros de una biblioteca

AUTOR GENERO
#codautor #codgenero
+nomautor +descgenero
1
+escribir()
1
*
LIBRO

#codlibro
*
+titulo
+numpag
+codautor
+codgenero

CASO PRÁCTICO 02
Desarrollar el diagrama de clases de compras de productos de una tienda

PROVEEDOR
CATEGORIA
#cod proveedor
+nomcia #codcat
+direcia +descripccion
+telcia
+webcia
1
1
PRODUCTOS

* +cod prod
*
+nomprod
+punitario
+smax
+smin
+codproveedor
+cod categoria

Pá gina 127
 ANALISIS Y DISEÑ O DE SISTEMAS

CASO1
VENTA EN RESTAURANTE

Un restaurante desea implementa un S.I para esto identifica los siguientes procesos:

1. Recepcionar cliente

El mozo se acerca, le da la bienvenida ofrece los dos tipos de mesa: mesa ejecutiva, mesa
común.
El cliente comunica sobre que mesa ubicarse.

2. Tomar pedido.

El mozo solicita al cliente lo que van servirse.

El cliente informa lo que va a servirse.
Todos los datos son registrados en nota pedido los cuales numero mesa, platos, precio de
plato, bebida, precio bebida, cantidad y por último los datos del cliente: nombres, apellidos
y DNI.

Pá gina 128
 ANALISIS Y DISEÑ O DE SISTEMAS

3. Registrar pedido.

Luego el mozo se acerca al asistente de cocina y le entrega la nota pedido, registra todos los
datos al sistema y luego la nota de pedido es alcanzarlo al cocinero. Para que este sirva el
plato y bebidas.
Luego el mozo atiende la mesa.

4. Cancelar servicios.

Finalmente el mozo se acerca a la mesa a realizar las respectivas cobranzas, el mozo

entrega el total a pagar, el cliente cancela con efectivo o tarjeta, los datos del cliente son
ingresados al sistema, con la fecha, total y el servicio luego el sistema imprime el
comprobante de pago.
El mozo entrega el comprobante y el cliente se retira.
Por otro lado el restaurante cuenta con tres pc cada una con impresora.

Desarrolle un diagrama de clases

CLIENTE
SISTEMA
#codcliente
+nomcliente +numcomprobante
+apellcliente +registra()
+DNI cliente +guardar()
MOSO
+consumir() +editar()
1 +buscar()
1 #codempleado
COMPROBANTE * +nomempleado
+apellempleado
* #numcomprobante
* +codcliente +atender()
+codempleado 1
+fecha
+total *
1
+servicio
*
+guardar() MESA
+imprimir() 1 #nummesa
1 +catmesa

BEBIDA
* 1
+cantbebidas *
+nombebida *
+precbebida PLATO
NOTA 1
* +nomplato
#numnota +cantplatos
+nummesa +preciplato
*
+platos
1 +precplato
1
+bebida
+precibebida
+cantidad
+datcliente
+guardar()

CASO2

Pá gina 129
 ANALISIS Y DISEÑ O DE SISTEMAS
PARTIDO POLITICO

Un partido político independiente encarga la responsabilidad al personero técnico registrar

a los adherentes, para los cuales se toman los siguientes datos:
DNI, nombres, apellido paterno, apellido materno.
Luego los datos son ingresados al sistema.
Luego el personero técnico valida los datos del sistema con RENIEC, para verificar si son
correctos, si son correctos se guardan en el sistema, sino serán rechazados.
Finalmente el personero realizara una impresión con el Padrón de adherentes, el cual
entrega al jurado nacional de elecciones (JNE).
Desarrolle un diagrama de clases

Pá gina 130
 ANALISIS Y DISEÑ O DE SISTEMAS

PERSONERO ADHERENTE SISTEMA

#codpersonero #DNI #codadherente
+nompersonero +nomadherente +nomadherente
+apellpersonero +apelladherente +apelladherente
+registrar() 1 * +ingresar() * 1 +ingresar()
+guardar() +guardar() +guardar()
+editar() +editar() +editar()
+buscar() +buscar() +buscar()

1 *

*
1
PADRON
#codpadron RENIEC
+DNIadherente JNE
#codpersonero
+nomadherente
+padron +DNIadherente
+apelladherente
* 1 +verificar datos()
+ingresar() +guardar()
+guardar()
+editar()
+buscar()

CASO3
LIBRERÍA

El propietario de una librería desea implementar un sistema informático para registrar los
libros de acuerdo al autor y al género.
Considerando las siguientes características de acuerdo al objeto definido; para libro se debe
considerar código de libro, titulo, fecha de publicación, numero de página.
Para el autor se consideran los siguientes datos:
 Código del autor
 Nombre del autor
 Apellido del autor
Para género se considera los siguientes datos:
 Código de genero
 Nombre de genero
Las actividades que realizan son las siguientes:
El objeto autor permitirá:
 inserta,

Pá gina 131
 ANALISIS Y DISEÑ O DE SISTEMAS
 guardar,
 editar
 buscar
De la misma manera ocurre para género y libro.
Interpretación 1.
 Un autor puede hacer uno a muchos libros
 Uno a muchos libros pertenecen a un autor.
Interpretación 2.
 Un género puede tener uno a muchos libros
 Uno a muchos libros pertenecen a un género.

Desarrolle un diagrama de clases

AUTOR GENERO
#codautor #codgenero
+nomautor +nomgenero
+apellautor
+ingresar()
+ingresar() +guardar()
1 LIBRO
+guardar() +editar()
+editar() 1 +buscar()
* #codlibro
+buscar()
+titulo
*
+fechapublic
+numpag

+ingresar()
+guardar()
+editar()
+buscar()

CASO4
APERTURA DE MODULOS

La especialidad de computación informática desea apertura un módulo de los muchos que

ofrece la carrera para esto la carrera de computación e informática desea implementar un
sistema informático que permita organizar dichos módulos.
Teniendo en cuenta que un módulo puede tener uno o muchos temas y por lo consiguiente
uno o muchos temas pertenecen a un módulo.
Por otro lado un módulo puede tener muchos materiales o no puede tener materiales por lo
consiguiente muchos materiales pertenecen a un módulo.

Un módulo se caracteriza por los siguientes datos:

 Código del modulo
 Titulo
 fecha de inicio
 Fecha final.
Las características del tema son los siguientes:
 Código de tema
 Título de tema

Pá gina 132
 ANALISIS Y DISEÑ O DE SISTEMAS
 Número de horas.
Las características de los materiales son los siguientes:
 Código de material
 Título.
Las actividades que realiza cada objeto son:
 Insertar
 Guardar
 Actualizar
 Buscar.
El modulo debe completar un total de horas para que culmine.
Interpretación 1.
 Uno a muchos temas pertenecen a un módulo.
 Un módulo pueden tener uno a muchos temas.
Interpretación 2.
 Un módulo puede tener mucho o no puede tener material.
 Muchos materiales pertenecen a un módulo.

Desarrolle un diagrama de clases

TEMA
#codtema
+titulotema
+numhoras
+insertar()
+guardar()
+actualizar()
+buscar() * MODULO
MATERIALES
#codmodulo
1 +titulo #codmaterial
+fechainicio +titulo
+fechafinal
* +insertar()
1
+insertar() +guardar()
+guardar() +actualizar()
+actualizar() +buscar()
+buscar()

CASO 5
ORGANIZAR PROVEEDOR

El propietario de una bodega desea implementar un sistema de registro de productos.

Para esto considera al proveedor con las siguientes características
 código de proveedor
 razón social
 dirección
 teléfono
 email

Pá gina 133
 ANALISIS Y DISEÑ O DE SISTEMAS

También considera la característica de categoría

 Código de la categoría
 Nombre de la categoría.

Las características del producto son:

 Código del producto
 Nombre del producto
 Precio unitario
 Stock máximo
 Stock mínimo

Las actividades son

 Insertar
 Guardar
 Editar
 buscar
Desarrolle un diagrama de clases

PROVEEDOR PRODUCTO CATEGORIA

+codproveedor +codproducto +codcategoria
+razonsocial +nomproducto +nomcategoria
+dirección +preciounitario
+telefono +stockminimo +incentar()
+stockmaximo 1 +guardar()
+email * *
1 +editar()
+insertar() +insertar() +buscar()
+guardar() +guardar()
+editar() +editar()
+buscar() +buscar()

CASO 6
AGENCIA DE TRANSPORTE

Una agencia de transporte desea implementar un sistema informático para los cuales se
considera lo siguiente. El pasajero el cual tiene las siguientes características:
 DNI
 Nombres
 Apellidos

Pá gina 134
 ANALISIS Y DISEÑ O DE SISTEMAS
 Dirección
 Razón social y
 RUC
Además considerar al empleado, el cual tiene las siguientes características
 DNI
 Nombres y
 Apellidos
Loa datos del boleto del viaje son lo siguiente:
 Número del boleto
 Fecha de emisión
 Fecha de viaje
 Hora de viaje
 Numero de asiento
 Origen
 Destino
 Valor
Como dato de boleto se registra los datos del pasajero y los datos del empleado que los
emite.
Desarrolle un diagrama de clase considerando sus relaciones

EMPLEADO PASAJERO VIAJE

#DNI #DNI #numbol

+nombre +nombres +fecha emision
+apellidos +apellidos +fecha viaje
1 * +hora viaje
+direccion
+ingresar() +razonsocial +numasiento
* 1
+guardar() +RUC +origen
+editar() +destino
+busacr() +ingresar() +valor
+guardar()
+editar()
+buscar()

CASO 7
VENTA DE UTILES DE ESCRITORIO

Un propietario de una tienda de ventas de útiles de escritorio desea implementar un sistema

informático para los cuales tiene encuentra los siguientes catos:
 Código de cliente
 Nombres
 Apellido
 Dirección
 razón social

Pá gina 135
 ANALISIS Y DISEÑ O DE SISTEMAS
 Ruc
Con respecto al producto se considéralos siguientes datos
 Código del, producto
 Descripción
 Precio unitario
 Stock máximo
 stock mínimo
Teniendo en cuenta que los productos pertenecen a una categoría para lo cual se considera los
siguientes datos:
 Código de categoría
 Nombre
La tienda solo emite comprobante de pago por horas y por boletas. Para los cuales considera
los siguientes datos
 Numero de boleta
 Fecha de emisión
 Total
 código de empleado
 código del cliente
En< los detalles de las boletas se considera
 número de boleta
 código de productos
 cantidad

CLIENTE
BOLETA CATEGORIA
#codcliente
+nombres #numboleta #codcategoria
+apellido +fechadeemisión +nombre
+dirección +total +incertar()
+razonsocial +codempleado +guardar()
+RUC +codcliente +editar()
1 *
+insertar() +incertar() +buscar()
+guardar() +guardar()
+actualizar() +editar() 1
+buscar() +buscar()
+eliminar()
*
1
PRODUCTO
*
#codproducto
DETALLE +descripción
+preciounitario
#numboleta +stockminimo
+codproductos +stockmaximo
+cantidad
1 +incertar()
*
+incertar()
Pá gina 136 +guardar()
+guardar() +editar()
+editar() +buscar()
+buscar() +eliminar()
 ANALISIS Y DISEÑ O DE SISTEMAS
Desarrolle un diagrama de clase considerando sus relaciones

CASO 8
ORGANIZAR PROVEEDOR

Una empresa comercializadora de productos desea implementar un sistema informática

considera los siguientes datos: los datos del proveedor son los siguientes:
 Cód. proveedor
 Razón social
 Ruc
 Dirección

Pá gina 137
 ANALISIS Y DISEÑ O DE SISTEMAS
 Telefoneo
 Correo electrónico.

Por otro lado se considera a los productos los cuales son:

 Cód. producto
 Nombre
 Precia
 Stock mínimo
 Stock máximo
Teniendo en cuenta que pertenecen a una categoría Los cuales son:
 Código
 Descripción
También se considera a los datos del empleado los cuales son:
 Código del empleado
 Nombre
 Apellido
 Dirección
 Teléfono.
La empresa comercializadora contara con los servicios se transporte de envío para esto se
considera:
 el código de transporte de envío
 nombre de compañía
 dirección
 teléfono
Por otro lado se considera la nota de pedido de, los Cuales son los siguientes datos:
 numero de pedido
 fecha de emisión
 fecha de pedido
 fecha de entrega
 total

Teniendo en cuenta que la nota de o pedido le pertenece a un proveedor le emite un

empleado y lo transporta a una compañía de envío.

Además se considera el detalle a la nota de pedido en él se contempla:

 Numero de pedido
 Código de producto
 Cantidad de descuento

Desarrolle un diagrama de clase considerando sus relaciones

Pá gina 138
 ANALISIS Y DISEÑ O DE SISTEMAS

CATEGORIA
PROVEEDOR PRODUCTO
#codcat
#codproveedor #codproducto +descripcat
+razonsocial +nomproducto
+RUC +preciounit +ingresar()
+direccion +stockminimo 1 +guardar()
+telefono +stockmaximo * +editar()
+correlectronic 1 * +buscar()
+ingresar()
+ingresar() +guardar()
+guardar() +editar()
DETALLE
+editar() +buscar()
+buscar() +eliminar() +numpedido
+codproducto
*
+cantdescuento

*
1 1

NOTA PEDIDO
EMPLEADO
SERVICIO ENVIO #numpedido
#codempleado +fecha emision
#codtranspenvio +nomempleado +fecha pedido
+nomcompañia +apellempleado +fecha de entrega
+direccion +dereccion +total
+telefono +telefono
* 1 1 *
+ingresar()
+registrar() +ingresar() +guardar()
+guardar() +guardar() +editar()
+buscar() +editar() +buscar()
+editar() +buscar() +eliminar()

CASO 9
SISTEMA MATRICULA

La oficina del instituto desea implementar un sistema informático para los cuales desea
Con respecto al alumno
 Código alumno.
 Nombre
 Apellido
 Dirección
 Teléfono
Por otro lado los datos de la secretaria
 Código secretaria
 Nombre
 Apellido

Pá gina 139
 ANALISIS Y DISEÑ O DE SISTEMAS
 Dirección
 Teléfono
Además se considera el concepto del servicio como puede ser:
 Código concepto
 Descripción
 Monto.
Los datos se registran en una ficha de matrícula los cuales son:
 Numero
 Fecha
 Código alum
 Código secretaria
 Código carrera
Considerando los datos de la carrera
 código de la carrera
 Nombre carrera
Cada ficha de matrícula genera un recibo de pago en los cuales se considera
 Numero de recibo
 Fecha
 Total
 Código concepto

ALUMNO SECRETARIA
CONCEPTO SERVICIO
#codalumno #codsecretaria
+nombre +nombre #codconcepto
+apellido +apeellido +descripción
+dirección +dirección +monto
+telefono +telefono +incertar()
+incertar() +incertar() +editar()
+editar() +editar() +buscar()
+buscar() +buscar() +guardar()
+guardar() +guardar()
+eliminar() 1
1
*

* 1
1

RECIBO
FICHA DE MATRICULA
#numrecibo
#numero +fecha
+fecha +total
+codalumno +codconcepto
+codsecretaria
+codcarrera 1 +incertar()
1
+editar()
+incertar() * +buscar()
+editar() +guardar()
CARRERA
+buscar() 1
+guardar() #codcarrera
+nomcarrera
+incertar()
+editar()
+buscar()
+guardar()

Pá gina 140
 ANALISIS Y DISEÑ O DE SISTEMAS

CASO 10
ALQUILER DE DISFRACES

Una tienda de alquiler de disfraces desea implementar un sistema de informático para el mejor control de
alquiler.
Para esto tiene en cuenta al cliente, al cual se le considera los siguientes datos: código del cliente, DNI,
nombres, apellidos, dirección, teléfono.
Además se considera la empleada que realiza el alquiler, para ello se considera los siguientes datos, código
del empleado, nombres, apellidos, dirección, teléfono.

Pá gina 141
 ANALISIS Y DISEÑ O DE SISTEMAS
Por otro lado se considera, todo alquiler de disfraces se registra en una ficha de alquiler, en la cual se
considera número del alquiler, fecha de solicitud, fecha de salida, fecha de devolución, código del cliente,
código del empleado y el total del alquiler.
Por otro lado se considera al disfraz y se considera los siguientes datos.
Código del disfraz, nombre del disfraz, número de piezas
Además el disfraz pertenece a una categoría y tiene los siguientes datos, código de categoría, descripción.
Toda ficha de alquiler, tiene detalle en donde se considera el número del alquiler, código del disfraz y la
cantidad.

Desarrolle el diagrama de clases.

REGISTRO ALQUILER EMPLEADO

CLIENTE
#numalquiler #codempleado
#codcliente +fechasolicitud
+DNIcliente +nomempleado
+fechasalida +apelempleado
+nomcliente +fechadevolucion
+apelcliente +direccionempleado
+codcliente +telefonoempleado
+dircliente +codempleado * 1
+telcliente 1 *
+ingresar()
+registrar() +guardar()
+ingresar() +guardar()
+guardar() +editar()
+buscar() +buscar()
+editar() +editar()
+buscar()

DISFRAZ *
#coddisfraz TIPO
+nomdisfraz DETALLE
+numpiesas #codtipo
* #coddisfras +descriptipo
+precioalquiler 1
+coddisfraz
+ingresar() +cantidad +ingresar()
* 1
+guardar() +guardar()
+ingresar() +editar()
+editar()
+borrar() +buscar()
+buscar()

Pá gina 142
ANALISIS Y DISEÑ O DE SISTEMAS

Pá gina 143
 ANALISIS Y DISEÑ O DE SISTEMAS
DIAGRAMAS DE ESTADO
CASO PRÁCTICO:
AGENCIA DE TRANSPORTE

Una agencia de transporte desea implementar un sistema informático para los cuales se
considera lo siguiente. El pasajero el cual tiene las siguientes características:
 DNI
 Nombres
 Apellidos
 Dirección
 Razón social y
 RUC
Recordar que los datos del pasajero se verifican si es que ya existen.
Además considerar al empleado, el cual tiene las siguientes características
 DNI
 Nombres y
 Apellidos
Recordar que los datos del pasajero se verifican si es que ya existen.
Loa datos del boleto del viaje son lo siguiente:
 Número del boleto
 Fecha de emisión
 Fecha de viaje
 Hora de viaje
 Numero de asiento
 Origen
 Destino
 Valor
Como dato de boleto se registra los datos del pasajero y los datos del empleado que los
emite.
Desarrolle un diagrama de clases
Desarrolle el diagrama de estados de las clases identificadas.
Considerar un diagrama que contemple diagrama de estados compuestos secuenciales,
concurrentes y submaquinas de estados.

1. Desarrolle un diagrama de clases

Pá gina 144
 ANALISIS Y DISEÑ O DE SISTEMAS

VIAJE PASAJERO
EMPLEADO
+numboleta +DNI
+DNI +fechaemisión +nompasajero
+nomempleado +fechaviaje +apelpasajero
+apeempleado +horaviaje +dirección
+numasiento +razonsocial
+ingresar() 1 +origen
+buscar() * 1 +RUC
+destino *
+editar() +valor +ingresar()
+guardar() +buscar()
+ingresar() +editar()
+buscar() +guardar()
+editar()
+guardar()

2. Desarrolle el diagrama de estados de las clases identificadas.

Incertar y guardar un nuevo empleado

ingresando DNI

DNI ingresada

ingresando nomempleado

ingresando nomempleado
guardando nuevo empleado

ingresando aplempleado guardondo nuevo empleado

ingresando aplempleado

Pá gina 145
ANALISIS Y DISEÑ O DE SISTEMAS

Incertar y guardar nueva boleta

guardando nueva boleta

ingresando fechaemisión guardar nueva boleta

fechaemisión ingresada valor ingresado

ingreando fechaviaje ingresando valor

fechaviaje ingresada
destino ingresado

ingresando horaviaje
ingresando destino

horaviaje ingresanda
origen ingresado
numasiento ingresada
ingresando numasiento ingresando origen

Pá gina 146
 ANALISIS Y DISEÑ O DE SISTEMAS

Incertar y guardar pasajero

guardando nuevo pasajero

RCU ingresado
ingresando DNI ingresando RUC guardando

DNI ingredada razon social ingresado

ingresando razon social

ingresando nompasajero

dirección ingresado
nompasajero ingresada
apelpasajero ingresado
ingresando apelpasajero ingresando dirección

DIAGRAMAS DE ACTIVIDADES
Caso 09: Realizar venta farmacia (utiliza carriles)

Una persona ingresa a una farmacia. Se acerca al vendedor y realiza unas consultas. El
vendedor ingresa los datos del medicamento al sistema, el sistema proporciona la
información del medicamento.
La persona decide comprar, entonces el vendedor registra en un ticket los datos de la
compra. Luego la persona se acerca a caja para canjear el ticket por un comprobante de
pago, cancela el monto y recibe el comprobante. Luego se acerca a despacho, entrega el
comprobante de pago y recibe el medicamento.

Pá gina 147
 ANALISIS Y DISEÑ O DE SISTEMAS

cliente vendedor cajero sistema

realizar consulta y compra

entrega comprobante
ingresar datos de medicamento

proporcionar inf. medicamento

existencia de medicamento

registrar ticket

no existencia de medicamento

canjear ticket y cancela monto

entrega comprobante
recibe el medicamento

Caso 10: Actualizar DNI (utiliza carriles)

Una persona desea realizar los trámites para actualizar los datos de su DNI en la oficina
de RENIEC, esta persona debe realizar los siguientes procesos.
La persona en primer lugar debe esperar turno.
El agente de seguridad entregara un ticket de turno a la persona.
Luego la persona de acuerdo a su turno ingresara a la oficina, el asistente de
administración solicita los documentos para verificarlos si están correctamente. Luego
la persona se acerca al administrador, el administrador solicita los documentos
verificados, luego el administrador ingresa el número de DNI a sistema de La RENIEC el
sistema de la RENIEC verifica los datos de la persona.
Luego el administrador solicita los datos de la persona para actualizarlos.

Pá gina 148
 ANALISIS Y DISEÑ O DE SISTEMAS
Luego el administrador con la conformidad de la persona, guarda los datos
Finalmente la persona firma y sella el padrón de actualización de datos de la persona.

[PERSONA] [ADMINISTRADOR] [SISTEMA]

solicita actualizacion de datos atender solicitud

¿aceptada?

notifica rechazo
(no)

(si)

notificar aceptacion verificar conformidad actualizacion

firmar actualizacion ingresar fecha de actualizacion

Caso 11: Atender mesa (utiliza carriles)

En el restaurant “LA OLLA GORDA” se realizan los siguientes procesos para atender a los
diferentes clientes cuando el cliente ingresa la anfitriona les da la bienvenida y recibe las
prendas y los objetos de los clientes.
Los clientes son atendidos por meseros los cuales le van ha indicar una mesa disponible.
El mesero entregara a los clientes la carta con el menú del día.
Los clientes deben seleccionar el menú a degustar.
El mesero recoge la carta con el menú seleccionado y se dirige hacia la cocina , en
donde entregara la lista con el menú seleccionado. Cocina servirá los menús
seleccionados el cual el mesero le hará llegar a los clientes que le solicitaron.

Pá gina 149
 ANALISIS Y DISEÑ O DE SISTEMAS
Los clientes después de disfrutar la comida llamaran al mesero para solicitarle la cuenta.
Finalmente los clientes se retiran del restaurant “La Olla Gorda “recogiendo sus prendas
y objetos que serán entregados por la anfitriona.

cliente mesero cocina

solicita mesa revisa mesa

disponible

notificar mesas ocupadas

no

si

notificar mesas disponibles

realiza pedido

anota pedido prepara pedido

consume menu entrega menu sirve menu

cancela menu entrega comprobante

retirar

DIAGRAMAS DE DESPLIEGUE
CASO 01:
Implementa un centro de cómputo con 5 PC clientes y un servidor conectado a internet
(Rauter). La interconexión es mediante un switch de 8 puertos.
El servidor tiene impresora, scanner y parlantes.

Pá gina 150
 ANALISIS Y DISEÑ O DE SISTEMAS

PC CLIENTE 1
ROUTER

PARLANTES

PC CLIENTE 2

SERVIDOR SWITCH

PC CLIENTE 3
SCANNER

PC CLIENTE 4

IMPRESORA

PC CLIENTE 5

CASO 02:
Un edificio de 3 pisos, cada piso cuenta con 3 máquinas y un servidor, cada piso tiene un
switch, los switch están conectados en topología bus.
La máquinas están conectadas en topología estrella.

Pá gina 151
 ANALISIS Y DISEÑ O DE SISTEMAS

PC 1

SWITCH 1 SERVIDOR 1

PC 2

PC 3

PC 4

SWITCH 2
SERVIDOR 2

PC 5

PC 6

PC 7
SWITCH 3

SERVIDOR 3

PC 8

PC 9

CASO 03:

Representa mediante un diagrama de despliegue tu centro de cómputo.

Pá gina 152
 ANALISIS Y DISEÑ O DE SISTEMAS

PC PRINCIPAL

PC 19 PC 13 PC 7 PC 1

PC 20 PC 14 PC 2
PC 8

PC 9 PC 3
PC 21 PC 15

SWITCH

PC 16 PC 10 PC 4
PC 22

PC 11 PC 5
PC 23 PC 17

PC 18 PC 12 PC 6
PC 24

Pá gina 153