Ver el código de «Análisis y diseño orientado a objetos.»

= Introducción =
En términos generales se define análisis como “la distinción y separación de las partes de un todo hasta llegar a conocer sus principios o
elementos” [RAE, 2014]

Desde un punto de vista informático se define análisis como “el estudio, mediante técnicas informáticas, de los límites, características y posibles
soluciones de un problema al que se aplica un tratamiento por ordenador” [RAE, 2014]

Para la Ingeniería del Software el análisis es la parte del proceso de desarrollo de software cuyo propósito principal es realizar un modelo del dominio del problema

Se puede definir más precisamente como “el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hardware o de software , así como el proceso de estudio y refinamiento de dichos requisitos” [IEEE, 1999]

Analizar los requisitos en la forma de un modelo de análisis es importante por varios motivos [Jacobson et al., 1999]
* Un modelo de análisis ofrece una especificación más precisa de los requisitos que la que se tiene como resultado de la captura de requisitos, incluyendo al modelo de casos de uso 
* Un modelo de análisis se describe utilizando el lenguaje de los desarrolladores y puede, por tanto, introducir un mayor formalismo y ser utilizado para razonar sobre los funcionamientos internos del sistema
* Un modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su modificación y, en general, su mantenimiento
* Un modelo de análisis puede considerarse como una primera aproximación al modelo de diseño y es, por tanto, una entrada fundamental cuando se da forma al sistema en el diseño y en la implementación

= El análisis orientado a objetos =
 El análisis orientado a objetos es el proceso que modela el dominio del problema mediante la identificación y la especificación de un conjunto de
objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema [Monarchi y Puhr, 1992].

* Permite describir el sistema en los mismos términos que el mundo real
* Se centra en la comprensión del espacio (dominio) del problema
* Contiene elementos de síntesis
** La abstracción de requisitos de usuario y la identificación de los objetos clave del dominio es seguida del ensamblaje de estos objetos en estructuras de forma que soporten el diseño en fases posteriores 
* Es difícil determinar dónde acaba el análisis orientado a objetos y dónde comienza el diseño orientado a objetos
* El objetivo es modelar la semántica del problema en términos de objetos distintos pero relacionados
* El análisis casa con el dominio del problema
* Los objetos del dominio del problema representan cosas o conceptos utilizados para describir el problema (objetos semánticos)
* Los objetos del dominio del problema tienen una equivalencia directa en el entorno de la aplicación
* Se centra en la representación del problema
** Identificar abstracciones que contengan el significado de las especificaciones y de los requisitos
* El modelo de casos de uso identifica secuencias de eventos e interacciones entre actores y el sistema
* El modelo de análisis especifica las clases de objetos que se encuentran o existen en el sistema
* No existen reglas fijas para esta transformación
* Se centra en la elaboración de un modelo del sistema, el modelo de análisis
** Modelo funcional
*** Representado por los casos de uso
** Modelo objeto análisis
*** Representado por los diagramas de clase y objetos
** Modelo dinámico
*** Representado por los diagramas de secuencia y los diagramas de transición de estados

== Actividades del análisis orientado a objetos ==
* La identificación de las clases semánticas, los atributos, el comportamiento y las relaciones (generalizaciones,
agregaciones y asociaciones)
* El emplazamiento de las clases, atributos y comportamiento
* La especificación del comportamiento dinámico mediante paso de mensajes

== Tipos de proceso en análisis ==


Existen diferentes enfoques de proceso en el análisis según: 
* Centran en la información (datos) del sistema
* Centran en la funcionalidad (comportamiento) del sistema
* Síntesis de los dos procesos anteriores

El Proceso Unificado [Jacobson et al., 1999] sigue el enfoque de síntesis
* Inicio por la funcionalidad (Casos de uso)
* Refinamiento por la información (Diagramas de Clases)
* Consolidación por la funcionalidad (Diagramas de secuencia /colaboración)



= UML =

= Diagramas =

== De estructura ==	
=== Clases ===

=== Componentes ===

=== Estructura Compuesta ===

=== Despliegue ===

=== Objetos ===

=== Paquetes ===

== De comportamiento ==	
=== Actividades ===

=== Máquina de estados ===

=== Casos de Uso ===

== Interacción	==
=== Comunicaciones ===

=== Secuencia ===

=== Interacción ===

=== Temporización ===

= Patrones =
Son unos principios que deberíamos tener como base antes de proponer una arquitectura de software para el desarrollo de nuestras aplicaciones.

Estos principios nos brindan formas de pasar del código estrechamente acoplado y pobremente encapsulado a los resultados deseados de las necesidades reales de una empresa y que puede ser escalable en un futuro

Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento.

== SOLID == 
SOLID es un acrónimo de:
* S: Single Responsibility Principle (SRP)
* O: Open/Closed Principle (OCP)
* L: Liskov substitution Principle (LSP)
* I: Interface Segregation Principle (ISP)
* D: Dependency Inversion Principle (DIP)

== Patrones de diseño ==
Un patrón de diseño es una forma reutilizable de resolver un problema común.

El concepto de patrón de diseño lleva existiendo desde finales de los 70, pero su verdadera popularización surgió en los 90 con el lanzamiento del libro de Design Pattern de la Banda de los Cuatro (Gang of Four). En él explican 23 patrones de diseño

Los patrones de diseño son útiles porque suponen:
* Ahorro de tiempo
* Validez de tu código
* Uso de un lenguaje común

Los patrones de diseño nos ayudan a cumplir muchos de estos principios o reglas de diseño. Programación SOLID, control de cohesión y acoplamiento o reutilización de código son algunos de los beneficios que podemos conseguir al utilizar patrones.

Existen muchos patrones de diseño y siguen apareciendo nuevos. Detallaremos aquí los 23 patrones del libro Gang of Four clasificados en:
* Patrones Creacionales
* Patrones Estructurales
* Patrones de Comportamiento

Los patrones de diseño pretenden:
* Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
* Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
* Formalizar un vocabulario común entre diseñadores.
* Estandarizar el modo en que se realiza el diseño.
*Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:
* Imponer ciertas alternativas de diseño frente a otras.
* Eliminar la creatividad inherente al proceso de diseño.

== Patrones creacionales ==
=== Abstract factory ===

=== Builder ===

=== Factory Method ===

=== Prototype ===

=== Singleton ===

== Patrones estructurales ==

=== Adapter ===

=== Bridge ===

=== Composite ===

=== Decorator ===

=== Facade ===

=== Flyweight ===

=== Proxy ===

== Patrones de comportamiento ==

=== Chain of Responsibilty ===

=== Command === 

=== Interpreter === 

=== Iterator === 

=== Mediator === 

=== Memento === 

=== Observer === 

=== State === 

=== Strategy === 

=== Template Method === 

=== Visitor ===

= Bibliografía =

= Referencias =
* https://diagramasuml.com/diagrama-de-clases/