G. Semana 8 - HazelMartinez/Portafolio- GitHub Wiki

UML, PATRONES Y CALIDAD DE SOFTWARE

EL profesor da dos ejemplos para representar el concepto de empírico y profesional Representación de una casa como empírico Plano de una casa como profesional

Hay dos formas de hacer nuestros trabajos

*Metodologías de manejo de proyectos *Desarrollo de metodologías

UML

Tiene una estrecha relación con el paradigma orientado a objetos.

Paradigma Orientado a Objetos

Metodos son las operaciones en data. Nos conectamos por medio de mensajes.

Encapsulamiento:

Evitar el acceso directo con el usuario. Ocultar los detalles de la implementación.

Firma del método:

Nombre, los para metros y la salida.

Interfaz del objeto:

Conjunto de firmas.

Class: Especificación de los atributos e interfaz de los objetos.

*Se crea por un proceso de instanciación.

Herencia:

Transmitir atributos de una clase padre a una clase hija. Se extiende una clase padre. Una subclase debe acceder a todos los atributos definidos.

Clase abstracta:

Define una interfaz común para las clases.

Clase concreta:

Instancias que hacen de la clase abstracta. Se crean instancias de la clase hija.

Overwritting:

Capacidad de tomar un método de la clase padre y modificarlo a la clase hija.

Overloading: Metodos con el mismo nombre pero diferentes parametros.

Poliformismo: En tiempo de ejecución se asocia con el método de la clase.

Permite intercambiar objetos con la misma interfaz en tiempo de ejecución. ejemplo: podemos agregar a la clase animales el perro y el gato.

Composición: Se unen dos clases en uno mismo.

Acoplamiento y Cohesión

Grado de dependencia entre dos clases de un sistema. Ambas clases están estrechamente acopladas.

Cohesión: Clases a lo interno de un modulo están relacionadas.

Baja cohesión

Es que estan poco relacionadas.
Clases no dependan entre ellas.

Bajo acoplamiento:

En lo interno de cada clase si hay una estrecha relación entre los elementos.

UML

Modelado unificado de lenguaje

SDLC Ciclo de vida de desarrollo de software.

*Necesario modelar software para poder modelar la estructura. *Controlar la arquitectura del sistema. *Construir modelos para gestionar el riesgo. *Es mejor para entender el sistema que se están construyendo. *Gestionar los riesgos.

Modelamos porque es una técnica de ingeniería

Un modelo es una simplificación de la realidad (abstracción).

UML está compuesto de tres tipos de módulos.

*Funcional *Objeto *Dinámico Cada modelo compuesto de un set de diagramas.

Uses cases diagram

*Captura el comportamiento del sistema, subsistema, comparte clases. *Veo el intercambio de mensajes. *Veo las diferentes funcionalidades.

<< include >> Cuando un caso depende de otro

<< extend >> Se "podría" ejecutar, pero no necesariamente. Habrán casos donde no se va a ejecutar.

Diagrama de clases

Conocido como vista estática = No contiene información del comportamiento dinámico. Permite capturar las estructuras de los objetos. Tengo también objetos relacionados con la solución estructura de datos. class name atributos operación(nombre descriptivo) Diagramas tienen que tener multiplicidad muchas reservaciones.

Reflexivo Muchos empleados están relacionados a un empleado.

Agregación Composicion debil. Composición Composicion fuerte.

Diagrama de componentes

Diagrama de modulos del sistema y establece una relación a cada modulo.

Diagrama de secuencia

Familializar el comportamiento dinamico del sistema. Veo el flujo de comunicación.



Patrón de diseño

Estructura que puedo reutilizar, hay que re-adecuarlo. Regularidad discernible en el mundo. Los diseñadores utilizan lo que ya existe. Reutilizan soluciones.

Cada problema es único pero el patrón da una forma de resolver el problema.

*Solución general reutulizable para un problema común en un contexto especifico.

*Contiene la descripción de las comunicaciones que permiten dar solución a un problema.

Es una buena práctica una solución algo conocido a nivel mundial.

Cada patrón tiene un nombre, un problema, solución y consecuencias.

Nombre: Es corto que describe el patrón en una o dos palabras. Consecuencias: Cualquier patrón tiene costos y beneficios.

Se clasifican en propósito y alcance.

Builder: Separa la construcción y dividirlo en representaciones. Construyo partes de un producto por separado.

Debe permitir diferentes representaciones del construido. Consecuencias: Permite variar la representación interna del producto.

Patrones estructurales:

Como las clases y los objetos se componen para proveer nuevas funcionalidades.

Facade: Provee una interfaz unificada para un conjunto de interfaces.

Sistema complejo solucionado *Vista simple *Mucha dependencia *Desacoplar el sistema de los clientes Desacoplamos a los clientes del sistema

Adapter

Permite lograr que dos objetos trabajen en conjunto. Aplica cuando se tienen clases que no trabajan juntos.

Comportamiento

Observer

Define una dependencia de uno a muchos Aplica cuando una abstracción tiene 2 elementos. El uno no sabe cuantos los apuntan. Muchos dependen de 1. Los otros no saben cuantos hay. Usos: Permite comunicación masiva.

Cadena Responsabilidad

Existen varios destinarios. Cualquiera puede atender una solicitud Puede ser que no se entienda. Ej: Call Center, una llamada exclusiva de ventas.

Consecuencias *Reduce el acoplamiento, porque otros objetos contestan la situación. *Distribuye responsabilidades. *Existe una posibilidad de que no sea atendida.

¿Como seleccionar un patrón de diseño?

¿Que queremos resolver? ¿Hay acoplamiento o no? ¿Que cosas pueden cambiar? Para no tener que cambiar el diseño una vez elaborado el proyecto.

Calidad en el software

Calidad en el proceso. Calidad en el producto.

QA, QC, Testing

QA:

Aseguramiento de la calidad Asegurar que el proceso de desarrollo o de mantenimiento es adecuado y con objetivo de garantizar que se cumplan los objetivos del producto. Aplicar calidad (Auditoria)

QC:

Control de calidad Evaluar el producto que se está desarrollando,

Testing

Actividades para el control de calidad. Evaluar si el producto se esta elaborando en el proceso. Ejecuto pruebas para encontrar defectos.

El problema de no hacer pruebas es que mi producto se ve afectado. QA y QC son esenciales para encontrar calidad en el software.

⚠️ **GitHub.com Fallback** ⚠️