Ingeniería Del Software I

1. Escalabilidad
2. Calidad
3. Productividad
4. Repetibilidad
5. Cambios

1. Funcionalidad
2. Confiabilidad
3. Usabilidad
4. Eficiencia
5. Mantenibilidad
6. Portabilidad

1. Dibujar el diagrama de contexto: único transformador.

2. Dibujar el DFD del sistema existente

3. Modelado del sistema propuesto: Dibujar el DFD del sistema propuesto e identificar la frontera hombre-máquina

+ que es,
Es una implementación parcial de un sistema cuyo propósito es aprender algo del problema a resolver o del enfoque de la solución

+ enfoques,
Throwaway, descartable
Evolutionary, evolutivo

+ cuándo es necesario,
Los requerimientos de dividen en tres grupos: los entendidos, los parcialmente comprendidos y los desconocidos. Además los requerimientos parcialmente comprendidos pueden ser críticos o no. Si el conjunto de requerimientos críticos parcialmente comprendidos es substancial, es necesario un prototipo (descartable).

+ tipos de prototipado
Vertical: Una parte del sistema se construye completamente
Horizontal: El sistema es organizado como una serie de capas y alguna capa es el foco del prototipo.

1. Correcta
2. Completa
3. No ambigua
4. Consistente
5. Verificable
6. Rastreable
7. Modificable
8. Ordenada en aspectos de importancia y estabilidad

Se determina solo con la SRS.
Define el tamaño en términos de la "funcionalidad".

Tipo de funciones
+ Entradas externas
+ Salidas externas
+ Archivos lógicos internos
+ Archivos de interfaz externa
+ Transacciones externas

Contar cada tipo de función diferenciado según sea compleja, promedio o simple. Y se pondera con w_ij.

C_ij determina la cantidad de funciones tipo "i" con complejidad "j"

UFP = sum(i=1, 5, sum(j=1, 3, w_ij * C_ij)

Ajustar el UFP de acuerdo a la complejidad del entorno. Se evalúa según:

Comunicación de datos
Objetivos de desempeño
Reusabilidad
Facilidad para la instalación
Intención de facilitar cambios

Cada uno de estos items debe evaluarse como:

No presente: p_i = 0
Influencia insignificante
Influencia moderada
Influencia promedio
Influencia significativa
influencia fuerte: p_i = 5

CAF = 0.65 + 0.01 sumatoria(i=1, 14, p_i)

Punto funcion ajustado = CAF * UFP

Describe los componentes y su interacción en tiempo de ejecución.

Componentes: Son entidades de ejecución, es decir, elementos computacionales o de almacenamiento de datos.

Conectores: Son mecanismos de interacción entre las componentes.

1. Pipe and filter
2. Estilo de datos compartidos (estilo pizarra o repositorio)
3. Estilo cliente servidor

4. Estilo publicar-suscribir
5. Estilo peer to peer
6. Estilo de procesos que se comunican

Architecture Trade off Analysis Method
Sirve para analizar una arquitectura y comparar

1. Recolectar escenarios
2. Recolectar requerimientos y/o restricciones
3. Describir las vistas arquitectónicas
4. Análisis específicos a cada atributo
5. Identificar puntos sensitivos y de compromisos

1. Corrección
2. Eficiencia
3. Simplicidad

1. Partición y jerarquía
2. Abstracción
3. Modularidad

El acoplamiento es un concepto inter-modular, que determina la forma y nivel de dependencia entre módulos.

Dos módulos son independientes si cada uno puede funcionar completamente sin la presencia del otro.

Factores que influyen en el acoplamiento:
1. Tipo de conexiones entre módulos
2. Complejidad de las interfaces
3. Tipo de flujo de información entre módulos

Es intra-modular. Tiene que ver con la relación de las componentes del mismo módulo. Y determina cuán fuertemente vinculados están los elementos de un módulo.

Tipos de cohesión
1. Casual
2. Lógica
3. Temporal
4. Procedural
5. Comunicacional
6. Secuencial
7. Funcional

Apunta a controlar la estructura y proveer pautas para auxiliar al diseñador en el proceso de diseño.

Pasos principales
1. Reformular el problema como un DFD
2. Identificar las entradas y salidas más abstractas
3. Realizar el primer nivel de factorización
4. Factorizar los módulos de entrada, de salida, y transformadores
5. Mejorar la estructura (heurísticas, análisis de transacciones

Objetivo: proveer una evaluación cuantitativa del diseño (así el producto final puede mejorarse).

Se aplican dentro de UN MISMO proyecto y siempre se debe ser consistente.

1. Tamaño estimado
2. Complejidad de módulos
3. Métricas de red
4. Métricas de estabilidad
5. Métricas de flujo de información

Tipos:
1. Interacción
2. Componentes
3. Herencia

Cohesión de método
Cohesión de clase
Cohesión de Herencia

Las entidades de software deben ser abiertas para extenderlas y cerradas para modificarlas.

El comportamiento puede extenderse para adaptar el sistema a nuevos requerimientos, pero el código existente no debería modificarse. Es decir, permitir agregar código pero no modificar el existente.

Si se cumple el principio de Sustitución de Liskov se cumple el principio abierto-cerrado:

Principio de sustitución de Liskov
Un programa que utiliza un objeto O con clase C debería permanecer inalterado si O se reemplaza por cualquier objeto de una subclase de C.

En general Liskov => abierto-cerrado.

El punto de partida es el modelo obtenido durante el análisis OO. El producto final debe ser un plano de la implementación (incluyendo algoritmos y optimización).

1. Producir el diagrama de clases
2. Producir el modelo dinámico y usarlo para definir operaciones de las clases.
3. Producir el modelo funcional y usarlo para definir operaciones de las clases
4. Identificar las clases internas y sus operaciones
5. Optimizar y empaquetar

1. Métodos pesados por clases (WMC)
2. Profundidad del árbol de herencia (DIT)
3. Cantidad de hijos (NOC)
4. Acoplamiento entre clases (CBC)
5. Respuesta para una clase (RFC)

PLD es un tipo de pseudocódigo; captura la lógica completa del procedimiento, aunque revela pocos detalles de implementación.

PLD tiene la sintaxis externa de un lenguaje de programación estructurado, pero el vocabulario de un lenguaje natural.

Estructura estática: orden de sentencias en el código
Estructura dinámica: orden de ejecución de las sentencias

El objetivo es que sean lo más similares posible

1. Escribir código para implementar una funcionalidad
2. Escribir los sripts de tests
3. Correr el script de tests si hay errores arreglarlos y volver a correrlos, si no hay errores se vuelve a 1 si falta implementar otra funcionalidad sino se termina.

1. Escribir los scripts de test para alguna funcionalidad que describa la especificación
2. Escribir código que pase los tests
3. Correr el script, si hay errores, corregirlos. Si no: 4
4. Si el código necesita mejorar, refactorizar, si no: 5
5. Si falta implementar algun requerimiento: 1, si no, terminar.

La refactorización es la tarea que permite realizar cambios en un programa con el fin de simplificarlo y mejorar su comprensión (i.e. hacerlo testeable y mantenible), sin cambiar el comportamiento observacional de éste.

El objetivo es
Reducir acoplamiento.
Incrementar cohesión.
Mejorar la respuesta al principio abierto-cerrado

Refactorizaciones más comunes
DE METODOS
1. Extracción de métodos
2. Agregar/eliminar parámetros

DE CLASES
1. Desplazamiento de métodos
2. Desplazamiento de atributos
3. Extracción de clases
4. Reemplazar valores de datos por objetos

DE JERARQUÍAS
1. Reemplazar condicionales con polimorfismos
2. Subir métodos/atributos en la jerarquía de herencia