1.

Principios de Diseño de software

I
● Abstracción
○ Dos mecanismos clave de abstracción son la parametrización y la
especificación. La abstracción por especificación conduce a tres tipos
principales de abstracción:
■ abstracción procesal,
■ abstracción de datos y
■ abstracción de control (iteración).
● Acoplamiento y cohesión
○ El acoplamiento se define como la fuerza de las relaciones entre módulos,
mientras que la cohesión se define por cómo los elementos que componen
un módulo están relacionados.
● Descomposición y modularización
○ Descomponiendo y modularizado software grande en varios más pequeños
independientes.
II

● Encapsulación / ocultación de información

○ Significa agrupar y empaquetar los elementos y detalles internos de una
abstracción y hacer esos detalles inaccesible.
● Separación de interfaz e implementación
○ Implica definir un componente especificando una interfaz pública, conocida
por los clientes, separada de los detalles de cómo se realiza el componente.
● Suficiencia e integridad
○ Lograr la suficiencia y la integridad significa garantizar que un componente
de software capture todo lo importante características de una abstracción, y
nada más.

2. Consideraciones clave en el diseño de software

● Concurrencia
○ Cómo descomponer el software en procesos, tareas y subprocesos y tratar
problemas relacionados con la eficiencia, la atomicidad, la sincronización y la
programación.
● Control y manejo de eventos
○ Cómo organizar el flujo de datos y control, cómo manejar eventos reactivos y
temporales a través de diversos mecanismos, como la invocación implícita y
las devoluciones de llamada.
● Distribución de componentes
○ Cómo distribuir el software a través del hardware, cómo se comunican los
componentes, cómo se puede utilizar el middleware para lidiar con
heterogéneos software.
● Manejo de errores y excepciones y tolerancia a fallas
○ Cómo prevenir y tolerar fallas y lidiar con condiciones excepcionales.
● Interacción y presentación
 ○ Cómo estructurar y organizar las interacciones con los usuarios y la
presentación de información (por ejemplo, separación de presentación y
negocio lógica utilizando el enfoque Modelo-Vista-Controlador).
● Persistencia de datos
○ Cómo se deben manejar los datos de larga duración.

3. Estrategias y métodos de diseño de software

DISEÑO ORIENTADO A FUNCIONES (ESTRUCTURADO)

● Este es uno de los métodos clásicos de diseño de software, donde la

descomposición se centra en identificar principales funciones de software y luego
elaborarlas y refinar las de arriba hacia abajo.
● Design El diseño estructurado se usa generalmente después de un análisis
estructurado, produciendo, entre otras cosas, datos diagramas de flujo y
descripciones de procesos asociados.

DISEÑO ORIENTADO A OBJETOS

● Se han propuesto numerosos métodos de diseño de software basados en objetos.

● Field El campo ha evolucionado desde el diseño inicial basado en objetos de
mediados de la década de 1980 (sustantivo = objeto; verbo = método; adjetivo =
atributo) a través del diseño OO,
● La herencia y el polimorfismo juegan un papel clave.
● Design El diseño basado en la responsabilidad también se ha propuesto como un
enfoque alternativo para el diseño OO

DISEÑO BASADO EN COMPONENTES (CBD)

● Un componente de software es una unidad independiente, con interfaces y

dependencias bien definidas que pueden estar compuesto y desplegado de forma
independiente.
● Design El diseño basado en componentes aborda problemas relacionados con la
provisión, desarrollo e integración de tales componentes para mejorar la
reutilización.

4. Definición de arquitectura

“La arquitectura software implica la descripción de los elementos desde los que se
construye el sistema, interacciones entre esos elementos, patrones que guían su
composición, y restricciones en
estos patrones”

“La arquitectura software de un programa o sistema informático es la estructura o

estructuras del sistema, que comprende componentes software, las propiedades
externamente visibles
de estos componentes y las relaciones entre ellos”.
● El proceso de diseño para la identificación de los sub-sistemas que componen un
sistema y el marco para el sub-sistema de control y comunicación.
○ El resultado de este proceso de diseño es una descripción de la arquitectura
de software.

5. Estilo de Objetos

● Los componentes son objetos

○ Datos y operaciones asociadas
● Los conectores son mensajes para invocar métodos.
○ Invariantes del estilo
● La representación interna está escondida
○ Ventajas
■ Cambiar la representación interna sin afectar a los clientes
■ Descomposición del sistema en un conjunto de agentes que
interaccionan
○ Desventajas
■ Los objetos deben conocer la identidad de otros objetos

6. Estilo por Capas

● Organización jerárquica del sistema

○ Cliente-servidor multi-nivel
○ Cada capa soporta un API para que lo utilice la capa superior
● Los conectores son protocolos de interacción entre capas
● Las restricciones topológicas: interacción sólo entre capas adyacentes

7. Estilo Repositorio

● Dos tipos de componentes:

○ estructura de datos central que representa el estado actual
○ componentes independientes operando en esa estructura central
● Dos subtipos:
○ Si las acciones parten de los componentes, BD
○ Si a los componentes los dispara la estructura: blackboard.
● En el estilo blackboard el control es dirigido por el estado de la estructura central
(ejecución oportunista de los componentes).

8. Estilo Microservicios

● "Arquitectura de microservicios" describe una forma particular de diseñar

aplicaciones de software como conjuntos de servicios implementables
independientemente.
● Características
 ○ Altamente mantenible.
○ Se puede testear.
○ Bajamente acoplado.
○ Despliegue independiente.
○ Organizado alrededor de capacidades de negocio.
○ Mantenido por un grupo pequeño.
● API REST
○ API es un servicio backend que se utiliza para conectar dos aplicaciones.
○ REST es un estilo de arquitectura de software (desarrollado por Leonard
Richardson) que se utiliza para describir cualquier interfaz entre diferentes
sistemas que utilice HTTP para comunicarse.
○ Diseño
■ Tipo de contrato: Swagger 2.0 (Open API)
■ Información general: nombre, descripción y versión
■ Protocolos soportados: HTTPS
■ Verbos: GET, POST, PUT y DELETE
■ Seguridad: Basic Auth, Oauth 2.0

9. Estilo de Descomposición modular

● Los estilos de la descomposición de subsistemas en módulos.

● No hay distinción rígida entre la organización y la descomposición modular del
sistema.

10. Importancia de la construcción

● Es la etapa más larga del proceso de desarrollo de software.

● Es la actividad central del proceso de desarrollo de software.
● Con un enfoque en la construcción, la productividad del programador individual
puede mejorar enormemente.
● El código fuente, es a menudo la única descripción exacta del software.
● Construction is the only activity that’s guaranteed to be done.
● La construcción es la única actividad que debe garantizarse.
● La calidad de la construcción afecta considerablemente a la calidad del producto de
software
 11. Decisiones clave en la construcción

● Elección del lenguaje de programación

● Convenciones de codificación
● Localización en la onda tecnológica
● Selección de las mejores prácticas de construcción

12. Entidad, Atributo y Métrica

ENTIDAD

● Objeto que va a ser caracterizado a través de la medición de sus atributos

● Entidades a medir en Ingeniería de Software
○ Producto
■ Cualquier artefacto, producto o entregable que resulte de los
procesos de Ingeniería de Software
■ Ejemplos: SRS, diseños UML, código fuente.
○ Proceso
■ Todas las actividades del ciclo de vida del software
■ Conocer el estado de los procesos y cómo se llevan a cabo
■ Ejemplos: Elicitación, especificación, diseño, implementación,
metodologías de construcción
○ Recurso
■ Cualquier entrada de una actividad de un proceso.
■ Ejemplos: Licencias, computadores, personal, infraestructura

ATRIBUTO

● Característica medible de una entidad

● Los atributos de una entidad (proceso, producto o recurso) pueden ser de dos tipos:
○ Internos
■ Se pueden medir directamente a partir de la entidad
■ Sirven para la medición de atributos externos
○ Externos
■ Atributos que relacionan a las entidades con el entorno.
■ Se miden mediante métricas indirectas
■ Suelen relacionarse con la Calidad

METRICA

● Evaluación cuantitativa del grado en el cual un producto o proceso de software

posee un atributo
● determinado
● Tipos de métricas de software
○ Directas: Obtenidas directamente de la entidad. Ej: longitud de código,
número de defectos
○ Indirectas: Derivadas de una o más métricas. Ej: densidad de defectos
 ○ Objetivas: Valor independiente del operador
○ Subjetivas: La persona que realiza la medición introduce factores de juicio en
el resultado

13. Métricas de tamaño de los sistemas

● Se utilizan como umbrales o indicadores de posibles problemas.

● McCabe establece que si una función, procedimiento o método excede las 60 líneas
es más propensa a tener errores.
● Líneas de código (LoC)
○ Más utilizadas por su facilidad y simplicidad de cálculo.
○ Existen variantes:
■ DSI: Delivered Source Instruction (número de sentencias efectivas)
■ NCLoC: Líneas no comentadas
■ CLoC: Líneas comentadas
○ Indicador de densidad de comentarios
■ DoC=CLoC/(LoC+CLoC)
● SIZE1
○ Número de puntos y coma
○ Se creo para evitar el problema de la ambigüedad de de LoC

FUNCIONES

1. Determinar el tipo de conteo de puntos de función

2. Identificar los componentes funcionales que formarán parte el conteo.
3. Identificar las transacciones de negocio
4. Identificar los componentes de datos
5. Determinar el conteo de puntos función

14. Métricas de la complejidad del software

● Complejidad ciclomática
○ Número de caminos independientes dentro de un método.
○ NO mide ciclos.
○ Fórmula: Número de condiciones + 1.
● Resultados
○ 1-10 Programa Simple, sin mucho riesgo.
○ 11-20 Programa de riesgo moderado.
○ 21-50 Programa de alto riesgo.
○ 50 Programa de muy alto riesgo, no se puede probar.
(HALSTEAD)

● Estas métricas se calculan estáticamente a partir del código.

● Métricas
○ Operadores = Palabras reservadas, aritméticos, asignación y lógicos
○ Operandos = Constantes, variables e identificadores
○ n1= #TotalOperadoresDistintos
○ n2 = #TotalOperandosDistintos
○ N1= #TotalOperadores
○ N2 = #TotalOperandos
● Fórmulas
○ Vocabulario n=n1 + n2
○ Longitud N=N1 + N2
○ Volumen V=Longitud * Log2n
○ Dificultad D=(n1/2) * (N1/n2)
○ Esfuerzo mental E=Dificutad * Volumen
○ Errores B=Volumen / 3000
○ Tiempo T=E / 18

(FAN-IN FAN-OUT)

● Cuenta el número de llamadas entre módulos

● FAN-IN de m
○ Concentración
○ Número de flujos que terminan en m
● FAN-OUT de m
○ Expansión
○ Número de flujos que salen de m
● Complejidad de un módulo
○ longitud = número de sentencias del módulo m
○ MHK = longitud(m) * [fan-in(m) * fan-out(m)]2

(ARQUITECTURAS DE SOFTWARE)

● Tamaño = n + a
○ n es el número de nodos
 ○ a es el número de arcos
● Profundidad = trayectoria más larga desde el nodo raíz (superior) hasta un nodo
hoja.
● Ancho = número máximo de nodos en cualquier nivel de la arquitectura.

15. Métricas para organizaciones pequeñas

● “La gran mayoría de las organizaciones de desarrollo de software tienen menos de

20 personas en sus departamentos de software […] No es razonable, y en la
mayoría de los casos es irreal, esperar que tales organizaciones desarrollen
programas de métricas de software exhaustivos.”

Roger Pressman

● Eficiencia de remoción de defecto

○ Medida de mejora del proceso
○ Ecambio / (Ecambio + Dcambio)
○ Tiempo transcurrido (horas o días) desde el momento en el que se hace una
petición hasta que la evaluación está completa, (tcola)
○ Esfuerzo (persona-horas) para realizar la evaluación, (Weval)
○ Tiempo transcurrido (horas o días) desde la conclusión de la evaluación
hasta la asignación de la orden de cambio al personal, (teval).
○ Esfuerzo requerido (persona-horas) para hacer el cambio, (Wcambio).
○ Tiempo requerido (horas o días) para hacer el cambio, (tcambio).
○ Errores descubiertos durante el trabajo para hacer el cambio, (Ecambio).
○ Defectos descubiertos después de liberar el cambio al cliente base,
(Dcambio).

16. Desarmonías de identidad

● Feature Envy (Fowler)

○ Los métodos están más interesados en otras clases que en su propia clase.
● Data Class (Fowler)
○ Agrega datos pero no comportamiento.
○ Síntoma de una mala encapsulación de datos y funcionalidad
● God class (Fowler)
○ Interactúa con muchas otras clases, centraliza el funcionamiento y realiza
demasiado trabajo.
● Brain Method
○ El método tiene una complejidad muy alta y contiene la mayoría de las
funcionalidades de la clase.
○ A veces incluso la funcionalidad de todo el sistema
● Brain Class
○ Contiene muchos “Brain method”
● Significant Duplication (Fowler)
○ Alta duplicación de código