Apuntes Ingeniería del Software

Alex Marqués Fernández

Preámbulo
El principio de la asignatura es hacer comprender al alumno que el desarrollo del software es
una actividad industrial. Esto significa que se deben aplicar principios de ingeniería y buenas
prácticas de gestión.

Una opinión comúnmente aceptada en la industria es que:

 Para obtener un producto de calidad en un tiempo y coste determinado…

 … se deben de aplicar de forma sistemática un conjunto de métodos, técnicas y
herramientas. Además…
 ESTO NO ES NEGOCIABLE

Ingeniería del Software se centra en el aprendizaje de las tareas vinculadas a la construcción

del producto software.

Esto consta de un análisis y un diseño que acabarán en un proyecto software, objetivo y

asignatura que se trabajarán en el siguiente cuatrimestre donde se trabajarán los aspectos
relacionados con la gestión de esa construcción.

Se debe de aprender a:

 Realizar un análisis del sistema.

 Determinar los requisitos de un sistema software antes de su construcción.
 Planificar y ejecutar un conjunto de pruebas que permitan verificar y validar el
software a lo largo del proceso de construcción.

BIBLIOGRAFÍA

 Ingeniería del Software (Ian Sommerville) Editorial Pearson

 Ingeniería del Software, enfoque práctico (Roger S. Pressman) Editorial, McGraw Hill
 El lenguaje Unificado del Modelado (Manual de Referencia) (Grady Booch)

Tema 1 (Cap. 1 Pressman)

Según la RAE:

 Ingeniería:
o Conjunto de conocimientos orientados a la invención y utilización de técnicas
para el aprovechamiento de los recursos naturales o para la actividad
industrial.
o Actividad profesional del ingeniero.
 Programa:
o Conjunto de instrucciones pensadas para ser ejecutadas en un orden concreto.
Crisis del software
En la década de entre los 60’ y los 80’, había una enorme cantidad de programas que no
funcionaban, o siquiera compilaban.

A causa de la falta de estandarizaciones, tecnología, lenguajes de programación disponibles, se

idea la Ingeniería del Software (de ahora en adelante ISW) como una forma de industrializar el
proceso de desarrollo del software.

La ingeniería no es una disciplina nueva, especialmente en las modalidades de arquitectura y

Obras Públicas.

 Los programas de ordenador no se hacen “porque sí”

 No vale cualquier cosa (que compile)
 Hay técnicas y estándares aplicables al desarrollo de software
 Hay programas buenos y malos, mejores y peores
 Funciona -> Bueno === Falacia

Pressman define el software como el conjunto de:

1. Instrucciones que se ejecutan en un ordenador y proporcionan la función y

rendimiento deseado.
2. Estructuras de datos que permiten a los programas manipular adecuadamente la
información y…
3. DOCUMENTOS que describen la operación y el uso de los programas.

Dejando así al software compuesto por estos tres elementos indispensables.

La creación de software como proceso industrial

Se insiste en el uso de criterios de calidad, claro está, el desarrollo de software también es una
actividad comercial.
La informática como profesión está sujeta a un fenómeno de “amateurización”:

 Cursillos de programación en 15 días

 Lo peor, las empresas también creen en la amateurización de esta disciplina -> no
tienen fe en la contratación de profesionales de la ISW

A pesar de la falta de fe, las empresas dependen del software cada vez más y esto implica que:

 MAL SOFTWARE -> COSTES ELEVADOS

SOFTWARE ¡= HARDWARE: No se fabrica, se desarrolla:

 Política de precios especial

 Fenómeno de la piratería
 ¿¿Creación de productos ensamblando componentes ajenos es típico del HW, pero y
del SW??

El software no se estropea, pero tampoco sirve para toda la vida:

 Curva de fallos en el hardware:

 Curva de fallos en el software idealizada vs la real

Mitos del software:

 Si falla la planificación, siempre se puede añadir más gente (Concepto de la horda

mongola)
 Una declaración general de los objetivos es suficiente para escribir los programas, se
puede detallar más adelante.
 Los requisitos cambian continuamente, pero los cambios pueden acomodarse
fácilmente puesto que el software es flexible
 Una vez puesto en marcha, el trabajo ha terminado
 Hasta que no tengo un programa ejecutándose, realmente no tengo forma de
comprobar su calidad
 Lo único a entregar al cliente es el programa funcionando
 No hay una manera para desarrollar diferente a ponerse delante de la pantalla a
programar
 La documentación no existe
 La ISW no existe, programar es arte

Trabajo REAL (la dura realidad):

 Presupuestos ajustados
 Mala comunicación con el cliente
 Rotación de personal
 Cambios en los sistemas de desarrollo
 Desarrollo de proyectos de forma arbitraria y artesanal
 No seguimiento de estándares
 Escasa reutilización
 Poca importancia a las pruebas
 Modelo de ciclo de vida “Code & Fix” -> A lo americano (a lo loco)

Problemas derivados

 Mantenimiento de alto coste

 Gran dependencia del individuo
 Incumplimiento de la entrega
 No se tiene tiempo de recoger datos sobre el proceso de desarrollo de software que
permitan estimaciones y planificaciones fiables
 Insatisfacción de los usuarios con el producto terminado
 Dudosa calidad del resultado
 Poca importancia de las pruebas

Riesgos

 Sobrepasar límites de los recursos asignados

 Finalización fuera de plazo
 Mala gestión del proyecto
 Incompatibilidad con el entorno

Y lo peor…

 Pérdida de oportunidades de negocio

 Pérdida de credibilidad
Definición de ISW (Boehm)

“Aplicación práctica del conocimiento científico en el diseño y construcción de programas y la

documentación asociada requerida para desarrollarlos, operarlos y mantenerlos”

Definición de ISW (Bauer)

“Establecer principios y métodos con el fin de obtener un SW fiable”

Aportaciones de la ISW
Problema Solución ISW
Mantenimiento de alto coste y riesgo Reutilización y documentación
Dependencia del individuo Estandarización del desarrollo
Incumplimiento del plazo de entrega Planificación de proyectos
Ausencia de datos para estimaciones Gestión de proyectos
Dudosa calidad del SW Métricas de calidad

Beneficios adicionales de la ISW

 Optimización de recursos
 Aumento de la formación del personal
 Gerión de la configuración
 Posibilidad de subcontratación
 Simplificación de auditorías de seguridad
 Minimización de riesgos de contingencias

¿Realmente ayuda a rebajar costes la ISW?, la respuesta es que en producción no

necesariamente, a veces incluso aumentando los costes, sin embargo, reduce los costes de
mantenimiento drásticamente
Tema 2: El Proceso Software (Cap. 3 Pressmann, Página 48)
“La ingeniería es el análisis, diseño, construcción, verificación y gestión de entes”

Todo ingeniero debe plantearse:

- Cuál es el problema para resolver

- Qué características tiene el “ente” en cuestión
- Cómo se realizará este “este”.
- Cómo se construirá
- Cómo se asegurará que se han detectado los errores que hayan podido darse en su
diseño y construcción
- Qué pasará cuando sea necesario introducir modificaciones…

Estas respuestas las englobaremos en el PROCESO SOFTWARE.

Una aproximación al proceso de construcción de software…

1. Análisis: Qué hay que hacer

a. Documento de requisitos (especificaciones)
b. Calendario de prototipos
c. Calendario de tareas (Gantt y Pert)
d. VTP: Validation Test Plan
e. Diagramas use-case (UML)
2. Diseño: Cómo va a hacerse
Dependiendo del paradigma/metodología elegida:
a. Diagramas (UML)
b. Cómo serán las estructuras de datos (de ahora en adelante ED) a utilizar
c. Cómo se traducirá el diseño en un lenguaje de programación
d. Cómo se implementarán los detalles de diseño
e. Cómo se efectuarán las pruebas de VTP
3. Implementación:
a. Construcción de los diferentes prototipos, cumpliendo los hitos y directrices
marcadas en 1 y 2.
b. Incluye las pruebas (VTP)
4. Mantenimiento:
Las modificaciones a posteriori son inevitables. Existen cinco tipos de
mantenimiento.
a. CORRECTIVO (Errores que se han escapado)
b. ADAPTATIVO (Cambios en el entorno)
c. PREVENTIVO (Anticiparse a los problemas)
d. PERFECTIVO (Mejorar lo que está bien)
e. LEGAL (Adaptativos, pero causado por temas legales)
El Proceso
Debe establecer una serie coherente de actividades para la producción de software:

- Definición de tareas en que se descompondrá el proceso de creación de nuestro

software
o Planificación temporal (es decir, un calendario)
- Hitos o “milestones”: deben aparecer en el calendario.
o A nivel interno o externo (entregas al cliente y su correspondiente
retroalimentación) …
- Existencia (y cumplimiento) de un “Libro de Estilo”.
- Gestión de configuración
o Seguimiento de las versiones y compatibilidad entre ellas.
- Seguimiento temporal y económico (¿Se cumple el calendario?)

Modelos de Proceso del SW

El desarrollo de software puede caracterizar como un bucle de cuatro elementos:

Modelos
Comentaremos modelos de procesos de software

Modelo Lineal-Secuencial (en cascada)

Análisis

 De requisitos. El ingeniero debe llegar a entender el dominio del problema,

requerimientos, comportamiento, rendimiento e interrelación de los elementos.
 Lista de requerimientos para el SW, para que responda a lo anterior
 El cliente documenta, repasa y valida los requerimientos

Diseño: Traducción de los requisitos a una representación del SW validable antes de

producción.

 Modelado de Sistemas Informáticos

 Definición de ED
 Arquitectura del Software
 Diseño de la interfaz del usuario
 Definición de los principales algoritmos

Generación del código: Un diseño detallado simplifica enormemente la generación del código

Pruebas: Se comprueba que todos los requisitos se cumplen a riesgo de que, si el documento
de requisitos falla, la producción también.

Problemas:

 Los proyectos reales no siguen un desarrollo secuencial

 El cliente no suele saber o es capaz de hacer un documento de RQ serio
 El modelo exige la existencia de un documento de RQ
 Si todavía no existe una versión final de RQ, la incertidumbre que eso genera no se
adapta al modelo (o al revés)
 El cliente no tendrá resultados tangibles hasta muy avanzado el desarrollo, a causa de
una falta de retroalimentación
 Bloqueo en el desarrollo, no se puede empezar ninguna parte del proceso hasta que
acaba la anterior
Modelo de construcción en prototipos
 Un cliente suele tener unos objetivos generales claros, pero no tiene RQ detallados de
entrada, procesamiento y salida.
 Otras veces que el desarrollador no está seguro de la idoneidad de la solución
proporcionada (o hay varias alternativas a contemplar).
 Desarrollador y cliente consensuan unos objetivos generales, identificando los RQ más
evidentes y esbozando las “grandes líneas” del sistema, generalmente apoyadas en el
IU
 Se prepara un diseño rápido y se genera el “prototipo”:
o Un programa parcialmente funcional
o No deja de ser una maqueta
 El objetivo último de un prototipo es:
o Mejorar el documento de requisitos
o Detectar la necesidad de incorporar nuevas funcionalidades
o Etc.

Riesgos:

 Puede ser complicado hacer comprender al cliente que el prototipo no es (ni mucho
menos) el producto terminado.
 El desarrollador puede caer en el mismo error que el cliente

Ventajas:

 Al cliente le gusta ver resultados “pronto”

 A los ingenieros habitualmente también
Modelo RAD (Rapid Application Development=
 Concepto basado en metodologías ágiles
 Basado en modelo secuencial, pero hace énfasis en ciclos de desarrollo corto.
 La rapidez viene dada por la reutilización (SOA, webservices, librerías propias o
externas etc.)
 Pensado para problemas que o bien los RQ son muy sencillos o conocidos.
 Si tenemos experiencia en el campo y en otros proyectos similares, mejor.

Problemas

 Este método no es apto para toda casuística

Modelo Incremental
 Combina elementos del modelo “secuencial” y del modelo “prototipado”
 Normalmente las primeras etapas desarrollan elementos básicos del sistema
añadiendo sobre estos
 El cliente utiliza los prototipos para generar nuevos RQ
 En un momento dado, se puede estar desarrollando distintos “incrementos” en
paralelo.
 Es necesario un calendario de prototipos.

 Permite arrancar un prototipo con pocos desarrolladores y si funciona, pasamos a

hacer un desarrollo “en serio”.
 Planificar el calendario de prototipos puede dar ciertas ventajas:
o Esperar a que se consolide cierta tecnología
o Esperar a que baje el precio de cierta tecnología
o Lo comentado en el modelo de prototipado.
Modelo en Espiral
 Otro modelo evolutivo (como el incremental)
 Desarrollo conversiones incrementales
 Se consideran una serie de “actividades estructuradas”:
1. Comunicación con el cliente
2. Planificación
3. Análisis de riesgos
4. Ingeniería
5. Construcción y adaptación
6. Evaluación del cliente

RUP (Rational Unifying Process)

 Ian Jackobsen, Grady Booch y James Rumbaugh
 Padres de UML
 Intento de reunir los mejores elementos de los procesos SW existentes
 Abraza los principios del “desarrollo ágil”
Tema 3: Requisitos (Cap. 3 Sommerville y IEEE 830-1998)
Los requisitos para un sistema son:

- La descripción de los servicios (funcionalidad) proporcionados por dicho sistema…

- Y sus restricciones operativas.

Los requisitos terminan reflejando las necesidades de los clientes del sistema

En la fase de análisis, una de las misiones será redactar un documento que incluya una lista con
los requisitos del sistema a construir: El documento de especificación de requisitos (SRS)

Tenemos información adicional al respecto en “Systems and Software engineering. Life cycle
processes. Requirements engineering,” en el Moodle.

Ingenieria de requisites:

- Disciplina interdisciplinar en la que intervienen los participantes del proyecto para

establecer y mantener los requisitos que deben cumplir tanto el sistema como el
software o el servicio asociado.
- Se ocupa del descubrimiento, comunicación, documentación y gestión de requisitos
- Genera como resultado una serie de requisitos que
o Referencia un determinado sistema, software o servicio
o Definen los términos de acuerdo establecidos ente los participantes
o Han sido validados con respecto a las necesidades reales
o Su implementación es factible
o Constituyen una referencia para la posterior verificación de los diseños e
implementación.
IEEE 29418-2018
La definición de requisitos comienza considerando las necesidades u objetivos de los
“stakeholders” o candidatos a requisito.

Esos candidatos son refinados y evolucionan hasta que son aceptados y pasan a incluirse en la
lista de requisitos.

Los aspectos que inicialmente consideren los miembros del equipo no tienen por qué terminar
incluidos en la lista de requisitos

La ingeniería de requisitos guía a los participantes a refinar sus ideas iniciales, hasta conseguir
un conjunto final de requisitos y objetivos que resultan mejor estructurados y sean
objetivamente adecuados.

Un requisito es una expresión (frase, párrafo, …) que:

- Puede ser verificado

- Refleja los aspectos que el sistema a construir deberá cumplir o poseer, para resolver
un problema o lograr un objetivo.
- Está asociado a magnitudes medibles y/o limitada por restricciones.
- Define las prestaciones o capacidades del sistema a construir, no las capacidades o
conocimiento de los usuarios u operadores.
- Expresa que una necesidad que pueda tener asociadas una serie de restricciones,
condiciones y/o asunciones
- Si se emplea el lenguaje natural, la frase estará formada por un sujeto, un verbo y un
predicado.

Es importante acordar los términos que van a utilizarse en el documento para indicar el alcance
de un requisito, para intentar evitar problemas de interpretación, ejemplo

 Cuando el requisito sea una cláusula obligatoriamente vinculante (mandatory binding

provisions), se usará el verbo deberá (shall).
 Cuando se trate de preferencias u objetivos que son deseables (no obligatorias y no
vinculantes), se usará el verbo debería (should).
 Si lo que contiene el requisito son sugerencias (no obligatorios y no vinculantes) se
utilizará el verbo podrá (may).

Se debe utilizar una “lógica positiva”, evitando los requisitos de lógica negativa:

La temperatura deberá ser menor a 150º C. -> Correcto

La temperatura no deberá ser superior a 150º C. -> Incorrecto

Un requisito debe entenderse como:

 Una declaración abstracta de alto nivel de un servicio que debe proporcionar el

sistema, o una restricción de éste.
 Definición detallada y formal de la función del sistema.
Para un requisito tenemos dos posibles enfoques:

1. Al presentar un contrato para un proyecto software “grande”, una empresa (el cliente)
debe definir sus necesidades de forma suficientemente general como para permitir
establecer a partir de ellas, una solución
o Estos primeros requisitos deberán generarse de forma que, varios contratistas
puedan licitar formas diferentes de cumplir con las necesidades expuestas.
2. Una vez que el software se asigna, el contratista debe redactar una definición del
sistema más detallada de forma que el cliente pueda comprender y validar lo que hará
finalmente el software.

Requisitos del usuario:

 Declaraciones en lenguaje y diagramas de los servicios (funcionalidad) que se espera

que el sistema proporcione…
 Y de las restricciones bajo las que debe funcionar

Requisitos del sistema:

 Establecen con detalle las funciones, servicios y restricciones operativas del sistema
 El documento de requisitos del sistema (especificación funcional) debe ser preciso y
exhaustivo.
 Debe definir exactamente qué se va a implementar
 Es razonable que forme parte del contrato.

Ambos son importantes, tanto los requisitos del usuario, como los del sistema.

Diferente información para distintos niveles

Es necesario redactar los requerimientos en distinto s niveles de detalle puesto que los lectores
lo utilizarán de manera distinta.

Lectores de los requisitos de usuario:

 Administradores clientes, usuarios finales, ingenieros clientes, administradores

contratistas, arquitectos del sistema
o No les importa ni interesa cómo se implementará el sistema ni los detalles de
su implementación
 Lectores de los requisitos del sistema
o Programadores etc. Que sí que les interesa cómo se implementará el sistema ni
los detalles de su implementación.
Requisitos de Usuario

Deben ser comprensibles por las personas que intervienen en el proceso, sin conocimientos
técnicos especiales.

Deben especificar el comportamiento EXTERNO del sistema.

Deben evitar, en lo posible, tratar las particularidades del diseño del sistema

Por lo tanto, no deben utilizarse jerga del software ni notación formal, sino un lenguaje sencillo
y diagramas intuitivos

Son un punto de partida, pero no el fin del viaje.

Requisitos del Sistema

Son versiones extendidas de los requisitos de usuario.

Utilizados por los ingenieros software como punto de partida para realizar el diseño del sistema

Pueden utilizarse como parte del contrato, aunque debe ser una especificación completa y
consistente del sistema en su conjunto.

Deben describir el comportamiento EXTERNO y no de sus restricciones operativas y por lo

tanto nunca indicarán cómo deberá diseñarse o implementarse el sistema

Todo esto es más fácil de decir que de hacer

Cuando los requisitos son muy detallados y se detalla mucho el QUE, quedan pocas variantes
del Cómo

La manera en la que estructuramos los requisitos en subsistemas puede acabar condicionando

el diseño.

Si el sistema debe interactuar con otros ya existentes, aparecerán restricciones que estarán
condicionando el diseño.

De la ambigüedad y otros venenos tóxicos

La interpretación de los requisitos es una fuente de constantes problemas.

Ante un requisito ambiguo

El desarrollador del sistema lo interpretará de forma que le facilite la vida -> Interpretación
máxima.

El cliente normalmente hará una interpretación máxima.

Si se detecta el “desacople” de puntos de vista, de deberá de establecer nuevos requisitos

complementarios, que pueden derivar en un retraso en la entrega y un aumento en los costes.
Tipos de Requisitos

1. Requisitos funcionales
 Declaraciones de los servicios que debe proporcionar el sistema
 Indican cómo debe reaccionar el sistema antes entradas particulares
 Cómo debe comportarse ante situaciones particulares.
 Pueden también indicar lo que el sistema NO debe hacer
2. Requisitos NO Funcionales
 Características relativas a los servicios o funciones ofrecidas por el sistema
 Limitaciones de tiempo sobre el proceso de desarrollo
 Por lo general, son de aplicación al conjunto del sistema
3. Requisitos de dominio
 Reflejan las características del dominio de la aplicación
 Pueden ser funcionales y no funcionales

Requisitos funcionales
La especificación de requisitos funcionales debe ser completa y consistente

Completitud: TODOS los servicios solicitados por el usuario deben estar definidos

Consistencia: Los requisitos no deben tener definiciones contradictorias

En sistemas grandes puede ser difícil de conseguir llevar a la práctica, esto genera problemas
que se encuentran tarde, mal y peor.

Requisitos NO funcionales
No ser refiera a las funciones consustanciales al sistema, sino a sus propiedades características
como:

 Fiabilidad
 Disponibilidad
 Mantenibilidad
 Portabilidad
 Tiempo de respuesta
 Capacidad de almacenamiento

O sus restricciones intrínsecas, como la capacidad de dispositivos de entrada y salida o la

representación de datos condicionada por el interfaz del sistema

Pueden ser más “puñeteros” que los requisitos funcionales:

 El no cumplir con un requisito funcional suele ser un problema acotado

 Incumplir un requisito de fiabilidad de una central nuclear puede obligar a desechar (y
rehacer) todo un sistema.

Además, pueden ser difíciles de verificar: ¿Cómo se mide la usabilidad? ¿Y la portabilidad?

Tipos de requisitos no funcionales.

1. Requisitos de producto
Especifican el comportamiento del producto, por ejemplo, rendimiento, fiabilidad,
portabilidad, usabilidad, etc.
2. Requisitos de la organización
Derivados de políticas implantadas por la organización del cliente, por ejemplo, estándares
a cumplir, lenguajes, módulos, por ejemplo:

La documentación deberá seguir el Estándar IEEE 84128-323

Insistimos

Todos los requisitos deben estar redactados de tal manera que sea posible (con facilidad) saber
si se cumplen o no.

Redacción en términos cuantitativos, que suele ser más sencillo con los requisitos
funcionales

Uso de métricas:

o Rapidez, prestaciones, transacciones por segundo, etc.

o Tamaño: kilobytes, etc.
o Facilidad de uso: tiempos de formación etc.
o Fiabilidad: MTBF1, probabilidad de no disponibilidad, tasa de fallos,
disponibilidad
o Robustez: Tiempo de reinicio después de fallos, porcentaje de eventos que
provocan fallo, probabilidad de corrupción tras un fallo, etc.
o Portabilidad: Porcentaje de declaraciones dependientes del objetivo, número
de sistemas objetivo, etc.

Requisitos del dominio

Derivados del domino de aplicación del sistema, más que de las necesidades de los usuarios.
Pueden (suelen) incluir jerga asociada al dominio.

Son muy importantes, puesto que tratan del dominio de aplicación, y eso es necesariamente
importante.

Es deseable que, cuando competa, se asocien los requisitos a un fundamente, que expliquen el
porqué de un requisito y que indique quién “lideró” su inclusión en la lista de requisitos del
sistema.

Ventajas:

 Ayuda a terceras personas a entender el contexto que motivó la aparición del requisito
en cuestión.
 Se sabe a quién hay que ir a preguntar para obtener más información (antes de
eliminarlo, cambiarlo, modificarlo o incluso a la hora de implantarlo)

1
Mean Time Between Failure
El lenguaje natural
Aunque pueda ser muy útil en los requisitos de usuario, causa muchos problemas en los
requisitos de sistema

La comprensión del lenguaje natural depende de que lectores y redactores utilicen el mismo
vocabulario de la misma manera. El lenguaje natural puede ser ambiguo, y además en los
peores momentos posibles.

Una especificación en lenguaje natural es demasiado flexible, proponemos, por lo tanto:

 Lenguaje natural estructurado y

 SADT

Lenguaje Natural Estructurado

Con el objetivo de minimizar los malentendidos, los requisitos se redactan de forma estándar,
haciendo uso de unos formularios prefijados

Ofrece como ventaja que mantiene la expresividad del lenguaje natural y asegura cierta
uniformidad en las especificaciones.

Y sigue permitiendo la inclusión de TODO aquello que ayude a mejorar el requisito, como:

 Diagramas
 Gráficos
 Etc.
Introducción del documento IEEE 830-1998
Se establecen métodos estandarizados de comunicación cliente-trabajador para salvar errores
que se pudieran cometer de otro modo.

Para los clientes, proveedores, y otros; un buen SRS deberá proveer bastantes beneficios
específicos, como:

 Establecer la base del acuerdo entre cliente y trabajador sobre lo que hay que hacer
 Esto permite saber previamente si el software satisfará las necesidades del cliente
antes de empezar su implementación.
 Reducir los costes de desarrollo
o un buen Sr se evita tener que hacer a posteriori revisiones de código y test
innecesarios
o una revisión del SRS puede detectar omisiones y fallos en este.
 Ofrece una base de estimado de costes
o ofreciendo así una ventaja con respecto a otras empresas
 Ofrece una base para validación y verificación
o que agiliza el desarrollo
o y ofrece un sitio en el que apoyarse contra quejas del cliente.
 Facilidad de transferencia.
o Si vale para uno, para otro con la misma casuística o similar, también.
o De la misma manera sucede esto por parte del cliente.
 Sirve de la misma manera como base para la mejora.
 Puesto que el SRS hoy discute el producto y no el proyecto que lo manufacturará, sirve
para mejorar este.

A partir de ahora, hasta nuevo aviso, se seguirá el IEEE 830-1998.

Tema 4: UML
El “unified modeling language” es un lenguaje para modelar sistemas.

Puede considerarse un estándar. Especifica un conjunto de notaciones. Puede utilizarse para:

 Visualizar
 Especificar
 Construir y…
 documentar los elementos de un sistema que necesite “cierta cantidad de software”

Está compuesto por:

 elementos
 relaciones
 y diagramas.

Elementos.
Estructurales: Son la parte estática del modelo, como las clases, interfaces, casos de uso,
colaboraciones, …

De comportamiento: es la parte dinámica del modelo. Muestra la evolución del

comportamiento a lo largo del tiempo:

 Interacciones: Conjunto de mensajes intercambiados entre una serie de objetos.

 Máquinas de estados: Define los estados que atraviesa un sistema como respuesta a
una serie de elementos.
 Actividades: especifica la secuencia de pasos que ejecuta un proceso computacional.

Relaciones
 de dependencia: establecen
o Relación de uso semántico entre 2 elementos.
o Un cambio en el elemento independiente puede afectar a la semántica del
elemento dependiente.
  De asociación:
o Relación estructural entre clases.
o Establece conexiones entre objetos q por ejemplo empresa empleado.
o Agregación y composición: relación estructural entre un todo y sus partes
o Se representan:

 Generalización:
o Relación de especialización /generalización
o Herencia
o El hijo se basa en la estructura y funcionalidad del padre, al que puede llegar a
sustituir.

 Realización
o Relación semántica entre clasificaciones
o Un extremo especifica un contrato que el otro deberá cumplir
o Lo encontraremos en interfaces/clases

Tipos de diagramas UML

Diagramas
De casos de uso: muestra un actor, casos de uso y sus relaciones. Indican que hace el sistema
coma no cómo. Es la frontera entre el es la frontera entre el análisis y el diseño.

De clases: Visión estática del sistema. Muestran las clases coma e interfaces y colaboraciones
existentes, así como las relaciones.

De paquetes: Muestra la descomposición del modelo en unidades organizativas y sus

dependencias.

De interacción: visión dinámica asociada a un escenario.

 Diagrama de secuencia.
o Muestra un conjunto de objetos o roles y los mensajes que se intercambian.
o Resalta ordenación temporal de mensajes.
 Diagrama de colaboración/comunicación:
o Es equivalente al anterior.
o Resalta la organización estructural de los elementos que envían mensajes.
 De actividades:
o un tipo de diagrama de estados.
o Muestra un flujo de control entre objetos.
o Detallan paso a paso qué cosas suceden. Asociadas a un escenario.
 De Estado:
o HP muestra una máquina de estados formada por estados coma y transiciones,
eventos y actividades.
o Hola muéstrame el comportamiento dinámico dirigido por eventos de un
objeto/subsistema/sistema.
o Hola útil en sistemas reactivos: interfaces de usuario, workflow, sistemas de
control...
 Hola de componentes (composed structure diagram)
o HD define las partes del sistema y la comunicación entre ellos (vía interfaces)
 HP de despliegue:
o muestra los nodos de procesamiento en tiempo y ejecución. Hoy además
también muestra los artefactos que residen en ellos.

Arquitectura Software:
La visualización, especificación, construcción y documentación de un sistema complejo con una
gran cantidad de software, requiere que sea visto desde varias perspectivas.

Usuarios finales como analistas, desarrolladores, publicistas, etcétera. Van a tener visiones
distintas sobre cómo se va a describir el software.

La arquitectura se define a partir de:

 La organización del sistema software.

 La selección de elementos estructurales y sus interfaces.
 Descripción sobre su comportamiento.
  La composición de esos elementos estructurales y de comportamiento, (formando
subsistemas más grandes).
 El estilo arquitectónico que guía esa organización.

En UML, un sistema software complejo puede describirse a partir de 5 vistas interrelacionadas:

 Vista de diseño
 Vista de interacción
 Vista de casos de Uso
 Vista de implementación
 Vista de despliegue

UML: Casos de Uso

Diagramas de Despliegue (deployment)

Elementos:

 Nodos:
o Es un elemento físico
o Representa un recurso computacional
o Existe en tiempo de ejecución
o Entre ellos pueden existir relaciones de dependencia, generalización y
asociación
 Artefactos:
o Elementos que van a alojarse en un nodo. Normalmente ficheros.
o Ejemplo: ficheros ejecutables o similares (.exe, .jar, .dll, …)
o Ficheros de configuración, librerías, etc.

Usos habituales:

 Modelado de procesadores y dispositivos

 Distribución de componentes
 Descripción de sistemas distribuidos
Diagramas de Clases (UML)
Componentes básicos de un diagrama de clases, compuesto de tres partes:

 Sección superior: Contiene el nombre de la clase

 Sección central: Contiene los atributos de la clase
 Sección inferior: Contiene las operaciones de la clase (métodos).

Modificadores de acceso a los miembros: Son los modificadores que pondremos en cada una
de las líneas de una clase:

 Público (+)
 Privado (-)
 Protegido (#)
 Paquete (~)
 Derivado (/)
 Estático (subrayado)

También hay más tipos de componentes, como señales, tipos de datos, paquetes, interfaces,
enumeraciones, objetos, artefactos, etc.

Finalmente, a la hora de relacionar las diferentes clases que modelan nuestro sistema,
tenemos las Interacciones, estas constan de:

 Herencia (flecha completa sin rellenar)

 Asociación bidireccional:
  Asociación unidireccional:

Ejemplo de un diagrama de clases completo: