Universidad Autónoma de

Chihuahua

Facultad de Ingenierı́a

Fundamentos de Modelado

Juan C. Sáenz-Carrasco

June 6, 2019
1 Conceptos generales
Dentro del gran repertorio de definiciones del cuerpo del conocimiento de
la ingenierı́a del software, podemos destacar los siguientes como los más
significativos para este curso:

• Método
interesección de definiciones
de la RAE1 , wikipedia y SWEBOK hispano2

• Modelo interesección de definiciones de la RAE, wikipedia y SWE-

BOK hispano.

• Sistemas S definido por Lehman en [?], S por specification, refiere a

aquellos sistemas o programas que pueden ser claramente implemen-
tados dada su especificación, pero sobre todo resuelven el problema
definido en tiempo polinomial. Ejemplos de estos sistemas son las fun-
ciones matemáticas o algoritmos cuyo tiempo de cómputo es ≤ O(nk )
donde k es una constante.

• Sistemas P definido por Lehman en [?], P por problem-solution, refiere

a aquellos sistemas o programas como los tipo S, pero cuya solución es
polinomial no determinı́stica, es decir, el costo (en tiempo o espacio)
es demasiado en comparación con los programas S. Ejemplos ? (tip: el
tiempo para dar respuesta o solución puede ser exponencial como en
TSP)

• Sistemas E definido por Lehman en [?], E por embedded, refiere a

sistemas donde la participación del usuario es constante o requiere asis-
tencia del usuario para su conclusión. Desempeño ?, Ejemplo ? (tip:
mecanización de la actividad humana).

2 Importancia
En este documento vamos a discutir básicamente dos aspectos que delimitan
la importancia del modelado de software: la administración y el histórico.
1
www.rae.es
2
http://www.cc.uah.es/drg/b/HispaSWEBOK.Borrador.pdf

1
 En la administración de proyectos de software, muchos proyectos de soft-
ware fallan. Las fallas se deben a múltiples causas:

• Presupuesto: Costos excesivos

• Calendarización: Entrega tardı́a

• Funcionalidad: No se cumplen los requerimientos y necesidades del

sistema (la especificación)

Estos son los tres factores más importantes para administrar un proyecto
de software. El modelado efectivo y prácticas sólidas de administración de
procesos ayudan a evitar tales fallas.
Avances tecnológicos tales como paradigmas de programación, ambientes
de desarrollo y herramientas visuales han ayudado en el incremento de la
codificación, pero NO han resuelto estos problemas.
Por otro lado, el aspecto histórico, podemos mencionar que antes del
establecimiento del UML, la cantidad de normas y herramientas para modelar
software eran tantos y tan diferentes, que era difı́cil definir un estándar.

3 Propósitos
Un modelo representa un trabajo creativo.
No hay una solución final o una respuesta correcta que sea verificada al
final del trabajo.
Los diseñadores del modelo aseguran las metas y los requerimientos a
través del trabajo iterativo. Pero un modelo no es final, tı́picamente es ac-
tualizado y cambiado a través de un proyecto que refleja nuevos conceptos y
experiencias.
Durante el modelado, las mejores soluciones son generalmente obtenidas
cuando se lleva a cabo una lluvia de ideas de alto nivel durante la cual difer-
entes soluciones y visiones son modeladas y probadas.
Al discutir diferentes posibilidades, los diseñadores alcanzan un entendimiento
profundo del sistema y pueden entonces crear modelos del sistema que logrará
las metas y requerimientos del sistema y sus usuarios.
En resumen, los modelos útiles son:

• Precisos. Describen de manera correcta el sistema que representan.

2
 • Entendibles. Deben ser tan sencillos como sea posible sin perder el
cumplimiento del propósito y sin sacrificar la comunicación.

• Consistentes. Diferentes vistas no deben expresar ideas en conflicto

entre ellas.

• Modificables. Facilidad para cambiar y actualizarse.

4 Caracterı́sticas de los modelos

Si vemos al modelo expresado como lenguaje de modelado, podemos destacar
las siguientes caracterı́sticas.

• Notación, definición

• Sintaxis, nos dice cómo los sı́mbolos debe mirarse y combinarse. Una
analogı́a es el de las palabras en el lenguaje natural: su pronunciación
y el orden para formar oraciones.

• Semántica, explica el significado de los sı́mbolos por si solos o cuando

se encuentran en contexto con otros sı́mbolos.

• Pragmática, es acerca de la intención del uso de los sı́mbolos con el

fin de lograr el entendimiento del modelo para todos los usuarios.

5 Desarrollo guiado por modelos

El modelo es colocado en el centro de la gestión de la información y en este
caso la aplicación los diagramas de UML como la médula espinal del desar-
rollo de software. En otras palabras, dado un diagrama de UML, el proceso
de codificación se basa en dicho diagrama en lugar de la especificación del
cliente (original). Esto implica que el modelo no sustituye a dicha especifi-
cación sino que la traduce en algo “digerible” para los programadores.

3
5.1 Ejemplo

6 Lenguajes de modelado
Tal como mencionamos en § 4, un lenguaje lleva a cabo de manera escrita
u oral las acciones a desarrollar tomando en cuenta el modelo. En nuestro
caso, el desarrollo de software, distintos lenguajes se han diseñado pero men-
cionaremos algunos de ellos.

• IEEE Std. 1320.2-1998: es el estándar llamado Standard for Con-

ceptual Modeling Language—Syntax and Semantics for IDEF1X97 o
simplemente IDEF1X97. Mayormente usado por el gobierno de los Es-
tados Unidos de América. Su enfoque son las bases de datos relacionales
y las bases de datos orientadas a objetos.

4
 • UML por sus siglas en inglés Unified Modelling Language. estándar
de la IEEE 830 para UML, aceptado mayormente por la industria y el
enfoque para el desarrollo de software Orientado a Objetos.

• OCL por sus siglas en inglés Object Constraint Language y es un

lenguaje especializado del UML para hacer más especı́ficos los detalles
del lenguaje natural. Se mencionan unas restricciones a continuación
(constraints) de OCL

– Una expresión OCL debe tener un Contexto definido donde

evaluarse. Frecuentemente el contexto se determina según
dónde se escribe la expresión, por ejemplo con una nota
asociada a un clasificador. Se puede hacer referencia al
clasificador que determina el contexto utilizando del key-
word self.
– Se pueden seguir las asociaciones entre clasificadores, y
usar los end-names (roles) como si fuesen atributos del
clasificador de origen.
– Las expresiones OCL pueden asociarse a las operaciones
para capturar pre y post condiciones, utilizando los key-
words pre y post respectivamente. Para hacer referen-
cia al resultado de una operación, en una expresión de
poscondición se utiliza el keyword result Al igual que con
las invariantes se puede dar un nombre a las expresiones.

7 Evolución de los lenguajes de modelado

Describir la evolución puede ser una tarea que implique varios documentos,
por lo que en esta sección nos enfocamos en el caso de UML. Como origen,
el UML se debe mayormente a los trabajos y esfuerzos de tres personas o
“The Three Amigos”, quienes por sus apellidos son Grady Booch, Ivar John
y James Rumbaugh.

La unificación se dió en 17 de noviembre de 1997 y cuyo estándar es actual-

mente gestionado por la organización Object Management Group (OMG).

La versión más reciente a enero del 2019 es la ISO 19505-3.