DISEÑO DE MÓDULOS,

COMPONENTES Y DATOS DE
SOFTWARE
Training CENEVAL Marzo 2023 – Luis Armando Villa
Ceballos
DISEÑO DE
MODULOS
 DISEÑO EN EL
NIVEL DE
COMPONENTES
 ¿Qué es un componente?
■ Un componente es un bloque de construcción de software.
La Especificación UML define un componente como: “Es
una parte modular, desplegable y sustituible de un sistema,
que incluye la implantación y expone un conjunto de
interfaces”. Los componentes juegan un papel importante
en el éxito del sistema que se va a construir. Los
componentes se encuentran en la arquitectura del software,
deben comunicarse y colaborar con otro componentes y
con entidades.
 ¿Qué es el diseño a nivel de
componentes?
■ El diseño en el nivel de componentes define las estructuras de
datos, algoritmos y mecanismos de comunicación asignados a
cada componente del software. Antes de elaborar el software,
tenemos que ser capaces de determinar si funcionará.
■ Se busca garantizar la corrección y la consistencia con otras
representaciones del diseño.
■ Esto proporciona un medio para evaluar si funcionarán las
estructuras de datos, interfaces y algoritmos.
■ El Diseño a Nivel de Componentes, llamado también Diseño
Procedimental, tiene lugar después de haber establecido los
Diseños de Datos, Interfaces y Arquitectura.
■ El objetivo es convertir el Modelo de Diseño en un Software
Operacional.
■ Sin embargo, el nivel de abstracción del Modelo de Diseño
existente es relativamente alto y el nivel de abstracción del
Software Operacional es bajo.
■ Cuando el modelo de diseño se convierte en código fuente,
deberá seguirse una serie de principios que lleven a cabo una
conversión que <<no introduzca errores desde el principio».
■ Este diseño consiste en convertir el diseño de datos,
interfaces y arquitectura en un software operacional.
■ Para poderlo llevar a cabo, el diseño se deberá
representar a un nivel de abstracción cercano a un
código.
■ El diseño a nivel de componentes establece los datos
algorítmicos que se requieren para manipular las
estructuras de datos, efectuar la comunicación entre los
componentes del software por medio de las interfaces.
■ ¿Quién lo hace? Un ingeniero del software.
 ¿Por qué es importante?
■ Para determinar si el programa funcionará antes de
construirlo.
■ El diseño a nivel de componentes representa el software
que permite revisar los datos del diseño para su
corrección y consistencia con las representaciones de
diseño anteriores (diseño de datos, interfaces y
arquitectura).
■ Con este diseño se proporciona un medio de evaluar el
funcionamiento de las estructuras de datos, interfaces y
algoritmos.
¿Cuáles son los pasos para elaborarlo?

■ Las representaciones de los diseños de datos, arquitectura

e interfaces forman la base del diseño a nivel de
componentes.
■ Para representar este diseño se utilizan las notaciones
gráficas, tabulares y basadas en texto.
¿Cuál es el producto obtenido?

■ El diseño procedimental de cada componente representado

en forma de notación gráfica, tabular o basada en texto es
el primer producto durante el diseño a nivel de
componentes.
¿Cómo puedo estar seguro de que lo he
hecho correctamente?
■ Mediante una revisión estructurada y una inspección.
■ El examen del diseño se realiza para determinar si las
estructuras de los datos, las secuencias del proceso y las
condiciones lógicas son correctas.
■ Mediante la utilización de un lenguaje de programación
es posible representar el diseño a nivel de componentes.
■ En esencia, el programa se crea empleando como guía el
modelo de diseño.
■ También se puede representar utilizando algo que se pueda
transformar fácilmente en código fuente.
■ Independientemente del mecanismo que se utilice para
representar el diseño a nivel de componentes, la definición
de las estructuras de datos, interfaces y algoritmos deberán
ajustarse a las líneas generales del diseño procedimental
establecidas.
 Visión Orientada a Objetos
■ Un componente contiene un conjunto de clases que
colaboran.
■ Cada clase dentro de un componente se elabora por
completo para que incluya todos los atributos y
operaciones relevantes para su implantación.
■ También deben definirse todas las interfaces que permiten
que las clases se comuniquen y colaboren.
■ Para lograr esto, se elaboran clases de análisis y clases de
infraestructura.
 Módulos

■ Se conoce como módulo a una estructura o bloque de

piezas que, en una construcción, se ubican a fin de hacerla
más sencilla. Estos tienen tres funciones importantes:
1. Coordina la invocación de los componentes del dominio
del problema.
2. Implanta una necesidad que requiere el cliente.
3. Es responsable de las funciones que dan apoyo al
procesamiento requerido en el dominio del problema.
■ También llamados módulos, estos provienen del
modelo de análisis y contine tres funciones
importantes:
1) Componentes de control: coordina la invocación de
todos los demás componentes.
2) Componentes del dominio del problema: implanta
una función completa o parcial que requiere el cliente
3) Componente de infraestructura: responsable de las
funciones que dan apoyo al procesamiento requerido.
 Ejemplo: Sistema de Imprenta
■ Considere un software que debe elaborarse para una imprenta.
El objetivo es obtener los requerimientos que plantea el
cliente en el mostrador, presupuestar un trabajo de impresión
y después pasar éste a una instalación automatizada de
producción. En la próxima figura: cada rectángulo representa
un componente del software. Cada operación se representa
como módulo aislado que se invoca como se indica en la
figura. Para controlar el procesamiento se utilizan otros
módulos, por lo que son componentes de control.
Traducción
Diagrama de componentes: ‘Compute
Page Cost’’Calcular costo por pagina’
■ El comportamiento del módulo se representa con un
diagrama de estado. Para ilustrar este proceso, considere el
módulo ‘Compute Page Cost’. El objetivo de este módulo es
calcular el costo de impresión por página con base en las
especificaciones dadas por el cliente. Los datos requeridos
para realizar esta función son: número de páginas en el
documento, número total de documentos que se va a
producir, impresión por uno o dos lados, color y tamaño. El
costo por página es inversamente proporcional al tamaño del
trabajo y directamente proporcional a su complejidad.
Sin traducción
 Visión relacionada con la arquitectura
■ Se ha puesto énfasis en la necesidad de elaborar sistemas
que utilicen componentes de software o patrones de diseño
ya existentes. Conforme se desarrolla la arquitectura del
software se escogen del catalogo compontes o patrones de
diseño y se usan para construir la arquitectura.
 Ejemplo de diseño de componentes basados
endeclase
■ El diseño en el nivel componentes se centra en la
elaboración de clases especificas del dominio del problema
y en el refinamiento de las clases de infraestructura
contenidas en el modelo de requerimientos.
 Principios básicos del diseño

■ Hay cuatro principios básicos que son aplicables al diseño en el

nivel de componentes y que han sido ampliamente aceptados
para la aplicación de la ingeniería de software orientada a
objetos: La motivación para aplicar estos principios es crear
diseños que sean más factibles de cambiar, así como reducir la
propagación de efectos colaterales cuando se hagan cambios.
Estos principios pueden usarse como guía cuando se desarrolle
cada componente del software.
 Principios básicos en el diseño
Existen cuatro principios básicos que se aplican al diseño de nivel de
componentes:
• Principio Abierto – Cerrado (PAC): Un modulo debe ser abierto para la
extensión pero cerrado para la modificación.
• Principio de sustitución de Liskov (PSL): una clase de base debe
funcionar bien si una clase derivada de la clase base pasa al componente.
• Principio de Inversión de la Dependencia (PID): entre mas dependa un
componente de otros componentes concretos, mas difícil será ampliarlo.
• Principio de segregación de la interfaz (PSI): el PSI sugiere que debe
crear una interfaz especializada que atienda a cada categoría principal de
clientes.
 Principio Abierto-Cerrado (PAC)

■ “Un módulo [componente] debe ser abierto para la extensión pero

cerrado para la modificación". Este enunciado parece ser una
contradicción, pero representa una de las características más
importantes de un buen diseño en el nivel de componentes. Dicho en
pocas palabras, debe especificarse el componente en forma tal que
permita extenderlo (dentro del dominio funcional a que está
dirigido) sin necesidad de hacerle modificaciones internas (en el
nivel del código o de la lógica). Para lograr esto, se crean
abstracciones que sirven como búfer entre la funcionalidad que sea
probable extender y la clase de diseño en sí.
 Ejemplo: Sistema Casa Segura

■ La función de seguridad Casa Segura utiliza la clase

Detector que debe revisar el estado de cada tipo de sensor de
seguridad. Es probable que, conforme pase el tiempo, crezca
el número y tipos de sensores de seguridad. Si la lógica de
procesamiento interno se implementa como una secuencia de
comandos si-entonces-en otro caso, cada uno dirigido a un
tipo diferente de sensor, cuando se agregue uno nuevo se
requerirá una lógica de procesamiento interno adicional (otro
si-entonces-en otro caso). Esto sería una violación del PAC.
.Principio de sustitución de Liskov.

■ “Las subclases deben ser sustituibles por sus clases de base”.

Un componente que use una clase de base debe funcionar bien
si una clase derivada de la clase base pasa al componente. El
PSL demanda que cualquier clase derivada de una clase de base
debe respetar cualquier contrato implícito entre la clase de base
y los componentes que la usan. En el contexto de este análisis,
un “contrato” es una precondición que debe ser verdadera antes
de que el componente use una clase de base y una
postcondición que debe ser ver dadera después de ello.
 Principio de cierre común

■ “Las clases que cambian juntas pertenecen a lo mismo”. Las

clases deben empacarse en forma cohesiva. Es decir, cuando
las clases se agrupan como parte de un diseño, deben estar
dirigidas a la misma área de funciones o comportamiento.
Cuando deba cambiar alguna característica de dicha área, es
probable que sólo aquellas clases que haya dentro del
paquete requieran modificación. Esto lleva a un control de
cambios y a un manejo de la liberación más eficaces.
 Principios adicionales

Existen otro principios que son adicionales.

• Principio de equivalencia de la reutilización (PER):
Cuando las clases o componentes se diseñan para ser
reutilizables, existe un contrato implícito que se
establece.
• Principio de cierre común (PCC): cuando las clases se
agrupan como parte de un diseño. Deben estar dirigidas
a la misma área de funciones o comportamiento.
• Principio de la reutilización común (PRC): Las clases
que no se reutilizan juntas no deben agruparse juntas.
 Lineamientos de diseño en el nivel de
componentes
En el nivel de componentes se aplicaron lineamientos
prácticos a los componentes, entre estos tenemos:
• Componentes: Deben establecerse convenciones para dar
nombre a los componentes.
• Interfaces: Las interfaces dan información importantes
sobre la comunicación y la colaboración.
• Dependencias y herencia: Para tener una mejor
legibilidad, es buena idea modelar las dependencias de
izquierda a derecha y la herencia de abajo hacia arriba.
 Cohesión
La cohesión implica que un componente o clase sólo
contiene atributos y operaciones que se relacionan de cerca
uno con el otro y con la clase o componente en sí.
Existen 3 categorías:
1. Funcional. Lo tienen sobre todo las operaciones; este
nivel de cohesión ocurre cuando un componente realiza
un cálculo y luego devuelve el resultado.
2. De capa. Lo tienen los paquetes, componentes y clases;
este tipo de cohesión ocurre cuando una capa más alta
accede a los servicios de otra más baja, pero ésta no tiene
acceso a las superiores.
3. De comunicación. Todas las operaciones que acceden a
los mismos datos se definen dentro de una clase.
 Acoplamiento

■ Es la medición cualitativa del grado en el que las

clases se conectan una con otra. Conforme las clases (y
componentes) se hacen más interdependientes, el
acoplamiento crece. Un objetivo importante del diseño
en el nivel de componente es mantener el
acoplamiento tan bajo como sea posible.
■ Es la medición cualitativa del grado en el que las clases se
conectan una con otra. El acoplamiento de las clases de
manifiesta de varias maneras y se definen las siguientes
categorías de acoplamiento:
 Ingeniería de Software Basada en
Componentes
La ISBC (ingeniería del software basada en componentes, CBSE)
es un proceso que se centra en el diseño y construcción de
sistemas basados en computadora que utilizan componentes de
software reutilizables.
Objetivos de la ISBC:
• Desarrollar sistemas a partir de componentes ya construidos.
• Desarrollar componentes como entidades reusables.
• Mantener y evolucionar el sistema a partir de la adaptación y
reemplazo de sus componentes.
 Realización del diseño en el nivel de
componentes
Debe transformarse la información de los modelos de requerimientos y
arquitectónico a una a representación de diseño que de suficientes
detalles para guiar la actividad de construcción. Los pasos siguientes
representan un conjunto de tareas comunes para el diseño en el nivel de
componentes:
1. Identificar todas las clases de diseño que correspondan al dominio del
problema
2. Identificar todas las claves de diseño que correspondan al dominio de
la infraestructura.
3. Elaborar todas las clases de diseño que no sean componentes
reutilizables.
4. Describir las fuentes persistentes de datos de datos (bases de
datos y archivos) e identificar las clases requeridas para
administrarlos.
5. Desarrollar y elaborar representaciones del comportamiento para
una clases o componente.
6. Elaborar diagramas de despliegue para dar mas detalles de la
implantación.
7. Rediseñar cada representación del diseño en el nivel de
componentes y siempre considerar alternativas.
 Diseño en el nivel de componentes para
software
El diseño en el nivel de componentes de software con frecuencia
incorpora elementos de diseño del contenido y de las funciones.
Un componentes de software es:
• Una función cohesiva bien definida que manipula contenido o
da procesamiento de computo o de datos para un usuario final o
• Un paquete cohesivo de contenido y funciones que brindan al
usuario final alguna capacidad solicitada.
 Diseño de contenido en el nivel de
componente
■ El diseño del contenido en el nivel de componentes se
centra en objetos de contenido y en la forma en la que
se empacan para su presentación a un usuario final del
software.
■ La formalidad del contenido en el nivel de
componentes debe adaptarse a las características del
software que se va a elaborar.
 Diseño de las funciones en el nivel de
componentes
■ Las funciones del software se entregan como una serie
de componentes desarrollados en paralelo con la
arquitectura de la información que garantice que sean
consistentes. Durante el diseño de la arquitectura, el
contenido y funciones del software se combinan para
crear una arquitectura funcional.
 Visión a Estructurada
■ Los fundamentos del diseño a nivel de componentes proceden de
los años sesenta, con Edsgar Dijkstra y sus colaboradores, que
propusieron usar un conjunto de construcciones lógicas restringidas
para formar cualquier programa.
■ Las construcciones son secuenciales , condicionales y repetitivas.
■ La construcción secuencial implementa el proceso en pasos
esenciales para especificar cualquier algoritmo.
■ La condicional proporciona las funciones a partir de una condición
lógica .
■ La repetitiva proporciona los bucles.
■ Las tres construcciones son fundamentales para la programación
estructurada -técnica importante de diseño a nivel de componentes.
■ Las construcciones estructuradas se propusieron para restringir el diseño
del software a un número reducido de operaciones predecibles . La
utilización de construcciones estructuradas reduce la complejidad del
programa y mejora la capacidad de comprender, comprobar y mantener.
■ La utilización de un número limitado de construcciones lógicas contribuye
al proceso de comprensión humana denominado: fragmentación ( troceado
o chunking ). Para entender este proceso, consideremos cómo leemos esta
diapositiva. Las letras no se leen individualmente: más bien, se reconocen
formas o trozos de letras que forman palabras o frases. Las construcciones
estructuradas son fragmentos lógicos que permiten al lector reconocer
elementos procedimentales de un módulo en lugar de leer el diseño o el
código línea a línea.
 Diseño de componentes tradicionales
Las construcciones ponían el énfasis en el “mantenimiento del
dominio funcional”. Es decir, cada construcción tenia una estructura
lógica predecible que se introducía al principio y salía por el final, lo
que permitía que el lector siguiera el flujo del procedimiento con
mas facilidad.
Las construcciones son:
• Secuencia: implementa pasos de procedimiento que son
esenciales en al especificación de cualquier algoritmo.
• Condición: proporciona el medio para seleccionar un
procesamiento con base en algún suceso lógico.
• Repetición: permite la ejecución de lazos.
 Notación grafica en el diseño
■ Las herramientas gráficas => diagramas de flujo o de cajas , proporcionan
formas gráficas excelentes para representar fácilmente datos procedimentales
.El diagrama de flujo es una imagen bastante sencilla. Usando una caja se
indica un paso del proceso. Un rombo representa una condición lógica y las
flechas indican el flujo de control. Una secuencia se puede representar como
cajas de procesamiento conectadas por una línea (flecha) de control.
■ La condición, llamada también si-entonces-si - no , se representa mediante el
símbolo del rombo de decisión que, si es cierto, provoca el procesamiento de
la parte entonces , y, si es falso, invoca el procesamiento de la parte si-no. La
repetición se representa mediante dos formas ligeramente diferentes. El
mientras-hacer prueba una condición y ejecuta una tarea de bucle
repetidamente siempre que la condición siga siendo verdad. Un repetir-hasta
primero ejecuta la tarea de bucle, después prueba la condición y repite la
tarea hasta que la condición falla.
■ No hay duda de que herramientas graficas, como el diagrama
UML de actividades o el diagrama de flujo, constituyen
patrones gráficos útiles que ilustran fácilmente detalles de
procedimiento. No obstantes, si se hace mal uso de las
herramientas graficas, surge una imagen equivocada que
conduce al software equivocado.
 Notación de diseño tabular

Las tablas de decisión proporcionan una notación que traduce las

acciones y condiciones a una forma tabular. Para desarrollar una
tabla de decisión se empelan los pasos siguientes;
1. Enlistar todas las acciones asociadas con un procedimiento (o
componente) específico.
2. Enlistar todas las condiciones durante la ejecución del
procedimiento.
3. Asociar conjuntos específicos de condiciones con
acciones especificas, desarrollar toda posible permutación
de las condiciones.
4. Definir reglas indicando que acciones suceden para un
conjunto dado de condiciones.
 El Lenguaje de Diseño de Programas

■ El Lenguaje de Diseño de Programas (LDP) , Lenguaje Estructurado o

Pseudocódigo, es <<un lenguaje ‘ rudimentario ’, pues usa el vocabulario de un
idioma humano (ejemplo: Inglés ), y la sintaxis de un lenguaje estructurado de
programación>>. A primera vista LDP se parece a un lenguaje de programación
moderno. Con la diferencia del empleo de texto descriptivo (Inglés o Español,
dependiendo de tu idioma) insertado en las sentencias de LDP.
■ Como se utiliza texto descriptivo insertado directamente en una estructura
sintáctica, este lenguaje no se puede compilar. Sin embargo, las herramientas
LDP (PSeInt)actuales convierten LDP en un <<esquema>> de lenguaje de
programación, y/o representación gráfica (diagrama de flujo de diseño, tablas
de referencia cruzadas, etc.).
■ Una sintaxis básica de LDP debe incluir construcciones
para: definir los componentes, describir la interfaz, hacer
la declaración de los datos, estructurar bloques, hacer
construcciones condicionales, de repetición y de entrada y
salida (E/S).
■ El LDP no es un lenguaje de programación. Se adapta
según se requiera din preocuparse por errores de sintaxis.
 Desarrollo basado en componentes
■ Es un proceso que pone el énfasis en el diseño y
construcción de sistemas basados en computadora que
emplean “componentes” reutilizables de software.
 Calificación, adaptación y combinación de los
componentes
La ingeniería del dominio genera la biblioteca de componentes
reutilizables, la existencia de componentes reutilizables no garantiza
que estos se integran con facilidad o eficacia en la arquitectura
escogida para una nueva aplicación.
Calificación: garantiza que un componentes candidato ejecute la
función requerida, “encaje” en forma adecuada en el estilo
arquitectónico.
Adaptación: en ocasiones se emplea una técnica de adaptación
llamada envoltura de componentes.
Combinación: debe establecerse una infraestructura que ligue los
componentes en un sistema operativo.
 Ingeniería del dominio
El objetivo de la ingeniería del dominio es identificar, construir,
catalogar y diseminar un conjunto de componentes de software que
sean aplicables al software existente y al del futuro en un dominio
particular de aplicaciones. Los pasos de este proceso se definen
como sigue:

1. Definir el dominio que se va a investigar

2. Clasificar los aspectos extraídos del dominio
3. Reunir una muestra representativa de aplicaciones en el dominio
4. Analizar cada aplicación en la muestra y definir clases de
análisis
5. Desarrollar un modelo de los requerimientos para las clases
 Reutilización de Componentes

■ En las últimas dos décadas, la comunidad de la ingeniería de

software ha puesto el énfasis en la necesidad de elaborar
sistemas que utilicen componentes ya existentes.
■ En esencia, a medida que avanza el trabajo de diseño se
dispone de un catálogo de diseño probado o de componentes
en el nivel de código.
■ Como estos componentes fueron construidos teniendo en
mente lo reutilizable, se dispone totalmente de la descripción
de su interfaz, de las funciones que realizan y de la
comunicación y colaboración que requieren.
Clasificación y recuperación de componentes

La clasificación permite encontrar y recuperar componentes

que son candidatos a la reutilización, pero debe existir un
ambiente propicio para integrarlo con eficacia.
La biblioteca de reutilización es un elemento de un
repositorio mayor de software y brinda herramientas para el
almacenamiento de componentes de software.
 Análisis y diseño para la reutilización
Se promueve el uso de componentes de software ya existentes, hay
veces en las que deben desarrollar se otros nuevos para integrarlos con
CSS disponibles y con otros propios. Como estos nuevos componentes
se vuelven miembros de la biblioteca de componentes. Se sugiere varios
aspectos clave que constituyen la base del diseño para la reutilización:
Datos estándar: El dominio de la aplicación debe investigarse y tienen
que identificarse las estructuras de datos globales estándar.
Protocolos de interfaz estándar: Deben establecerse tres niveles de
protocolos de interfaz
Plantillas de programa: Se elige un estilo arquitectónico que sirve
como plantillas para el diseño.
 Conclusiones
El nivel de componentes surge después de que se termina el diseño de
arquitectura, con el principal objetivo de traducir el modelo del diseño a
software operativo.
Un componentes es una parte modular, desplegable y sustituible de un
sistema que debe ser capaz de comunicarse y colaborar.
Hay cuatro principios básicos de diseño en el nivel de componentes pero
también existen principios adicionales de agrupamiento que propone
Martin.
Hay siete pasos a seguir para realizar el diseño en el nivel de
componentes estos pasos representan un conjunto de tareas comunes.
■ El proceso de diseño en el nivel de componentes incluye
una secuencia de actividades que reduce el nivel de
abstracción con el que se representa el software.
■ El diseño en el nivel de componentes ilustra al software en
un nivel de abstracción cercano al código.
■ El enfoque orientado a objetos se centra en la elaboración
de clases de diseño que provienen tanto del dominio del
problema como de la infraestructura.
DISEÑO DE DATOS
 ¿Qué es el diseño de datos?
■ El diseño de datos consiste en descubrir y definir completamente los
proceso y características de los datos de la aplicación. Es un proceso
de perfeccionamiento gradual que abarca las situaciones más simples
como por ejemplo ¿Qué datos requieren la aplicación? ¿Cómo se
accederán a esos datos? ¿Cómo se almacenarán los datos?. Si se
logra un diseño de datos 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.
 Ejemplo
■ El diseño de datos consiste en descubrir y
definir completamente los proceso y
características de los datos de la aplicación.
Es un proceso de perfeccionamiento gradual
que abarca las situaciones más simples como
por ejemplo ¿Qué datos requieren la
aplicación? ¿Cómo se accederán a esos datos?
¿Cómo se almacenarán los datos?. Si se logra
un diseño de datos 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.
■ El diseño de datos se centra más que todo en el diseño de la estructura
de la base de datos y los archivos que van a ser usados por el sistema
de información en construcción.
■ Aunque en el diseñado de datos trataremos de cubrir todos los aspectos
fundamentales y necesarios para el diseño adecuado para almacenar,
mantener y recuperar datos es imposible precisar al inicio de un diseño
cómo, cuándo y dónde se van almacenar los datos, generalmente solo
se puede prever el uso de un motor de base de datos relacional.
■ Para un diseño de datos adecuado se debe incluir la identificación de
datos, la definición de datos, la integridad de datos, precauciones que
se deben adoptar al diseñar datos.
 Identificación de datos:
■ La identificación de datos es un proceso iterativo que a
medida que va iterando va siendo más preciso y de alto
nivel, esto permite adquirir más conocimiento sobre
los procesos previstos de la aplicación y hacerlos más
fiables. Cuando identificamos un dato generalmente se
debe documentar la siguiente información: nombre,
descripción general (qué es), propiedad (quién es el
responsable), características (como se mide, que
magnitud puede tener), relaciones, procesos y eventos
lógicos ( cómo y cuándo se crea, modifica y utiliza).
■ Es importante resaltar, los datos tienen muchas características
diferentes y es importante cuantificar cada uno de los datos con
atributos medibles. Algunas características típicas de los datos
son las siguientes:
 Atributos de ubicación (dirección, país, lugar de
almacenamiento).
 Atributos físicos (peso, dimensiones, volumen, color, material,
textura).
 Atributos conceptuales (nombre, categoría, número de serie).
 Atributos relacionales (conjuntos formados por subconjuntos,
escritores de varios libros).
 Atributos de valor (moneda, disposición, consideración).
■ Los datos nos permiten describir cosas, personas,
productos, elementos, clientes entre otras muchas cosas
más que nos permiten realizar tareas de clasificación por
categorías, organización y mantenimiento.
■ Es importante resaltar que no todos los datos deben ser
incluidos en el desarrollo web y está en nuestra habilidad
como desarrolladores saber qué vamos a documentar y qué
características van a tener estos datos.
 Definición de datos:
■ A medida que vamos identificando los datos y su estructura
general a través de las características de los datos podemos crear
relaciones entre ellos y diseñar un poco más nuestra base de
datos aplicando lo que hemos visto en cursos anteriores. Para
definir los datos se debe realizar las siguientes acciones:

 Definir tablas, filas y columnas

 Insertar claves de índice (llaves primarias)
 Insertar relaciones entre tablas.
 Asignar tipos de datos
 Definir tablas, filas y columnas
■ Independientemente de la forma en que se almacenan los datos en la
aplicación estos generalmente deben estar establecidos en tablas donde por
medio de conjuntos de atributos identificaremos al objeto o dato que
hacemos relación. Por ejemplo un dato persona, contendrá los campos
Nombre, Dirección y Teléfono y un ID numérico.
Tabla de personas

ID Nombres Dirección Teléfono

108825212 Andrés del Valle xxxxx xxxxxxxx (xxx) xxx xxxx
112313566 Carlos García xxxxx xxxxxxxx (xxx) xxx xxxx
212425667 Isabel Díaz xxxxx xxxxxxxx (xxx) xxx xxxx
4464574577 Bernardo Ramírez xxxxx xxxxxxxx (xxx) xxx xxxx
 Insertar claves de índice (llaves primarias)
■ Para el ejemplo anterior la llave primaria o clave de
índice sería el atributo o campo Id el cual nos permite
crear una relación con el objeto único persona, ya sea
Bernardo Ramírez o Isabel Díaz.
■ Una clave es un campo especial que proporciona un
índice para la recuperación de datos de forma rápida.

ID
108825212
112313566
212425667
4464574577
 Insertar relaciones entre tablas.
■ Atributos de un mismo dato se relaciona en una tabla y a
su vez atributos de otras tablas se pueden relacionar con un
atributo que sea único de una tabla, por ejemplo, para la
tabla personas, la clave de índice o llave primaría es Id,
esto nos permitirá relacionar por ejemplo, con otra tabla
que fuera notas de la persona. Tal cual como vimos en el
curso de base de datos.
 Asignar tipos de datos
■ Por último nos queda solo asignar de forma
adecuada los tipos de datos para cada atributo
del dato por ejemplo el atributo nombre de la
tabla persona debe ser de tipo texto ya que
nadie se llama 1418523578. Estos tipos de
datos generalmente van muy relacionado al
tipo de base de datos que usemos y pueden
cambiar sus características de un motor de base
de datos a otro. Lo importante a resaltar en esta
etapa de diseño es recordar que el espacio de
almacenamiento es un recurso finito y que
asignar el tipo de dato adecuada en la fase de
diseño nos permitirá optimizar y mantener de
una forma más adecuada nuestro software.
 Integridad de datos:
■ Con la integridad de datos nos referimos a los valores
reales que almacenamos y utilizamos en la base de datos
del desarrollo web, debemos garantizar que el desarrollo
web solo acepte, almacene y mantenga los datos
adecuados generando control sobre los mismos y
generando los mecanismos para la corrección de los
mismos, hay distintas formas de garantizar la integridad
de los datos como lo son:
 Normalizar datos

■ Explica el proceso que consiste en perfeccionar

las definiciones de datos para eliminar grupos
de dependencias innecesarias.
■ Este proceso consiste en tratar de minimizar las
dependencias entre claves y que exista una
mayor cohesión de los datos supongamos que
tenemos un dato en el cual existen más de una
llave única, la normalización nos enseña que lo
ideal es separar estas en datos más pequeños y
minimizar riesgos.
■ Hay 3 niveles de normalizar los datos y es un
proceso que deben recordar de las bases de
datos
 Definir reglas de empresa
■ Por medio de las reglas de la empresa establecemos el control
coherente y correcto para el acceso a datos de la aplicación esto
incluye la inserción, actualización, eliminación y vista de los datos,
validación de datos, controlar la seguridad de los datos, controlar el
acceso a datos de varios archivos.

Proporcionar integridad referencial

■ Es el mecanismo por el cual garantizamos que se dañen los datos.
 Validación de los datos
■ Son los procesos por los cuales comprobamos que los datos
almacenados sean válidos, este proceso puede ser antes, durante y
después de que el dato este en nuestra base de datos, por ejemplo
cuando la persona este llenando los apellidos, podemos crear un filtro
en el código de nuestro sistema para asegurarnos que solo se suban
caracteres de letras y no números. Que en el campo teléfono solo se
permitan valores numéricos, ya cuando los datos estén almacenados en
nuestra base de datos podemos convertir los datos de un tipo de dato a
otro y por último si deseamos eliminar los datos y no dejar cobertura
debemos asegurarnos que estos datos no puedan ser legibles.
 DISEÑO DE MÓDULOS,
COMPONENTES Y DATOS DE
SOFTWARE
Training CENEVAL Marzo 2023 – Luis Armando Villa
Ceballos