REQUERIMIENTOS DE INGENIERÍA Y ADMINISTRACIÓN

DISEÑO DE SISTEMAS

Luis Moreno

TUTOR:
MOISES DE JESUS RODRIGUEZ BOLAÑO

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

CEAD PALMIRA, VALLE DEL CAUCA
SEPTIEMBRE DE 2018
 CONTENIDO

1. INTRODUCCIÓN........................................................................................................................4

2. OBJETIVOS................................................................................................................................5

3. DESARROLLO...........................................................................................................................6

3.1. Cuando se “escribe” un programa, ¿se diseña software? ¿En qué difieren el
diseño de software y la codificación?.........................................................................................6

3.2. ¿Cómo se evalúa la calidad de diseño de software?...................................................6

3.3. Dé ejemplos de tres abstracciones de datos y de las abstracciones de

procedimiento que se usan para manipularlas.........................................................................7

3.4. Describa con sus propias palabras arquitectura de software......................................9

3.5. Sugiera un patrón de diseño que encuentre en una categoría de objetos

cotidianos (por ejemplo, electrónica de consumo, automóviles, aparatos, etc.). Describa
el patrón en forma breve.............................................................................................................10

3.6. ¿Cuándo debe implementarse un diseño modular como software monolítico?

¿Cómo se logra esto? ¿El rendimiento es la única justificación para la implementación
de software monolítico?..............................................................................................................10

3.7. ¿Cómo relaciona conceptos de acoplamiento y la portabilidad de software? Dar

ejemplos para apoyar su punto de vista..................................................................................11

3.8. Describir brevemente cada uno de los cuatro elementos del modelo de diseño...11

3.9. Con el uso de la arquitectura de una casa o edificio como metáfora, establezca
comparaciones con la arquitectura del software. ¿En qué se parecen las disciplinas de
la arquitectura clásica y la del software? ¿En qué difieren?.................................................12

3.11. Algunos de los estilos arquitectónicos citados en la sección 10 tienen

naturaleza jerárquica, mientras que otros no. Elabore una lista de cada tipo. ¿Cómo se
implementarían los estilos arquitectónicos que no son jerárquicos?..................................19
 3.12. Los términos estilo arquitectónico, patrón arquitectónico se presentan a menudo
en el análisis de la arquitectura de software. Investigar y describir cada uno de ellos y
como se diferencian de los demás............................................................................................23

3.13. Seleccione una aplicación con la que está familiarizado. Responda:..................26

3.14. En ocasiones resulta difícil definir el término componente. Primero dé una

definición general y luego otras más explícitas para el software orientado a objetos y
para el tradicional. Por último, elija tres lenguajes de programación con los que esté
familiarizado e ilustre la manera en la que cada uno define un componente....................28

3.15. ¿Por qué son necesarios los componentes de control en el software tradicional
y por qué en general no se requieren en el orientado a objetos?........................................31

3.16. Investigar los tipos de cohesión y los tipos de acoplamiento................................31

3.17. ¿Qué es un componente de la web App?.................................................................34

3.18. Todos los lenguajes modernos de programación implementan las

construcciones de programación estructurada. Dé ejemplos de tres lenguajes de
programación................................................................................................................................34

3.19. Seleccione un componente codificado pequeño y represéntelo con 1) un

diagrama de actividades, 2) un diagrama de flujo, 3) una tabla de decisión y 4) LDP... .34

3.20. ¿Por qué es importante la "lotificación" en el proceso de revisión del diseño a

nivel de componentes?...............................................................................................................34

4. CONCLUSIONES.....................................................................................................................35

5. REFERENCIAS........................................................................................................................36
 1. INTRODUCCIÓN

Los sistemas informáticos hoy por hoy son una de las bases fundamentales del

desarrollo de las sociedades, pues al cohesionarse a otros aspectos de alto impacto para

un adecuado avance y desarrollo colectivo, como son la educación, la salud, los servicios

públicos, entre otros, se convierten en una herramienta de apoyo que ayudan a simplificar

procesos, mejorar tiempos de respuesta en diferentes aspectos, contribuyen con el control

y mejoramiento continuo en las organizaciones, en otras palabras son unos mecanismos

que aportan a las 3E, esto es: Eficiencia, Efectividad y Eficacia.

Hoy nos estamos formando como profesionales en Ingeniería de Sistemas y el

propósito de este perfil profesional consiste básica y fundamentalmente en la resolución

de situaciones asociadas a la administración de la Información y Comunicación, en

consecuencia, desarrollamos el presente documento en el que nos proponemos, a través

de la respuesta a 20 preguntas generadoras, apropiar conocimiento sobre temáticas

referentes a Diseño y Arquitectura de Software que contribuyan al fortalecimiento de

competencias para el desarrollo de sistemas informáticos basados en software que

cumplan con altos estándares de calidad.

El desarrollo del presente documento se realizó a través de la consulta de material

académico que se relaciona en las referencias, atendiendo además al principio de trabajo

colaborativo, que consistió en la división de grupos de preguntas entre 5 integrantes para

su respuesta, además de aportes significativos a la construcción del presente informe.

 2. OBJETIVOS

Responder a 20 preguntas generadoras que nos permitan apropiar conocimientos y

por tanto fortalecer competencias como profesionales en ingeniería de sistemas para:

2.1. Desarrollar sistemas informáticos basados en software que cumplan con

estándares de calidad.

2.2. Identificar representaciones de un software tomando como características la

resistencia, la funcionalidad y la belleza.

2.3. Detallar aspectos claves asociados a la arquitectura de software, estructuras

de datos, interfaces y componentes que se necesitan para implementar un sistema

informático.
 3. DESARROLLO

3.1. Cuando se “escribe” un programa, ¿se diseña software? ¿En qué

difieren el diseño de software y la codificación?

Cuando estamos escribiendo un programa estamos diseñando un software porque

este permite modelar el sistema o producto que se va a construir, también medir la calidad

y su mejora antes de generar código.

La diferencia entre el diseño de software y la codificación es que el acto de

codificación es escribir un código en cualquier lenguaje basado en su idioma, sintaxis y

alfabeto, para dar instrucciones a la computadora, para que ella realice las actividades de

manera mas rápida y el diseño de software es el análisis de cada una de las

especificaciones solicitadas por un cliente, además ver sus funciones y como se muestran

en pantalla.

3.2. ¿Cómo se evalúa la calidad de diseño de software?

La norma ISO 9126 es un estándar internacional para la evaluación de la calidad del

software que se dividen en 6 características globales.

 Funcionalidad. Las funciones del software son aquellas que buscan satisfacer las

necesidades del usuario.

  Confiabilidad. La capacidad del software de mantener su rendimiento bajo ciertas

condiciones durante cierto período de tiempo.

 Usabilidad. Basada en el esfuerzo necesario para utilizar el software por parte de un

grupo de usuarios.

 Eficiencia. Basada en la relación entre el nivel de rendimiento del software y el

volumen de recursos utilizado, bajo ciertas condiciones.

 Capacidad de mantenimiento. Basada en el esfuerzo necesario para realizar

modificaciones específicas.

 Portabilidad. Basada en la capacidad del software para ser transferido de un entorno a

otro.

3.3. Dé ejemplos de tres abstracciones de datos y de las abstracciones de

procedimiento que se usan para manipularlas.

Una abstracción es una simplificación de algún elemento complejo de un sistema

usado para comunicar significado en una sola frase, es decir, la abstracción consiste en

captar las características esenciales de un objeto, así como su comportamiento. Cuando

se usa la abstracción hoja de cálculo, se supone que se comprende lo que es una hoja de

cálculo, la estructura general de contenido que presenta y las funciones comunes que se

aplican a ella.
 En la práctica de la ingeniería de software, se usan muchos niveles diferentes de

abstracción, cada uno de los cuales imparte o implica significado que debe comunicarse,

por lo tanto, existen diferentes tipos de abstracción, como son: (programación, 2018)

Abstracción procedimental: Es una secuencia dada de instrucciones que tiene una

función específica y limitada.

Abstracción de datos: Es una colección determinada de datos que describen un

objeto de datos.

Abstracción de control: Implica un mecanismo de control del programa sin

especificar detalles internos. Por ejemplo: sincronización de un semáforo para coordinar

actividades de un sistema operativo.

Ejemplos de abstracción:

Caso 1: Imaginemos que queremos aplicar la abstracción a las Aves.

El objeto sería el pájaro, y sus características, por ejemplo, serian: pico, alas, pluma

y patas.

Las funcionalidades asociadas serian: volar, parar, etc.

Caso2: Tenemos automóviles y abstraemos los siguientes datos: marca, modelo,

número de chasis, peso llantas o cauchos, puertas, ventanas.

Las funcionalidades asociadas a su comportamiento serian: acelerar, frenar,

retroceder etc.
 Caso 3: En este caso podemos considerar una Persona como un objeto que tiene

propiedades (como): nombre, altura, peso, color de pelo, color de ojos, etcétera

Sus funcionalidades asociadas a su comportamiento son hablar, mirar, andar, correr,

parar, etc.

3.4. Describa con sus propias palabras arquitectura de software.

Es un conjunto de patrones que proporcionan un marco de referencia necesario para

guiar la construcción de un software, permitiendo a los programadores, analistas y todo el

conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir

todos los objetivos y restricciones de la aplicación

También se puede entender como un diseño o modelo para construir software, es el

diseño de más alto nivel de la estructura de un sistema donde se elabora una planificación

de la estructura y funcionamiento de un software

La arquitectura del software de un programa o sistema de cómputo que comprende

a los componentes del software, sus propiedades externas visibles y las relaciones entre

ellos. Así mismo es la forma en que queremos predecir los comportamientos en las

acciones que deseamos implementar al desarrollar un software. Por lo que se dice que la

arquitectura de Software nos permite analizar la efectividad del diseño para cumplir los

requerimientos establecidos, por esto las razones de importancia de la Arquitectura son

muy relevantes, ya que las representaciones de la arquitectura del software permiten la

comunicación entre todas las partes interesadas en el desarrollo de un sistema, así

mismo resalta las primeras decisiones que tendrán un efecto profundo en todo el trabajo

de ingeniería de software.

3.5. Sugiera un patrón de diseño que encuentre en una categoría de objetos

cotidianos (por ejemplo, electrónica de consumo, automóviles, aparatos, etc.).

Describa el patrón en forma breve.

Un patrón que encontramos dentro de la categoría de objetos es Abstract Factory, el

cual nos provee una interfaz que delega la creación de un conjunto de objetos

relacionados sin necesidad de especificar en ningún momento cuáles son las

implementaciones concretas, igualmente nos permite crear, mediante la interfaz,

conjuntos o familias de objetos también denominados productos. (Patrón Abstract Factory,

19 marzo 2013)

3.6. ¿Cuándo debe implementarse un diseño modular como software

monolítico? ¿Cómo se logra esto? ¿El rendimiento es la única justificación para la

implementación de software monolítico?

Se debe efectuar un diseño modular como software monolítico cuando una

aplicación se diseña para cumplir una sola función, que sea autónoma, independiente de

otras aplicaciones computacionales. Se logra combinando la interfaz de usuario, la

confirmación, lógica de negocio y acceso de datos en un solo programa de una plataforma

única. Como justificación para implementar software monolítico además del beneficio es
que funciona más rápido, es fácil de desarrollar y es eficiente, ya que se producen pocos

cambios en el contexto.

3.7. ¿Cómo relaciona conceptos de acoplamiento y la portabilidad de

software? Dar ejemplos para apoyar su punto de vista.

Para que el software sea portable es decir que el sistema sea fácil de implementar,

cuando pasa de una plataforma a otra; tiene que tener una ensambladura mínimo

aceptable donde la relación entre módulos sea mínima. Ejemplos: un sistema operativo

como Linux que tiene bajo acoplamiento al ser un sistema monolítico por lo que es

portable al poderse instalar en una computadora de cualquier marca. Otro ejemplo es el

navegador de internet Google Chrome, que se puede ejecutar en cualquier dispositivo con

acceso a internet.

3.8. Describir brevemente cada uno de los cuatro elementos del modelo de

diseño.

 Diseño de datos: se encarga de modelar las estructuras de datos que se

necesitan para dar soporte al software. Propiamente se crean las bases de datos y las

relaciones entre las tablas.

 Diseño arquitectónico: tiene su origen en las especificaciones y requerimientos

obtenidos en el análisis, se trata de organizar las funciones que el sistema debe

incorporar para cumplir con los requisitos que se han solicitado, asimismo debe mostrar

las relaciones entre el sistema, los subsistemas y las interacciones con otros sistemas.

 Diseño de interfaces: describe la forma como el sistema interactua con el usuario

más que la apariencia del sistema.

 Diseño a nivel de componente: El diseño a nivel de componente es una

descripción procedimental de cada una de las partes que fueron especificadas en el

diseño arquitectónico.

3.9. Con el uso de la arquitectura de una casa o edificio como metáfora,

establezca comparaciones con la arquitectura del software. ¿En qué se parecen las

disciplinas de la arquitectura clásica y la del software? ¿En qué difieren?

En general cuando se habla de la arquitectura, de una forma o de otra se refiere a

algo en específico muy relacionado: las clasificaciones. El hecho es que no es solo como

una cuestión clasificatoria, sino que cada forma arquitectónica tiene gran relación y se

asocia con herramientas, conceptos, experiencias y problemas a estas clasificaciones se

les ha llamado de varias formas, como: clases de arquitectura, tipos arquitectónicos,

arquetipos recurrentes, especies, paradigmas topológicos, marcos comunes y varias

docenas más. Desde hace más de una década esas cualificaciones arquitectónicas se

vienen denominando: estilos, o alternativamente patrones de arquitectura. Los estilos sólo

se manifiestan en arquitectura teórica descriptiva de alto nivel de abstracción; los

patrones, por todas partes. [CITATION arq04 \n \l 3082 ]

 La gran mayoría coincide en que esta se refiere a la estructura a grandes rasgos del

sistema Por lo que se define Arquitectura de Software como la estructura y organización

de los elementos de software de un Sistema Informático, cómo y bajo qué condiciones y

configuraciones se van a comunicar dichos elementos a la arquitectura en un nivel de

diseño que se utiliza en las dos arquitecturas, la diferencia de cada uno de ellas es la que

se plantea por medio de diseños; Se puede concluir que la Arquitectura de Software es:

una disciplina independiente de cualquier metodología de desarrollo, representa un alto

nivel de abstracción del sistema y responde a los requerimientos no funcionales ya que

estos se satisfacen mediante el modelado y diseño de la aplicación.

3.10. De ejemplos de arquitecturas centradas en datos, arquitecturas de flujo de

datos, arquitecturas orientadas a objetos y arquitecturas en capas

Arquitecturas centradas en datos: Un almacén de datos se encuentra en el centro

de esta arquitectura, otro componente tiene acceso a él y cuentan con la opción de

gestionar los datos de ese almacén. El software cliente tiene acceso a un almacén central,

en algunos casos este es pasivo, el software cliente accede a los datos

independientemente de cualquier cambio hecho en los datos o las acciones de otro

software cliente. Ejemplo:

Software Software
Cliente Cliente

Software Software
Cliente Cliente

Almacenamiento de datos

(repositorios) Software
Software Cliente
 Software Software
Cliente Cliente

Figura.1

Se basa en un patrón tuberías y filtros. Este consta de un conjunto de componentes

denominados “filtros” conectados entre sí por “tuberías” como vemos la figura 10.1, que

transmiten los datos desde un componente al siguiente. Cada filtro trabaja de manera

independiente de los componentes que se encuentren situados antes o después de ella.

Se diseñan de tal modo que esperan que un conjunto de datos en un determinado formato

y obtiene como resultado datos de salida en un formato especifico.

Esta arquitectura se aplica cuando datos de entrada van a transformarse en datos

de salida a través de una serie de componentes computacionales o manipuladores. Un

patrón de tubo y filtro (véase la figura 2) tiene un conjunto de componentes, llamados

filtros, conectados por tubos que transmiten datos de un componente al siguiente. Cada

filtro trabaja en forma independiente de aquellos componentes que se localizan arriba o

abajo del flujo; se diseña para esperar una entrada de datos de cierta forma y produce

datos de salida (al filtro siguiente) en una forma especificada. Sin embargo, el filtro no

requiere ningún conocimiento de los trabajos que realizan los filtros vecinos. Si el flujo de
datos degenera en una sola línea de transformaciones, se denomina lote secuencial. Esta

estructura acepta un lote de datos y luego aplica una serie de componentes secuenciales

(filtros) para transformarlos.

Tipos Abstractos de Datos y OO

Descripción: Las representaciones de los datos y las operaciones están

encapsulados en un tipo abstracto de datos u objeto

Los componentes son objetos, las invocaciones de métodos son los conectores

Restricciones: Los objetos son responsables de la integridad de sus

representaciones. Dicha representación es ocultada al resto de los objetos

Ventajas: Gracias al invariante de ocultación es posible reemplazar la

Implementación sí que afecte a los clientes, también se presentan arquitecturas

orientadas a objetos

Ejemplo:

Proceso

Place orden

Capacidades Aplicación
Entidades
Bus

Clientes Call center

Ordenes
 Productos
Procesos

Capacidades

Aplicación
capacidades
Entidades

aplicación
Entidades

Figura 3

Los componentes de un sistema incluyen datos y las operaciones que deben

aplicarse para manipularlos. La comunicación y coordinación entre los componentes se

consigue mediante la transmisión de mensajes.

Arquitecturas en capas: En la figura 4 se ilustra la estructura básica de una

arquitectura en capas. Se define un número de capas diferentes; cada una ejecuta

operaciones que se aproximan progresivamente al conjunto de instrucciones de máquina.

En la capa externa, los componentes atienden las operaciones de la interfaz de usuario.

En la interna, los componentes realizan la interfaz con el sistema operativo. Las capas

intermedias proveen servicios de utilerías y funciones de software de aplicación. Estos

estilos arquitectónicos tan sólo son un pequeño subconjunto de los que están disponibles.

Una vez que la ingeniería de requerimientos revela las características y restricciones del
sistema que se va a elaborar, se elige el estilo arquitectónico o la combinación de

patrones que se ajusten mejor a esas características y restricciones. En muchos casos,

más de un patrón es apropiado y es posible diseñar y evaluar estilos arquitectónicos

alternativos. Por ejemplo, en muchas aplicaciones de bases de datos se combina un estilo

en capas (apropiado para la mayoría de los sistemas) con una arquitectura centrada en

datos.

Arquitecturas de capas.

Capa núcleo
Componente
s
Capa de utilerías

Placa de aplicación

Placa de interfaz
de usuario

Figura 4

En la figura 4 se ilustra la estructura básica de una arquitectura en capas. Se define

un número de capas diferentes; cada una ejecuta operaciones que se aproximan

progresivamente al conjunto de instrucciones de máquina. En la capa externa, los

componentes atienden las operaciones de la interfaz de usuario. En la interna, los

componentes realizan la interfaz con el sistema operativo. Las capas intermedias proveen

servicios de utilerías y funciones de software de aplicación.

Estos estilos arquitectónicos tan sólo son un pequeño subconjunto de los que están

disponibles.

Una vez que la ingeniería de requerimientos revela las características y restricciones

del sistema que se va a elaborar, se elige el estilo arquitectónico o la combinación de

patrones que se ajusten mejor a esas características y restricciones. En muchos casos,

más de un patrón es apropiado y es posible diseñar y evaluar estilos arquitectónicos

alternativos. Por ejemplo, en muchas aplicaciones de bases de datos se combina un estilo

en capas (apropiado para la mayoría de los sistemas) con una arquitectura centrada en

datos.

Ventajas: Soporta la mejora, los cambios solo afectan a las capas vecinas. Se

pueden cambiar las implementaciones respetando las interfaces con las capas

adyacentes.

Desventajas: no todos los sistemas pueden estructurarse en capas y es difícil

encontrar la separación en capas adecuada

Arquitectura de flujo de datos: Es una arquitectura de computadores que

contrasta directamente con la tradicional Arquitectura de von Neumann o de estructuras

de control.

Arquitecturas orientadas a objetos: Los componentes de un sistema encapsulan

 los datos y las operaciones que se deben realizar para manipular los datos. La

comunicación y la coordinación entre componentes se consiguen a través del paso de

mensaje. La representación de los datos y sus operaciones primitivas asociadas son

encapsuladas en un tipo de dato abstracto u objeto. Por ejemplo, las tareas que

realizamos en AutoCAD o Revit

Arquitecturas de capas: Los servicios son puestos en la red y operan de manera

cooperativa para dar soporte a uno o más procesos de negocios. En este modelo, una

aplicación se convierte en un conjunto de servicios de usuario, negocios y datos que

satisface las necesidades de los procesos de negocios o procesa su soporte. Por ejemplo,

una aplicación web típica está compuesta por una capa de presentación (funcionalidad

relacionada con la interfaz de usuario), una capa de negocios (procesamiento de reglas

de negocios) y una capa de datos (funcionalidad relacionada con el acceso a datos).

3.11. Algunos de los estilos arquitectónicos citados en la sección 10 tienen

naturaleza jerárquica, mientras que otros no. Elabore una lista de cada tipo. ¿Cómo

se implementarían los estilos arquitectónicos que no son jerárquicos?

Arquitectura Centrada en Datos: Un almacén de datos se encuentra en el centro

de esta arquitectura, otro componente tiene acceso a él y cuentan con la opción de

gestionar los datos de ese almacén. El software cliente tiene acceso a un almacén central,

en algunos casos este es pasivo, el software cliente accede a los datos

independientemente de cualquier cambio hecho en los datos o las acciones de otro

software cliente. Una variación de este enfoque transforma el depósito en un pizarrón que

envía notificaciones al software cliente cuando cambian datos de interés para el cliente.

Características: Promueve la capacidad de integración, es decir, que es posible

cambiar componentes existentes y agregar nuevos componentes a la arquitectura sin

preocuparse por otros clientes, además es posible pasar datos entre clientes empleando

el mecanismo del pizarrón. Los componentes clientes ejecutan los procesos de manera

independiente.

Arquitectura de Flujo de Datos: Es una arquitectura de computadores que

contrasta directamente con la tradicional Arquitectura de von Neumann o de estructuras

de control.

Características: Las arquitecturas de flujo de datos no se basan en un contador de

programa (al menos conceptualmente) en tanto en cuanto la posibilidad de ejecución de

las instrucciones solamente viene determinada por la disponibilidad de los argumentos de

entrada de las instrucciones.

Ventajas: La ejecución fuera de orden se ha convertido en

el paradigma computacional por excelencia desde los años 90. Es una forma de flujo de

datos restringido. Este paradigma introdujo la idea de ventana de ejecución, que sigue el

orden secuencial de la arquitectura de von Neumann; sin embargo, dentro de la ventana

se permite que las instrucciones sean completadas en el orden de las dependencias de

datos.
 Desventajas: La complejidad lógica de mantener el rastro de las dependencias de

datos de forma dinámica restringe a los procesadores basados en ejecución fuera de

orden a un reducido número de ejecuciones (de 2 a 6) y limita el tamaño de la ventana de

ejecución de 32 a 200 instrucciones, mucho menor que las utilizadas en las máquinas

puras de flujo de datos.

Arquitectura de Llamada y retorno: Estilo clásico desde los años 1960.

Descomposición jerárquica en subrutinas (componentes) que solucionan una tarea o

función definida. Los datos son pasados como parámetros y el manejador principal

proporciona un ciclo de control sobre las subrutinas. Reflejan la estructura del lenguaje de

programación. Permite al diseñador del software construir una estructura de programa

relativamente fácil de modificar y ajustar a escala. Se basan en la bien conocida

abstracción de procedimientos/funciones/métodos.

Características: Hilo de control simple soportado por los lenguajes de

programación. Usa una estructura implícita de subsistemas. Razonamiento jerárquico,

cambios en una subrutina implican cambios en las subrutinas que hacen la invocación.

Pretenden incrementar el desempeño distribuyendo el trabajo en múltiples procesadores.

Ventajas: Utilizados en grandes sistemas de software. La descomposición en

módulos disminuye la complejidad. Persiguen escalabilidad y modificabilidad.

Desventajas: Dependencia y acoplamiento entre módulos. La reutilización y el

mantenimiento son difíciles

 Arquitectura Orientada a Objetos: Los componentes de un sistema encapsulan los

datos y las operaciones que se deben realizar para manipular los datos. La comunicación

y la coordinación entre componentes se consiguen a través del paso de mensaje. La

representación de los datos y sus operaciones primitivas asociadas son encapsuladas en

un tipo de dato abstracto u objeto.

Características: En este estilo los componentes son los objetos, o instancias de

tipos de datos abstractos. Estos objetos son de un tipo de componente denominado

manager porque es responsable por preservar la integridad de un recurso. Los objetos

interactúan a través de invocaciones a procedimientos y funciones.

Aspectos importantes: Un objeto es responsable de preservar la integridad de su

representación (usualmente manteniendo algún invariante). La representación se oculta a

otros objetos.

Ventajas: Como un objeto oculta su representación a sus clientes, es posible

cambiar su implementación sin modificar los clientes: modificabilidad. La integración de un

conjunto de rutinas de acceso con los datos que manipulan permite a los diseñadores

descomponer los problemas en colecciones de agentes que interactúan.

Desventajas: Para que un objeto interactúe con otro (mediante la invocación a un

procedimiento) debe conocer la identidad del otro objeto. Luego, cuando la identidad de

un objeto cambie es necesario modificar todas las invocaciones a tal objeto. Se pueden

presentar efectos laterales: si los objetos A y C usan al objeto B, entonces los efectos de

C en B lucen como efectos laterales no esperados en A, y viceversa.

 Arquitectura Estratificada: Se crean diferentes capas y cada una realiza

operaciones que progresivamente se aproximan más al cuadro de instrucciones de la

máquina. En la capa externa, los componentes sirven a las operaciones de interfaz de

usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema.

Las capas intermedias proporcionan servicios de utilidad y funciones de software de

aplicaciones.

Características: Organización jerárquica, cada capa proporciona servicios a la

capa superior y actúa como cliente de la capa inferior. Los componentes se organizan en

capas. Los conectores son definidos por los protocolos que determinan cómo interactúan

las capas.

Restricciones topológicas incluyen limitar las interacciones a capas adyacentes.

Aplicabilidad: Grandes sistemas caracterizados por una mezcla de elementos de

alto y bajo nivel, donde los elementos de alto nivel dependen de los de bajo nivel.

3.12. Los términos estilo arquitectónico, patrón arquitectónico se presentan

a menudo en el análisis de la arquitectura de software. Investigar y describir cada

uno de ellos y como se diferencian de los demás.

Estilo arquitectónico: Es un conjunto de componentes que realiza una función

requerida por el sistema, un conjunto de conectores que posibilitan la comunicación, la

coordinación y la cooperación entre los componentes; restricciones que definen como se

puede integrar los componentes que forman el sistema; y modelos semánticos que
permiten al diseñador entender las propiedades globales de un sistema para analizar las

propiedades conocidas de sus partes constituyentes.

Patrón Arquitectónico: Se utilizan para expresar una estructura de organización

base o esquema para un software. Proporcionando un conjunto de subsistemas

predefinidos, especificando sus responsabilidades, reglas, directrices que determinan la

organización, comunicación, interacción y relaciones entre ellos.

La diferencia entre el estilo arquitectónico y el patrón arquitectónico es que el estilo

interactúa con los demás estilos que tiene un sistema para lograr funcionar correctamente

y el patrón se encarga de seguir un protocolo y unas directrices para lograr la

comunicación entre ellos y así lograr mostrar al usuario lo que necesita.

Inteligencia artificial: Sistemas que simulan o incrementan la cognición humana, su

locomoción u otros procesos orgánicos.

Comerciales y no lucrativos: Sistemas que son fundamentales para la operación

de una empresa de negocios.

Comunicaciones: Sistemas que proveen la infraestructura para transferir y manejar

datos, para conectar usuarios de éstos o para presentar datos en la frontera de una

infraestructura.

Contenido de autor: Sistemas que se emplean para crear o manipular artefactos de

texto o multimedios.

Dispositivos: Sistemas que interactúan con el mundo físico a fin de brindar algún
Servicio puntual a un individuo.

Entretenimiento y deportes: Sistemas que administran eventos públicos o que

proveen una experiencia grupal de entretenimiento.

Financieros: Sistemas que proporcionan la infraestructura para transferir y manejar

dinero y otros títulos.

Juegos: Sistemas que dan una experiencia de entretenimiento a individuos o

grupos.

Gobierno: Sistemas que dan apoyo a la conducción y operaciones de una

institución política local, estatal, federal, global o de otro tipo.

Industrial: Sistemas que simulan o controlan procesos físicos.

Legal: Sistemas que dan apoyo a la industria jurídica.

Médicos: Sistemas que diagnostican, curan o contribuyen a la investigación médica.

Militares: Sistemas de consulta, comunicaciones, comando, control e inteligencia

así como de armas ofensivas y defensivas.

Sistemas operativos: Sistemas que están inmediatamente instalados en el

hardware para dar servicios de software básico.

Plataformas: Sistemas que se encuentran en los sistemas operativos para brindar

servicios avanzados.

Científicos: Sistemas que se emplean para hacer investigación científica y aplicada.

Herramientas: Sistemas que se utilizan para desarrollar otros sistemas.

Transporte: Sistemas que controlan vehículos acuáticos, terrestres, aéreos o

espaciales.
 Utilidades: Sistemas que interactúan con otro software para brindar algún servicio

específico. Desde el punto de vista

3.13. Seleccione una aplicación con la que está familiarizado. Responda:

Control. ¿Cómo se administra el control dentro de la arquitectura? ¿Existe una

jerarquía diferente al de control?

Para responder esta pregunta, se hace uso o referencia al Sistema Integrado de

Registros Públicos SII que manejan una gran parte de Cámaras de Comercio del País

para llevar la información de los registros públicos como: registro mercantil, registro de

proponentes y registro de entidades sin ánimo de lucro.

Este sistema usa una Arquitectura centrada en los datos y es de tipo cliente servidor,

por lo tanto consta de una base de datos centralizada y una aplicación web que permite a

los diferentes usuarios interactuar con estos datos.

La base de datos cuenta con una interfaz que define cómo las aplicaciones de

usuario deben interactuar con dichos datos, a su vez la aplicación web implementa varios

módulos con funciones muy bien definidas, por ejemplo:

Parametrización
 Radicación y recaudo

Generación de informes y estadísticas

Auditoría y control

Además de los módulos mencionados, existen muchos otros módulos, sólo se

mencionan los más relevantes. Es importante mencionar que cada uno de estos módulos

está dividido en otros módulos que cumplen funciones más específicas, por ejemplo, el

módulos de parametrización contiene otros módulos que permiten a los usuarios

administradores de la aplicación poder gestionar los usuarios, sus perfiles y roles, también

cuenta con módulos de parametrización de conceptos registrales, flujo de trámites y sus

costos, aspectos que por ley estas entidades deben permitir realizar a quienes están

interesados en registrar alguna empresa, entre otros módulos más específicos. De esta

forma, es que la aplicación está estructurada y es la única jerarquía de control que

contempla.

Datos. ¿Cómo se comunican los datos entre los componentes? ¿El flujo de datos es

continuo o los objetos de datos pasan al sistema en forma esporádica?

Los datos están centralizados en una base de datos, por lo tanto cada módulo

accede a estos datos, a través de estos módulos el usuario realiza acciones sobre dichos

datos que de manera posterior se verán reflejados en otros módulos al ser accedidos por

estos, así que en la medida en que se van realizando acciones sobre los datos estos van

siendo registrados en el sistema.

 3.14. En ocasiones resulta difícil definir el término componente. Primero dé

una definición general y luego otras más explícitas para el software orientado a

objetos y para el tradicional. Por último, elija tres lenguajes de programación con

los que esté familiarizado e ilustre la manera en la que cada uno define un

componente.

Un componente es un bloque de construcción de software de cómputo.

Con más formalidad, la Especificación OMG del Lenguaje de Modelado

Unificado [OMG03a] define un componente como “una parte modular,

desplegable y sustituible de un sistema, que incluye la implantación y

expone un conjunto de interfaces”. Los componentes forman la arquitectura

del software y, en consecuencia, juegan un papel en el logro de los objetivos

y de los requerimientos del sistema que se va a construir. Como los

componentes se encuentran en la arquitectura del software, deben

comunicarse y colaborar con otros componentes y con entidades (otros

sistemas, dispositivos, personas, etc.) que existen fuera de las fronteras del

software. (Pressman, s.f.).

Orientación a objetos: en el contexto de la ingeniería de software orientada a

objetos, un componente contiene un conjunto de clases que colaboran. Cada clase dentro

de un componente se elabora por completo para que incluya todos los atributos y

operaciones relevantes para su implantación. Como parte de la elaboración del diseño,

también deben definirse todas las interfaces que permiten que las clases se comuniquen y
colaboren con otras clases de diseño. Para lograr esto, se comienza con el modelo de

requerimientos y se elaboran clases de análisis (para los componentes que se relacionan

con el dominio del problema) y clases de infraestructura (para los componentes que dan

servicios de apoyo para el dominio del problema). (Pressman, s.f.).

Tradicional: En el contexto de la ingeniería de software tradicional, un componente

es un elemento funcional de un programa que incorpora la lógica del procesamiento, las

estructuras de datos internas que se requieren para implantar la lógica del procesamiento

y una interfaz que permite la invocación del componente y el paso de los datos. Dentro de

la arquitectura del software se encuentra un componente tradicional, también llamado

módulo, que tiene tres funciones importantes: 1) como componente de control que

coordina la invocación de todos los demás componentes del dominio del problema, 2)

como componente del dominio del problema que implanta una función completa o parcial

que requiere el cliente y 3) como componente de infraestructura que es responsable de

las funciones que dan apoyo al procesamiento requerido en el dominio del problema.

(Pressman, s.f.).

Ejemplo de implementación de componentes en diferentes lenguajes de

programación:

C#

//Importación de librerías requeridas para una aplicación básica

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

//Espacio de trabajo
namespace EspacioTrabajo
{
//Definición de Clase
public class NombreClase
{
//Definición de propiedades
Public String variable

//Definición de métodos
Public nombreMetodo()
{
//Acciones del método
}
}

PHP
//Definición de clase
class NombreClase {
// Declaración de propiedades
public $variable;

// Declaración de un método
public function nombreMetodo(){
//Acciones del método
}
}

JAVA
//Definición de clase
class NombreClase {
// Declaración de propiedades
public variable;

// Declaración de un método
public function nombreMetodo(){
//Acciones del método
}
}
 3.15. ¿Por qué son necesarios los componentes de control en el software

tradicional y por qué en general no se requieren en el orientado a objetos?

Los componentes de control coordinan la invocación de otros componentes que son

de tipo funcional o que dan respuesta al dominio del problema, esto es porque en el

software tradicional se presenta una alta segregación respecto de las funcionalidades del

software lo que conlleva a que necesariamente existan unos componentes intermediarios

que controlen o permitan una adecuada comunicación, mientras en el software orientado

a objetos son los mismos componentes, que en sus propias clases, contemplan los

aspectos necesarios para la colaboración con las clases de otros componentes.

3.16. Investigar los tipos de cohesión y los tipos de acoplamiento.

La Cohesión implica que un componente o clase sólo contiene atributos y

operaciones que se relacionan de cerca uno con el otro y con la clase o componente en

sí. Lethbridge y Laganiére [Let01] definen varios tipos diferentes de cohesión. (Pressman,

s.f.).

Cohesión Funcional: lo tienen sobre todo las operaciones; este nivel de cohesión

ocurre cuando un componente realiza un cálculo y luego devuelve el resultado.

(Pressman).
 Cohesión de Capa: lo tienen los paquetes, componentes y clases; este tipo de

cohesión ocurre cuando una capa más alta accede a los servicios de otra más baja, pero

ésta no tiene acceso a las superiores. (Pressman, s.f.).

Cohesión de Comunicación: Todas las operaciones que acceden a los mismos

datos se definen dentro de una clase. En general, tales clases se centran únicamente en

los datos en cuestión, acceden a ellos y los guardan. (Pressman, s.f.).

El Acoplamiento es la medición cualitativa del grado en el que las clases se

conectan una con otra. Conforme las clases (y componentes) se hacen más

interdependientes, el acoplamiento crece. Un objetivo importante del diseño en el nivel de

componente es mantener el acoplamiento tan bajo como sea posible. (Pressman, s.f.).

Acoplamiento de Contenido: Tiene lugar cuando un componente “modifica

subrepticiamente datos internos en otro componente” [Let01]. Esto viola el ocultamiento

de la información, concepto básico del diseño. (Pressman, s.f.).

Acoplamiento Común. Sucede cuando cierto número de componentes hacen uso

de una variable global. Aunque a veces esto es necesario (por ejemplo, para establecer

valores definidos que se utilizan en toda la aplicación), el acoplamiento común lleva a la

propagación incontrolada del error y a efectos colaterales imprevistos cuando se hacen

los cambios. (Pressman, s.f.).

Acoplamiento del Control: tiene lugar si la operación A() invoca a la operación B()

y pasa una bandera de control a B. La bandera “dirige” entonces el flujo de la lógica

dentro de B. El problema con esta forma de acoplamiento es que un cambio no

relacionado en B puede dar como resultado la necesidad de cambiar el significado de la

bandera de control que pasa A. Si esto se pasa por alto ocurrirá un error. (Pressman, s.f.).

Acoplamiento de Molde: se presenta cuando se declara a ClaseB como un tipo

para un argumento de una operación de ClaseA. Como ClaseB ahora forma parte de la

definición de ClaseA, la modificación del sistema se vuelve más compleja. (Pressman,

s.f.).

Acoplamiento de Datos: ocurre si las operaciones pasan cadenas largas de

argumentos de datos. El “ancho de banda” de la comunicación entre clases y

componentes crece y la complejidad de la interfaz se incrementa. Se hace más difícil

hacer pruebas y dar mantenimiento. (Pressman, s.f.).

Acoplamiento de Rutina de Llamada: tiene lugar cuando una operación invoca a

otra. Este nivel de acoplamiento es común y con frecuencia muy necesario. Sin embargo,

aumenta la conectividad del sistema. (Pressman, s.f.).

Acoplamiento de Tipo de Uso: ocurre si el componente A usa un tipo de datos

definidos en el componente B (esto ocurre siempre que “una clase declara una variable de

instancia o una variable local como si tuviera otra clase para su tipo” [Let01]). Si cambia la

definición de tipo, también debe cambiar todo componente que la utilice. (Pressman, s.f.).

Acoplamiento de Inclusión o Importación: pasa cuando el componente A importa

o incluye un paquete o el contenido del componente B. (Pressman, s.f.).

Acoplamiento Externo: sucede si un componente se comunica o colabora con

componentes de infraestructura (por ejemplo, funciones del sistema operativo, capacidad

de la base de datos, funciones de telecomunicación, etc.). Aunque este tipo de

acoplamiento es necesario, debe limitarse a un número pequeño de componentes o

clases dentro de un sistema. (Pressman, s.f.).

3.17. ¿Qué es un componente de la web App?

3.18. Todos los lenguajes modernos de programación implementan las

construcciones de programación estructurada. Dé ejemplos de tres lenguajes de

programación.

3.19. Seleccione un componente codificado pequeño y represéntelo con 1)

un diagrama de actividades, 2) un diagrama de flujo, 3) una tabla de decisión y 4)

LDP.

3.20. ¿Por qué es importante la "lotificación" en el proceso de revisión del

diseño a nivel de componentes?

4. CONCLUSIONES
 5. REFERENCIAS

Sols Rodriguez – Candela, A. (2014). Systems engineering: theory and practice. Pontifical

Comillas University Recuperado de:

http://bibliotecavirtual.unad.edu.co:2077/lib/unadsp/reader.action?

ppg=136&docID=11002046&tm=1499805437434

UNAD (2017). Requirements Engineering and management. [Video file]. Recuperado de:

http://hdl.handle.net/10596/12732

Gilb, T., & Brodie, L. (2005). Competitive Engineering: A Handbook For Systems Engineering,

Requirements Engineering, and Software Engineering Using Planguage. Oxford:

Butterworth-Heinemann. Recuperado de: http://bibliotecavirtual.unad.edu.co:2048/login?

url=http://search.ebscohost.com/login.aspx?

direct=true&db=nlebk&AN=166420&lang=es&site=ehost-live&ebv=EB&ppid=pp_35

Saltzer, J. H., & Kaashoek, F. (2009). Principles of Computer System Design: An Introduction.

Burlington, MA: Morgan Kaufmann. Recuperado de:

http://bibliotecavirtual.unad.edu.co:2139/eds/ebookviewer/ebook/bmxlYmtfXzMxOTY1M19f

QU41?sid=6ab8cd0e-1d96-44bb-a88d-

9e2295ac0ea7@sessionmgr104&vid=1&format=EB&rid=3

Pressman, R. (s.f.). Ingeniería del software, un enfoque práctico. 7ed. McGrawHill. Recuperado

de: http://cotana.informatica.edu.bo/downloads/ld-

Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF