REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA

UNIVERSIDAD POLITÉCNICA TERRITORIAL DE FALCÓN “ALONSO GAMERO”

PROGRAMA NACIONAL DE FORMACIÓN EN INFORMATICA

Trayecto III Trimestre II Sección 01

INGENIERIA DEL SOFTWARE

UNIDAD 8: Diseño de componentes:

Participantes:

Eyner Amaya

Cedula: 27.247.962

Javier Arana
.
Cedula: 13.724.982

INDICE Santa Ana de Coro, Julio del 2023

INTRODUCCION………………………………………………….…...… Pág. 1

8.1.- Principios del Diseño de Componentes Patrones de Diseño

Orientado a Objetos (GOF)…………................................................. Pág. 2

8.2.- Modelado de componentes y despliegues……………………………….

………………...………….….Pág. 6

8.3.- Documentación de los componentes………………………..

………………………………….....Pág. 7

8.4.- Integración de componentes……………………………………… Pág. 9

CONCLUSION……………………………..…………………………….Pág. 11

BIBLIOGRAFIA………………………..…………………………………Pág. 12
 INTRODUCCION

Según Roger S. Pressman, el diseño de componentes implica

identificar las diferentes partes del sistema y definir cómo se comunican
entre sí, especificando las interfaces de los componentes y las
dependencias entre ellos. Este enfoque permite una mayor modularidad y
reutilización de código, facilitando el mantenimiento y la evolución del
sistema. Además, favorece la colaboración entre equipos de desarrollo al
permitirles trabajar en componentes específicos sin afectar a los demás.

El siguiente informe expondrá los puntos clave que se deben tomar en

cuenta durante el diseño de componentes y en qué consisten los patrones
dentro del diseño orientado a objetos. Finalmente se resaltara cómo se da
la integración de los componentes y como es el modelado de los mismos,
su despliegue, implementación y documentación.

1
8.1.- Principios del Diseño de Componentes Patrones de Diseño
Orientado a Objetos (GOF).

Algunos de los principales principios en el diseño de componentes

son:

 Principio de responsabilidad única (SRP): Un componente debe

tener una única responsabilidad o funcionalidad claramente

definida.

 Principio de abierto/cerrado (OCP): Un componente debe estar

abierto para su extensión, pero cerrado para su modificación. Esto

implica que se deben poder agregar nuevas funcionalidades sin

modificar el código existente.

 Principio de sustitución de Liskov (LSP): Los componentes

deben ser reemplazables por instancias de sus subtipos sin alterar

la integridad del sistema.

 Principio de segregación de interfaces (ISP): Los componentes

no deben depender de interfaces que no utilizan. En lugar de eso,

se deben definir interfaces específicas para cada caso de uso.

 Principio de inversión de dependencia (DIP): Los componentes

deben depender de abstracciones en lugar de implementaciones

concretas. Esto permite una mayor flexibilidad y facilita el cambio

de implementaciones sin afectar al sistema.

2
En cuanto a los patrones de diseño orientados a objetos (GOF), estos son
soluciones probadas y documentadas para problemas comunes en el
diseño de software. Fueron propuestos por el grupo conocido como "Gang
of Four" (GoF), compuesto por Erich Gamma, Richard Helm, Ralph
Johnson y John Vlissides., y estos se pueden clasificar de la siguiente
manera:

 Patrones de creación:
o Abstract Factory: Proporciona una interfaz para crear
familias de objetos o que dependen entre sí, sin especificar
sus clases concretas.
o Builder: Separa la construcción de un objeto complejo de su

representación, de forma que el mismo proceso de

construcción pueda crear diferentes representaciones.

o Factory Method: Define una interfaz para crear un objeto,

pero deja que sean las subclases quienes decidan qué clase

instanciar. Permite que una clase delegue en sus subclases

la creación de objetos.

o Prototype: Especifica los tipos de objetos a crear por medio

de una instancia prototípica, y crear nuevos objetos

copiando este prototipo.

o Singleton: Garantiza que una clase sólo tenga una

instancia, y proporciona un punto de acceso global a ella.

3
 Patrones estructurales
o Adapter: Convierte la interfaz de una clase en otra distinta

que es la que esperan los clientes.

o Bridge: Desvincula una abstracción de su implementación,

de manera que ambas puedan variar de forma

independiente.

o Composite: Combina objetos en estructuras de árbol para

representar jerarquías de parte-todo.

o Decorator: Añade dinámicamente nuevas

responsabilidades a un objeto, proporcionando una

alternativa flexible a la herencia para extender la

funcionalidad.

o Facade: Define una interfaz de alto nivel que hace que el

subsistema sea más fácil de usar.

o Flyweight: Usa el compartimiento para permitir un gran

número de objetos de grano fino de forma eficiente.

o Proxy: Proporciona un sustituto o representante de otro

objeto para controlar el acceso a éste.

 Patrones de comportamiento
o Chain of Responsibility: Crea una cadena con los objetos

receptores y pasa las peticiones a través de esta hasta que

esta sea tratada por algún objeto.

4
o Command: Encapsula una petición en un objeto,

permitiendo así marcar parámetros entre los clientes con

distintas peticiones.

o Interpreter: Dado un lenguaje, define una representación de

su gramática junto con un intérprete que usa dicha

representación para interpretar las sentencias del lenguaje.

o Iterator: Proporciona un modo de acceder secuencialmente

a los elementos de un objeto agregado sin exponer su

representación interna.

o Mediator: Se usa un objeto que encapsula la manera de

interactuar de un conjunto de objetos.

o Memento: Representa y externaliza el estado interno de un

objeto sin violar la encapsulación, de forma que éste puede

volver a dicho estado más tarde.

o Observer: Define una dependencia de uno-a-muchos entre

objetos, de forma que cuando un objeto observador cambia

de estado se notifica y actualizan automáticamente todos los

objetos.

o State: Permite que un objeto modifique su comportamiento

cada vez que cambia su estado interno.

o Strategy: Permite que un algoritmo varíe

independientemente de los clientes que lo usan.

o Template Method: Permite que las subclases redefinan

ciertos pasos del algoritmo sin cambiar su estructura.

5
 o Visitor: Permite definir una nueva operación sin cambiar las

clases de los elementos sobre los que opera.

8.2.- Modelado de componentes y despliegues.

Según Geoffrey Sparks “el modelo de componentes ilustra los

componentes de software que se usarán para construir el sistema. Se
pueden construir a partir del modelo de clases y escribir desde cero para
el nuevo sistema o se pueden importar de otros proyectos y de productos
de terceros. Los componentes son agregaciones de alto nivel de las
piezas de software más pequeñas y proveen un enfoque de construcción
de bloques de “caja negra” para la elaboración de software.”

Entendemos entonces que el modelado de componentes se refiere a la

representación visual de los componentes del sistema, sus relaciones y
las interfaces que utilizan para comunicarse entre sí. Esto permite tener
una visión clara y organizada de cómo se compone el sistema y cómo
interactúan sus diferentes partes.

Anexo 1 Ejemplo de descripción de componente en lenguaje UML.

6
Por otro lado, el modelado de despliegues se centra en la representación
de la infraestructura física en la cual se ejecutará el sistema. Esto incluye
servidores, redes, dispositivos y cualquier otro elemento necesario para el
funcionamiento del sistema; Por medio de este modelado es posible
identificar posibles cuellos de botella o puntos de fallo.

Al trasportar este proceso a UML podemos ver:

 Mostrar qué elementos de software se implementan mediante qué

elementos de hardware.

 Ilustrar el procesamiento en tiempo de ejecución para el hardware.

 Proporcionar una vista de la topología del sistema de hardware.

Anexo 2 Ejemplo de diagrama de despliegue en UML.

8.3.- Documentación de los componentes.

Es el proceso de registrar y describir detalladamente cada uno de

los componentes que forman parte del sistema. Esta documentación tiene
como objetivo proporcionar información clara y precisa sobre la

7
estructura, funcionalidad, interfaces y comportamiento de estos,
facilitando así su comprensión y utilización por parte de los
desarrolladores, diseñadores y otros miembros del equipo.

El procedimiento para documentar los componentes en el diseño de

ingeniería de software puede variar dependiendo de la metodología y las

herramientas utilizadas, pero generalmente incluye los siguientes pasos:

 Identificación y clasificación de los componentes: Se clasifican

todos los componentes que forman parte del sistema, teniendo en

cuenta su funcionalidad y relación con otros componentes.

 Descripción de los componentes: Se proporciona una

descripción detallada que incluya su nombre, propósito,

funcionalidades, interfaces, dependencias, restricciones y cualquier

otra información relevante.

 Documentación de las interfaces: Esto incluye describir los

métodos, parámetros y tipos de datos utilizados en cada interfaz y

la manera en que permite la interacción entre los distintos

componentes.

 Diagramas de componentes: Se pueden utilizar diagramas para

representar visualmente la estructura y las relaciones entre los

componentes del sistema.

 Documentación adicional: Además de la descripción y los

diagramas, puede ser necesario incluir documentación adicional

como manuales de uso, guías de instalación, requisitos de

8
 hardware y software, y cualquier otra información relevante para el

uso y mantenimiento de los componentes.

Es importante destacar que la documentación de los componentes

debe mantenerse actualizada a lo largo del ciclo de vida del sistema, ya
que los componentes pueden sufrir modificaciones o actualizaciones a
medida que se desarrolla y evoluciona el software.

8.4.- Integración de componentes.

La integración de componentes consiste en combinar y ensamblar los

diferentes componentes del sistema para formar una solución completa y
funcional. Este proceso implica asegurarse de que los componentes se
conecten correctamente entre sí y que funcionen de manera coherente
para lograr los objetivos del sistema.

La integración de componentes implica los siguientes pasos:

 Identificación de las dependencias entre componentes: Se

deben identificar cómo se relacionan y se comunican entre sí. Esto

implica comprender las interfaces y los protocolos de comunicación

utilizados por cada componente.

 Diseño de las conexiones entre componentes: Se implementan

conexiones que permitan la comunicación y la interacción entre los

componentes; esto puede incluir el diseño de interfaces, la

definición de protocolos de comunicación y la configuración de los

parámetros de conexión.

9
  Pruebas de integración: Se deben realizar pruebas exhaustivas

para verificar que los componentes se integren correctamente y

que funcionen de manera adecuada en conjunto. Esto implica

probar la comunicación entre los componentes, la interoperabilidad

y la funcionalidad del sistema completo.

 Resolución de problemas y ajustes: Es importante identificar y

resolver los problemas que pueden surgir durante el proceso de

integración para asegurar una integración exitosa. Esto puede

implicar ajustes en la configuración, correcciones de errores o

modificaciones en los componentes.

 Documentación de la integración: Es importante documentar

todo el proceso de integración, incluyendo las decisiones tomadas,

los problemas encontrados y las soluciones aplicadas. Esta

documentación es útil para futuras referencias y para facilitar la

comprensión y el mantenimiento del sistema.

En resumen, la integración de componentes en el diseño de componentes

de ingeniería de software implica combinar y ensamblar los diferentes
componentes del sistema de manera coherente y funcional, asegurando
una comunicación adecuada y un funcionamiento correcto del sistema
completo.

10
 CONCLUSION

El diseño de componentes es una parte fundamental en el desarrollo de

software, ya que permite crear sistemas más flexibles, reutilizables y
sostenibles en el tiempo. Los principios del diseño de componentes
establecen pautas y buenas prácticas para garantizar la calidad y
eficiencia de los componentes desarrollados y constituye un proceso
fundamental para crear sistemas. Mediante la aplicación de los principios
y los patrones de diseño, el modelado, la correcta documentación y una
integración adecuada, se puede lograr un diseño de componentes exitoso
que cumpla con los objetivos del sistema y las necesidades del cliente.

11
 BIBLIOGRAFIA

Carlos A. Guerrero, Johanna M. Suárez* y Luz E. Gutiérrez (2013)

“Patrones de Diseño GOF (The Gang of Four) en el contexto de Procesos
de Desarrollo de Aplicaciones Orientadas a la Web”, consultado en
scientific electronic library online en www.Scielo.cl

Roger S. Pressman (2010) "Ingeniería del software: Un enfoque práctico

7ma edición” recuperado en idoc.pub

Geoffrey Sparks Sparx Systems “Una Introducción al UML El Modelo de

Componentes” traducido por Fernando Pinciroli y y Aleksandar Orlic,
recuperado en: www.sparxsystems.com.ar

12