Instituto de Educación Superior Tecnológico Público

“República Federal de Alemania”

Módulo Profesional : Desarrollo de software y Gestión de

base de datos.
Unidad didáctica : Análisis y Diseño de Sistemas.

Sesión 3 : Análisis y diseño de sistemas de

información. Mg. Danny M. Chuquizuta Herrera.
Análisis y diseño de
sistemas orientado a objetos.
Comprensión y modelado de
los sistema organizacionales.
Descripción gráfica de los
sistemas.

Mg. Danny M. Chuquizuta Herrera

Análisis y diseño de sistemas orientado a objetos
Es una metodología diseñada para facilitar el desarrollo de sistemas que
deben cambiar con rapidez en respuesta a los entornos empresariales
dinámicos.
Se cree que las técnicas orientadas a objetos funcionan bien en situaciones
en las que los sistemas de información complejos pasan a través de un
continuo proceso de mantenimiento, adaptación y rediseño . Las
metodologías orientadas a objetos utilizan el estándar de la industria para
modelar sistemas orientados a objetos, conocido como lenguaje de
modelado unificado (UML), para descomponer un sistema en un modelo de
caso de uso.
La programación orientada a objetos difiere de la programación
tradicional por procedimientos en cuanto a que examina a los objetos
que forman parte de un sistema. Cada objeto es una representación
computacional de una cosa o evento real. Los objetos pueden ser
clientes, artículos, pedidos, etcétera. Los objetos se representan y
agrupan mediante clases, las cuales son ideales para la reutilización y
la facilidad de mantenimiento.

Una clase define el conjunto de atributos y comportamientos

compartidos que se encuentran en cada objeto de la clase.
Las fases en el UML son similares a las del SDLC. Como estos dos
métodos comparten un modelado rígido y exigente, se realizan a un
ritmo más lento y reflexivo que las fases del modelado ágil. El
analista pasa por las fases del problema y de identificación, una fase
de análisis y una fase de diseño.

Mg. Danny M. Chuquizuta Herrera

 El proceso del UML
1. Definir el modelo de caso de uso: El analista identifica a los actores y los
eventos principales iniciados por los actores. A menudo el analista empieza
por dibujar un diagrama con figuras hechas con líneas que representan a los
actores y flechas que muestran las relaciones entre ellos. A esto se le conoce
como diagrama de caso de uso y representa el flujo estándar de eventos en el
sistema. Después de esto, el analista por lo general escribe un escenario de
caso de uso que describe con palabras los pasos que se llevan a cabo
comúnmente.
2. Durante la fase de análisis de sistemas, empezar a dibujar diagramas de
UML: El analista dibujará Diagramas de actividad, los cuales ilustran todas
las principales actividades en el caso de uso. Además el analista creará uno o
más diagramas de secuencia para cada caso de uso, los cuales muestran la
secuencia de actividades y su sincronización. Ésta es una oportunidad para
regresar y revisar los casos de uso, replantearlos y modificarlos si es
necesario.

Mg. Danny M. Chuquizuta Herrera

Los pasos en el proceso de desarrollo
de UML

Mg. Danny M. Chuquizuta Herrera

3. Continuar en la fase de análisis, desarrollar diagramas de clases: Los sustantivos
en los casos de uso son objetos que se pueden agrupar potencialmente en clases. Por
ejemplo, todo automóvil es un objeto que comparte características con otros
automóviles. En conjunto conforman una clase.

4. Aún en la fase de análisis, dibujar diagramas de estado: Los diagramas de clases

se utilizan para dibujar diagramas de estado, los cuales ayudan a comprender procesos
complejos que no se pueden derivar completamente mediante los diagramas de
secuencia. Los diagramas de estado son en extremo útiles para modificar los diagramas
de clases, por lo que continúa el proceso iterativo de modelado de UML.

Mg. Danny M. Chuquizuta Herrera

5. Empezar el diseño de sistemas mediante la modificación de los diagramas de
UML; después, completar las especificaciones: El diseño de sistemas significa
modificar el sistema existente, para lo cual hay que modificar los diagramas que
se dibujaron en la fase anterior. Es posible usar estos diagramas para derivar
clases, sus atributos y métodos (éstos son simplemente operaciones). El analista
tendrá que escribir especificaciones de clase para cada una de las clases e incluir Atributos:
los atributos, métodos y sus descripciones. También desarrollará especificaciones • Color
• Velocidad
de los métodos en las que se detallen los requerimientos de entrada y salida para • Ruedas
cada método, junto con una descripción detallada del procesamiento interno del • motor
método.
Métodos:
• Arranca(
6. Desarrollar y documentar el sistema: UML es, obviamente, un lenguaje de )
modelado. Un analista podrá crear modelos maravillosos, pero si el sistema no se • Frena()
• Dobla()
desarrolla no tiene mucho sentido crearlos. La documentación es imprescindible.
Entre más completa sea la información que usted proporcione al equipo de
desarrollo por medio de la documentación y los diagramas de UML, más rápido será
el desarrollo y más sólido será el sistema de producción final.

Mg. Danny M. Chuquizuta Herrera

 SELECCIONE CUANDO

 Los sistemas se hayan desarrollado y documentado mediante el uso

de SDLC.
 Sea importante documentar cada paso del proceso.
La metodología
 La administración de nivel superior se sienta más cómoda o segura si
del ciclo de vida
utiliza SDLC.
del desarrollo de
 Haya los recursos y el tiempo adecuados para completar el SDLC
sistemas (SDLC).
completo.
 Sea importante la comunicación en relación con la forma en que
funcionan los nuevos sistemas.
 Haya un defensor de proyectos de métodos ágiles en la organización
 Haya que desarrollar aplicaciones rápidamente en respuesta a un
entorno dinámico.
Metodologías  Haya que realizar un rescate (el sistema falló y no hay tiempo de
ágiles. averiguar qué salió mal).
 El cliente está satisfecho con las mejoras incrementales.
 Los ejecutivos y analistas están de acuerdo con los principios de las
metodologías ágiles.
 Los problemas modelados se prestan a sí mismos para convertirlos en
clases.
Metodologías  Una organización ofrece apoyo para aprender UML.
orientadas a  Es posible agregar sistemas en forma gradual, un subsistema a la vez.
objetos.  La reutilización de software escrito con anterioridad es una
posibilidad.
 Es aceptable hacer frente a los problemas difíciles primero.

Mg. Danny M. Chuquizuta Herrera

En un día cálido y soleado de finales de octubre, Luis Muler estaciona su automóvil y camina hacia su oficina en la Central
Pacific University. Se sentía bien empezar como analista de sistemas y estaba esperando conocer al resto del personal. En la
oficina, Dana Linday se presenta a sí misma. “Nos han asignado para trabajar como equipo en un nuevo proyecto. ¿Por qué no te
pongo al corriente con los detalles y después damos un paseo por las instalaciones?” “Me parece bien”, responde Luis. “¿Cuánto
tiempo llevas trabajando aquí?” “Aproximadamente cinco años”, le responde Dana. “Empecé como analista programador pero
durante los últimos años me he dedicado al análisis y diseño. Espero que encontremos formas de aumentar nuestra
productividad”, continúa Dana.

“Cuéntame sobre el nuevo proyecto”, dice Luis. “Bien”, le responde Dana, “al igual que muchas organizaciones, tenemos una
gran cantidad de microcomputadoras con distintos paquetes de software instalados en ellas. Hasta donde sé, en la década de
Ejercicio
1980 había pocas computadoras personales y una colección dispersa de software. Esto se expandió con rapidez en la década de
De la conversación de presentación que
1990 y ahora todos usan computadoras.
compartieron Luis y Dana, ¿Cuáles de los
Algunos miembros del cuerpo docente utilizan más de una. El sistema actual que utilizamos para dar mantenimiento al software elementos mencionados podrían sugerir
y hardware, que en un principio era bastante útil, ahora es obsoleto y está bastante abrumado”. “¿Qué hay sobre los usuarios? ¿A el uso de herramientas CASE.
quién debo conocer? ¿Quién crees que será importante para ayudarnos con el nuevo sistema?”, pregunta Luis. “Vas a conocer a
todos, pero hay personas clave que acabo de conocer y te diré lo que he aprendido para que las recuerdes cuando las conozcas”.

“Dot Matricks es gerente de todos los sistemas de microcomputadoras en Central Pacific. Al parecer nos llevamos bien en el
trabajo. Es muy competente. Realmente le gustaría poder mejorar la comunicación entre los usuarios y los analistas”. “Será un
placer conocerla”, especula Luis. “Y también está Mike Crowe, experto en mantenimiento de computadoras. Realmente parece
el tipo más amable, pero está demasiado ocupado. Necesitamos ayudar a aligerar su carga. La contraparte de Mike encargada del
software es Cher Ware. Es un espíritu libre, pero no me malentiendas: conoce su trabajo”, dice Dana.

“Tal vez sea divertido trabajar con ella”, reflexiona Luis. “Podría ser”, asiente Dana. “También conocerás al analista financiero,
Paige Prynter. Todavía no puedo entenderla bien”. “Tal vez yo te pueda ayudar”, dice Luis. “Por último, deberías – más bien
dicho, tienes que – conocer a Hy Perteks, quien hace un excelente trabajo como encargado del Centro de información. A él le
gustaría que pudiéramos integrar nuestras actividades del ciclo de vida”. “Suena prometedor”, dice Luis. “Creo que me va a
Mg. Danny M. Chuquizuta Herrera
Comprensión y modelado de los sistemas organizacionales

Para analizar y diseñar sistemas de información apropiados, los analistas de

sistemas deben concebir a las organizaciones en que trabajan como sistemas
configurados por la interacción de 3 fuerzas principales: los niveles de
administración, el diseño de las organizaciones y las culturas organizacionales.

Conceptualizar a las organizaciones como sistemas complejos permite entender

la forma en que funcionan a través de los principios de sistemas. Para establecer
en forma adecuada los requerimientos de información y diseñar sistemas de
información apropiados, es primordial comprender a la organización como un
todo. Todos los sistemas están compuestos de subsistemas; por lo tanto, al
estudiar una organización también debemos examinar como se involucran los
sistemas más pequeños y la manera en que funcionan.

Mg. Danny M. Chuquizuta Herrera

 Capacidad de interrelación e interdependencia de los sistemas

Todos los sistemas y subsistemas están interrelacionados y son

interdependientes. Este hecho tiene implicaciones importantes, tanto para
las organizaciones como para los analistas de sistemas que buscan ayudar a
estas organizaciones a cumplir mejor sus objetivos. Cuando se modifica o
elimina algún elemento de un sistema, también se afecta considerablemente
al resto de los elementos y subsistemas de ese sistema.

Todos los sistemas procesan entradas provenientes de sus entornos. Por

definición, los procesos cambian o transforman las entradas en salidas.
Cada vez que examine un sistema, identifique qué se está cambiando o
procesando . Algunos procesos comunes en los sistemas son verificar,
actualizar e imprimir.

Mg. Danny M. Chuquizuta Herrera

La retroalimentación es una forma de control de un
sistema. Como sistemas, todas las organizaciones
usan la planeación y el control para administrar sus
recursos con efectividad.

Mg. Danny M. Chuquizuta Herrera

 Sistemas empresariales: considerar a la organización como un sistema

También denominados sistemas de planificación de recursos empresariales

(ERP), constituyen un termino empleado para describir un sistema de
información organizacional (empresarial) integrado. En esencia, ERP es
software que ayuda al flujo de información entre las áreas funcionales de la
organización.
Es un sistema personalizado que, en vez de desarrollarlo dentro de la empresa,
por lo general se compra a una de la empresas de desarrollo de software
reconocidas por sus paquetes ERP, como SAP y Oracle.

Mg. Danny M. Chuquizuta Herrera

 Fundamentos del Análisis de
sistemas

Los sistemas y el diagrama de flujo

de datos a nivel de contexto.
Los sistemas y el modelo entidad
relación.
Modelado de casos de uso.

Mg. Danny M. Chuquizuta Herrera

1. Los sistemas y el diagrama de flujo de datos
a nivel de contexto
El primer modelo es el diagrama de flujo de datos a nivel de
contexto. Estos diagramas se enfocan en los datos que fluyen hacia el
sistema y salen de él, además del procesamiento de estos datos.
El diagrama de flujo de datos a nivel de contexto emplea sólo tres
símbolos:
1. Un rectángulo con esquinas redondeadas,

Mg. Danny M. Chuquizuta Herrera

 2. Un cuadrado con dos bordes sombreados,

3. Una flecha.

Los procesos transforman los datos entrantes en información de salida

y el nivel de contenido tiene solo un proceso, que representa a todo el
sistema completo.
La entidad externa representa a cualquier entidad que suministra o
recibe información del sistema, pero que no forma parte del mismo.
Esta entidad puede ser una persona, un grupo de personas, un puesto o
departamento corporativo o, inclusive, otros sistemas. 5

Mg. Danny M. Chuquizuta Herrera

Ejemplo

Mg. Danny M. Chuquizuta Herrera

5

Mg. Danny M. Chuquizuta Herrera

Diagrama de flujo de datos a nivel de contexto para el sistema de
reservación de una aerolínea

Mg. Danny M. Chuquizuta Herrera

2. Los sistemas y el modelo de entidad
relación
Un analista puede mostrar el alcance del sistema y definir limites
apropiados para el mismo mediante el uso de un modelo entidad – relación.
Los elementos que conforman un sistema organizacional se pueden
denominar entidades. Una entidad puede ser una persona, un lugar o una
cosa, como un pasajero en una aerolínea, un destino o un avión.
O bien, una entidad puede ser un evento, como el fin de mes, un periodo de
ventas o el tiempo de inactividad de un máquina. Una relación es la
asociación que describe a la interacción entre las entidades.

Mg. Danny M. Chuquizuta Herrera

Ejemplo del modelo de entidad relación

Mg. Danny M. Chuquizuta Herrera

 3. Modelado de casos de uso
Aunque en un principio se presentaron como un diagrama para usarlo en el
UML orientado a objetos, ahora los casos de uso se utilizan sin importar la
metodología para el desarrollo de sistemas. Se puede usar en SDLC o en el
modelado ágil.
Un modelado de caso de uso describe qué hace un sistema sin describir
cómo lo hace ; es decir, es un modelo lógico del sistema.
Un analista desarrolla casos de uso en un esfuerzo de cooperación con los
expertos de negocios que ayudan a definir los requerimientos del sistema.

Símbolos de los casos de uso

Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso,
junto con líneas conectoras. Lo actores son similares a las entidades externas;
existen fuera del sistema.
El término actor se refiere a un rol específico de un usuario del sistema. El
actor existe fuera del sistema e interactúa con éste de una manera específica.
Un actor puede ser un humano, otro sistema o un dispositivo como un teclado
o una conexión Web. Los actores pueden iniciar una instancia de un caso de
uso. Un actor puede interactuar con uno o más casos de uso; un caso de uso
puede involucrar a uno o más actores.
Mg. Danny M. Chuquizuta Herrera
 También es conveniente hacer una lista de los actores
junto con sus objetivos y prioridades. Cada objetivo se
puede convertir en un caso de uso.
Un caso de uso provee a los desarrolladores una
perspectiva de lo que quieren los usuarios, sin detalles
técnicos o implementación. Podemos considerar un caso
de uso como una secuencia de transacciones en un
sistema.
El modelo de casos de uso se basa en las interacciones y
relaciones de casos de uso individuales.
Un caso de uso siempre describe tres cosas: un actor que
inicia un evento, el evento que desencadena un caso de
uso y el caso de uso que realiza las acciones
desencadenado por el evento. En un caso de uso, un actor
que utiliza el sistema inicia un evento que comienza una
serie relacionada de interacciones en el sistema. Los casos
de uso se utilizan para documentar una transacción o
evento únicos.
Mg. Danny M. Chuquizuta Herrera
Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de
comportamiento y se utilizan principalmente en los
diagramas de casos de uso. Existen cuatro tipos básicos de
relaciones de comportamiento:
1. Comunica,
2. Incluye,
3. Extiende,
4. Generaliza.

Mg. Danny M. Chuquizuta Herrera

Comunicación
Esta relación de comportamiento se utiliza para conectar
un actor con un caso de uso.
Ejemplo: un Estudiante se comunica con Inscribir en el
curso.

Inclusión
Describe la situación en la que un caso de uso contiene
comportamiento común para más de un caso de uso. Es
una flecha punteada que apunta al caso de uso común
indica la relación de inclusión.
Ejemplo: caso de uso pagar cuotas de estudiantes que se
incluye en Inscribir en el curso y hacer arreglos de
hospedaje., ya que en ambos casos los estudiantes deben
pagar sus cuotas.
Mg. Danny M. Chuquizuta Herrera
Extensión
Esta relación describe la situación en la que un caso de
uso posee el comportamiento que permite al nuevo caso
de uso manejar una variación o excepción a partir del caso
de uso básico. La flecha va del caso de uso extendido al
caso de uso básico.
Ejemplo: seguro médico de estudiantes extiende el caso
de uso básico pagar cuotas de estudiantes.

Generalización
Esta relación implica que una cosa es más común que
otra. Esta relación puede existir entre dos actores o dos
casos de uso.
Ejemplo: un estudiante de medio tiempo generaliza a un
estudiante.

Mg. Danny M. Chuquizuta Herrera

Mg. Danny M. Chuquizuta Herrera
Desarrollo del alcance del sistema
El alcance de un sistema define sus limites, lo que está al
alcance (dentro del sistema) y lo que está fuera de él. Los
actores siempre están fuera del alcance del sistema.
Las líneas de comunicación que conectan a los actores con
los casos de uso son los limites y definen el alcance.

Por qué son útiles los diagramas de casos de

uso
Los diagramas de caso de uso se están haciendo populares
debido a su sencillez y carencia de detalles técnicos. Se
utilizan para mostrar el alcance de un sistema, junto con
las principales características del mismo y los actores que
trabajan con esas características principales. Los usuarios
ven el sistema, pueden reaccionar a él y proveer
retroalimentación. También pueden ayudar a determinar si
se debe crear o comprar el software.
Mg. Danny M. Chuquizuta Herrera
Diagrama de caso de uso que representa al sistema
utilizado para planear una conferencia

Mg. Danny M. Chuquizuta Herrera

Un escenario de caso de uso se divide en tres secciones:
identificación e iniciación; pasos realizados; y condiciones,
suposiciones y preguntas.
Nombre del caso de Registrarse para la ID único: Conf RG 003
uso: conferencia
Área: Planeación de la conferencia
Actor (es): Participante.
Interesados: Patrocinador de la conferencia, oradores de la
conferencia.
Nivel: Azul
Descripción: Permitir que el participante de la conferencia se registre
en línea mediante un sitio web seguro.
Evento El participante utiliza el sitio web de registro para la
desencadenador: conferencia, introduce su ID de usuario y su contraseña,
y hace clic en el botón del inicio de sesión.
Tipo de Externo Temporal
desencadenador:
Pasos realizados (ruta principal) Información para los pasos.
1. El participante inicia sesión mediante el ID de usuario, contraseña.
servidor web seguro.
2. Se lee el registro del participante y se Registro del participante, ID de
verifica su contraseña. usuario, contraseña.

Mg. Danny M. Chuquizuta Herrera

Continúa la tabla.
3.Se muestra la información del participante y
la sesión en la pagina web de registro.
4. El participante introduce su información en
el formulario web de registro y hace clic en el
botón enviar.
5. Se valida la información de registro en el
servidor web.
6. Se muestra la página confirmación de
registro para confirmar la información de
registro.
7. Se hace un cargo a la tarjeta de crédito
equivalente a las cuotas de registro.
8. Se escribe el registro en el diario de agregar
registros.
9. Se actualiza el registro en el archivo maestro
de registros.
10. se actualiza el registro de la sesión para
cada sesión seleccionada en el archivo maestro
de sesiones.
11. Se actualiza el registro para el participante
en el archivo maestro de participantes.
12. Se envía la página web de confirmación de
registro exitoso al participante.
Registro del participante, registro
de la sesión.
Formulario web de registro.
Formulario web de registro.
Pagina web de confirmación.
Pagina web segura para tarjeta
de crédito.
Pagina web de confirmación.
Pagina web de confirmación,
registro del proceso de registro.
Pagina web de confirmación,
registro de la sesión.
Pagina web de confirmación,
registro de participantes.
Número de confirmación del
registro en el proceso de registro. Mg. Danny M. Chuquizuta Herrera
Continúa la tabla.
Precondiciones: El participante ya se registró y creó una cuenta de usuario.
Postcondiciones: El participante se registró con éxito para la conferencia.

Suposiciones: El participante tiene un navegador web, además de un ID

de usuario y contraseña válidos.

Garantía de éxito: El participante se registro para la conferencia y está

inscrito en todas las sesiones seleccionadas.

Garantía mínima. El participante pudo iniciar sesión.

Requerimientos Permitir que los participantes de la conferencia se registren

cumplidos: mediante un sitio web seguro.

Cuestiones Cómo se debe manejar una tarjeta de crédito rechazada?

pendientes:
Prioridad: Alta
Riesgo: Medio

Mg. Danny M. Chuquizuta Herrera

GRACIAS
Mg. Danny M. Chuquizuta Herrera

chuhedama@gmail.com