Diagramas de clases y patrones de diseño

SDLS ( Software Development Life Cicle)

1. Recopilación de requerimientos.
2. Análisis de requerimientos.
3. Diseño de software.
4. Implementación.
5. Pruebas.
6. Instalación y mantenimiento.

La ingeniería de software trata de crear código/software de calidad. El software de calidad puede ser determinado por varios aspectos como que sea funcionable, mantenible, reusable y que se ajuste al tiempo y presupuesto del proyecto.

Modelo Cascada:

Condujo a la crisis del software en los 80. Se duraba mucho tiempo para entregar el producto y cuando se hacía el software ya no era necesario. Además por su estructuctura se tornaba casi imposible realizar cambios al proyecto, pues se tendría que devolver a etapas más tempranas, significando más dinero y tiempo invertido. Por otro lado, no existía una comumicación con el cliente de manera constante.

Modelo en espiral:

Se realizan entregables de manera constates lo que permite realizar cambios a lo largo del proyecto. Es iterativo incremental. Las formas más comunes de este modelo es el Rational Unified Process, sin embargo, fracasó. De este modelo sale el UML.

Agile: Scrum, XP

Diseño Orientado a Objetos

• Modelo para guiar el programador durante el proceso de diseño de software bajo el paradigma OO.

• Provee un conjunto de principio para calificar que tan bien está el diseño de software.

Primera fase: Modelo Conceptual

• Entender el dominio del problema y crear un modelo conceptual. Este modelo se puede hacer a criterio del diseñador.
• Debe ser fácil de entender.
• Story Board.
• ¿Cómo calza el software en el cuadro completo?

Segunda fase: Análisis

• Construir historias de usuario/requerimientos.
• User stories siguen un formato: " yo como _rol quiero ser capaz de __acción__con el fin de objetivos
• Se pueden crear prototipos para entender mejor el problema.

Tercera fase: Arquitectura

• Definir la estructura de la solución para cumplir los requerimientos funcionales y de calidad.
• Documentar las decisiones.

Cuarta fase: Diseño detallado

• Construir de forma iterativa un diseño detallado del sistema a construir.

• Pase #1: Identifique las clases

  * Busque los sustantivos en las historias de usuario.
  * Algunos sustantivos se convertirán en clases. Otros se eliminarán y otros se unen.
  * Las clases deben tener una sola responsabilidad.
  

• Paso #2: Identifique asociaciones

  * Identificar cómo interactuán las clases entre sí.
  * Una asociación tiende a convertirse en una atributo.
  

• Paso #3: Identifique atributos y métodos

Patrones de diseño

• Un patrón de diseño es una regularidad
• En el software hay regularidades o problemas recurrentes.
• Reutilizar buenas soluciones es una buena práctica convencida por los ingenieros software. Basar nuevas soluciones en experiencias previos.

Patrón de diseño:

• Solución general para un problema común en un contexto dado.
• Es una buena práctica.
• Son conocidos por muchos profesionales a nivel mundial

Existen tres tipos de patrones de diseño:

    *  Creacionales : Determinan cómo crear objetos.
    *  Estructurales: Cómo usar objetos entre sí mediante composición.
    *  Decomportamiento: Cómo comunicar objetos sin componerlos directamente.  

Creacionales	Estructurales	De comportamiento
Factory	Adopter	Interprete
Builder	Bridge	Cadena de responsabilidad
Singleton	Composite	Comando
Prototype	Decorator	Iterador
	Facade	Memento
	Proxy	Observer
	Abstract Factory

Patrones Factory:

Crea una clase factory que crea objetos concretos mediante un selector. El caller no conoce las clases concretas.

interface Dog { 
     void bark();
}

class Rottweiller implements Dog {
     public void bark() {
    }
}

class Poodle implements Dog {
     public void bark() {
    }
}

class Dog_Factory {
  
     public static Dog getDog(DogTyped d) {
         if (d==DogTyped.BIG){
             return new Rottweiller();
         } else if (d==DogTyped.SMALL) {
             return new Poddle();
         } else {
             throw new Exception("Unknown Dog typed");
     }
}

enum DogType {
    SMALL,
    BIG;
}

Facade:

Crea una clase que funcione como fachada para un subsistema complejo. El caller interactúa con el facade y no como con el subsistema directamente.

Singleton

Patrón que permite restringir la instancanciación de una clase. Únicamente se puede instanciar una sola clase.

public class Singleton(){
        private static Singleton instance = null;
        
        private Singleton(){}


       public static synchronized Singleton getInstance(){
           if(instance == null){
                    instance = new Singleton();
           }
           return instance;

       }
}