Diferencias

Muestra las diferencias entre dos versiones de la página.

--- apuntes:diagramas [08/06/2018 09:01] – [Clase: Atributos, Métodos y Visibilidad] Fernando Valdeón
+++ apuntes:diagramas [16/09/2024 19:32] (actual) – editor externo 127.0.0.1
@@ Línea 1: / Línea 1: @@
+====== Elaboración de Diagramas ======
+===== Lenguaje de Modelado Unificado (UML)=====
+{{ :apuntes:uml_logo.svg.png?100|}}
+Es un lenguaje de modelado universal para el campo del desarrollo de software que sirve de estandar a la hora de diseñar los sistemas.
+__No es un lenguaje para crear programas__ sino para diseñar partes del mismo, su estructura, cómo se relaciona con otras partes del programa, cómo se comporta o funciona ante un usuario, los estado por los que puede pasar en su ejecución, etc. **UML es un lenguaje, por lo que usa unos símbolos concretos para cada modelo**.
+Dentro de la familia de diagramas UML hay tipos más usados habitualmente, aunque cada uno tiene su finalidad:
+{{ :apuntes:diagramas_uml.png?700 |}}
+===== Diagramas de Casos de Uso =====
+Un diagrama de casos de uso es una lista de pasos que definen la interacción entre un actor y el sistema propiamente dicho. Deben cumplir los siguientes objetivos:
+  * Indicar los requisitos funcionales: cómo funciona un programa/sistema.
+  * Proporcionar una descripción clara de su uso: cómo el usuario interactúa con el sistema.
+  * Se debe leer con claridad.
+  * Orientar en la realización de pruebas: nos dice cómo debe funcionar (requisitos).
+  * Sirve de guía para crear la documentación de uso del programa.
+Un diagrama de casos de uso debe mostrar a simple vista, qué se puede hacer con un programa desde el punto de vista de un usuario. Cada cosa que el usuario hace, //es un caso de uso//.
+{{ :apuntes:tienda_web_use_cases.png?500 |}}
+==== Elementos de un diagrama de casos de uso ====
+UML es un lenguaje, por lo que debemos usar su notación concreta para cada elemento:
+  * **Actores**: Es cualquier cosa que interactúa con el sistema, y es externo a él. No es necesariamente una persona, puede ser un dispositivo u otro sistema. Se representan mediante un //monigote//.
+  * **Casos de uso**: Representan el funcionamiento que se produce tras la orden de un actor. Se representan con una //elipse//, y dentro se escribe la descripción textual.
+  * **Relaciones**: Relacionan a los actores con los casos de uso, aunque en algunos casos también permiten relacionar unos casos de uso con otros.
+  * Un rectángulo se usa para representar los límites del sistema, si es necesario.
+{{ :apuntes:notacion_caso_de_uso.png?400 |}}
+**Para diseñar un diagrama de casos de uso se comienza por reconocer los actores y los casos de uso, para posteriormente relacionarlos.**
+{{ :apuntes:bank_use_case.png?400 |}}
+==== Relaciones entre casos de uso ====
+Las principales relaciones entre casos de uso son las de inclusión y extensión. Muchas veces se suelen confundir:
+  * **Inclusión**: Un caso de uso inicial incluye a otro caso de uso secundaria, cuando para realizar el caso de uso inicial se debe __obligatoriamente__ realizar el caso de uso secundario.
+{{ :apuntes:include_use_case_example.png?500 |}}
+  * **Extensión**: Un caso de uso extiende de otro, cuando hace algo similar pero amplía la funcionalidad. La idea es muy similar a la de herencia en programación.
+{{ :apuntes:extends_use_case_example.png?500 |}}
+===== Diagramas de Clases =====
+Un diagrama de clases nos ayuda a tener un enfoque de las relaciones entre las clases que conforman un programa.
+Está compuesto de los siguientes elementos:
+  - **Clases**:  Reflejan sus atributos y métodos, y la visibilidad de ambos.
+  - **Relaciones**: Reflejan la relación entre las clases/objetos: herencia, composición, agregación, asociación, uso, etc.
+==== 1 - Clases: Atributos, Métodos y Visibilidad ====
+Define las características de un tipo de objeto concreto. Encapsula toda la información de un objeto, y está compuesta de métodos y atributos o campos.
+El UML se representa por una //caja// con 3 secciones:
+{{ :apuntes:uml-clase.png?130|}}
+  * Superior: Nombre de la clase.
+  * Intermedio: Atributos de la clase.
+  * Inferior: Métodos de la clase.
+=== Visibilidad ===
+Se coloca alguno de los siguientes símbolos delante del nombre del miembro de la clase (atributo o método):
+| + | Público |
+| - | Privado |
+| # | Protegido |
+| ~ | Default (Package-private) |
+=== Tipos de miembros ===
+Los miembros de una clase pueden ser: instancias o clasificadores.
+  * Instancias: tienen como ámbito una instancia (objeto) específica.
+  * Clasificadores: (miembros estáticos) son los mismos para todas las instancias de esa clase. No dependen del estado del objeto (instancia). Se representan con su nombre **__subrayado__**.
+{{ :apuntes:uml_class_relation.png?500 |}}
+=== Tipo de clase ===
+Si la clase es una clase abstracta o una interface (clase abstracta pura), se indica sobre el nombre de la clase con comillas:
+{{ :apuntes:interface_uml.png?300 |}}
+==== 2 - Relaciones entre objetos====
+Representa las //conexiones// que hay entre las distintas clases u objetos de un programa. Indican de qué forma una clase usa elementos de otras clases.
+  - Herencia
+  - Asociación
+    - Agregación
+    - Composición
+=== Herencia ===
+Se representa por una línea con una flecha en el extremo de la superclase.
+{{ :apuntes:uml_herencia.png?300|}}
+Indica que una clase puede ser de distintos tipos de clase: varias subclases //extienden// de una superclase.
+{{ :apuntes:uml_herencia.jpg?400 |}}
+=== Asociación ===
+Se representa por una flecha abierta.
+{{ :apuntes:uml_asociacion.png?300|}}
+Representa cualquier tipo de asociación entre dos clases. Por ejemplo, cuando una clase usa métodos de otra clase, o cuando hay un método que recibe tipos de datos de otra clase.
+Además, en cualquier tipo de relación de asociación se puede indicar la cardinalidad de la relación para indicar la cantidad de participación entre las dos clases.
+Hay dos tipos de asociación mas restrictivos que concretan el tipo de relación de asociación entre dos clases: la agregación y la composición. Ambas representan relaciones entre objetos pero se diferencian en su rigidez.
+{{ :apuntes:association_aggregation_composition.jpg?200 |}}
+Para explicar el concepto vamos a plantear el siguiente ejemplo:
+//Una universidad posee varios departamentos, y cada departamento tiene un numero de profesores. Si la universidad cierra, los departamentos dejan de existir para siempre, pero los profesores de esos departamentos seguirán existiendo.
+Una Universidad es una composición de Departamentos, y un Departamento es una agregación de Profesores. Además un Profesor puede trabajar en más de un Departamento, pero un Departamento solo puede pertenecer a una Universidad.//
+=== Agregación ===
+{{ :apuntes:uml_agregacion.png?300|}}
+Se representa por una línea con un rombo. Es un tipo de relación de Asociación, pero más específica.
+Una agregación se da cuando una clase es una colección o un contenedor de otras clases, pero no depende de la existencia de esas otras clases. Si la clase que contiene a la colección desaparecen, no afecta a las clases contenidas.
+En el siguiente ejemplo, la clase Departamento es un contenedor de clases Profesor:
+<code java>
+public class Departamento{
+   private String nombreDepartamento;
+   private ArrayList<Profesor> listadoProfesores;
+   //Los profesores ya existen y recibo un listado por parámetro
+   public Departamento(ArrayList<Profesor> listadoProfesores){
+      this.listadoProfesores = listadoProfesores;
+   }
+}
+</code>
+Los Profesores no desaparecen porque desaparezca el objeto Departamento.
+=== Composición ===
+{{ :apuntes:uml_composicion.png?300|}}
+Se representa por una línea con un rombo negro.
+La composición de clases es una relación aun más estricta que la agregación. Se da cuando una clase contiene referencias a otra clase, pero la vida de las instancias contenidas está ligada a la vida de la instancia contenedora. O sea, si la clase compuesta desaparece también lo harán las clase contenidas.
+<code java>
+public class Universidad{
+   private String nombreUniversidad;
+   private ArrayList<Departamento> listadoDepartamentos;
+   public Universidad(){
+      this.listadoDepartamentos = new ArrayList<>();
+   }
+   public void nuevoDepartamento(String codigo, String nombreDepartamento){
+      Departamento nuevoDepartamento = new Departamento(codigo, nombreDepartamento);
+      listadoDepartamentos.add(nuevoDepartamento);
+   }
+}
+</code>
+Si desaparece el objeto Universidad desaparecen también los departamentos que posee. Además un departamento solo puede pertenecer a una sola Universidad.
+=====Herramientas para diseñar diagramas=====
+Para crear un diagramas de clases y casos de uso nos basta con alguna aplicación que permita crear cajas, elipses, etc. Podemos usar la herramienta [[http://www.yworks.com/products/yed|yEd]].
+Por otra parte, también existen diferentes herramientas para crear diagramas de clases y generar el código posterior. Una de las herramientas más famosas para el modelado UML de clases es [[http://argouml.tigris.org|ArgoUML]]. También hay diversos //plugins// que podemos integrar con eclipse.
+=====Ingeniería inversa=====
+Se conoce con este término el proceso de obtener un modelo a partir del código ya realizado. Este proceso es **inverso** al órden de las etapas a la hora de desarrollar software, ya que primero se realiza el modelado, para posteriormente tener claro qué se debe programar.
+Existen distintas herramientas para obtener el diagrama de clases a partir de un código fuente ya creado. También podemos crear un diagrama de una bbdd a partir del código sql con el que hemos definido la base de datos.
+PhpMyAdmin y MySQL WorkBench permiten realizar ingeniería inversa a partir de una base de datos. Para Java existe la herramienta ArgoUML y también existen diversos pluggins para hacerlo desde Eclipse.
+===== Prácticas =====
+  - Modelado del comportamiento de un programa. Diagrama de casos de uso.
+  - Modelado de la estructura de un programa. Diagramas de clases.
+----
+(c) {{date> %Y}} Fernando Valdeón