5.resumen 1 4

ARQUITECTURA Y DISEÑO DE
SOFTWARE
Moisés López Bermúdez, Mg. Ing.Soft.

Unidad 1
FUNDAMENTOS DEL DISEÑO DE
SOFTWARE
Unidad 1
OBJETIVO
Conocer los conceptos y principios

aplicados al diseño de software
focalizando el modelo de negocio e
interacción con los requisitos de
usuario.
23/6/2020 19:21:32 3
Unidad 1
Tema 1
FUNDAMENTOS DEL DISEÑO DE
SOFTWARE
Tema 1
OBJETIVO
Conocer los fundamentos de diseño

de Software: conceptos generales,
procesos para diseñar y los principios
de diseño de software que se deben
aplicar.
23/6/2020 19:21:32 5
Tema1:Fundamentos de diseño
de Software
• Subtema 1: Conceptos generales de diseño
Subtema 2: El contexto del diseño de software
Subtema 3: Procesos de diseño de software
Subtema 4: Principios de diseño de software
23/6/2020 19:21:32 6
sobre este curso ...
¡Palabra!
Clave
23/6/2020 19:21:32 7
Entonces¿Qué es el diseño?
• ¿Arte?
• Ingenieria?
• Mezcla de ambos?
• Piensa por 15 segundos ...
23/6/2020 19:21:32 8
¿Es el diseño creativo como los
artistas?
"El diseño está dirigido a los seres

humanos. Diseñar es resolver
problemas humanos
identificándolos y ejecutando la
mejor solución."
Ivan Chermayeff
23/6/2020 19:21:32 9
¿Es el diseño lo que hacen los innovadores?
" En el vocabulario de la mayoría de las
personas, diseño significa barniz.
Es el interior decorando. Es el tejido de la

cortina del sofá. “Diseño es el alma
fundamental de una creación hecha por
el hombre que termina expresándose
en sucesivas capas externas del
producto o servicio."
El difunto Steve Jobs(Apple)
23/6/2020 19:21:32 10
¿Es el diseño lo que hacen los arquitectos?
Algunos arquitectos tienen una

noción preconcebida de lo que
debería ser un edificio: diseñan
desde el exterior como si el edificio
fuera una pieza de escultura.
Curtis W. Fentress
23/6/2020 19:21:32 http: //www.businesswire.com/ multimedia / home / 20090106005735 / de / 1739565 11

Software Diseño Perspectiva
"Hay dos formas de construir un

diseño de software:
• una es hacerla tan simple que
obviamente no haya deficiencias.
• la otra es hacerla tan complicada
que no haya deficiencias obvias.
El primer método es mucho más
difícil."
-CAR Hoare
23/6/2020 19:21:32 12
Aprendizaje Resultados:
1. trabajo en equipo
Trabajo de partes
interesadas del proyecto
de software, que incluye
clientes, usuarios y
desarrollores.
¡Evaluar la efectividad del

equipo!
23/6/2020 19:21:32 13
Los resultados del aprendizaje:
2. Problemas y soluciones
Reconocer las diferencias

entre problemas y
soluciones, y lidiar con
sus interacciones.
23/6/2020 19:21:32 http: //www.geekologie.com/ 2007/02 /rubiks_cube_for_the_lazy_perso.php 14

3. Métodos ágiles
¡Use métodos ágiles para

desarrollar un sistema
real para un cliente!
La posición de yoga del día - Kak Asana Desde

http://yogaanywhere.org/blog/2012/04/yoga-pose-of-the-day-kak-asana-crow-
posture-and-bak-asana-crane-pose/ /
23/6/2020 19:21:32 15
4. Orientado a objetos Diseño
Demostrar conceptos básicos

de diseño orientado a
objetos.
como:
» modelos de dominio.
» diagramas de clases,
» diagramas de interacción
(secuencia y comunicación).
23/6/2020 19:21:32 16
http: //enterprisegeeks.com/ blog / 2009/07 /
5. Fundamental Diseño
Principios, métodos, patrones

y estrategias de diseño
fundamentales en la creación
de un sistema de software y
sus documentos de respaldo.
http: //www.amazon.com/ Design-Patterns-Elements-Reusable-Object-Oriented /dp/ 0201633612

23/6/2020 19:21:32 17
6) Patrones
Identifique criterios
para el diseño de un
sistema de software y
seleccione
patrones, cree Primer uso de un freno de aire en
marcos y divida el competición - Mercedes-Benz 300
SLR en Le Mans, 1955. Desde http:
software //justacarguy.blogspot.com/2010/04/
air-brakes-were-first-deployed-at-
1955.html.
23/6/2020 19:21:32 18
Aprendizaje Resultados:
7) Análisis de diseño
Analizar y explicar la viabilidad y

solidez de un software.
23/6/2020 19:21:32 http: //en.wikipedia.org/ wiki /Archivo: Wrightfallingwater.jpg 19

Trabajo atrasado
• No tenemos días de retraso.
– Es como la industria: se entrega en la
fecha definida.
23/6/2020 19:21:32 20
"Deberes" Asignación
• Ver en el curso virtual aula moodle!
23/6/2020 19:21:32 32
Conceptos generales de diseño
Las palabras de uno de los metodólogos pioneros del diseño, J. Christopher Jones, tomado de su
trabajo clásico, Métodos de diseño: Semillas de futuros humanos ( Design Methods: Seeds of Human
Futures , Jones, 1970).
“El problema fundamental es que los diseñadores están obligados a utilizar la

información actual para predecir un estado futuro que no se producirá a menos
que sus predicciones sean correctas.
El resultado final del diseño debe ser asumido antes de que se puedan explorar los
medios para lograrlo''.
23/6/2020 19:21:32 22
La interacción entre la humanidad y el 'mundo' circundante ha
tomado históricamente dos caminos:
• El camino de Ciencias se ha preocupado por estudiar las cosas que existen, con la
observación y la experimentación como actividades clave. En su forma "clásica", el
enfoque científico es la resolución de problemas.
• El camino de Ingeniería ha estado mucho más preocupado por crear nuevo cosas,
siendo las actividades clave involucradas la de construcción y evaluación. estas
actividades se dirigen mucho más hacia el logro de un objetivo (un Producto).
23/6/2020 19:21:32 23
La naturaleza complementaria de las actividades científicas y de ingeniería
Esfuerzos humanos /
interacción con el
Camino de la ciencia mundo Camino de la ingeniería
Estudio de las cosas como son Fabricación de cosas 'nuevas' (pirámides,

(astronomía, biología, química, etc.) barcos, automóviles, teléfonos,
software,etc.)
Observación Construcción
Medición Evaluación
Experimentación Mejores herramientas
Mejor comprensión de los materiales. medida, etc.
23/6/2020 19:21:32 24
Diseño de ingeniería - Simple Definición
• "Diseño" especifica la estrategia

de "cómo" los requisitos serán
implementados.
• El diseño es a la vez un "Proceso"

y un "Artefacto"
23/6/2020 19:21:32 25
Donde hacer Diseños ¿Viene de?
• Intuición/Evolución
• Adopción
• Ingenieria
23/6/2020 19:21:32 26
"Diseño" es "codificación?"
si o no porque?
• Nuevamente, piense por 15 segundos ...
NO LO ES
23/6/2020 19:21:32 27
Diseño ¿Viene de?
• La tarea principal para el diseñador es especificar la

mejor solución a un problema.
• Producir una descripción(documentos, gráficos) de

cómo la solución estará organizada.
23/6/2020 19:21:32 28
Requisitos externos
UN MODELO DEL PROCESO DE DISEÑO
Especificación de requisitos
1 Aclarar la
naturaleza 2 Analice las
de los necesidades y
requisitos cree el modelo de
'caja negra' de
problema
Especificación funcional
4 Validar
Lista de desajustes solución
3 Postule una
(incluido el uso
solución de
de prototipos)
diseño de 'caja
blanca'
Modelo caja blanca
5 Implementación del
plan de diseño
utilizando un adecuado
23/6/2020 19:21:32 forma de software 29
MODELO DE PROCESO DE DISEÑO
• Formular una solución.

• Construir un modelo de la solución.
• Evaluar el modelo contra el requisito original
• Elaborar el modelo para producir una especificación
detallada de la solución.
23/6/2020 19:21:32 30
Los diseñadores de pirámides y catedrales casi seguramente habrán intercambiado
ideas con sus pares y aprendido de ellos, aunque solo con el surgimiento de prácticas de
ingeniería hubo nuevas entradas significativas para los procesos de aprendizaje del
diseñador como las siguientes:
1. El primero de ellos fue el conocimiento obtenido de la investigación científica.
2. El segundo fue el concepto de reutilizar. Una consecuencia de la revolución

industrial, fue la idea de 'estandarizar' los componentes..
Los canales de comunicación del diseñador
Es que un diseñador de software puede necesitar adquirir cierto grado de

"conocimiento de dominio" como parte rutinaria de la entrada necesaria para
emprender cualquier tarea de diseño en particular. El diseñador de software puede
necesitar responder a muchos canales de comunicación con otras personas.
• Especificación de requisitos
• Planes para la realización del diseño.
• Restricciones
• Conocimiento del dominio
23/6/2020 19:21:33 32
POR EJEMPLO
En un proyecto grande que emplea muchos programadores, los planes de diseño
necesitarán capturar una gama más amplia de factores que los que necesitará el
proyecto de una persona. Por lo general, dichos planes se ocuparán de describir:
▪ La estructura estática del sistema, incluidos los subprogramas que se

utilizarán y sus jerarquía.
▪ Cualquier objeto de datos para ser utilizado en el sistema.
▪ Los algoritmos a utilizar;
▪ Interacciones entre componentes.
23/6/2020 19:21:33 33
PROCESOS DE DISEÑO DE SOFTWARE
¿Qué es el software?
Se consideraba que el software abarcaba todas las formas relacionadas con la
generación de 'código binario ejecutable' destinado a la ejecución en una sola máquina.
De hecho, esta suposición estaba implícita en todas las primeras reflexiones sobre el
diseño de software.
La estructura de tales sistemas se fijó en gran medida cuando se compiló el código, por
lo tanto, las ideas de los diseñadores se dirigieron a producir una única unidad
monolítica de código binario.
23/6/2020 19:21:33 34
.
Propiedades del software como factores principales que afectan su desarrollo:
• Complejidad. Esto se ve como una propiedad esencial del software, en el que no dos partes son iguales
y un sistema puede poseer muchos estados durante la ejecución.
• Conformidad. Se espera que el software sea 'flexible' y se ajuste a los estándares impuesto por otros
componentes, como hardware, o por cuerpos externos, o por software existente.
• Posibilidad de cambiar. El software sufre una necesidad constante de cambio, en parte debido a la
aparente facilidad para hacer cambios (y técnicas relativamente pobres para costarlos).
• Invisibilidad. Debido a que el software es 'invisible', cualquier forma de representación que sea usado
para describirlo carecerá de cualquier forma de visual enlace que puede proporcionar una relación
fácilmente comprendida entre la representación y el sistema.
23/6/2020 19:21:33 35
La construcción de un modelo para una solución propuesta le permite al diseñador explorar
las limitaciones potenciales de la solución, así como evaluar su comportamiento y estructura.
Especificación de
requisitos
Descripción del
programa Proceso de
Decisiones del diseñador
diseño
Restricciones (recursos, organización,

experiencia, reutilización del software
existente
Cuando se desarrollan sistemas más grandes, el proceso de diseño puede dividirse en
dos fases distintas,
FASE 1: El diseñador desarrolla un modelo altamente abstracto de una solución (el diseño
'arquitectónico' o 'lógico') en el que solo se incluyen las propiedades (CAJA NEGRA)
FASE 2: Los "fragmentos" abstractos del problema que se identificaron en la primera fase
se asignan a unidades basadas en la tecnología (el diseño "detallado" o "físico"), por lo que
Se denomina caja blanca. El resultado de esta fase proporciona las especificaciones para
los programadores.
23/6/2020 19:21:33 37
LAS PRINCIPALES FASES DEL PROCESO DE DISEÑO DE SOFTWARE
Especificación Decisiones de
Detalles de
de requisitos diseño
diseño lógico
arquitectónico
Decisiones de
Detalles de
diseño
diseño físico
detalladas
23/6/2020 19:21:33 38
Restricciones sobre el proceso de diseño y el producto.
• Algunos pueden estar determinados por el entorno de

tiempo de entrega
• Cuando también se pretende que el sistema se construya

reutilizando los componentes de software existentes.
• La necesidad de ajustarse a un 'estilo arquitectónico'
particular de diseño, para ayudar en el mantenimiento futuro.
23/6/2020 19:21:33 39
ARQUITECTURA Y DISEÑO
DE SOFTWARE
Moisés López Bermúdez, Mg. Ing.Soft
Moisés López Bermúdez, Mg. Ing.Soft 1

Unidad 1
FUNDAMENTOS DEL DISEÑO
DE SOFTWARE
Tema 2: Cuestiones claves de diseño.

Tema 2: Conceptos claves de diseño
• Subtema 1: Concurrencia
• Subtema 2: Persistencia de datos
• Subtema 3: Control y manejo de eventos
• Subtema 4: Confiabilidad y seguridad

3
Diagnóstico…
❑Ingresar al siguiente test diagnóstico en con tu cuenta

institucional @unemi.edu.ec.
❑El contexto introductorio al tema

INTRODUCCIÓN
OBJETIVO
Aplicar los conceptos de
concurrencia, persistencia de datos,
manejo de errores y seguridad a un
proyecto de diseño de software
típico.

Subtema 1: Concurrencia
QUÉ ES CONCURRENCIA?
Un conjunto de computadoras independientes aparecen al usuario
como un solo sistema, a esto se denomina sistema distribuido.
Grandes procesos pueden ejecutarse al mismo tiempo en
computadoras independientes en red.
Dichos procesos pueden (pero no es necesario) comunicarse uno
con el otro durante su operación normal.

Concurrencia en Sistemas Distribuidos
Son impredecibles.
El tiempo de respuesta
depende de la carga
total del sistema, su
arquitectura y la carga
de la red.

A más de cumplir con los requerimientos funcionales, un programa
concurrente debe cumplir con ciertas propiedades adicionales:
Propiedad de exclusión mutua: mientras un proceso acceda a un recurso,

otros procesos deberán esperar a que sea liberado, para evitar conflictos.
Condición de sincronización: si un proceso necesita que ocurra un evento

para seguirse ejecutando, esta propiedad garantiza que el proceso no
continúe hasta que el evento no ocurra.
Interbloqueo: garantiza que no se produzca interbloqueo cuando todos los

procesos están esperando a un evento que nunca va a ocurrir

SUBTEMA 2: PERSISTENCIA DE DATOS
Se llama persistencia a la capacidad de guardar la

información de un programa para poder volver a utilizarla en
otro momento.

: PERSISTENCIA DE DATOS
Es la capacidad de un dato para seguir existiendo en memoria

tras determinadas operaciones, se los denomina variables en los
programas.
Los Sistemas Administradores de base de datos permiten que

los datos persistan fuera de la memoria y dan un gran apoyo
automático al manejo de Datos.

: PERSISTENCIA DE DATOS
Tenemos el modelo de datos relacional como el mas

utilizado en las bases de datos.
Las soluciones tecnológicas, que combinan sistemas de BI

tradicional con la opción del cloud computing se deben
considerar en los diseños para grandes manejos de datos.
Diseñar la arquitectura idónea para llevar a cabo procesos de

inteligencia empresarial (BI), que conviertan los datos
en información de valor para la organización.

Subtema 3: Control y manejo de eventos
Los sistemas distribuidos son más
complejos que los sistemas centralizados.
Esto los hace más difíciles de diseñar,
implementar y poner a prueba

: Control y manejo de eventos
Ventajas de Sistemas Distribuidos

Compartición de recursos .de hardware y software, como discos, impresoras, archivos y
compiladores en una red.
2. Apertura Los sistemas distribuidos. diseñados en torno a protocolos estándar que permiten la
combinación de equipo y software de diferentes proveedores.
3. Escalabilidad pueden aumentarse al agregar nuevos recursos para enfrentar nuevas demandas
del sistema.
4. Tolerancia a fallas La disponibilidad de muchas computadoras y el potencial de reproducir

información significa que los sistemas distribuidos pueden tolerar algunas fallas de hardware y
software
Tolerancia a fallas en el desarrollo
El sistema se diseña de modo que se detectan las fallas en el desarrollo o

el comportamiento inesperado del sistema en el tiempo de ejecución, y
se gestionan para que no ocurra una falla de sistema.
se usan por lo general cuando se requiere un nivel muy alto de

disponibilidad y fiabilidad del sistema.
Como resultado, las compañías de desarrollo de software aceptan que su

software siempre presentará algunas fallas residuales.
Aplicar técnicas para evitar, detectar y tolerar fallas en el desarrollo
conduce a una situación de bajo de rendimiento.
:Tolerancia a fallas en el desarrollo
Mecanismo que permitan al sistema permanecer operacional
después de que una falla en el desarrollo causó una falla en la
operación del sistema.
Esto significa que debe diseñarse para incluir componentes y

mecanismos redundantes, que permitan cambiar el control de un
componente a otro.
ejemplos de sistemas:
• los sistemas en las aeronaves, que deben estar en operación
durante todo el vuelo,

: Control y manejo de eventos
Por ejemplo cómo organizar datos Cómo manejar eventos

y el flujo de control
• mediante mecanismos como invocación
implícita.

Manejo De Errores Y Excepciones
Durante la ejecución de una rutina existen dos posibles respuestas ante una excepción:
Reintentar: se intenta cambiar las condiciones que llevaron a la rutina al estado de excepción,
y se ejecuta nuevamente desde el principio. Generalmente es la opción más adecuada que
permite que se rectifiquen los parámetros incorrectos y no paraliza la ejecución de la rutina
Falla: No se puede manejar la excepción. La ejecución de la rutina no se logró completar, y

termina en un estado de falla.

Subtema 4: Confiabilidad y seguridad
LA CONFIABILIDAD
• El término “confiabilidad” fue propuesto por Laprie (1995)

para cubrir los atributos relacionados con sistemas:
disponibilidad, fiabilidad, protección y seguridad.

20
Las fallas del sistema afectan a un gran número de
individuos, muchos sistemas incluyen funcionalidad
que se usa rara vez.´
La confiabilidad es Los usuarios rechazan a menudo los sistemas que

ahora más importante son poco fiables, carecen de protecciones o son
inseguros .
que su funcionalidad
por las siguientes Los costos por las fallas del sistema suelen ser
razones: enormes
Los sistemas no confiables pueden causar pérdida

de información y el costo por recuperarlos es muy
alto

21
Por lo tanto, al diseñar un sistema confiable se debe considerar:
Falla del hardware Falla en el desarrollo de Falla de operación

software
El hardware del sistema El software del sistema Los usuarios fallan al usar
puede fallar por errores puede fallar debido a o ejecutar el sistema
en su diseño errores en su correctamente.
especificación

Propiedades de confiabilidad
• No se puede expresar numéricamente la confiabilidad. En vez de ello,
se usan:

Además de las cuatro propiedades básicas de confiabilidad, también se
pueden considerar las siguientes:
Reparabilidad Mantenibilidad Tolerancia para el error
Las fallas del sistema son Mientras se usan los sistemas, Es parte de la usabilidad y refleja
inevitables; la falla podría surgen nuevos requerimientos y la medida en que el sistema se
minimizarse siempre que el es importante mantener diseñó de modo que se eviten y
sistema logre repararse funcionando pese a esos cambios toleren los errores de entrada de
rápidamente. usuario.

Por lo tanto, para desarrollar software confiable, es necesario
garantizar que:
Se evite la Se diseñen Se desarrollen Se configure

entrada de procesos de mecanismos de correctamente
errores verificación y protección el sistema
validación que contra ataques
sean efectivos

Disponibilidad y fiabilidad
• La disponibilidad y fiabilidad del sistema son propiedades

estrechamente relacionadas que se expresan también como
probabilidades numéricas.

La fiabilidad y disponibilidad del sistema pueden definirse de manera
más precisa como lo siguiente:
Disponibilidad es la
Fiabilidad es la probabilidad de que un
probabilidad de operación sistema, en un momento
libre de falla durante en el tiempo, sea
cierto tiempo, operativo y brinde los
servicios solicitados.

Las fallas en el desarrollo no siempre derivan en errores del sistema, y los errores del
sistema no necesariamente originan caídas del sistema. Las razones para esto son las
siguientes:
El sistema puede incluir

mecanismos de
detección de fallas y de
No todo el código en un Los errores son
protección, que
programa se ejecuta. transitorios.
aseguran que el
comportamiento
erróneo se descubra

Protección
• Los sistemas críticos para la protección son aquellos en los que resulta esencial
que la operación del sistema sea segura en todo momento; esto es, el sistema
nunca debe dañar a las personas o a su entorno, incluso cuando falle.

El control de hardware de los sistemas críticos para la protección es
más fácil de implementar y analizar que el control del software.
A pesar de ello, ahora se construyen sistemas de tal complejidad

que no pueden controlarse tan sólo con el hardware.
El control del software es esencial debido a la necesidad de

manejar gran cantidad de sensores y actuadores con leyes de
control complejas.

El software crítico para la protección se divide en dos
clases:
Software primario Software secundario

crítico para la crítico para la
protección protección
• Éste es software • Es un software que

embebido que sirve podría repercutir
como controlador indirectamente.
en un sistema.

Hay cuatro razones por las que los sistemas de software que son fiables no
necesariamente son seguros:
Nunca se puede
tener una total
La especificación
certeza de que
podría estar
un sistema de
incompleta
software esté
libre de fallas
El mal
Los operadores
funcionamiento
del sistema
del hardware
pueden generar
origina que el
entradas que no
sistema se
son
comporte de
individualmente
forma
incorrectas,
impredecible
SEGURIDAD
• La seguridad es un atributo del sistema
que refleja la habilidad de éste para
protegerse a sí mismo de ataques
externos, que podrían ser accidentales
o deliberados.
• Estos ataques externos son posibles
puesto que la mayoría de las
computadoras de propósito general
ahora están en red y, en consecuencia,
son accesibles a personas externas.

En cualquier sistema en red, existen tres principales tipos de amenazas a
la seguridad:
Amenazas a la confidencialidad Amenazas a la disponibilidad

del sistema y sus datos. Amenazas a la integridad del
del sistema y sus datos, dichas
sistema y sus datos tales
difundir información a individuos amenazas pueden restringir el
amenazas pueden dañar o
o programas que no están acceso al software o sus datos a
corromper el software o sus
autorizados. usuarios autorizados
datos.

Los controles que se deben implementar para mejorar la
seguridad del sistema son comparables con los de la fiabilidad y
protección:
Evitar la Detectar y Limitar la

vulnerabilidad neutralizar ataques exposición y
controles cuya controles cuya recuperación
intención sea intención sea controles que
garantizar que los detectar y repeler soportan la
ataques no tengan ataques.. recuperación de los
éxito. problemas.
BIBLIOGRAFÍA
• Ian Somerville (2011). Pág. 479-485; Gomma (2016).
Pág. 53
• Brookshear (2005). Pág. 391-441
• Ian Somerville (2011). Pág. 479-484
• Swebok v3 (2014). Pág. 53
• Ian Somerville (2011). Pág. 289-340

DE SOFTWARE
Moisés López Bermúdez, Mg. Ing.Soft 30/6/2020 11:06

Unidad 1
DE SOFTWARE
Tema 3: Principios de diseño.

30/6/2020 11:06
Tema 3: Principios de diseño
• Subtema 1: Abstracción
• Subtema 2: Descomposición, encapsulamiento
(Ocultación de información).
• Subtema 3: Cohesión y acoplamiento (Modulos)
Moisés López Bermúdez, Mg. Ing.Soft 30/6/2020 11:06 3

OBJETIVO DEL TEMA
Explicar los principios del diseño
de software basados en los
principios de abstracción,
ocultación y acoplamiento.

Diagnóstico…El diseño ¿Qué es?
El objetivo del diseño es producir un modelo o

representación que tenga resistencia, funcionalidad y
belleza. Para lograrlo, debe practicarse la
diversificación(alternativas).
Se está con un pie en dos mundos —el mundo de la tecnología
y el de las personas
❑ !

El diseño ¿Qué es?
. Es el lugar en el que las reglas de la creatividad, los requerimientos de
los participantes, las necesidades del negocio y las consideraciones
técnicas, se unen para formular un producto o sistema.
• El diseño crea una representación o modelo del software, pero, a

diferencia del modelo de los requerimientos que se centra en
describir los datos que se necesitan, la función y el comportamiento.
• El diseño proporciona detalles sobre la arquitectura del software,
estructuras de datos, interfaces y componentes que se necesitan para
implementar el sistema.
Análisis versus diseño
• Análisis Classes/
Objects
• Investigación del problema.
y requisitos, más bien
que una solución
Operatio
Patterns O-O Design ns/Meth
• Diseño ods
• UNA solución conceptual,

en lugar de su implementación
• Excluye detalles de bajo nivel.
Data/Att
ributes

¿Cuáles son los pasos?
• El diseño representa al software de varias maneras:
1. representarse la arquitectura del sistema o producto( D. alto).
2. Después se modelan las interfaces que conectan al software con los
usuarios finales, con otros sistemas y dispositivos, y con sus propios
componentes constitutivos(D intermedio)
3. Por último, se diseñan los componentes del software que se utilizan
para construir el sistema(D. Bajo).
• Cada una de estas perspectivas representa una acción de diseño distinta,

pero todas deben apegarse a conceptos de diseño que guíe el trabajo.
Elaboración y Refinamiento ...
• Empezando con Requisitos

Resumenes(Abstracto)
• Elaborarlos y perfeccionarlos
sucesivamente en especificaciones
técnicas, modelos y, finalmente,
implementación

Como se indicó, el diseño organiza tareas para su
implementación.
Entonces, ¿Qué hace que el software

se diseñe diferente a otras disciplinas de ingeniería?
• piense por 15 segundos ...

Los principios básicos de diseño hacen posible que el
ingeniero del software navegue por el proceso de diseño:
Un buen diseñador deberá

deberá poderse rastrear hasta
tener en cuenta enfoques
el modelo de análisis
alternativos
El diseño deberá minimizar la

distancia intelectual entre el deberá presentar uniformidad e
software y el problema, como si integración
de misma vida real se tratara

El diseño no es escribir
deberá estructurarse para
código y escribir código no
admitir cambios
es diseñar
deberá evaluarse en función

El diseño deberá revisarse
de la calidad mientras que se
para minimizar los errores
va creando, no después de
conceptuales (semánticos)
terminarlo

Subtema 1: Abstracción
Es un proceso mediante el cual se identifican los aspectos relevantes

de un problema ignorando los detalles
Un cliente de un módulo no necesita saber más de lo que está en la

interfaz.

Existen diferentes niveles de abstracción:
Alto Inferior Bajo
La solución se pone como Se toma una orientación Se establece la solución

una medida extensa, más procedimental para poder
empleando el lenguaje implementarse
entorno al problema directamente

Tipos de abstracción
Abstracción Abstracción Abstracción

de datos procedimental de control
Secuencia
Colección • Mecanismo de
identificada de
identificada de control de
instrucciones que
datos que programa sin
tiene una función
describe un especificar los
especificada y
objeto de datos datos internos
limitada.

Descomposición:
Especialización
Principio de separación de una
Forma común de la herencia,
abstracción en sus componentes
donde el objeto derivado tiene
propiedades más precisas que el
objeto base Principios
de
abstracción
Individualización:
Instanciación: • El agrupamiento de objetos
Es el proceso de crear instancias similares para propósitos
de una clase. comunes
• Un objeto de una clase dada
tiene un propósito o rol dado

SUBTEMA 2: DESCOMPOSICIÓN, ENCAPSULAMIENTO
(OCULTACIÓN DE INFORMACIÓN)
Descomposición
Descomponer un software en diversas unidades más
pequeñas, con el fin de situar diferentes
funcionalidades en diferentes componentes.
Encapsulamiento
El grado de encapsulación de un componente viene definido
por la forma en el que el componente oculta la información
innecesaria y la lógica de lo que hace al resto de componentes
del sistema.

Supongamos un diseño en el que la clase X está bien encapsulado.
2
Por otro lado, si hacemos que la
funcionalidad de la clase X se
base en la implementación de
interfaces, los componentes que
necesiten usar X se referirán a
ella por sus interfaces y no por la
clase en sí
1
El hecho de ocultar la lógica hacia el
exterior hace que podamos cambiar
la implementación interna sin que
afecte al resto de clases del diseño.

Los módulos se caracterizan por las
decisiones de diseño que (cada uno) oculta
al resto
Ocultación El ocultamiento de la información es un

de buen medio para conseguir abstracción
información
Con la información oculta, la información
que podría cambiar potencialmente se
encapsula dentro un objeto.

Subtema 3: Cohesión y acoplamiento
La cohesión
• La cohesión es la medida de la relación funcional de los
elementos de un módulo.
• A mayor cohesión, mejor: el módulo en cuestión será más
sencillo de diseñar, programar, probar y mantener.

Niveles de cohesión :
Mayor Cohesión
Funcional Caja Negra
Secuencial
Comunicacional
Procedural Caja Gris

Temporal
Lógica
Coincidental o casual Peor Cohesión Caja Transparente

Funcional Devuelve un resultado sin efectos colaterales
Secuencial La salida de una tarea sirve como entrada de la siguiente
Todos los módulos que manipulan ciertos datos se mantienen

Comunicacional unidos y el resto se excluye
Procedural composición de partes de funcionalidad que se organizan

secuencialmente pero tienen poca relación entre sí
Temporal Actividades diferentes relacionadas por el tiempo
Actividades con la misma categoría General que se seleccionan
Lógica fuera del módulo
Casual Actividades diferentes sin relaciones significativas entre ellas

Acoplamiento
• El acoplamiento mide el grado de relacionamiento de un

módulo con los demás.
• A menor acoplamiento, mejor: el módulo en cuestión será
más sencillo de diseñar, programar, probar y mantener.

Niveles de Acoplamiento :
Mejor
Normal
- acoplado Bajo
De Datos
Por Estampados
De control
Débil
Externo
Común
Peor Alto
Contenido
+ acoplado

Mejor acoplamiento
Dos módulos A y B están normalmente

acoplados sí: un módulo A llama a otro B, y
B retorna el control a A
Acoplamiento normal
Dos módulos están acoplados normalmente
cuando no se pasan ningún parámetro
entre ellos, sólo existe la llamada de uno a
otro

Todas las E/S al y
Cada parámetro es desde el módulo
una unidad llamado son
elemental de datos argumentos de datos
y no de control
Los módulos se
Reducir el número de
comunican mediante
parámetros
parámetros
Acoplamiento
de datos

Acoplamiento por estampado
Dos módulos están acoplados por estampado si ambos

hacen referencia a la misma estructura de datos
No estructura de datos global
No es deseable si el módulo que recibe esa estructura de

datos, necesita sólo parte de los elementos que se le pasan

Niveles moderados se caracterizan por el paso de control entre
módulos
Paso de parámetros de
control entre módulos
Influencia de un módulo
Acoplamiento de control
en la ejecución de otro
Una variable controla las

decisiones en un módulo
superior o subordinado

Acoplamiento externo
• Los módulos están ligados a un

entorno externo al software.
• Por ejemplo la E/S acopla un
módulo a dispositivos, formatos
y protocolos de comunicación.
• Este acoplamiento es esencial
pero deberá estar limitado a
unos pocos módulos

Niveles altos de acoplamiento
Los módulos acceden a datos en un área de datos

global (un área de memoria accesible por ejemplo).
Comparten una estructura de datos global
Viola los principios básicos de encapsulamiento y

Acoplamiento modularidad
Común
El diagnostico de problemas en estructuras con

acoplamiento común es costoso en tiempo y difícil
de realizar

Acoplamiento de contenido
Se da cuando un módulo
hace uso de datos o de
Un módulo modifica
información de control Un módulo utiliza una
algún elemento en el
mantenidos dentro de variable local del otro
otro módulo
los límites de otro
módulo
Desde un módulo se
salta a otro, pero la
Dos módulos comparten
sentencia a la que se
los mismos contenidos
pasa no está definida
como punto de entrada

Cohesión y acoplamiento son criterios inversamente relacionados

BIBLIOGRAFÍA
• Using UML-Engineering with Objetcs and Components (2006). Pág. 7, 12;
• Gomma (2016). Pág. 48
• Pressman, R. S. (2011). Pág. 230

DE SOFTWARE

3/7/2020 7:53 1
Unidad 1
DE SOFTWARE
Tema 4: Interacción entre diseño y requerimientos

3/7/2020 7:53
Tema 4: Interacción entre diseño y requerimientos
• Subtema 1: Análisis del modelo de negocio

• Subtema 2: Obtención de requisitos
• Subtema 3: Requisitos, análisis y diseño
• Subtema 4: Interfaz gráfica (GUI, prototipo, arquitectura )

03/07/2020 08:19 a. m.
Diagnóstico…
❑Ingresar al siguiente test diagnóstico en con tu cuenta

institucional @unemi.edu.ec.
❑El contexto introductorio al proceso de ingeniería de
software, lea detenidamente y responda las preguntas...

INTRODUCCIÓN
OBJETIVO
Entender la relación y transición
entre la etapa de requerimiento
hacia el diseño y arquitectura de
software.

Subtema 1: Análisis del modelo de negocio
Durante el proceso de modelado del negocio, se examina

la estructura de la organización y se observan los roles en
la compañía y como estos se relacionan.
Modelo del Negocio Se examina el flujo de trabajo de la organización, los

procesos principales dentro de la compañía y como
ellos trabajan.
Además, se deben examinar las entidades externas,

Modelo de Casos Modelo de cualquier individuo u otras compañías, y como
de Uso del Objetos del interactúan con el negocio, y observar las implicaciones
Negocio Negocio de esas interacciones.

La importancia que tiene al elaborar un modelo de negocios, es el
siguiente:
Maneja información que le pertenece al negocio.
Será utilizado en organizaciones que ejecutan procesos del

negocio cada vez más automatizable.
Se adaptará al entorno de la organización que lo usará.
Para identificar con facilidad donde están los problemas y

oportunidades de crecimiento y mejora.

03/07/2020 08:19 a. m. 7
Conceptos fundamentales de modelo de negocios
Proceso
• Conjunto de actividades que emplean un insumo
• Agregan valor
Proceso de negocio
• Grupo de tareas o actividades
• Ofrecen resultados de interés a alguien
Área Funcional
• Grupo de trabajo
Objetivos
• Comprende la dinámica de la función objetivo
• Obtiene de forma preliminar los requerimientos del sistema

¿Qué muestra el modelo del negocio?
Dos modelos del negocio

Proceso del Estructura
Clientes
negocio organizacional
Modelo de casos De
uso del negocio
Roles y Entregables
Productos
responsabilidades internos
Modelo de
Eventos Objetos del negocio
03/07/2020 08:19 a. m. 9
SUBTEMA 2: OBTENCIÓN DE REQUISITOS
✓ Tiene como objetivos buscar, investigar y ayudar a los

clientes y usuarios a documentar sus necesidades
✓ La documentación de los requisitos deberá hacerse
siempre usando el vocabulario de clientes y usuarios, de
forma que estos puedan entenderlos, siendo lo más
habitual emplear lenguaje natural

10
Técnicas de Requisitos
Entrevistas Desarrollo Desarrollo de Observación Estudio de Cuestionarios

Conjunto de prototipos documentaci
Aplicaciones ón
( JAD )
Tormenta de Puntos de Escenarios Casos de uso Etnografía

ideas vista

Entrevista
Se puede definir como un “intento

sistemático de recoger información de otra
persona” a través de una comunicación
interpersonal que se lleva a cabo por medio
de una conversación estructurada.

Desarrollo Conjunto de Aplicaciones ( JAD )
• Se utiliza para promover la cooperación y el trabajo en equipo entre
usuarios y analistas.
Se comienza con un
documento de trabajo y Al final del JAD
se discute
Doc. De requisito es
aprobado

03/07/2020 08:19 a. m. 13
Las razones para usar JAD son las siguientes:
Reducir tiempo
Reducir costo
Mejora la calidad de los resultados
Genera la mayor identificación del

usuario

03/07/2020 08:19 a. m. 14
Desarrollo de Prototipos
• Los prototipos suelen consistir en

versiones reducidas, demos o
conjuntos de pantallas (que no son
totalmente operativos) de la
aplicación pedida.

03/07/2020 08:19 a. m. 15
Esta técnica es particularmente útil cuando:
El área de la
Es necesario evaluar
aplicación no está El costo del rechazo
previamente el
bien definida de la aplicación por
impacto del sistema
(posiblemente por los usuarios es muy
en los usuarios y en
ser algo muy alto.
la organización.
novedoso).

03/07/2020 08:19 a. m. 16
Observación
Por medio de esta técnica el analista

obtiene información de primera mano
sobre la forma en que se efectúan las
actividades.
Este método permite observar la forma

en que se llevan a cabo los procesos y,
por otro, verificar que realmente se
sigan todos los pasos especificados.

03/07/2020 08:19 a. m. 17
Estudio de documentación
Varios tipos de documentación, como manuales y reportes, pueden proporcionar al analista

información valiosa con respecto a las organizaciones y a sus operaciones.
La documentación difícilmente refleja la forma en que realmente se desarrollan las actividades, o

donde se encuentra el poder de la toma de decisiones. Sin embargo, puede ser de gran importancia
para introducir al analista al dominio de operación y el vocabulario que utiliza.

03/07/2020 08:19 a. m. 18
Permite a los analistas reunir información
proveniente de un grupo grande de personas.
Proporcionan datos más confiables que otras

técnicas
CUESTIONARIO
Al igual que con las entrevistas, se debe
seleccionar a los encuestados.
El analista debe asegurar que el conocimiento y

experiencia de éstos califiquen para dar
respuestas a las preguntas.

03/07/2020 08:19 a. m. 19
Tormenta de ideas ( Brainstorming )
Consiste en reuniones con cuatro a diez personas
donde como primer paso sugieren toda clase de ideas
sin juzgar su validez y después de recopilar todas las
ideas se realiza un análisis detallado de cada
propuesta.
Esta técnica se puede utilizar para identificar un

primer conjunto de requisitos en aquellos casos
donde no están muy claras las necesidades que hay
que cubrir.

Puntos de Vista
Los métodos orientados a puntos de vista (viewpoints)

toman en consideración estas perspectivas diferentes y
las utilizan para estructurar y organizar tanto el proceso
de obtención, como los requerimientos mismos.
Uno de estos métodos es el método VORD

(Definición de Requerimientos Orientado a
Puntos de Vista), el cual provee un marco de
trabajo orientado para la obtención y
documentación de requerimientos.

03/07/2020 08:19 a. m. 21
Identificación de puntos Estructuración de
puntos de vista:
de vista
• Comprende agrupar los
Implica descubrir los que reciben relacionados en una jerarquía.
los servicios del sistema e
identificar los servicios específicos Las etapas • Los servicios comunes se
que se suministran a cada punto ubican en los niveles altos de la
de vista. principales jerarquía y se heredan los
puntos de vista de bajo nivel.
del punto
Trazado del punto de de vista Documentación de
vista del sistema: puntos de vista:
comprende identificar los objetos Comprende refinar la
en un diseño orientado a objetos descripción de éstos y los
utilizando la información del servicios identificados.
servicio encapsulado en los puntos
de vista

03/07/2020 08:19 a. m. 22
Escenarios
Estos se utilizan para documentar el

comportamiento del sistema cuando se le presentan
eventos específicos.
Los escenarios de eventos incluyen una descripción

del flujo de datos y las acciones del sistema,
documenta las excepciones que puedan surgir.

03/07/2020 08:19 a. m. 23
Las convenciones para los diagramas utilizados en los
escenarios de eventos son:
Las entradas y salidas de Las salidas de datos se

Los datos proporcionados
la información de control ubican a la derecha de
desde un punto de vista
se ubican en la parte cada recuadro. Si no están
se representan como
superior de cada encerradas, significa que
elipses.
recuadro. pertenecen al sistema.
Las excepciones se
El nombre del siguiente
muestran en la parte
evento esperado después
inferior del recuadro. Si
de completar el escenario
existen varias excepciones
se muestra en un
posibles, éstas se
recuadro sombreado.
encierran en un recuadro.

03/07/2020 08:19 a. m. 24
Casos de uso
sistemas
• Los casos de uso describen
interacciones entre los usuarios y el
sistema, enfatizando en lo que el personas hardware
usuario necesita del sistema.
• En un modelo de caso de uso se puede
Los actores
identificar a un conjunto de actores pueden tener las
involucrados y su relación con varios siguientes
casos de uso. representaciones:

03/07/2020 08:19 a. m. 25
Etnografía
técnica de observación que se puede utilizar para entender los
requerimientos sociales y organizacionales.
Los requerimientos que se derivan
de la forma en la que la gente
trabaja realmente más que de la
forma en la que las definiciones
de los procesos establecen que
La etnografía es especialmente debería trabajar.
efectiva para descubrir dos tipos
de requerimientos:
se derivan de la cooperación y
conocimiento de las actividades
de la gente.

03/07/2020 08:19 a. m. 26
Subtema 3: Requisitos, análisis y diseño
El modelado de requisitos
Aborda el desarrollo de los requisitos funcionales y no funcionales del sistema.
COMET diferencia el análisis del diseño de la siguiente manera:
análisis diseño
• está rompiendo • es sintetizar o

o componer
descomponiendo (armar) la
solución
el problema

Actividades en modelado de requisito
En el modelo de
requisitos, el sistema se
considera como una caja
negra.
Se desarrolla el modelo
de caso de uso.

Modelado de casos de uso.
Definir actores y casos de uso de caja negra.
Los requisitos funcionales del sistema se describen en términos de

casos de uso y actores.
Las descripciones de casos de uso son una vista de comportamiento;

Las relaciones entre los casos de uso dan una visión estructural

Casos de Uso
Describe un sistema desde sus

distintas formas de utilización.
Cada caso de uso debe ser guiado por
el usuario de manera secuencial por
eventos

03/07/2020 08:19 a. m. 30
SISTEMA DE
Ejemplo: BIBLIOTECA
Prestar libro
Actualizar
Catálogo
Usuario
Bibliotecario
Devolver libro

03/07/2020 08:19 a. m. 31
Ejemplo
Sist. Punto de Venta
Actor Caso de uso
Cajero Log in Dar vuelto Comprar producto
Cajero Log In
Cliente
Cliente Comprar productos
Paga productos Pagar producto
Gerente Iniciar Terminar

Inicializar
Sistema administrador Agregar nuevos usuarios Gerente

Terminar
Sist. Adm.
Agregar usuarios

03/07/2020 08:19 a. m. 32
Actividades en modelado de análisis
En el modelo de análisis, el énfasis está en entender el

problema; por lo tanto:
se debe identificar los

objetos del dominio problemas como si el si el mensaje enviado
del problema y la objeto es activo o es asíncrono o
información que se pasivo, síncrono,
pasa entre ellos.

Las actividades son las siguientes:
Modelado de
Estructuración de
Modelado estático. interacción
objetos.
dinámica.
Modelo de
máquina de estado
dinámico yo ng.

Modelado estático.
Definir el modelo estático específico del problema,
Las clases se definen en términos de sus atributos, así como de su

relación con otras clases.
Las operaciones se definen en el modelo de diseño.
Para los sistemas de uso intensivo de información, esta vista es de

gran importancia.

03/07/2020 08:19 a. m. 36
Estructuración de objetos.
• Determine los objetos que participan en cada caso de uso.
• Se proporcionan criterios de estructuración de objetos para ayudar a determinar
los objetos de software en el sistema
objetos de objetos de
entidad límite
estos pueden ser:
objetos lógicos objetos de

de aplicación. control

Modelado de interacción dinámica.
Los diagramas de
secuencia se
desarrollan para
Los casos de uso se mostrar cómo los
realizan para mostrar objetos se comunican
la interacción entre entre sí para ejecutar
los objetos que el caso de uso
participan en cada
caso de uso.

03/07/2020 08:19 a. m. 38
Modelo de máquina de estado dinámico young.
La vista del sistema dependiente del estado se define

mediante Modelo de máquina de estado dinámico young.
La vista del sistema dependiente del estado se define

mediante diagramas de estado jerárquicos.
Cada objeto dependiente del estado se define en

términos de su diagrama de estado constituyente.
El diseño de máquinas de estado finito y gráficos de

estado

03/07/2020 08:19 a. m. 39
Actividades en modelado de diseño
• En el modelo de diseño, se considera el

dominio de la solución.
• Durante esta fase, el modelo de análisis
se asigna a un modelo de diseño
concurrente

03/07/2020 08:19 a. m. 40
Las actividades son las siguientes:
Integrar el modelo de comunicación de objetos.
Tomar decisiones sobre la estructura del subsistema y las

interfaces.
Tome decisiones sobre interfaces de clase
Tome decisiones sobre cómo estructurar la aplicación distribuida

en subsistemas distribuidos,
Tome decisiones sobre las características de los objetos,

particularmente si son activos o pasivos.

03/07/2020 08:19 a. m. 41
Subtema 4: Interfaz gráfica (GUI, prototipo, arquitectura )
Las interfaces son los puntos de contacto que establecen un

contrato que permite el intercambio de información entre
elementos que forman parte de la arquitectura de un sistema
de software.

Interfaz grafica de usuario
También conocida como GUI (Graphical

User Interface), es un programa que hace intermediario
las veces de intermediario entre usuario y
máquina.

Características de las Interfaces gráficas de usuario (GUI)
Ventanas:
• Ventanas múltiples permiten que se despliegue
simultáneamente información diversa en la pantalla del
usuario.
Iconos:
• Representan diferentes tipos de información, por ejemplo
archivos, procesos ,etc.
Menús:
• Los comandos se seleccionan de un menú en lugar de
teclearse en un lenguaje de ordenes.

03/07/2020 08:19 a. m. 44
Apuntador:
• Para seleccionar opciones de un menú o para indicar
elementos de interés en una ventana , se utiliza un
dispositivo apuntador , como el ratón.
Gráficos:
• Los elementos gráficos se pueden mezclar con texto en el
mismo despliegue.

03/07/2020 08:19 a. m. 45
Proceso de Diseño de la GUI
Analizar y comprender Producir un

las actividades del prototipo de
Evaluar el diseño con los
usuario diseño en
usuarios finales
papel
Diseñar el Producir el
prototipo prototipo del diseño Evaluar el diseño con los
dinámico usuarios finales
Prototipo Implementar la interfaz del

ejecutable
usuario final

3/7/2020 7:53 46
BIBLIOGRAFÍA
• Gomma (2016). Pág. 65
• Pressman (2010). Pág. 265

03/07/2020 08:19 a. m.

5.resumen 1 4

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

5.resumen 1 4

Cargado por

Copyright:

Formatos disponibles

ARQUITECTURA Y DISEÑO DE

Moisés López Bermúdez, Mg. Ing.Soft.

Conocer los conceptos y principios

Conocer los fundamentos de diseño

• Piensa por 15 segundos ...

"El diseño está dirigido a los seres

Es el interior decorando. Es el tejido de la

Algunos arquitectos tienen una

23/6/2020 19:21:32 http: //www.businesswire.com/ multimedia / home / 20090106005735 / de / 1739565 11

"Hay dos formas de construir un

¡Evaluar la efectividad del

Reconocer las diferencias

23/6/2020 19:21:32 http: //www.geekologie.com/ 2007/02 /rubiks_cube_for_the_lazy_perso.php 14

¡Use métodos ágiles para

La posición de yoga del día - Kak Asana Desde

Demostrar conceptos básicos

Principios, métodos, patrones

http: //www.amazon.com/ Design-Patterns-Elements-Reusable-Object-Oriented /dp/ 0201633612

Analizar y explicar la viabilidad y

23/6/2020 19:21:32 http: //en.wikipedia.org/ wiki /Archivo: Wrightfallingwater.jpg 19

• Ver en el curso virtual aula moodle!

“El problema fundamental es que los diseñadores están obligados a utilizar la

Estudio de las cosas como son Fabricación de cosas 'nuevas' (pirámides,

Mejor comprensión de los materiales. medida, etc.

• "Diseño" especifica la estrategia

• El diseño es a la vez un "Proceso"

• Nuevamente, piense por 15 segundos ...

• La tarea principal para el diseñador es especificar la

• Producir una descripción(documentos, gráficos) de

• Formular una solución.

1. El primero de ellos fue el conocimiento obtenido de la investigación científica.

2. El segundo fue el concepto de reutilizar. Una consecuencia de la revolución

Es que un diseñador de software puede necesitar adquirir cierto grado de

▪ La estructura estática del sistema, incluidos los subprogramas que se

▪ Cualquier objeto de datos para ser utilizado en el sistema.

▪ Los algoritmos a utilizar;

▪ Interacciones entre componentes.

Propiedades del software como factores principales que afectan su desarrollo:

Restricciones (recursos, organización,

• Algunos pueden estar determinados por el entorno de

• Cuando también se pretende que el sistema se construya

Moisés López Bermúdez, Mg. Ing.Soft

Moisés López Bermúdez, Mg. Ing.Soft 1

Tema 2: Cuestiones claves de diseño.

Moisés López Bermúdez, Mg. Ing.Soft 2

Moisés López Bermúdez, Mg. Ing.Soft

❑Ingresar al siguiente test diagnóstico en con tu cuenta

Moisés López Bermúdez, Mg. Ing.Soft 4

Moisés López Bermúdez, Mg. Ing.Soft 5

Moisés López Bermúdez, Mg. Ing.Soft

Moisés López Bermúdez, Mg. Ing.Soft

Propiedad de exclusión mutua: mientras un proceso acceda a un recurso,

Condición de sincronización: si un proceso necesita que ocurra un evento

Interbloqueo: garantiza que no se produzca interbloqueo cuando todos los

Moisés López Bermúdez, Mg. Ing.Soft 8

Se llama persistencia a la capacidad de guardar la

Moisés López Bermúdez, Mg. Ing.Soft 9

Es la capacidad de un dato para seguir existiendo en memoria

Los Sistemas Administradores de base de datos permiten que

Moisés López Bermúdez, Mg. Ing.Soft

Tenemos el modelo de datos relacional como el mas

Las soluciones tecnológicas, que combinan sistemas de BI

Diseñar la arquitectura idónea para llevar a cabo procesos de