1. El documento presenta conceptos clave relacionados con el modelado y análisis de sistemas de información. 2. Incluye elementos como entidades, atributos, relaciones, flujos de datos y diagramas para representar procesos. 3. El objetivo es facilitar el estudio y diseño de sistemas complejos a través de su descomposición en componentes más simples.

1. • RAMOS CHAVEZ Marco
• PAZCE LAZO Michael
• SANCHEZ ALANYA Jose L.
• ZACARIAS MUNGUIA Valeria
• HIDALGO HINOJOSA Nilton

3. El modelado de procesos, así como
su nombre lo indica, tiene 2 aspectos
que lo definen: el modelado y los  EJEMPLO:
procesos. Frecuentemente,
sistemas, conjuntos de procesos y
los
 La reingeniería de
subprocesos integrados en una procesos de
organización.
negocios, la cual se
Un modelo es una representación de
una realidad compleja. Modelar es encarga del rediseño
desarrollar una descripción lo más de los procesos de
exacta posible de un sistema y de las
actividades llevadas a cabo en él. negocios de las
Cuando un proceso es modelado, con organizaciones con el
ayuda de una representación gráfica
(diagrama de proceso), pueden
fin de hacerlos más
apreciarse con facilidad las eficientes.
interrelaciones existentes entre
distintas actividades, analizar cada
actividad, definir los puntos de
contacto con otros procesos, así
como identificar los subprocesos
comprendidos.

4. Representación

5.  Es la manera en que se
representa la forma en
que los datos cambian
conforme se mueven a Las transformaciones
través del sistema. que se aplican a los
datos son funciones
que debe realizar un
programa.
DESCRIPCIÓN
REPRESENTACIÓN

6. El Análisis se refiere al “extremo inicial”
de un proyecto de desarrollo de
sistemas, durante el tiempo en que los
requisitos del usuario son definidos y
documentados.

7.  El análisis de requisitos es el proceso de
estudio de las necesidades de los usuarios
para llegar a una definición de los requisitos
del sistema de hardware o de software; así
como su estudio y refinamiento.
 Tras haber estudiado las posibilidades con las
que se cuenta para el desarrollo del
sistema, así como sus limitaciones, se puede
establecer una lista más firme de
requisitos, tanto a nivel funcional como no
funcional.

8.  El software se construye para procesar datos,
para transformarlos es decir, para aceptar datos
de entrada, manipularlos y producir información
de salida. Pero el software también procesa
acontecimientos, que controlan al sistema y no
es más que un dato binario, tal como un sensor
que envía al software una señal de alarma.
 Por tanto, los datos ( números, caracteres,
imágenes, sonidos, etc. ) y el control (
acontecimientos ) son parte del dominio de la
información.

9.  1. Contenido de la Información
 2. Flujo de la Información
 3. Estructura de la Información

10.  El modelo de análisis debe cumplir tres
objetivos primarios:
 1: Describe lo que requiere el cliente
 2: Establecer una base para la creación de
un diseño de software
 3: Definir un conjunto de requisitos que
puedan validarse una vez construido el
software

11.  Es un esquema teórico de un sistema o realidad
compleja que se elabora para facilitar su
comprensión y estudio.
 Es una representación de los aspectos esenciales
de una realidad compleja de acuerdo a un criterio
 Todo modelo es necesariamente una
simplificación de la realidad
 ¿Por qué modelar?
Para facilitar el estudio y analizar el
comportamiento de un SI(sistema de
información), y sus componentes
Para rediseñar un SI, tal que satisfaga nuevos
objetivos y requerimientos de gestión

12.  Las entidades son los objetos principales
sobre los que se debe recoger información y
generalmente denotan
personas, lugares, cosas o eventos de interés.
Las entidades aparecen reflejadas en el
enunciado habitualmente como nombres.
Gráficamente se simbolizan con un
rectángulo.

13.  Los atributos se utilizan para detallar las entidades
asignándoles propiedades descriptivas tales como
nombre, color y peso. No solo es posible especificar
atributos en las entidades sino también en las
relaciones. Los atributos también aparecen reflejados
en el enunciado, generalmente, como nombres.
 Las entidades pueden clasificarse por la fuerza de sus
atributos identificadores, es decir, por su
dependencia o no dependencia respecto a otras
entidades. Las entidades fuertes tienen existencia
propia, es decir, poseen identificadores internos que
determinan de manera única la existencia de sus
ocurrencias. Las entidades débiles pueden tienen
existencia en la base de datos dependiendo de una
entidad fuerte. Gráficamente los atributos se
simbolizan con una elipse.

14.  Las relaciones representan asociaciones en el
mundo real entre una o más entidades. Las
relaciones se caracterizan por su nombre, el
grado (número de entidades que participan
en la relación), el tipo de cardinalidad
(número máximo de ejemplares de una
entidad asociados a una combinación de
ejemplares de las otras entidades de la
relación, que pueden ser 1 ó N). Gráficamente
las relaciones se simbolizan con un rombo.

15. En este modelo se presenta la vista unificada de los
datos, centrándose en la estructura lógica y abstracta
de los datos, como representación del mundo real, con
independencia de consideraciones del mundo físico.
 Un modelo Entidad-Relación tiene los siguientes
elementos:
 Entidad es “una
persona, lugar, cosa, concepto, suceso, real o
abstracto de interés para la empresa”. Es aquel objeto
acerca del cual queremos almacenar información en
la base de datos.
 Interrelación se define como la asociación o
correspondencia entre entidades.
 Atributos

16.  • El modelo funcional describe los
comportamientos y operaciones de los objetos.
 • El modelo funcional muestra la dependencia de
datos en el sistema.
 • El modelo funcional describe la computación
dentro del sistema, cómo los valores de salida se
 derivan de los valores de entrada, sin importar el
orden en que son computados.
 • El modelo funcional consiste de múltiples
diagramas de flujo de datos.

17.  El diagrama de flujo de datos ( DFD ) es una
técnica gráfica que representa el flujo de la
información y las transformaciones que se
aplican a los datos al moverse desde la
entrada a la salida.
 La notación básica para construir DFD’s es la
siguiente:

18.  Un rectangulo representa a un elemento del
sistema ( por ejemplo un hardware, una
persona, un programa ) o un sistema que
produce o recibe información que es
transformada por el software.
 Un circulo representa un proceso o
transformación que se aplica a los datos y los
cambia de alguna forma.

19.  La flecha representa a un elemento o una
colección de elementos de datos.
 Representa información almacenada y que
utiliza el software.

20.  El diagrama de transición de estados DTE
representa el comportamiento de un sistema
que muestra los estados y los sucesos que
hacen que el sistema cambie de estado.
 Un estado es un modo observable de
comportamiento, por ejemplo
monitoreando, comprobando, calculando, etc
. Cada estado representa un modo de
comportamiento y el DTE indica cómo se
mueve el sistema de un estado a otro.

21.  Un Diccionario de Datos es una lista con
todos los detalles y descripciones de los
elementos incluidos en los Diagramas de
Flujo de Datos que describen al sistema.

22.  1. Descripción de los almacenamientos de
datos
 2. Descripción de los procesos
 3. Descripción de las estructuras de datos
 4. Descripción de los elementos de datos
 5. Descripción de los flujos de datos

23. CONCEPTOS:

24.  Definición:
◦ La representación de las características esenciales de
algo sin incluir antecedentes o detalles irrelevantes
[Graham, 1994]

25.  Ventajas:
◦ Define y refuerza las restricciones de acceso
◦ Facilita el mantenimiento y la evolución de los sistemas
software
◦ Reduce los efectos laterales
◦ Limita el impacto global de las decisiones de diseño
locales
◦ Favorece la encapsulación, uno de los elementos de un
buen diseño
◦ Descripción de una función de un programa en el nivel
de detalle adecuado
◦ Cada paso en el proceso del software es un refinamiento
del nivel de abstracción de la solución software
(abstracciones funcionales y abstracciones de datos)
◦ Refinamiento y modularidad son conceptos cercanos al
concepto de abstracción

26.  Similitud con el procedimiento de partición y
refinamiento del análisis de requisitos
◦ La diferencia está en el nivel de detalle, no en el enfoque
 El refinamiento es un procedimiento de elaboración
◦ Función descrita a un nivel conceptual
◦ Refinamientos sucesivos que incorporan más detalles
 Gestiona la complejidad dividiendo problemas grandes
en problemas pequeños
◦ Permite que personas diferentes puedan trabajar con cada parte
◦ Permite la especialización de los ingenieros del software
◦ Cada componente individual es más pequeño y, por tanto, su
comprensión es más sencilla
◦ Las partes se pueden remplazar o cambiar sin tener que
remplazar o cambiar de forma generalizada el resto de las
partes

27.  Propiedad de un sistema que ha sido
descompuesto en un conjunto de módulos
coherentes e independientes
 El software se divide en componentes con
nombres y ubicaciones determinados, que se
denominan módulos y que se integran para
satisfacer los requisitos del proveedor.

28. MODULARIDAD
La modularidad del
software facilita el
desarrollo del
mismo, pero hasta
un cierto
límite, porque si
llegáramos a dividir
el problema en
infinitos
módulos, los
módulos tendrían
una complejidad y
un esfuerzo mucho
menor, pero crecería
el coste asociado a
la creación de
interfaces entre los
módulos,

29.  La arquitectura del software alude a la
“estructura global del SW y a las formas en
que la estructura proporciona la integridad
conceptual de un sistema”
 La arquitectura del SW es la estructura
jerárquica de los componentes del programa
(módulos), la manera en que los
componentes interactúan y la estructura de
datos que van a utilizar los componentes.

31.  La jerarquía de control, denominada también
“estructura del programa”, representa la
organización de los componentes del
programa (módulos) e implica una jerarquía
de control.
 No representa los aspectos procedimentales
del software, ni se puede aplicar
necesariamente a todos los estilos
arquitectónicos.

33.  La estructura de un programa debe partirse
horizontal y verticalmente
 La partición horizontal define ramas separadas de la
jerarquía modular para cada función principal del
programa
◦ Módulos de control
◦ Enfoque entrada/proceso/salida
 Beneficios de la partición horizontal
◦ Proporciona software más fácil de probar
◦ Lleva a un software más fácil de mantener
◦ Propaga menos efectos secundarios
◦ Proporciona software más fácil de ampliar
 Puntos en contra de la partición horizontal
◦ Aumenta la comunicación entre módulos, pudiendo
complicar el control global del flujo del programa

34.  Partición vertical o descomposición en factores
(factoring)
 La partición vertical expresa que el control, toma
de decisiones, y el trabajo se distribuyan de forma
descendente en la arquitectura del programa
 Los módulos de nivel superior deben realizar
funciones de control y poco trabajo de
procesamiento
 Los módulos que residen en la parte baja de la
arquitectura deben de ser los que realicen las
tareas de entrada, cálculo y salida

37.  La estructura de datos e una representación
de la relación lógica entre elementos
individuales de datos .
 Como la estructura de la información afectara
invariablemente al diseño procedimental
final, la estructura de datos es tan importante
como la estructura de programa para la
representación de la arquitectura de software

38.  La estructura del programa define la jerarquía de
control sin tener en consideración la secuencia
de proceso y de decisiones.
 El procedimiento de software se centra en el
procesamiento de cada modulo individualmente.
 El procedimiento debe proporcionar una
especificación precisa de
procesamiento, incluyendo la secuencia de
sucesos , los puntos de decisión exactos, las
operaciones repetitivas e incluso la estructura
, organizándole datos.

39.  “Los módulos de un sistema deben diseñarse
de modo que la información contenida en
ellos sea inaccesible a todos aquellos
módulos que no necesiten tal información”
David Parnas, 1970
◦ Los módulos deberán especificarse y diseñarse de
manera que la información (procedimientos y datos)
que está dentro de un módulo sea inaccesible a
otros módulos que no necesiten esa información

40.  El ocultamiento de la información es un buen
medio para conseguir abstracción
 Restricciones de acceso
◦ Detalle procedimental dentro del módulo
◦ Estructura de datos local empleada por el módulo
 El diseñador de cada módulo debe
seleccionar un subconjunto de las
propiedades del módulo como información
oficial del módulo, para ponerlas a
disposición de los autores de módulos o de
módulos clientes

41.  Las decisiones de diseño sujetas a cambio deben
ocultarse detrás de interfaces abstractas
◦ Las aplicaciones software han de comunicarse
únicamente a través de interfaces bien definidas
◦ La interfaz de un módulo debe revelar lo menos posible
de su funcionamiento interno
◦ Intercambio de módulos mientras que se mantengan
intactas las interfaces
◦ Ventajas a la hora de hacer cambios
 Ocultación significa que se puede conseguir una
modularidad efectiva definiendo un conjunto de
módulos independientes que se comunican
intercambiando la información necesaria para
realizar la función software

42. La cohesión hace referencia a la forma en que
agrupamos unidades de software
(módulos, subrutinas) en una unidad mayor.
 Por ejemplo: la forma en la que agrupamos
funciones en una librería.

43. El acoplamiento informático indica el nivel de dependencia entre las unidades de software
de un sistema informático, es decir, el grado en que una unidad puede funcionar sin
recurrir a otras; dos funciones son absolutamente independientes entre sí (el nivel más
bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la
otra. En este caso se dice que ambas están desacopladas.
 Ejemplo:
 Dos métodos completamente desacoplados, es decir ninguno necesita del otro para
realizar su tarea.
int metodo1(int a, int b)
{
return a * b;
}
int metodo2(int a, int b)
{
return a + b;
}

44. El diseño de datos consiste en descubrir y la definir completamente de
los procesos y características de los datos de la aplicación. El diseño
de datos es un proceso de perfeccionamiento gradual que abarca
desde la cuestión más elemental, "¿Qué datos requiere la
aplicación?", hasta los procesos y estructuras de datos precisos que
proporcionan dichos datos. Si el diseño de datos es bueno, el acceso a
los datos de la aplicación será rápido y fácil de mantener, y podrá
aceptar sin problemas las futuras mejoras de los datos.

45.  Define la relación entre los principales
elementos estructurales del programa. Se
obtiene a partir del modelo de análisis y de la
interacción de subsistemas definidos dentro
del modelo de análisis.
 La arquitectura de software nos proporciona
una visión global del sistema a construir.
 Marca decisiones de diseño tempranas y
proporciona el mecanismo para evaluar los
beneficios de las estructuras de sistema
alternativas.

46.  La información debe introducirse y obtenerse del
software en forma de mundo exterior, la
información entra en el sistema a lo largo de
caminos que transforman los datos externos a un
formato interno. Estos caminos se identifican
como flujo de entrada. La información entrante
se pasa a través de un centro de transformación
y empieza a moverse a lo largo de caminos que
ahora conducen hacia fuera del software. Los
datos que se mueven a lo largo de este camino
se denominan flujo de salida.

47.  El flujo de transacción se caracteriza por
datos que se mueven a lo largo de un camino
de entrada que convierte la información del
mundo exterior en una transacción. La
transacción se evalúa y, basándose en ese
valor, se inicia el flujo a lo largo de uno de
muchos caminos de acción. El centro de flujo
de información del que parten muchos de los
caminos de acción se denomina centro de
transacción.

48.  Describe como se comunica el software
consigo mismo, con los sistemas que operan
con él y con los operadores que lo emplean.
Los diagramas de flujo de datos y control
proporcionan la información necesaria para el
diseño de la interfaz.

49.  Transforma elementos estructurales de la
arquitectura del programa en una descripción
procedimental de los componentes del
software. Se obtiene a partir de la
especificación del proceso, la especificación
del control y el diagrama de transición de
estados

51.  1. Conceptos
 2. Análisis del Sistema Descripción
 3. Diseño del Sistema descripción

52.  Un objeto es aquello que tiene estado (propiedades
más valores), comportamiento (acciones y reacciones
a mensajes) e identidad (propiedad que lo distingue
de los demás objetos).
 Conjunto de objetos (Clase).
 Ejemplo: la clase Humanos, puede tener dos
subclases Hombres y Mujeres. Luego como objetos
podríamos poner hombre1, hombre2, que pertenecen
a la clase Hombres y mujer1, mujer2 pertenecientes a
la clase Mujeres.

53.  Conjunto de objetos que comparten una
estructura y comportamiento en común
 Plantilla o prototipo para crear objetos de
ese tipo, la cual contiene las características y
acciones comunes del objeto
 Ejemplo:
 La clase Humanos, puede tener dos subclases
Hombres y Mujeres.

54.  Es una especificación que define una
propiedad de un objeto diferenciándolo así
de los otros objetos.
 Describen la clase o el objeto de alguna
manera, la cual esta definida por un
dominio(conjunto de valores específicos).
 Ejemplo:
A la colección de entidades Alumnos, con el
siguiente conjunto de atributos en
común, (id, nombre, edad, semestre),

55.  un método son las operaciones asociadas a
un objeto.
 Por ejemplo, la casa puede estar cerrada o
abierta (siendo "estado De La Puerta" un
atributo con posibles valores "abierta" o
"cerrada"), y posee un método "abrir Puerta" o
"cerrar Puerta“
 Son las funciones o acciones del objeto en
caso de la persona, los métodos
son, caminar, hablar, reír, pensar, gritar,

56.  Los mensajes son el medio a través del cual
interactúan los objetos.
 Los mensajes y los métodos son dos caras de la
misma moneda LOS METODOS SON LOS
PROCEDIMIENTOS INVOCADOS CUANDO UN
OBJETO RECIBE UN MENSAJE ( Greg Voss)
 tres partes que componen un mensaje:
1. El objeto al cual se manda el mensaje (Tu
Bicicleta).
2. El método o función miembro que debe
ejecutar (Cambiar De Marcha).
3. Los parámetros que necesita ese método
(Marcha)

57.  Es empaquetar o proteger las variables de un
objeto con la protección de sus métodos.
 Es guardar atributos y funcionalidades de una
clase. No se puede acceder a los datos desde
fuera de la clase teniendo acceso a ello solo
los métodos que se encuentren dentro de la
clase, dividiéndola en interfaces e
implementación

58.  La herencia es la capacidad que tiene una
clase de derivar las propiedades y métodos
de otra, adoptando sus atributos y métodos
de la clase padre o primaria.
 Pero además pueden introducir
características particulares propias que las
diferencian.

59.  Clases diferentes que tienen métodos o
atributos denominados de forma
idéntica, pero que se comportan de manera
distinta, pueden compartir el mismo
nombre, al llamarlos por ese nombre se
utilizará el comportamiento correspondiente
al objeto que se esté usando

60.  Utilizado para conservar o mantener una
cierta característica o interfaz en común.
 Representan los escalones más elevados de
algunas jerarquías de clases y solo sirven
para derivar otras clases, en las que se van
implementando detalles y concreciones

61. 1. MetaClase
- Es una clase cuyas instancias son clases.
- En otras palabras, como los objetos son
instancias de una clase, las clases son
instancias de una meta clase.

62. 2. Subclase
- Una subclase hereda ciertas características de
las clases padres (e incluso pueden redefinirse
o agregarse nuevas características de la clase
superior también)

63.  Asociación entre Objetos:
1. Generalización
2. Agregación
3. Composición

64.  Permite una estructuración jerárquica de las
clases que comparten estructuras o
comportamientos
 Consiste en crear clases genéricas llamadas
súper clases o clases padre, con los elementos
comunes a un conjunto de subclases. Las
subclases heredan (recogen) los atributos y
comportamiento de la clase padre pudiendo
agregar atributos y comportamiento propios, y
modificar los atributos y comportamiento que
vienen del padre.

65.  La agregación es un tipo especial de relación
en el que se modela una semántica del tipo
“tiene” o “es parte de”, en la que una entidad
represente una entidad de mayor tamaño (el
“todo”), compuesta de entidades más
pequeñas (las “partes”)
Libro
CDLibro FormatoSuscripcion

66.  La agregación es enteramente conceptual y lo
único que hace es distinguir un “todo” de
una “parte”
 La composición representa una pertenencia
fuerte y una existencia coincidente entre el
“todo” y la “parte”

67. 1. Estados de un objeto
2. Eventos, tipos de eventos
3. Operaciones

68.  Se refiere al conjunto de los valores de sus
atributos en un instante de tiempo dado, la
apariencia que el objeto presenta al usuario, y
depende del valor que tenga sus
propiedades.
 Los objetos interactúan unos con otros y
como consecuencia de esas interacciones
cambian de estado.

69.  Los eventos producen cambios en el estado
de un objeto. Los eventos sirven como
indicadores de los instantes en que ocurren
los cambios de estado.
 Todos los objetos se relacionan con el mundo
que los rodea, esto significa que ningún
objeto está aislado y siempre recibe el influjo
de otros objetos. Los eventos son los
estímulos que un objeto ejerce sobre otro
 Los tipos de eventos indican los cambios
sencillos en el estado de un objeto

70.  Definen el comportamiento de un objeto.
 Las operaciones definen el comportamiento
de un objeto y cambian, de alguna manera,
los atributos de dicho objeto.
1. Operaciones de manipulación
2. Operaciones de estado
3. Operaciones que monitorizan

71.  El objetivo del análisis orientado a objetos es desarrollar una
serie de modelos que describan el software de computadora al
trabajar para satisfacer un conjunto de requisitos definidos por
el cliente.
 « Es un método de análisis que examina los requisitos desde
la perspectiva de las clases y objetos que se encuentran en el
vocabulario del dominio del problema » [booch 94].
 El diseño Orientado a Objetos (DOO) difiere considerablemente
del diseño estructurado ya que en DOO no se realiza un
problema en términos de tareas (subrutinas) ni en términos de
datos, sino se analiza el problema como un sistema de objetos
que interactúan entre sí.

72.  El análisis del dominio del software es la
identificación, análisis y especificación de requisitos comunes
de un dominio de aplicación específico, normalmente para su
reutilización en múltiples proyectos dentro del mismo
dominio de aplicación.
Pressman ing. Software quinta
edición

73.  Los componentes estáticos son estructurales por
naturaleza, e indican características que se mantienen
durante toda la vida operativa de una aplicación.
 Los componentes dinámicos se centran en el control, y son
sensibles al tiempo y al tratamiento de sucesos.

74. 1. La inteligencia del sistema debe distribuirse de manera
igualitaria.
2. Cada responsabilidad debe establecerse lo más general
posible.
3. La información y el comportamiento asociado a
ella, debe encontrarse dentro de la misma clase.
4. La información sobre un elemento debe estar
localizada dentro de una clase, no distribuida a través
de varias clases.
5. Compartir responsabilidades entre clases relacionadas
cuando sea apropiado.

75.  Diseño orientado a objetos es una fase de la metodología
orientada a objetos para el desarrollo de Software. Su uso
induce a los programadores a pensar en términos de
objetos, en vez de procedimientos, cuando planifican su
código
 El diseño orientado a objetos transforma el modelo de
análisis creado usando análisis orientado a objetos , en un
modelo de diseño que sirve como anteproyecto para la
construcción de software teniendo el uso de capaz.
1.Diseño de responsabilidades
2.Diseño de mensajes
3.Diseño de clases y objetos
4.Diseño de subsistemas

76.  La capa de responsabilidades.- Estructuras de datos y el
diseño algorítmico para todo los atributos y operaciones.
 La capa del subsistema.- representación de los subsistemas
que le permiten al software (requisitos e infraestructura
técnica que lo soportara)
 La capa de clases y Objetos.- jerarquías de clase que
permiten crear el sistema usando generalizaciones y
especializaciones mejor definidas.
 La capa de mensajes.- detalles que le permiten a cada objeto
comunicarse con sus colaboradores. Esta capa establece las
interfaces externas e internas para el sistema.

78. Se siguen los siguientes pasos:
 Partición del modelo de análisis en subsistemas.
 Identificar la concurrencia dictada por el problema.
 Asignar subsistemas a procesadores y tareas.
 Desarrollar un diseño para la interfaz de usuario.
 Elegir una estrategia básica para implementar la
administración (gestión) de datos.
 Identificar recursos globales y los mecanismos de control
requeridos para su acceso.
 Diseñar un mecanismo de control apropiado para el
sistema, incluyendo administración de tareas.
 Considerar cómo deben manejarse las condiciones de
frontera.

79. • El diseño de objetos tiene que ver con el diseño detallado
de los objetos y sus interacciones.
• Se completa dentro de la arquitectura global, definida
durante el diseño del sistema y de acuerdo con las reglas y
protocolos de diseño aceptados.