DESARROLLO DE SOFTWARE

(1)

MANUAL DE APRENDIZAJE

CÓDIGO: 89001718 Profesional Técnico

INGENIERÍA DE

SOFTWARE II

DESARROLLO

DE SOFTWARE

(2)

(3)

(4)

(5)

I. COMPRENDER Y DEFINIR LOS DIAGRAMAS DE CLASE DE UML.

OPERACIONES:

 Tipos de relaciones: Asociación, Agregación, Composición, Herencia, Dependencia.

 Diagrama de Interacción: objetos, mensajes, retornos, invocaciones.

 Diagrama de transición de Estados.

 Diagrama de Actividades, Diagrama de componentes. Diagrama de deployment (despliegue).

EQUIPOS Y MATERIALES:

 Computadora con microprocesadores Core 2 Duo o mayor capacidad.

 Sistema operativo Windows.

 Acceso a internet.

 Software visual Studio 2012, Block de Notas.

ORDEN DE EJECUCIÓN:

 Reconocer la Estructura de Relaciones en todos sus aspectos.

 Reconocer el Manejo de Diagramas Interacción y de Estados en UML.

 Reconocer el Manejo de Diagramas de Actividades y Componentes.

1.1. TIPOS DE RELACIONES.

UML: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico que permite visualizar, especificar de modo grafico secuencial y documentar cada una de las partes que comprende el desarrollo de un software. UML Este Lenguaje, permite modelar el análisis de manera conceptual, como lo son procesos de negocio y funciones de sistema, además de cosas concretas como podrían ser las clases en un lenguaje determinado, estructuras de bases de datos y componentes del software que interactuaran.

El lenguaje unificado de diagrama o notación (UML) permite especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es precisamente un método de desarrollo, lo que quiere decir que no servirá para determinar qué se deberá hacer como primer lugar o cómo se debe de diseñar el sistema; sino, básicamente permite visualizar el diseño y a hacerlo más accesible para otros. UML está controlado y basado, por el

ESCUELA DE TECNOLOGÍAS DE INFORMACIÓN 7

(6)

grupo de administración de objetos también conocido como OMG, que viene hacer el estándar de descripción de esquemas de software, técnicas que se utilizan para el diseño e implementación de los mismos.

UML, como se puede entender está básicamente diseñado para el uso con software orientado a objetos o también conocido como POO, y la desventaja es que tiene un uso limitado en otro tipo de estructuras de programación.

UML, se compone de muchos elementos de esquematización que van a representar los distintos métodos o partes de un sistema de software. Estos elementos UML se utilizan para poder crear diagramas, que van a representar alguna parte o estructura del sistema.

UML, permite realizar el análisis del software por medio de Diagramas, los cuales se derivan del diseño que se va realizando de manera conceptual. Los diagramas más utilizados y frecuentes son los siguientes:

• Diagrama de casos de uso: Este diagrama, muestra a los actores del sistema u otros usuarios del sistema, los casos de uso representan las situaciones que se producen cuando utilizan el sistema y sus relaciones.

• Diagrama de clases: Este diagrama, muestra las clases y la relaciones entre ellas, las cuales determinaran sus comportamientos y características.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN 8

(7)

• Diagrama de secuencia: Este diagrama, muestra los objetos y las múltiples relaciones entre ellos.

• Diagrama de colaboración: Este diagrama, muestra objetos y sus relaciones, resaltando los objetos que interactúan intercambiando mensajes.

(8)

• Diagrama de estado: Este diagrama, muestra estados, los cambios de estado y los eventos que se realizan en un objeto o en parte de un sistema.

• Diagrama de actividad: Este diagrama, muestra las actividades, así mismo, resalta los cambios de las actividades con los eventos que se suscitan en ciertas partes del sistema.

• Diagrama de componentes: Este diagrama, muestra los componentes que más se utilizan y de mayor nivel en la programación.

(9)

• Diagrama de implementación: Este diagrama, muestra las instancias de los componentes y sus relaciones.

• Diagrama de relaciones de entidad: Este diagrama, muestra los datos y las relaciones y restricciones entre ellos.

(10)

Los diagramas en UML son herramientas prácticas para poder identificar el análisis y diseños de un software a implementarse:

Diagramas de clase:

Los diagramas de clases permiten identificar las diferentes clases que componen y participan en un sistema y que tipo de relaciones tendrán entre ellas. Los diagramas de clases son diagramas estáticos, ya que muestran las clases, junto con sus métodos y atributos, así también permiten visualizar las relaciones estáticas entre ellas; por ejemplo se podría preguntar: qué clases se conocen, a qué otras clases se conocen, o qué clases son parte de otras clases, pero no visualizan los métodos mediante los que se invocan entre ellas.

(11)

Los Diagramas de Clases son de estructura estática que muestran las clases del sistema y sus interrelaciones, este tipo de relaciones pueden ser de herencia, agregación, asociación, etc. Los diagramas de clase son el punto básico del modelado UML, siendo estos utilizados para mostrar lo que el sistema puede hacer, lo que vendría a ser el análisis, y también utilizados para mostrar cómo puede ser construido el sistema, lo que vendría a ser el diseño.

El diagrama de clases de más alto nivel, será lógicamente un dibujo de los paquetes que componen el sistema. Las clases se pueden representar con una descripción de lo que realizan dentro del sistema, indicando sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de propósito, sus objetivos que intervienen en la relación y su opcionalidad.

Un diagrama de clases permite visualizar las relaciones entre las clases que interactúan en el sistema. Un diagrama de clases está compuesto por los siguientes elementos:

• Clase: Que contiene los atributos, métodos y visibilidad.

• Relaciones: Herencia, Composición, Agregación, Asociación y Uso

Clase:

En una clase se define los atributos y los métodos de una serie de objetos.

Todos los objetos de esta clase, conocidas también como instancias de esa clase, tienen el mismo comportamiento y el mismo conjunto de atributos, cabe resaltar que cada objetos tiene el suyo propio. En ocasiones se utiliza el término “Tipo” en lugar de clase, pero se debe de tener en cuenta que no son lo mismo, y que el término tipo tiene un significado más general.

Tipo, es la unidad básica que va a encapsular toda la información de un Objeto.

El Objeto viene a ser una instancia de una clase. A través de la clase se puede modelar el entorno en estudio, por ejemplo: una clase Casa, Auto, Cuenta Corriente, etc. En UML, una clase es representada por un rectángulo que posee tres divisiones:

 Superior: Contiene el nombre de la Clase.

 Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).

(12)

 Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo de Clase:

Atributos:

Existen tipos de atributos, los cuales pueden ser de tres características:

• Tipo Protected: Indica que el atributo no es accesible desde fuera de la clase, pero si podrá ser utilizado por métodos de la clase, así mismo podría utilizarse por las subclases que se deriven.

• Tipo Private: Indica que el atributo sólo es accesible desde dentro de la clase, es decir que sólo sus métodos lo pueden utilizar.

• Tipo Public: Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, que puede ser utilizado y ser accedido desde otros lados.

Métodos:

(13)

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

• Tipo Public: Indica que el método será visible tanto dentro como fuera de la clase, es decir, puede ser accedido desde todos lados.

• Tipo Private: Indica que el método sólo será accesible desde dentro de la clase, es decir, que sólo otros métodos de la clase pueden utilizarlo.

• Tipo Protected: Indica que el método no podrá ser utilizado desde fuera de la clase, pero si podrá ser utilizado por métodos de la clase además de métodos de las subclases que se puedan derivar.

TIPOS DE RELACIONES:

Existen tipos de relaciones en los diagramas de clases de UML, las cuales se utilizaran según su estructura y necesidad de lo diseñado, entre este tipo de relaciones, existen:

- Asociación:

Este tipo de relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Una Asociación es una relación estructural que describe una conexión entre objetos.

(14)

Ejemplo: Utilizar el programa StarUML, para realizar el ejemplo de Diagrama de Clase – Asociación:

• Menú File (Archivo) - New (Nuevo)

• Crear una Nueva Clase: Class

• Generar la Clase “Curso” y agregar los atributos “profesor: Profesor” y

“nombre: String”, se está indicando que la clase curso contiene atributos como un profesor y un nombre del curso

(15)

• Agregar los métodos u operaciones, en este caso se indica que se imprimirá el profesor y se imprimirá el nombre del curso

• Insertar la Clase Profesor, con el atributo Nombre de tipo String y se ingresara el método u operador getNombre de tipo String para el ingreso de un profesor.

• Generar la relación de Asociación entre las clases Curso y Profesor:

(16)

- Agregación:

Es muy similar a la relación de Asociación solo varía en la multiplicidad ya que en lugar de ser una relación "uno a uno" es de "uno a muchos". Se representa con una flecha que parte de una clase a otra en cuya base hay un rombo de color blanco.

- Composición:

Similar a la relación de Agregación solo que la Composición es una relación más fuerte. Aporta documentación conceptual ya que es una "relación de vida", es decir, el tiempo de vida de un objeto está condicionado por el tiempo de vida del objeto que lo incluye. Se representa con una flecha que parte de una clase a otra en cuya base hay un rombo de color negro.

- Herencia:

Este tipo de relación también es conocida como Generalización y Especialización. La herencia entre una superclase y sus subclases. Objetos de ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN 18

(17)

distintas clases pueden tener atributos similares y exhibir comportamientos parecidos. Ejemplo: Seres Humanos, Hombres y Mujeres.

La Relación entre elementos conocidos como Hijo – Padre:

El Hijo, tiene la misma especificación que el Padre, la cual se puede extender;

este tipo de Relación la clase hijo hereda todas las características de la clase padre, así mismo sus comportamientos.

Ejemplo: Una Clase “Figura”, la cual tendrá unas Clase Hijo “Rectángulo”,

“Circulo” y “Polígono”.

- Dependencia:

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana está condicionado a la instanciación proveniente desde el objeto Aplicación).

Cabe destacar que el objeto creado, en este caso la ventana gráfica, no se almacena dentro del objeto que lo crea.

Este tipo de relación es más débil que una asociación, que muestra la relación entre un cliente y el proveedor de un servicio usado por el cliente.

Cliente es el objeto que solicita un servicio.

Servidor es el objeto que provee el servicio solicitado.

(18)

Ejercicio 1: Crear un diagrama de clases y generar el Código para el lenguaje Java. Trabajar en StarUML:

- Archivo (File) – Nuevo (New); Seleccionar el tipo de Archivo a Generar:

- Seleccionar el tipo de diagrama (Clase) tipo de proyecto y modelamiento a generar. Clic a Ok

(19)

- Generar un nuevo paquete de trabajo: Clic derecho al Logical View – Seleccionar Package. Ingresar el Nombre “Ejercicio1”

- Generar las Clases Instituto, Alumno y Profesor; para ello dar clic derecho – Nuevo (New) - Clase (Class). Ingresar de Nombre “Instituto”, “Alumno” y

“Profesor”

(20)

- Se puede observar todas las clases generadas en el visor de componentes:

- Generar un Diagrama de Clases. Clic derecho a Ejercicio1 – Nuevo (New) – Diagrama de Clases (Class Diagram) – Ingresar el Nombre “Diagrama de clases)

- Dar doble clic al Diagrama de Clases para abrir su estructura y arrastrar las Clases en el interior del Diagrama

- Agregar los Atributos a las Clases. Clic derecho a la Clase Instituto – Nuevo Atributo (New Attribute). Una vez ingresado el primer Atributo presionar ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN 22

(21)

Enter para agregar el siguiente Atributo. Clic Izquierdo fuera de la clase para ya no ingresar más atributos. Ingresar los Atributos “IdInstituto”,

“NombreInstituto”

- Agregar los Métodos u Operaciones para las Clases. Clic derecho a la Clase – Nueva Operación (New Operation) – Ingresar el Nombre para la Operación; presionar Enter para agregar otro Operador o clic izquierdo fuera de la clase para ya no ingresar más operaciones. Operaciones

“CrearInstituto”, “ModificarInstituto” y “EliminarInstituto”

- Crear los Atributos y Operadores para todas las Clases del Diagrama:

(22)

- Modificar los Atributos Id de las Clases, por privadas:

- Crear la Relación entre Clases, Seleccionar la Herramienta de Relación de Asociación y arrastrar desde la tabla Alumno hasta la tabla Instituto:

(23)

- Realizar la misma relación entre las clases Profesor e Instituto:

- Seleccionar la Flecha de Relación, para cambiar la cardinalidad e indicar algunos atributos de la Relación creada. En el Panel de la Izquierda, Desactivar la opción Navigable, Seleccionar su Multiplicidad, en este caso de

“1…*” (de Uno a Muchos).

(24)

- Seleccionar la segunda referencia “Alumno”, Seleccionar la Multiplicity “1”.

- La cardinalidad entre la Clase Profesor y la Clase Instituto será igual,

“Instituto” desactivar “Navigable”, Multiplicity “1…n”, y el “Profesor”, seleccionar la Multiplicity “1”. La Relación de las Clases quedaría de la siguiente manera:

- Seleccionar todos los Componentes del Diagrama seleccionando arrastrando con el Clic izquierdo. Menú Tareas (Tools). Seleccionar la Plataforma para la cual se requiere generar el Código, para el Ejercicio, Seleccionar Java y luego Generar Código (Generate Code). Tener en cuenta que se puede seleccionar el tipo de plataforma para lo que se requiere el código. Así mismo, se debe de seleccionar todo lo de la ventana Diagrama de Clases.

(25)

- En la Ventana que se muestra, Seleccionar el Modelo para el Código de las Clases, se puede variar la Carpeta seleccionando el botón Buscar…

- En la Ventana Editar, se puede crear nuevos directorios, donde se guardara el Código Generado para las Clases, Así mismo se pueden Eliminar Carpetas ya creadas anteriormente, Cabe destacar que se debe de crear la Carpeta antes de Realizar la Generación del código, ya que en estas ventanas no permiten crear nuevos directorios físicos.

(26)

- Seleccionar Nuevo para crear el Directorio. Luego seleccionar Carpeta (Directory)

- Seleccionar la Carpeta que se ha creado para Guardar el Código:

- Verificar en la Carpeta donde se ha determinado la Generación de Código.

(27)

- Abrir los Archivos generados de las Clases y verificar el Código.

Código Clase Alumno:

//Source file: C:\\Java\\Ejercicio1\\Alumno.java Package Ejercicio1;

Public class Alumno {

Protected int IdAlumno;

Private int NombreAlumno;

/**

@roseuid 5651FF2502BA */

Public Alumno() {

} /**

@roseuid 5651F1E5026D */

Public void CrearAlumno() {

} /**

@roseuid 5651F1EB01C8 */

Public void ModificarAlumno() {

}

(28)

/**

@roseuid 5651F1F50043 */

Public void EliminarAlumno() {

} }

Código Clase Profesor:

//Source file: C:\\Java\\Ejercicio1\\Profesor.java Package Ejercicio1;

Public class Profesor {

Protected int IdProfesor;

Private int NombreProfesor;

/**

@roseuid 5651FF25030E */

Public Profesor() {

} /**

@roseuid 5651F1FE02D5 */

Public void CrearProfesor() {

} /**

@roseuid 5651F20300EE */

Public void ModificarProfesor() {

(29)

} /**

@roseuid 5651F2090130 */

Public void EliminarProfesor() {

} }

Código Clase Instituto:

//Source file: C:\\Java\\Ejercicio1\\Instituto.java Package Ejercicio1;

Public class Instituto {

protected int IdInstituto;

Private int NombreInstituto;

/**

@roseuid 5651FF250345 */

Public Instituto() {

} /**

@roseuid 5651F0F703AE */

Public void CrearInstituto() {

} /**

@roseuid 5651F0FF01F2

(30)

*/

Public void ModificarInstituto() {

} /**

@roseuid 5651F108013F */

Public void EliminarInstituto() {

} }

Nota: Ejercicio N° 1 del Capítulo 1 del Manual; nombre aplicación: “Ejercicio1”

Ejercicio 2: Se desarrollara un Caso Práctico; Sistema de Gestión de Pedidos:

Se desea implementar un sistema de Gestión de Pedidos, sabiendo que:

• Un Cliente Puede realizar varios Pedidos en un periodo de tiempo (un pedido es realizado por un Solo Cliente)

• Cada pedido está formado por varias líneas de pedido, cada una de las cuales se refiere a un solo producto

• Se diferencian dos tipos de Clientes, el Cliente Personal y el Cliente Corporativo. La diferencia entre los dos tipos de clientes es que el cliente personal pagará mediante una tarjeta de crédito, mientras el cliente corporativo tiene un contrato con la empresa y un límite de crédito

• Además, los vendedores de la empresa se encargan de atender las peticiones de los clientes corporativos, de forma de cada vendedor se hace cargo de una cartelera de clientes corporativos, y a cada cliente corporativo sólo le atiende un vendedor.

Paso1 – Identificar Clases:

- Crear un nuevo Archivo de Modelado.

- File – New – Package “SistemaPedidos”

(31)

- Agregar un nuevo Diagrama de Clases:

- Identificar y Crear las Clases que van a Interactuar en el Sistema de Pedidos:

Paso 2 – Establecer las relaciones entre Clases.

- Determinar algunos Atributos y las Relaciones y sus tipos según la necesidad de comunicación entre las Clases

(32)

- Entre las Clases Cliente, Cliente Personal y Cliente Corporativo existe una relación de Tipo Generalización, Cliente es una Clase General y que se puede particularizar en dos tipos.

- La Clase Sistema de Pago, como Clase General y se puede particularizar en dos tipos Tarjeta de Crédito o mediante un Contrato que se realiza entre el Cliente Corporativo y la Empresa.

- Entre la Clase Cliente y la Clase Pedido existe una Relación de tipo Asociación, de forma que a cada cliente se le pueda asociar los pedidos realizados, indicando que existe una Multiplicidad que un cliente puede tener 1 o más pedidos y que un Pedido solo pertenece a un solo cliente.

- Entre la Clase Pedido y Clase Línea de Pedido existe una relación de Tipo Asociación de tipo Composición, ya que un Pedido está formado por un conjunto de Líneas de Pedido.

- Entre la Clase Línea de Pedido y la Clase Producto existe una Relación de Asociación de tipo Agregación, esto quiere decir que una Línea de Pedido consta de uno o más Productos, pero existe dependencia, si esta relación se rompe, la Clase Productos puede seguir existiendo.

- Existe una Relación de Asociación entre las Clases Cliente Personal con la Clase Tarjeta de Crédito.

- Existe una Relación de Asociación entre las Clases Cliente Corporativo y la Clase Contrato.

- Existe una Relación de Asociación entre las Clases Cliente Corporativo y la Clase Vendedor. Un vendedor tiene una cartera de clientes corporativos por ello la multiplicidad es de 1 a muchos, pero un Cliente Corporativo solo puede tener un solo vendedor.

- Existe una Relación de Dependencia entre las Clases Vendedor y la Clase Sistema Pago, de forma, que cuando se realiza una venta en el sistema, esta tiene asociado un sistema de pago en concreto con lo que se realizara la operación.

(33)

Nota: Ejercicio N° 2 del Capítulo 1 del Manual; nombre aplicación:

“Modelamiento de Clases”

1.2. DIAGRAMA DE INTERACCIÓN.

El Diagrama de Interacción, es el modelo que permite describir a un grupo de objetos que van a colaborar para llegar a un objetivo. Estos objetos van a interactuar entre sí para poder realizar de manera colectiva los servicios que ofrecen las aplicaciones.

En sí, este tipo de diagrama muestra cómo se comunican los objetos en una interacción.

Estos Diagramas, muestran objetos, así como los mensajes que se pasan entre ellos. Básicamente se puede decir que el Diagrama de Interacción captura el Comportamiento de un Caso de Uso

Existen dos tipos de diagramas de Interacción, los cuales son:

• Diagrama de Colaboración.

• Diagrama de Secuencia.

• Diagrama de Colaboración: Este tipo de Diagrama permite representar la interacción entre objetos. Alterna al diagrama de secuencia, a diferencia de estos, el diagrama de colaboración pueden mostrar el contexto de la operación y los ciclos en la ejecución. Estos diagramas se prestan más al descubrimiento de abstracciones, ya que permite representar los objetos en una disposición próxima a la realidad.

Como se ha explicado, un Diagrama de Colaboración se realiza después de haber creado un Diagrama de Casos de Uso.

(34)

Ejercicio 3: Primero se deberá de desarrollar el Diagrama de Casos de Uso, para un sistema de Matriculas. Se utilizara StarUML, para ello realizar los siguientes pasos:

Paso 1: Diagrama de Casos de Uso.

- Crear un Nuevo Diagrama de Casos de Uso.

- Añadir tres Actores, que para este ejercicio será “Alumno”, “Secretaria” y

“Sistema”

- Crear un Caso de Uso “Registrar Matricula”

(35)

- Indicar la participación de los Actores con el caso de uso. Generar una Asociación Directa

Paso 2: Diagrama de Colaboración.

- Clic derecho al Diagrama de Caso de Uso “Registro Matricula”, Nuevo (New) – Diagrama de Colaboración (Collaboration Diagram) - StarUML

“Collaboration”

- Se genera el Diagrama de Colaboración. Ingresar el Nombre “Diagrama de Colaboración – Reg. Matricula” – StarUML “Communication Diagram”

(36)

- Arrastrar los Actores al Diagrama de Colaboración.

- Generar los Objetos de Conexión (Object Link) – StarUML “Connector”.

- Insertar los objetos del Diagrama, para los Mensajes (Link Message) y Conexión de Mensajes de Reserva (Reverse Link Message).

(37)

• Diagrama de Secuencia: Este tipo de Diagrama permite representar la secuencia de manera cronológica de mensajes entre objetos durante un escenario concreto. Cada objeto es representado por una barra horizontal.

La representación de la secuencia se realiza de arriba abajo. Si existiese demora entre la comunicación de un objeto u otro, se representa con una línea oblicua.

La exactitud temporal solo tomara importancia en las aplicaciones que se ejecutan en tiempo real, esto conlleva a que los ejes de tiempo contengan marcas temporales. El orden horizontal que se muestra para los objetos no tiene importancia.

Se puede decir, que un Diagrama de Secuencia va a mostrar a los objetos participantes y los mensajes que cambian entre ellos a los largo del tiempo de la ejecución de la aplicación.

Un objeto o Actor puede enviarse un mensaje así mismo:

(38)

Objeto o Actor

Mensaje

Las Instrucciones Condicionales se podrían representar de la siguiente manera:

Para una Instrucción de interacciones o Repetitivas, se podría representar de la siguiente manera:

Ejercicio 4: Utilizando el ejercicio anterior donde se creó un Diagrama de Casos de Uso para el Registro de Matricula, y se generó el diagrama de Colaboración. Se creara un Diagrama de Secuencia para el “Registro de Matriculas”

(39)

- Clic derecho al Diagrama de Caso de Uso Registro Matricula – Nuevo (New) – Diagrama de Secuencia (Sequence Diagram). Ingresar el nombre

“Diagrama de Secuencia – Reg. Matricula”.

- En el diagrama de secuencia, arrastrar desde los actores del caso de uso hacia el diagrama, quedando de la siguiente manera:

- Seleccionar Mensaje Libre (Message To Self), para empezar el proceso

“Generar Nuevo Registro”, con ello se dará inicio al proceso.

(40)

- Agregar un Mensaje de Secretaria a Alumno “Solicitar Nombres”

- Agregar Mensaje de Alumno a Secretaria “Dictar Nombres”

- Ir Ingresando los Mensajes de interacción en el sistema:

(41)

Nota: Ejercicio N° 3 del Capítulo 1 del Manual; nombre aplicación:

“Modelamiento”. Ejercicio N° 4 del Capítulo 1 del Manual, nombre aplicación:

“Modelamiento - DS”

1.3. DIAGRAMA DE TRANSICIÓN DE ESTADOS:

El Diagrama de Transición, permite observar las transiciones que se producen como consecuencia de los eventos y los procesos que se puedan realizar.

Permiten a su vez describir los comportamientos normales de un sistema.

También permite observar los comportamientos excepcionales de un sistema, estos pueden ser Errores, Excepciones, etc. Se debe de tener en cuenta que muchos de los eventos son provocados por el usuario.

Como conclusión se puede decir que los diagramas de transición de estados es la representación de un conjunto de estados por los que pasa un objeto durante

(42)

su ciclo de vida en respuesta a eventos y acciones; en estos encontraremos qué eventos pueden cambiar el estado o comportamiento de los objetos.

Reconocer los componentes del Diagrama de Transición de Estados:

Transiciones: Vienen a ser las líneas de comunicación, es lo que une un estado con otro, está compuesta por los eventos y las acciones a ejecutar. La representación gráfica es una flecha en línea con la punta abierta.

Estados: Son aquellos que dan lugar a un cambio en el comportamiento del sistema o a un momento significativo en su evolución, por ejemplo un método de una clase.

Diagrama de Estados: Es aquel que influye en el comportamiento y evolución del sistema, los estados siempre han de pertenecer a una clase y representa un resumen de los valores y atributos que puede tener la clase, un Diagrama de Estados, describe el estado interno de un objeto de una clase particular.

Además se puede decir que tiene lugar en un punto del tiempo pero no posee duración respecto a la granularidad temporal del sistema. No todos los cambios en los atributos de un objeto deben de estar representados por estados, solo aquellos en lo que el cambio afecta significativamente su comportamiento.

Tipos de Estado:

Inicio: Es el estado inicial en el que se inicia el objeto en su ciclo de vida, ningún evento puede retornar un objeto a este estado. Gráficamente está representado con un círculo negro.

Fin: Es el estado final en el que queda un objeto al final de su ciclo de vida, ningún evento puede sacar a un objeto de este estado. Gráficamente está representado con un círculo negro rodeado de otro círculo.

Estado: Son los diferentes estados por lo que puede pasar un objeto a lo largo de su ciclo de vida, de ellos se puede salir, quedarse en él y retornar.

Gráficamente está representado por un rectángulo.

Transiciones: Es el momento en donde un objeto pasa de un estado a otro mediante un evento. Se representa mediante una Flecha.

Anulado

(43)

Partes de un Diagrama de Estado:

Estado: Se identifica como un periodo de tiempo del objeto, en el cual dicho objeto se encuentra esperando alguna operación o suceso. Inicia con un estado característico a la espera de estímulos para su desencadenante.

Eventos: Es básicamente una ocurrencia que puede ser causada por la transición de un estado.

Mensajes: Permite representar una acción por medio de mensajes que van de un objeto a otro.

Transición Simple: Viene a ser una relación entre dos estados que permite indicar que un objeto en el primer estado puede ingresar al segundo estado y ejecutar un grupo de operaciones, cuando se suscita el evento.

Transición Interna: En este tipo de transición el objeto permanece en el mismo estado, en vez de trabajar con dos estados distintos. Va a representar un evento que no causara cambios de estados.

Transición compleja: En este tipo de transición interactúan tres o más estados, ya que es una transición de múltiples fuentes o destinos.

SubEstados: Un estado se puede dividir en subestados, que pueden poseer transiciones entre ellos y conexiones a nivel superior; estas conexiones se ven al nivel inferior como estados de inicio o fin.

Acciones: Se puede especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede determinar al ejecutar una acción como resultado de entrar, salir, estar en un estado, o por la ocurrencia de un evento.

Ejercicio 5: Desarrollar un Diagrama de Estado para generar una solicitud de permiso en el Instituto:

- Generar un nuevo Archivo en StarUML. Archivo (File) – Nuevo (New).

Presionar la Tecla Esc (Escape) para no indicar que tipo de Proyecto se va a realizar. No es necesario.

(44)

- Menú Model – Modelo – Diagrama de Estado (Statechart Diagram). Ingresar el Nombre “EstadoSolicitud”

- Doble Clic al Diagrama y Maximizar. Agregar los Estados (State)

“Tramitado”, “Aceptada Solicitud” y “Finalizado”

(45)

- Agregar un Estado de Inicio (Start State), un Estado Final (End State) y los Estados de Transición (State Transition)

- Dar Doble Clic en el Estado de Transición del Estado “Tramitado” y

“Aceptada Solicitud”, para dar la Especificación de la Transición del Estado (State Transition Specification). Ingresar el Evento: “Presentar Solicitud”. Dar Aceptar (Ok)

(46)

- Dar Doble Clic en el Estado de Transición del Estado “Aceptada Solicitud” y

“Finalizado”, para dar la Especificación de la Transición del Estado (State Transition Specification). Ingresar el Evento: “Comprobante de Solicitud”. Dar Aceptar (Ok).

- Se podría complementar con más estados, dependiendo de la necesidad de representación que el análisis requiera, así mismo se podría ingresar las transiciones entre estados indicando como va cambiando cada estado según su comportamiento.

- Finalmente el Diagrama de Estado quedara de la siguiente manera:

Nota: Ejercicio N° 5 del Capítulo 1 del Manual; nombre aplicación: “Diagrama Estado - Solicitud”

(47)

Ejercicio 6: Desarrollar un Diagrama de Estado más complejo para generar una solicitud de permiso en el Instituto:

Presionar la Tecla Esc (Escape) para no indicar que tipo de Proyecto se va a realizar. No es necesario.

- Menú Model – Modelo – Diagrama de Estado (Statechart Diagram). Ingresar el Nombre “Estado Solicitud Compleja”

- Ingresar el Inicio de Estado, el estado de “Pendiente de Aceptación” con la Transición de Estado “Finalizada Solicitud” y una Transición de Retorno para

“Modificar Hoja”

- Ingresar los Estados “No Aceptada” y “Pendiente de Revisión – Secretaria” y los Estados de Transición “Rechazada por Tutor” y “Aprobada por Tutor”. De ser Rechazada la Solicitud, Terminaría el Proceso.

(48)

- Ingresar los Estados “En Realización” y “Aprobada”, Ingresar los Estados de Transición “Revisión de Secretaria” y “Firma y Sello de Aprobación”. Una Transición de Retorno “Verificación de Adjuntos”. Finalmente Ingresar un Estado Final.

Nota: Ejercicio N° 6 del Capítulo 1 del Manual; nombre aplicación: “Diagrama Estado Complejo - Solicitud”

1.4. DIAGRAMA DE ACTIVIDADES, CALLES DEL DIAGRAMA DE COMPONENTES:

(49)

Diagrama de Actividades: Este tipo de diagrama, permite mostrar el flujo de acciones, también conocidos como Nodos de un proceso; respetando una secuencia mostrando así los resultados de las actividades realizadas.

Este diagrama captura las acciones internas que se realizan en un proceso;

captura las especificaciones que genera un diagrama de casos de uso para así mostrar los flujos entre los procesos del negocio.

La representación gráfica que utiliza es similar al diagrama de estados:

• Nodo Inicial: Determina el inicio o punto de partida del flujo de acciones o actividades; se representa por un circulo Negro

• Acción / Actividad: Es la imagen representativa para las actividades o acciones. Esta actividad normalmente utiliza un verbo. Se representa con un rectángulo con las puntas ovaladas.

• Flujo de secuencia / Transición: Es el paso de las ejecuciones entre una actividad u otra. Se representa mediante una Flecha con una punta.

• Decisión o Condicional: Muestra un punto donde se tomara una decisión de acuerdo a las condiciones establecidas; determinara con que actividad se continuara trabajando. Pueden salir más de dos flujos. Su representación gráfica es un Rombo.

• Unión o Merge: Normalmente llegan a él dos flujos de actividades y el proceso continuara con cualquiera de los dos flujos. Se representa por un rombo.

• Sincronización o Concurrencia: También conocido como Bifurcación o Entrada; Indica el inicio de varias actividades que se pueden realizar al ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN 51

(50)

mismo tiempo, de la cual pueden salir varias líneas para las siguientes actividades. Así mismo puede indicar que en este punto terminan varias actividades. Se representa como una línea pronunciada.

• Swinlanes (Calles): Muestra un objeto que puede pasar de una actividad a otra. Se representa como un rectángulo general en el diagrama, con el nombre subrayado dentro de la figura.

• Nodo Final: Representa el final del Flujo de las Actividades, por ende el final del Diagrama. Su representación gráfica es un círculo negro encerrado en otro círculo.

Ejercicio 7: Desarrollar un Diagrama de Actividades para generar el Ingreso de un Password o Acceso a un Sistema:

Presionar la Tecla Esc (Escape) para no indicar que tipo de Proyecto se va a realizar.

- Menú Model – Modelo – Diagrama de Actividades (Activity Diagram).

Ingresar el Nombre “Actividad”

- Insertar el Nodo Inicial, dos actividades “Solicitar Password” y “Permitir Acceso”, ingresar el Nodo Final.

(51)

- Se insertará la condicional para determinar si la contraseña es correcta o no, y las transiciones del flujo de actividades

Nota: Ejercicio N° 7 del Capítulo 1 del Manual; nombre aplicación: “Diagrama Actividades – Ingreso Sistema”

Ejercicio 8: Desarrollar un Diagrama de Actividades para generar el Ingreso de Productos al sistema, basándose en un caso de uso de determinar origen de un producto, se puede determinar que participaran dos actores Director y Coordinador, para los cuales se les aplicara dos calles en simultaneo; cada actor tendrá su esquema de actividades:

Presionar la Tecla Esc (Escape) para no indicar que tipo de Proyecto se va a realizar.

- Menú Model – Modelo – Diagrama de Actividades (Activity Diagram).

Ingresar el Nombre “Actividad de Producto”.

(52)

- Ingresar dos Swimlane (Línea de Tiempo) para el Coordinador y Director:

- Se trabajará inicialmente con el Coordinador; Insertar el Inicio de actividades, e insertar la actividad de Recepción del Producto y relacionarlo.

- Insertar el Objeto “Producto” e indicar el estado que tendrá. Clic derecho al objeto – Open Specification – Ingresar Name – State – New – Name: Recibir – Ok.

(53)

- Relacionar el Objeto con la Actividad con un Object Flow, añadirlo a las notaciones.

- El diagrama quedará de la siguiente manera:

(54)

- Ingresar otro objeto “Producto” pero indicarle un Estado nuevo que será

“Recibido” y asignarle una relación saliente. En el explorador de diagramas, se encuentra el Objeto Producto, por lo cual solo basta arrastrarlo al diagrama (no es necesario crear un nuevo objeto). Con eso se daría terminada la primera fase del diagrama

- En el actor director que es el que determinara el origen del producto, agregar una nueva actividad “Determinar Origen del Producto”. Relacionar el objeto Producto con la actividad.

- Se realizará la consulta si el producto fue una compra o un ingreso por devolución de alguna área. Si no fuera una compra, se ingresara un documento y terminara la actividad. Se ingresara el rombo de la condicional, la actividad de llenado de documento y el final de las actividades.

(55)

- Si la acción es una compra, generar la actividad “Verificar Documento de Compra”, relacionarla con la condicional indicando que si es una compra.

- Crear el objeto “Documento de compra” con el estado “Verificado”.

Relacionar la actividad con el objeto.

(56)

- Agregar una condición para verificar si el documento es correcto o tiene alguna falla, la condición será “Conforme”; si no está conforme, terminaría el Proceso.

- Si el Documento es conforme, ingresar la actividad “Aprobar Documento”.

Insertar el objeto “Documento de Compra”, agregándole un nuevo estado

“Aprobado” y finalizar toda la actividad.

- Se debe tener en cuenta que nunca existe una relación de actividad a actividad, siempre debe de existir un objeto o una condicional.

- Finalmente el diagrama quedaría estructurado de la siguiente manera:

(57)

Nota: Ejercicio N° 8 del Capítulo 1 del Manual; nombre aplicación: “Diagrama Actividades – Verificación de Producto”

Diagrama de Componentes: Este tipo de diagrama UML representa la estructura física del código. Permiten ilustrar los componentes del software que conforman un sistema, tiene un nivel alto de abstracción a diferencia del diagrama de clases. Está compuesto por:

- Componentes: Es la parte física del sistema, que puede representar los módulos, los ejecutables o las bases de datos. Se determina por componente a una o más clases ya que una abstracción que cuenta con atributos y métodos se pueden representar en componentes. Su representación gráfica es un rectángulo en el cual va el nombre acompañado de dos pequeños rectángulos al lado izquierdo.

-

Los Componentes se pueden agrupar en paquetes, así mismo pueden generar entre ellos relaciones de generalización, asociación, agregación y realización.

Se puede encontrar cinco estereotipos de componentes, los cuales son:

• Ejecutable; es aquel componente que se puede ejecutar.

• Library; compuesta por una biblioteca de objetos estáticos o dinámicos.

• Table; este tipo de componente representa una tabla de una base de datos.

• File; este componente es representado por un documento que contendrá los códigos fuentes del software o los datos del mismo.

• Document; este componente se representa mediante un documento.

- Interfaces: Viene a ser la unión entre uno o más componentes

Relaciones y Puntos de Entrada: Las relaciones se pueden realizar de dos maneras, añadiendo una interfaz conectándolo con una flecha; la otra manera es embeberlo en el componente.

(58)

Relaciones de Dependencia de los DC: Se pueden agrupar en paquetes así como los objetos de clases, además pueden tener entre ellos relaciones, tales como:

• Generalización.

• Asociación.

• Agregación.

• Realización.

• Dependencia.

Paquetes o subsistemas.

Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación. Esto básicamente son paquetes estereotipados en Subsistemas.

- Funcionalidad de los Subsistemas:

o Los subsistemas organizan la vista de realización de un sistema.

o Cada subsistema puede contener componentes y otros subsistemas.

o La descomposición en subsistemas no es necesariamente una descomposición funcional.

o La relación entre paquetes y clases en el nivel lógico es el que existe entre subsistemas y componentes en el nivel físico.

o Paquetes o categorías y clases en el nivel lógico.

o Paquetes o subsistemas y componentes en el nivel físico.

Pasos para elaborar un diagrama de componentes:

- Debe estar generado antes el Diagrama de Clases.

- Se debe de identificar todas las clases que participan en el sistema o subsistema que se va a desarrollar.

- Identificar los métodos.

- Los métodos pasaran a ser módulos con líneas de código independientes.

- Los módulos serán los componentes del diagrama.

(59)

II. RECONOCER LAS ARQUITECTURAS DE SOFTWARE.

OPERACIONES:

- Arquitectura del Software.

- Patrones de creación, patrones de estructura y patrones de comportamiento.

- Framework.

EQUIPOS Y MATERIALES:

- Computadora con microprocesadores Core 2 Duo o mayor capacidad.

- Sistema operativo Windows.

- Acceso a internet.

ORDEN DE EJECUCIÓN:

- Reconocer las Arquitecturas de Software.

- Reconocer el Funcionamiento de Patrones de Ingeniería de Software.

- Reconocer el funcionamiento de los Frameworks.

2.1. ARQUITECTURA DEL SOFTWARE.

Reconocer la arquitectura del SW. Estilos arquitectónicos. Patrones de diseño.

Se debe de tener como premisa, que el diseño de un software siempre debe de empezar con el análisis y la estructuración de los datos que participaran en él, ya que es el fundamento principal de todos los demás elementos del diseño.

La arquitectura de un software se puede determinar por etapas:

La primera etapa técnica, consiste en producir un modelo de representación técnica del software que se va a desarrollar. La arquitectura permitirá identificar todos los elementos que van a participar e interactuar, así como las relaciones entre ellos; se podría decir que la arquitectura del software brindara una visión global del sistema.

(60)

Toda arquitectura del sistema, inicia con el diseño de datos, para proceder con las representaciones de la estructura y comportamientos de la información que estarán involucradas en el sistema informático.

Se debe de tener en cuenta que toda la arquitectura de software es diseño, pero no todo el diseño es arquitectura. La arquitectura representa las decisiones del diseño que serán significativas y que le darán forma al sistema a desarrollar. Es la organización de un sistema de acuerdo a sus componentes, los cuales pueden incluir subsistemas y sus múltiples relaciones entre ellos. La arquitectura debe de ser coherente para establecer los patrones de abstracción, así permitirá trabajar a los desarrolladores en una misma línea.

Una arquitectura de software sigue un patrón o un conjunto de patrones que son proporcionados por la lógica del negocio, además debe de contemplar la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas. Se podría decir que la arquitectura de software es una forma de representar los sistemas de información complejos mediante el uso de la abstracción.

Estilos Arquitectónicos:

Vienen a ser una transformación que se impone al diseño de todo el sistema. El objetivo es establecer una estructura para todos los componentes del sistema.

Arquitecturas:

- Centradas en los Datos.

- Flujo de Datos.

- Llamada y Regresión.

- Capas.

- Centradas en los Datos: En este tipo de arquitectura el componente principal es el almacenamiento de datos, el cual será accedido frecuentemente por el resto de componentes que se ejecutan para añadir, modificar y eliminar. Se puede entender que el software que hará de cliente accederá a un almacenamiento de datos vacío. Este tipo de arquitectura proporcionan integridad, es decir que los componentes que ya existen en el

(61)

sistema pueden cambiar o modificarse e inclusive pueden añadirse más componentes sin que afecte ello a otros clientes.

Este tipo de arquitectura también es conocida como Clientes – Servidores.

Cuando se habla de un servidor se asume que este viene a ser una base de datos.

- Flujo de Datos: Este tipo de arquitectura se basa en la acción de la transformación de los datos de entrada en datos de salida, dicha acción se realiza mediante una serie de componentes que manipularon la data. Esto se basa en un patrón de Filtros, que se encuentran conectados por tubos que permiten transmitir los datos de un componente a otro. Cada filtro trabaja de manera independiente de los componentes que estarán antes o después del filtro. El resultado de ello serán los resultados en formatos específicos.

- Llamada y Regresión: Este tipo de arquitectura permite obtener una estructura de programa que es relativamente fácil de modificar y escalar, esta estructura puede contener subestilos.

• Arquitectura de Programa Principal / Subprograma: Esta estructura de programa permite descomponer una función en jerarquías de control por lo que el programa principal hará la invocación a un número de componentes, y a su vez estos invocaran a otros.

(62)

• Arquitectura de llamada de Procedimiento Remoto: Esta estructura determina que los componentes de un programa principal se encuentran distribuidos en una red o en múltiples computadoras.

- Orientada a Objetos: Esta estructura permite los mensajes entre los componentes, ya que estos componentes incluyen datos y operaciones que se deben de ejecutar al ser manipulados. Esta información se encuentra encapsulada.

• En Capas: Esta estructura se puede definir como un conjunto de niveles o capas en cada nivel. Se pueden definir un numero de capas distintas:

o Capa Externa: En esta capa los componentes atenderán a las operaciones de la interfaz del usuario (Diseño).

o Capa Interna: En esta capa los componentes interactúan la interfaz del sistema con el sistema operativo.

o Capa Intermedia: En esta capa se proveen servicios de utilerías y funciones de software de aplicación.

Subprograma Controlador

Programa Principal

Subprograma Controlador

(63)

2.2. PATRONES DE DISEÑO.

Los Patrones son básicamente una solución de tipo arquitectónica que servirá como base para el diseño de la arquitectura del diseño de un software. Se enfrentan a un problema de aplicación específico. Ejemplo, el modelo de requerimientos para cualquier aplicación de comercio electrónico; que ofrece una gran variedad de bienes a un grupo amplio de consumidores y permite que lo puedan comprar on line.

Patrones de Creación: Estos patrones proporcionan la ayuda para crear objetos desde la toma de decisiones, aunque sea de forma dinámica. Permiten estructurar y encapsular estas decisiones. En algunas oportunidades solo existe un patrón adecuado, otra en la que varios patrones podrían ser los adecuados y algunas otras en las que se pueden combinar múltiples patrones.

Existen dos maneras de clasificar los patrones de diseño de software de creación que se basan en las clases de objetos que se crean. Una forma es clasificar las clases que crean los objetos (Factory Method) y la otra forma se trata de la composición de objetos (objeto responsable de conocer las clases de los objetos producto). En este tipo de características, colaboran los patrones Abstract Factory, Builder o Prototype.

Abstract Factory: Si lo que se desea es crear diferentes objetos, todos pertenecientes a la misma familia, como puede ser un sistema de librerías necesarias para crear interfaces gráficas. Se podría decir que lo que intenta solucionar el patrón de diseño software de creación Abstract Factory es crear diferentes familias de objetos.

El patrón Abstract Factory, se recomienda cuando se va a utilizar la inclusión de nuevas familias de productos en un futuro, pero esto podría resultar contraproducente si es que se necesita añadir más productos o modificar los que ya existen, ya que tendría repercusión en todas las familias creadas.

(64)

Componentes:

 Cliente: Es la entidad que hará la llamada para crear uno de los objetos (ProductoA, ProductoB).

 AbstractFactory: Es la interfaz que se va a utilizar en las diferentes factorías.

Se debe ofrecer un método para la obtención de cada objeto que se pueda crear. ("crearProductoA()" y "crearProductoB()").

 Concrete Factories: Aquí se representaran las diferentes familias de productos. Provee la instancia concreta del objeto que se encarga de crear.

 Abstract Product: Se definen las interfaces para la familia de productos genéricos. En el diagrama son "ProductoA" y "ProductoB". El cliente trabajará directamente sobre esta interfaz, que será implementada por los diferentes productos.

 Concrete Product: Aquí se realiza la implementación específica de los diferentes productos.

Diagrama de Clases general con Patrón de Creación Abstract Factory:

Nota: Ejercicio N° 1 del Capítulo 2 del Manual; nombre aplicación: “Código de Java para Abstract Factory”

Factory Method: Este patrón de diseño de software de creación, se basa en utilizar una clase constructora abstracta con unos métodos definidos y otro que sea abstracto. El Factory Method, es el Abstract Factory simplificado. El patrón de diseño de software de creación Factory Method puede ser utilizado cuando:

 La creación de un objeto impide que se vuelva a utilizar sin una importante duplicación de código.

(65)

 La creación de un objeto requiere acceso a la información o recursos que no deberían estar contenidos en la clase de composición.

 La administración de la duración de los objetos generados debe ser centralizada para garantizar un comportamiento coherente en la aplicación.

Los componentes del patrón de creación Factory Method serían:

 Product: Permite definir una interfaz de un objeto que el método Factory creará.

 ConcreteProduct: Permite implementar la interfaz Product para crear un producto en concreto.

 Creator: Permite declarar el método Factory que devolverá un objeto del tipo Product.

 ConcreteCreator: Permite sobrescribir el método Factory del Creator que devolverá una instancia de un producto en concreto (ConcreteProduct).

Este sería el diagrama de clases general de este patrón de creación:

Nota: Ejercicio N° 2 del Capítulo 2 del Manual; nombre aplicación: “Código de Java para Factory Method”.

Prototype:

El patrón Prototype, permite crear el duplicado de un objeto, utiliza el método de la clonación. Utiliza una instancia de ese objeto que ya haya sido creada. El patrón tiene que especificar el tipo de objeto que se requiere clonar, creando así un 'prototipo' de esa instancia. Este tipo o clase de objetos deberá contener en su interfaz el procedimiento que permita solicitar esa copia, siendo desarrollado luego por las clases concretas del patrón que deseen crear ese clon.

Diagrama de clases general del patrón:

(66)

Los actores que intervienen en el patrón de creación Prototype, son:

 Cliente: Es el actor solicitante de la clonación de los nuevos objetos a partir de los prototipos.

 Prototipo Concreto: Es el actor o la clase que presenta unas características concretas que serán podrán se reproducidas en los nuevos objetos y que presenta la implementación necesaria para clonarse.

 Prototipo: Viene a ser la declaración de una interfaz, a la que accede el cliente, y sirve para la clonación de objetos.

Nota: Ejercicio N° 3 del Capítulo 2 del Manual; nombre aplicación: “Código de Java para Prototype”

Singleton: El patrón Singleton, busca restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto. Su intención es garantizar que una clase sólo sea instanciada una vez y, además, proporcionar un único punto de acceso global a la misma. Esto lo consigue gracias a que es la propia clase la responsable de crear esa única instancia, (declarando el constructor de la clase como privado) y a que se permite el acceso global a dicha instancia mediante un método de clase. Para implementar el patrón Singleton hay que crear un método que instancie al objeto sólo si todavía no existe ninguna otra instancia. Para asegurar que no vuelva a ser instanciado, se limita al constructor con atributos protegidos o privados.

Diagrama de clases general del patrón de creación Singleton:

(67)

Nota: Ejercicio N° 4 del Capítulo 2 del Manual; nombre aplicación: “Código de Java para Singleton”.

- Patrones de Estructura: Los patrones de diseño estructurales están enfocados en la gestión de la forma en la que las clases y los objetos se combinan para dar lugar a estructuras más complejas. Al igual que en las otros tipos de patrones, podemos hablar de patrones estructurales asociados a clases (Adapter) y asociados a objetos (Bridge, Composite, Decorator, Facade, Flyweight, Proxy). Los primeros utilizan la herencia mientras que los segundos se basan en la composición.

Adapter:

El patrón Adapter convierte la interfaz de una clase en la que otra necesita, permitiendo que clases con interfaces incompatibles trabajen juntas. Se puede decir que el uso de este patrón estructural está indicado cuando se quiere usar una clase ya implementada y su interfaz no es similar con la necesitada o cuando se desea crear una clase reusable que coopere con clases no relacionadas o que tengan interfaces compatibles. Sin embargo, hay que hacer distinción entre si se quiere adaptar un objeto o una clase o interfaz completa.

Sin embargo, un adaptador de objetos permite que un único Adapter trabaje con muchos Adaptees. De este modo, el Adapter también puede agregar funcionalidad a todos los Adaptees de una sola vez.

Los participantes de este patrón serían los siguientes:

 Client: Es el principal agente en la formación de objetos para la interfaz Target.

 Target: Interfaz del dominio específico que usa el Client.

 Adaptee: Es la interfaz ya existente que necesita adaptarse.

 Adapter: Es quien adapta la interfaz del Adaptee a la interfaz Target.

Este sería el diagrama de clases general del patrón:

(68)

Nota: Ejercicio N° 5 del Capítulo 2 del Manual; nombre aplicación: “Código de Java del Patrón Adapter”

Composite: El patrón Composite sirve para construir objetos que estén formados por tres objetos más simples, pero siempre similares entre sí, gracias a la composición recursiva. Al tener todos estos objetos una misma interfaz, el Composite simplifica el tratamiento de los mismos. El patrón Composite es utilizado en el tratamiento de interfaces de usuario en las que se necesita, representar un conjunto de elementos de una interfaz gráfica. Algunos de estos elementos serán simples, mientras que otros serán más complejos y estarán formados por varios elementos simples. Por tanto, el comportamiento y/o la información que proporciona un elemento complejo están determinada por los elementos que lo componen.

Los Componentes del patrón serían los siguientes:

 Client: Manipula objetos a través de la interfaz proporcionada por Component.

 Component: Declara la interfaz para los objetos de la composición, es la interfaz de acceso y manipulación de los componentes hijo e implementa algunos comportamientos por defecto.

 Composite: Define el comportamiento de los componentes compuestos, almacena a los hijos e implementa las operaciones de manejo de los componentes.

 Leaf: Definen comportamientos para objetos primitivos del compuesto.

Según esto, este sería el diagrama de clases general del patrón:

(69)

Nota: Ejercicio N° 6 del Capítulo 2 del Manual; nombre aplicación: “Código de Java del Patrón Composite”

Decorator: El patrón de diseño estructural Decorator facilita la tarea de añadir dinámicamente funcionalidades a un objeto. De este modo, elimina de necesidad de crear clases que fuesen heredando de la primera, incorporando no sólo la nueva funcionalidad, sino también otras nuevas y asociarlas a ella.

Este ejemplo de patrones estructurales de diseño software es útil cuando:

 Queremos añadir o expandir las funcionalidades de objetos de forma dinámica y transparente.

 Necesitamos que ciertas responsabilidades de un objeto puedan ser retiradas de forma sencilla en un futuro.

 No es posible o no compensa realizar esta expansión de funcionalidades mediante herencia.

 Existe la necesidad de expandir dinámicamente la funcionalidad de un objeto y/o eliminar la funcionalidad extendida.

Visto esto, señalar que los participantes de este patrón serían los siguientes:

 Component: Define la interface de los objetos a los que se le puede adicionar responsabilidades dinámicamente.

 ConcreteComponent: Define el objeto al que se le puede adicionar una responsabilidad.

 Decorator: Mantiene una referencia al objeto Component y define una interface de acuerdo con la interface de Component.

 ConcreteDecorator: Es el encargado de sumar la responsabilidad al componente. Puede haber varios ConcreteDecorator.

Por lo tanto, este sería el diagrama de clases general del patrón:

(70)

Nota: Ejercicio N° 7 del Capítulo 2 del Manual; nombre aplicación: “Código de Java del Patrón Decorator”

Proxy: Esta patrón estructural tiene como propósito proporcionar un intermediario para controlar el acceso a un objeto. Por ello tiene distintas aplicaciones:

 Proxy Remoto: Denominado así cuando representa a un objeto remoto.

 Proxy Virtual: Usado para crear objetos bajo demanda.

 Proxy de Referencia "inteligente": Cuando sirve como sustituto de un puntero que realiza operaciones adicionales cuando accede al objeto.

 Proxy de Protección: Denominado así cuando se usa para controlar el acceso al objeto original.

La finalidad principal del patrón de diseño estructural Proxy, sería proporciona un representante o sustituto de otro objeto para controlar el acceso a éste. Esto lo hace según la motivación de Motivación: retrasar el coste de crear e inicializar un objeto hasta que sea realmente necesario. Por lo tanto, es usado cuando se necesita una referencia a un objeto más flexible o sofisticado que un puntero.

Los componentes en el patrón, serían las siguientes:

 Proxy: Mantiene una referencia al objeto real, mientras que proporciona una interfaz idéntica a la del objeto real (Real Subject) y controla el acceso a este objeto, siendo responsable de crearlo y borrarlo.

 Subject: Define una interfaz común para el proxy y el objeto real.

 RealSubject: Clase del objeto real que el proxy representa.

Según esto, este sería el diagrama de clases general del patrón:

(71)

Nota: Ejercicio N° 8 del Capítulo 2 del Manual; nombre aplicación: “Código de Java del Patrón Proxy”

- Patrones de Comportamiento: Los patrones de diseño software de comportamiento son aquellos que están relacionados con algoritmos y con la asignación de responsabilidades a los objetos. Describen no solamente patrones de objetos o de clases, sino que también engloban patrones de comunicación entre ellos. Al igual que los otros tipos de patrones, se pueden clasificar en función de que trabajen con clases (Template Method, Interpreter) u objetos (Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor).

Command: El patrón de diseño software de comportamiento Command permite realizar una operación sobre un objeto sin conocer realmente las instrucciones de esta operación ni el receptor real de la misma. Esto se consigue encapsulando la petición como si fuera un objeto, además se facilita la parametrización de los métodos. Los Componentes del patrón de comportamiento Command serían:

 Facilitar la parametrización de las acciones a realizar.

 Implementar estructuras de CallBack, especificando qué órdenes queremos que se ejecuten de frente a qué situaciones.

 Independizar los eventos de "petición" y "ejecución".

 Dar un soporte factible a la operación "deshacer".

 Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con primitivas.

Los principales agentes de este patrón son:

 Command: Declara la interface para la ejecución de la operación.