En el paradigma de objetos, los componentes son...

objetos (a bajo nivel, marcamos los componentes con

círculos), las responsabilidades están definidas por la interfaz del objeto. Recordamos interfaz vs.
implementación; interfaz es lo que le puedo pedir a un objeto que haga (mensaje), la implementación es
cómo lo termina resolviendo (método). ¿Cómo se relacionan los objetos? Claro, enviándose mensajes.
Pero para eso se tienen que conocer. ¿Y cómo los conozco? Mediante una referencia temporal (variable
local, parámetro) o más permanente (variables de instancia o de clase, más allá de las variables globales
que no nos interesa tratar).

UML – Diagrama de Clases

Diagrama de clases

Modela cualquier elemento estructural (Clases) del sistema, y sus relaciones. Una clase, sus atributos y sus métodos
(operaciones) se representa así:

El estereotipo sirve para dar una particularidad a la clase, es como declararle un tipo, por tanto, puede haber unas
clases de un estereotipo, otras de otro, etc. Podríamos escribir un diagrama de cualquier tipo de los mencionados
hasta ahora con un diagrama de clases usando estereotipos:

Un ejemplo algo más complejo con otros tipos de relaciones (herencia, composición, etc.) sería este:
Casuística típica del trabajo con diagramas

¿Qué se hace con los diagramas?:

● Ingeniería directa: Diagramas hechos desde cero, diagramas de todo tipo.

● Ingeniería inversa: A partir de un código fuente se generan los diagramas, normalmente de clases, aunque
también pueden ser de secuencia.
● Validación: Ver un diagrama para ver si está bien hecho. Debería haber alguien que revise y valide los
diagramas desde el punto de vista de negocio, y desde el punto de vista técnico.
● Aplicación de patrones: Consiste en identificar patrones de diseño dentro del diagrama de clases.

Tipos de relaciones

● Asociación (línea continua, flecha abierta). Cooperación entre clases.

● Herencia (línea continua acabada en triángulo). Un elemento adquiere las propiedades de otro.
● Dependencia (línea discontinua, flecha abierta). Vínculo genérico de necesidad entre clases.
● Implementación (línea discontinua acabada en triángulo). El elemento origen de la flecha “realiza” al
elemento destino. Quiere decir que implementa la interfaz definida por el destino.

Diagramas de Clases
Para ver algunas de las relaciones que se pueden representar en un diagrama de clases, vamos a dibujar un diagrama
de lo que podría ser un sistema de gestión de regalos:

En el diagrama podemos ver 4 tipos distintos de relaciones entre las clases:

● Realización o implementación: ClientProxy implementa la interfaz definida por ClientFacade.

 ● Asociación de uso: La clase ClientProxy usa la clase GenericClient. Los métodos de ClientProxy devuelven o
toman como parámetros objetos de la clase GenericClient.
● Generalización o herencia: StandardClient y VipClient heredan de GenericClient.
● Dependencia: GenericClient depende de GiftController, podría ser una asociación de uso perfectamente.

Todas las clases definidas deberían tener atributos y métodos, si una clase no tiene alguno de ellos, posiblemente no
haría falta crearla.

Relaciones de asociación específicas

Las relaciones también se pueden caracterizar por:

● Estereotipo.
● Navegabilidad. La dirección de la flecha o flechas de la relación especifica desde donde o hasta donde se
puede navegar desde una clase.
● Cardinalidad.
● Restricciones: Se representan con ‘{}’. Por ejemplo: {balance < 5000}.
● Roles: Es el papel que juega la clase dentro de la relación (titular/propiedad, profesor/alumno). No se suele
usar, sobre carga el diagrama.

Subtipos de asociaciones

● Agregación: Una clase se compone de objetos de otras clases. Por ejemplo una factoría que monta coches. El
coche se compone de ciertas partes como ruedas, volante, etc. Los componentes tienen sentido por
separado, pero juntos forman el coche.
● Composición: Una clase crea objetos de otras clases, y éstas no tienen sentido si la clase que las crea. Por
ejemplo los movimientos de una cuenta no tienen sentido si la cuenta deja de existir. Otro ejemplo podría
ser el humo que sale de un coche. El humo no puede existir si no existe el coche.
Interfaces
Un interfaz es un elemento de programación que define métodos sin código. Se representa así:

Se dice que define lo que puede hacer, pero no cómo lo hace. Son los implementadores de la interfaz los que dicen
cómo se hace, es decir, los que implementan una manera propia de realizar los métodos/operaciones definidos por
la interfaz. Un interfaz es como un estándar.

Esto no quiere decir que todos los implementadores lo hagan bien, un implementador puede dejar el método en
blanco, o puede hacerlo mal. Un ejemplo real puede ser una conexión de BBDD en en Java. Se define una interfaz en
las clases estándar de Java, y cada fabricante crea una implementación para usar sus BBDD:
 Patrones de diseño
Estructura

• Propósito
• Motivación
• Participantes
• Colaboraciones
• Consecuencias
• Implementación
• Usos conocidos
• Patrones relacionados

Partes esenciales

• Nombre: Comunica el objetivo del patrón en una o dos palabras. Aumenta el vocabulario sobre diseño.
• Problema: Describe el problema que el patrón soluciona y su contexto. Indica cuándo se aplica el patrón.
• Solución: Indica cómo resolver el problema en términos de elementos, relaciones, responsabilidades y
colaboraciones. La solución debe ser lo suficientemente abstracta para poder ser aplicada en diferentes
situaciones.
• Consecuencias: Indica los efectos de aplicar la solución. Son críticas al momento de evaluar distintas
alternativas de diseño.

Clasificación

Los patrones de Diseño se clasifican en tres grandes categorías:

• Creacionales: abstraen el proceso de creación/instanciación de los objetos. Se los suele utilizar cuando debemos
crear objetos, complejos o no, tomando decisiones dinámicas en momento de ejecución.

• Comportamiento: resuelven cuestiones, complejas o no, de interacción entre objetos en momento de ejecución.

• Estructurales: resuelven cuestiones, generalmente complejas, de generación y/o utilización de estructuras

complejas o que no están acopladas al dominio.
Requerimientos

Definición IEEE-Std-610 (1990)

1. Condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo.

2. Condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un
contrato, un estándar, una especificación u otro documento formalmente impuesto.

3. Representación documentada de una condición o capacidad.

Requerimientos del usuario: Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera
que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.

Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operativas del sistema. El
documento de requerimientos del sistema (algunas veces denominado especificación funcional) debe ser preciso.
Debe definir exactamente qué es lo que se va a implementar.

A su vez, los requerimientos del sistema se clasifican en: Requerimientos funcionales y no funcionales.

Requerimientos Funcionales: “Describe lo que el sistema debe hacer”. Son declaraciones de los servicios que debe
proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe
comportar en situaciones particulares. En algunos casos, los requerimientos funcionales también pueden declarar
explícitamente lo que el sistema no debe hacer.

Requerimientos No Funcionales: No se refieren directamente a las funciones específicas que proporciona el sistema,
sino a las propiedades emergentes de este. Ejemplo: disponibilidad, tiempo de respuesta, seguridad, capacidad de
almacenamiento. Son restricciones de los servicios ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre
el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su
totalidad.

 La importancia del rol de los Requerimientos:

 Es un acuerdo entre desarrolladores-clientes-usuarios finales (interesados del proyecto).
 Base para el diseño del sistema.
 Soporte para verificación y validación.
 Soporte para la evolución del sistema.
 Detección temprana de errores
Especificación de Requerimientos de Software (SRS)

Una especificación de requerimientos de software (Software Requirements Specification) es un documento formal

que se crea cuando debe especificarse una descripción detallada de todos los aspectos del software que se va a
elaborar. Su contenido incluye: Requerimientos Funcionales, No Funcionales, Interfaces, Atributos especiales y otros.

Influencia del proceso de diseño

Stakeholders (parte interesada)

Son los individuos u organismos que ganan o pierden con algún cambio, son impactados positiva o negativamente
independientemente o no de su voluntad. Tienen interés en el resultado.

Interesados en su construcción: Responsabilidad por el diseño y desarrollo (Project Managers, Diseñadores,

Expertos)
Interés financiero: Responsabilidades sobre la compra o venta del desarrollo (Analistas de negocios, gerente de
compras, ventas)

Interesados en el despliegue y operación: Responsables de implementación y mantenimiento (Equipo de

capacitación, soporte, infraestructura)

Responsables de implementación y mantenimiento (Equipo de capacitación, soporte, infraestructura) Interesados

en el uso Todos los usuarios (directos e indirectos)

Ambiente de Desarrollo y Uso del Sistema

"El proceso de software siempre involucra transformaciones desde modelos mentales informales hasta una
implementación formal (que detalla cómo operará la solución provista)".

Se necesita de la abstracción para tratar con la complejidad:

- Es un examen selectivo de ciertos aspectos

- Su objetivo es destacar los aspectos importantes y suprimir los no importantes

Modelo

¿Qué es un modelo?

“Un modelo es una simplificación de la realidad”

Un buen modelo incluye aquellos elementos de gran injerencia y omite aquellos elementos que no son de
importancia para el nivel dado de abstracción.

Cada sistema puede ser descrito desde diferentes enfoques empleando diferentes modelos, donde cada modelo es
una abstracción semántica del sistema Un modelo puede ser estructural, con énfasis en la organización del sistema,
o puede ser conductual, haciendo énfasis en la dinámica del sistema.

¿Qué es un modelo de proceso de software?

“Un modelo de procesos del software es una descripción simplificada de un proceso del software que presenta una
visión (abstracción) de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y
productos de software y el papel de las personas involucradas en la ingeniería de software”.

¿Por qué se modela?

“Se modela para poder comprender mejor el sistema que se está desarrollando”

1. Los modelos ayudan a visualizar un sistema o cómo se pretende que sea.

2. Permiten especificar la estructura o el comportamiento de un sistema.

3. Son una plantilla que guía en la construcción de un sistema.

4. Los modelos documentan las decisiones tomadas.

¿Por qué se modela?

En software, según el modelo que se elija esto puede afectar profundamente la visión del mundo.

 Diseñador de base de datos

 Desarrollador orientado a objetos
 Analista estructurado
 Arquitecto

UML

“Es un lenguaje estándar para escribir diseños de software. El UML puede usarse para visualizar, especificar,
construir y documentar los artefactos de un sistema de software intensivo”

UML es bastante independiente del proceso, lo que significa que no está ligado a ningún ciclo de vida de desarrollo
de software en particular. Sin embargo, para obtener el máximo beneficio de UML, se debería considerar un proceso
que fuese:

 Dirigido por los Casos de Uso

 Centrado en la Arquitectura
 Iterativo e incremental

Diagramas UML

Con UML se construyen modelos a partir de bloques de construcción básicos. Los diagramas son un medio para ver
estos bloques de construcción. Un diagrama es una representación gráfica de un conjunto de elementos, que la
mayoría de la veces se dibuja como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se
utilizan para visualizar un sistema desde diferentes perspectivas.

Resumen UML

 UML es una herramienta de apoyo a la visualización, especificación y documentación de los artefactos de un

sistema de software.
 UML puede emplearse en diferentes etapas del ciclo de vida del desarrollo y en diferentes tecnologías de
implementación.
 UML es independiente del proceso de desarrollo de software.
 UML fue adoptado por OMG (Object Management Group), que es la institución que actualmente mantiene
la especificación.

Clasificación de diagramas UML

Los diagramas estructurales de UML pueden dividirse en estáticos y dinámicos.

Los estructurales permiten ver los aspectos estructurales de un sistema, tales como los que representan su
esqueleto (skeleton) y su andamiaje (stubs).

Los diagramas dinámicos permiten visualizar, especificar, construir y documentar aspectos de comportamiento de
un sistema. Así como los aspectos dinámicos de una construcción incluyen flujos de aire y tránsito entre las
habitaciones, los aspectos dinámicos de un sistema de software involucran cosas tales como el flujo de mensajes
entre los componentes
Ciclo de vida

(Según el Proceso Unificado) Se pueden definir 4 fases en el ciclo de vida del desarrollo de software: Concepción,
Elaboración, Construcción y Transición. En el diagrama, se representan los ejes: fase y actividad. El área en gris
representa el nivel de atención que requiere esa actividad según la fase.

Fases

Concepción: Es la fase donde surge la idea inicial y debe estar lo suficientemente bien fundamentada.

Elaboración: Es la fase donde se definen los requisitos del producto y su arquitectura.

Construcción: Es la fase cuando el software se lleva desde una base arquitectónica hasta su disponibilidad.

Transición: Es la fase donde el software es puesto en manos de la comunidad de usuarios.

Requerimientos (BIEN DEFINIDOS)

“Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus
restricciones operativas. Estos requerimientos reflejan las necesidades de los clientes de un sistema que ayude a
resolver algún problema” Ian Sommerville

“La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que desea el cliente,
analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin
ambigüedades, validar la especificación y administrar los requerimientos a medida de que se transforman en un
sistema funcional” Roger Pressman.

Definición IEEE-Std-610 (1990)

1. Condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo.

2. Condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un
contrato, un estándar, una especificación u otro documento formalmente impuesto.

3. Representación documentada de una condición o capacidad.

Niveles de requerimientos

 Requerimientos del usuario: Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se
espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.

 Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operativas del
sistema. El documento de requerimientos del sistema (algunas veces denominado especificación funcional)
debe ser preciso. Debe definir exactamente qué es lo que se va a implementar

Clasificación

 Requerimientos Funcionales:

“Describe lo que el sistema debe hacer” Son declaraciones de los servicios que debe proporcionar el sistema, de la
manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones
particulares. En algunos casos, los requerimientos funcionales también pueden declarar explícitamente lo que el
sistema no debe hacer.

 Requerimientos No Funcionales:

Describen cómo el sistema lo debe hacer. No se refieren directamente a las funciones específicas que proporciona
el sistema, sino a las propiedades emergentes de este. Ejemplo: disponibilidad, tiempo de respuesta, seguridad,
capacidad de almacenamiento. Son restricciones de los servicios ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo y estándares.

Importancia de los requerimientos

 Es un acuerdo entre desarrolladores-clientes-usuarios finales (interesados del proyecto).

 Base para el diseño del sistema.
 Soporte para verificación y validación.
 Soporte para la evolución del sistema.
 Detección temprana de errores.

Calidad

Peter Drucker:

“Calidad es lo que el cliente está dispuesto a pagar en función de lo que obtiene y valora”.

IEEE

● Grado en que un sistema, componente o proceso satisface los requerimientos especificados.

● Grado en el que un sistema, componente o proceso satisface necesidades y expectativas de un cliente o usuario.

¿Que es un BUG?

Bug es el término que se utiliza coloquialmente para describir un defecto en un sistema de información.

Error / Defecto / Falla Error:

 Error: Una equivocación de una persona al desarrollar alguna actividad de desarrollo de software.
 Defecto: Se produce cuando una persona comete un error. (por ej: cuando un diseñador comprende mal un
requerimiento y crea un diseño inadecuado).
 Falla: Es un desvío respecto del comportamiento esperado del sistema. Puede producirse en cualquier etapa.

Razones de las fallas:

 Especificación errónea (incompleta o incorrecta)

 La especificación puede tener un requerimiento imposible de implementar con la infraestructura disponible
  Defecto en el diseño del sistema.
 Defecto en el diseño del alguno de los módulos.
 Código fuente de un programa erróneo (un bug)

Cómo Evaluar (Medir) La Calidad del Diseño

El principal objetivo de Calidad del Software es minimizar la presencia de bugs (en sentido amplio) en el software.
Este es el sentido más básico de conformidad con los requerimientos. Se puede expresar cuantitativamente (medir):
● tasa de defectos: número de defectos / LOC (lines of codes)

● confiabilidad: número de fallas / N° horas de operación

Un Buen Diseño

McGlaughlin sugiere tres características para evaluar un buen diseño:

● Debe implementar todos los requerimientos explícitos contenidos en el modelo de requerimientos e incluir a
todos los requerimientos implícitos que desean los participantes.

● La documentación debe ser una guía legible y comprensible para quienes generan el código y para los que lo
prueban y dan el posterior soporte o mantenimiento.

● Debe abordar tanto el dominio de los datos, como las funcionalidades y el comportamiento desde el punto de
vista de la implementación.

Pressman propone las siguientes características para evaluar un buen diseño:

● Debe poseer una arquitectura que:

○ Se haya creado con el empleo de estilos o patrones arquitectónicos reconocibles.

○ Esté formada por componentes con buenas características de diseño.

○ Se desarrolle en forma evolutiva, de modo que faciliten la implementación y las pruebas.

● Debe ser modular, es decir, el software debe estar dividido de manera lógica en elementos o subsistemas.

● Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes.

● Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar y que surjan de
patrones reconocibles de datos.

● Debe llevar a componentes que tengan características funcionales independientes.

● Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambiente
externo.

● Debe obtenerse con el empleo de un método repetible motivado por la información obtenida durante el análisis
de los requerimientos del software.

● Debe representarse con una notación que comunique con eficacia su significado

MODELOS DE CALIDAD

McCall:

Fue el primer modelo de calidad en ser presentado en 1977 y se originó motivado por Air Forcé y Dod. Se focaliza en
el producto final identificando atributos claves desde el punto de vista del Cliente. Esto atributos se denominan
factores de calidad y son normalmente atributos externos pero también se incluyen algunos atributos internos.
Organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un
producto, basándose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se
desglosa en criterios de calidad.
FURPS

Hewlett-Packard en el año 1987 desarrolló un conjunto de atributos de la calidad del software a los que se dio el
acrónimo FURPS: Funcionalidad, Usabilidad, Confiabilidad, Rendimiento y Mantenibilidad.

Los atributos de calidad FURPS representan el objetivo de todo diseño de software:

● La funcionalidad se califica de acuerdo con el conjunto de características y capacidades del programa, la

generalidad de las funciones que se entregan y la seguridad general del sistema.

● La usabilidad considera que el software debe ser fácil de utilizar, sin esfuerzo adicional, por el usuario para quién
está diseñado. Esto significa que debe tener una interfaz de usuario apropiada y una documentación adecuada.

● La confiabilidad se evalúa con la medición de la frecuencia y gravedad de las fallas, la exactitud de los resultados
que salen, el tiempo medio para que ocurra una falla (TMPF), la capacidad de recuperación ante ésta y lo predecible
del programa.

● El rendimiento se mide con base en la velocidad de procesamiento, el tiempo de respuesta, el uso de recursos, el
conjunto y la eficiencia.

● La mantenibilidad combina la capacidad del programa para ser ampliable (extensibilidad), adaptable y servicial
(estos tres atributos se denotan con un término más común: mantenibilidad), y además que pueda probarse, ser
compatible y configurable y que cuente con la facilidad para instalarse en el sistema y para que se detecten los
problemas.

ISO 9126

El modelo de calidad ISO 9126 es un estándar internacional para la evaluación del software. Se basó (principalmente)
en el trabajo de los autores McCall (1977), Boehm (1978) y el modelo FURPS.

Identifica 6 atributos principales que caracterizan la calidad del software:

● Funcionalidad (Functionality)

● Confiabilidad (Reliability)

● Usabilidad (Usability)

● Eficiencia (Efficiency)

● Mantenibilidad (Maintainability)

● Portabilidad (Portability)
8 Dimensiones de la calidad

En 1987, David A. Garvin publicó en la Harvard Business Review su artículo “Compitiendo en las Ocho Dimensiones
de la Calidad” en donde propone detalladamente un nuevo modelo para la Calidad: la Gestión Estratégica de la
Calidad, convirtiéndose en el más reciente Gurú de la Calidad.
ISO 25000

La serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC 9126 (Software Product Quality) e
ISO/IEC 14598 (Software Product Evaluation).

Su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de
requisitos de calidad.

Establece criterios para la especificación de requisitos de calidad de productos software, sus métricas y su
evaluación.
La integración de ISO 9126 e ISO 15939 permiten plantear un proceso de 4 pasos:

1. Identificación de los requerimientos relacionados a la calidad del producto, es decir, seleccionar la parte del
modelo de calidad (ISO/IEC 9126-n) que resulta relevante para la evaluación de calidad.

2. Identificación del contexto de interpretación. Es decir, selección de los valores de 227 referencias y determinación
de los target especificados en un contexto determinado

3. Uso de las medidas derivadas de la etapa de preparación de los datos.

4. Comparación y análisis de los resultados obtenidos respecto de un conjunto de valores de referencia.

COSTOS

Costos de Calidad

Solucionar defectos compite -en prioridad- con desarrollar nuevas funcionalidades y avanzar en el proyecto.

Postergar la solución de bugs, puede llevar a elevadísimos costos (tanto de tiempo, costo y esfuerzo) cuando se lo
quiera tratar.

Costos de Prevención

Costo de todos aquellos esfuerzos para asegurar la calidad del software y prevenir defectos en todas las fases del
desarrollo de software. Ejemplo: Actividades de QA, definición de procesos, mejora de procesos, etc.

Costos de evaluación

Costo del esfuerzo para descubrir la condición de la calidad del software (evaluaciones planificadas). Ejemplo:
Auditorías, testing, estabilización, etc.

REGLA 1-10-11

 La regla 1 – 10 – 100 establece que si no se arregla un problema en el momento en que ocurre, se
volverá más costoso de arreglar más tarde, tanto en términos de dinero como de tiempo.